介绍2021年，618成功上线，平台下单金额再创新高，达到3056亿。作为大促线的主要前端承接团队，今年负责了16个场馆的开发。本文将从场馆创新功能、技术架构、协作方式三个方面揭秘，如何在短时间内开展多场馆、高需求的2021年618大促，化解秃头危机。不一样的6181.Taro3应用：连接H5和小程序近年来，小程序凭借其在用户触达和用户留存方面的优势，越来越受到关注。团队也接触到了需要用小程序（不是H5形式）??开发的场地，而Taro的优势就是用同一套代码封装多端程序，满足了我们对小程序的需求发展。考虑到未来的业务渠道，我们在2021年Q1完成了会场Taro3技术栈的落地，在这个过程中遇到了两个白屏问题：低版本安卓浏览器白屏和主浏览器白屏购买小程序。Android低版本浏览器出现白屏现象，一般是由于低版本浏览器对高级语法的兼容性不够所致。不断精简页面后，发现一个普通的空白项目也会出现白屏。最后确定问题在WebComponents的使用上。由于目前大会的主要渠道是H5的形式，经过与Taro开发团队的反馈和讨论，对于H5的应用，将WebComponents实现的基础组件替换为React组件；小程序中没有进行任何修改。Dom节点如下图所示：最新版本的Taro已经同步了该功能，用户无需特殊处理。一套项目代码，解决H5页面开发和小程序开发，节省双倍开发量。京东购物小程序对H5链接hash路由的特殊处理导致白屏Taro3在打包H5时添加了默认hash路由，在BabelTower（事件发布平台）发布事件时无法使用历史路由。程序在WebView处理链接的时候会加入一些参数和hash参数，会造成小程序中H5页面路径混乱。解决方案有3种：给小程序开白名单，修改H5的链接地址，添加“omitH5Params”，更改Taro3的路由设置。由于推广的场地多达16个，所以需要针对每个场地和渠道统计方案1和方案2。链接是有风险的。因此，经过与太郎开发组的讨论，最终实现方案三的效果，增加路由配置钩子，为H5设置单独的路由，通过babel默认链接访问小程序中的会场。降低开发和运维成本。最终项目关键配置如下：router:{forcePath:'/',customRoutes:{[`/pages/${process.env.TASK_DIR_NAME}/index`]:'/'}}2.容灾服务：用户体验保证推广会场上线时长1个月左右，访问量上亿PV，对页面安全性要求非常高。对于数据异常，前端的处理方式有两种：请求异常时跳转到简单的Babel网页监控请求，请求异常时使用内置的数据包。考虑到用户体验，两种方案各有优缺点。方案一的优点是可以展示实时的产品和广告组信息。缺点是页面结构与预期不同，缺乏交互引导。方案二的优点是和正常的页面结构一致。缺点是数据固定，不能及时跟进运营策略调整。为此，我们设计了容灾的整体流程：今年我们采用了新版的容灾服务，兼顾了方案一和方案二，客户端（各会场）配置监控接口（通常是第一屏数据拉取接口），以及备份数据的间隔时间（一般为1小时），服务器将去个性化数据的请求备份到OSS服务器，达到如下效果：无页面跳转，确保用户体验符合预期；跟随运行策略动态更新，底层数据每1小时备份一次（可配置）。在618专场和高潮期，我们统计了灾备业务的曝光情况，如下图（数据敏感暂不提供具体数值）：3.SmartUI：有效提升转化率与精细化运营战略的深入，以及智能化应用的普及，场馆内的商品BI已经不能满足用户的需求。今年又增加了“智能UI”的概念。根据用户设计画像的构建，相同的产品信息/场地入口，通过前端呈现不同的设计风格。如图所示对于前端，需求可以简化为：在页面加载时，通过请求后端接口下发的用户设计画像来确定商品/店铺的UI风格。功能实现作为一个典型的SPA项目，页面在加载完index.html和主脚本后，会开始请求页面数据并通过js渲染，如下图所示：为了防止页面被二次渲染，我们可以请求页面数据同时并行请求智能UI界面，如下图：实现效果以主会场底部的Feed和店铺入口为例。率和转化率得到有效验证。4、下拉刷新：另一种刷新方式是在京东购物APP首页。可以通过下拉操作触发页面刷新。甚至在一些特殊的日子（比如618大促），下拉也能触发xView显示会场入口，可见用户已经养成了下拉操作的习惯。但是在会场中，如果需要更新页面数据（比如闪购商品），只能返回父页面重新打开。由于大促会场是通过WebView呈现的，618在与负责团队沟通后，在2021年首次在会场推出了“下拉刷新”功能。功能实现首先我们需要设置WebView通过导航栏统一配置协议支持下拉刷新，并设置下拉刷新启动时调用的函数名。最后，我们只需要在回调函数中编写我们的页面刷新逻辑即可。成就效果5、VR转盘：酷Z世代尊重个性，拒绝随波逐流，对新鲜事物有强烈的好奇心和尝试心理。大牌烘干厂呈现从运营策略、设计风格到动态效果都进行了相应的调整。VR转盘就是一个典型案例。先来看一张视觉设计对比图。可以看出大家对实现精度的要求还是挺高的：功能实现轮盘的处理主要考虑三个部分：初始化，轮转中，停止轮转。初始化：处理圆形绘制（每张卡片高度设置，居中，旋转角度），设置每个状态的初始值，包括圆心坐标，触摸起点坐标，之前的角度旋转、旋转状态和锁定。旋转：触摸时：记录当前轮盘角度和起始坐标，解除锁定滑动过程：判断是否水平滑动，设置状态，计算滑动角度和当前项目索引，处理轮盘动画。停止旋转时：判断当前操作是否足够旋转（以1/2卡角为准），释放锁，设置旋转状态，触发轮盘的回调。变现效果总结2021年618有很多新颖的交互形式（如全渠道AB页、Z世代词条选择等），点击量和转化率比往年推广更高的模块（如如：百亿购物黄金系列、营业部楼层优化等）。可以参考设计系同学整理的战报。精彩交互展示：开发秘笈1、加入京东以来，技术框架经历了最初的gulp+ejs，然后是Webpack+Vue/React，再到现在的Taro3。我们迭代的最终目标是：更极致的性能，更快的开发效率，更低的维护成本，稳定的复用和迭代，首先通过底层基础配置和EUI组件库的支持，然后将常用的工具库封装在中间层，配合不同业务模块的组合，最终完成场馆的开发工作；而这一系列分工组合的基础，离不开良好的团队规范的执行；除了完成工作的前端工作，团队还会思考未来的技术方向（智能化）和更好的用户体验（容灾）。具体如下图所示：2.高效的协作方式开发周期短、工作量大的项目难免会遇到团队协作的场景。目前我们经常处理三种情况：多人协作同一个页面，比如大牌晒厂和多人协作场景页面同一个场地不同时段的页面，比如多路复用主会场四期不同场馆的相同组件，如大促会场百亿购物的融合。因此，高效的协作方式、合理的分支机构、科学的版本迭代就显得尤为重要。代码分支规范在开发项目时，代码分支管理是基于产品需求的。原则上，一个分支对应一个需求。在项目的开发周期中有一个开发分支dev，所有的特性分支都是基于开发分支dev创建的，并以feature-xxx的形式命名。功能模块开发完成后，功能分支会合并到开发分支dev中。如果分支dev在合并某个功能分支后出现问题，我们也可以快速回滚到合并分支之前的节点，甚至检查Problem分支，保证开发分支的可靠性和可维护性。公共模块公共模块的维护一直是开发中的一个关键问题。公共模块可以分为以下两类：技术层面的公共模块对于技术层面的公共模块，如请求库、组件库、工具类等，可以集成在脚手架中，以形式引入项目初始化时的npm。对于同一项目不同阶段的公共代码，如预加载模块、容错组件、底部导航等，通常可以创建一个文件夹，如common，用于存放。业务层面的公共模块对于业务层面的公共模块，可能会随着开发周期不断积累，所以不能提前在脚手架中集成工具等模块。比如在今年的618活动中，不少场馆都加入了红包雨、倒计时等功能。这些功能在不同场地的表现是相似的，所以可以共享同一套代码。在不同项目中引入公共代码，一般有npm、gitsubmodule、gitsubtree等方式。它们各有优缺点。比如npm更侧重于包的依赖管理，但是它无法实现双向同步，也就是说需要专人维护这个包。如果我在当前项目中开发了一个组件，这个组件在其他项目中也有可能被使用，但是我无法将其提升到npm包中，需要相应的人来做。又如gitsubmodule，其特点是允许在一个项目仓库中嵌入另一个子仓库，但嵌入的子仓库是基于某个commitID的。如果其他开发者在操作子仓库时没有遵循相应的规范，那么原子仓库的commitID如果发生变化，可能会影响到所有引入该子仓库的项目。公共模块管理方式比较优缺点npm引入简单，可在多个项目中使用，不能双向同步，需要专门维护和合约交付gitsubmodule作为子仓库导入，目录清晰基础关于commitID，commitID的变化可能会导致子仓库改变gitsubtree子仓库引入，目录清晰。子仓库的更新和推送指令相对复杂。Git子树相对来说更符合我们的需求。它允许我们像gitsubmodule一样在当前项目中引入子项目。这个子项目就像其他普通目录一样直观。如果有增加新的公共模块或修改功能模块等变更，只需要像维护其他仓库一样维护子项目对应的仓库，然后返回当前项目同步子项目的代码即可。项目版本迭代由于618活动时间较长，同一个活动项目可能会分为预热期、专场期、高潮期等不同阶段。每个时期都有相应的变化，如新楼层、新功能等。如果把预热期的功能送到高潮期，或者把高潮期的配置做成特殊时期，可能会出现灾难性的问题。一般来说，不同阶段的代码都可以通过分支进行管理，但这需要开发者有很强的分支管理能力，及时同步代码更新。即便如此，从错误的分支发布项目仍然会导致严重的事故。为了避免上述情况，我们采取了以下措施：不同的阶段对应不同的入口文件，在阶段命名目录中存放不同的阶段特定功能/楼层，不同的阶段配置不同的发布指令。以京东金榜事件为例。时期分为特殊时期和高潮时期。我们在项目中使用s1和s2目录分别对应特殊时期和高潮时期的入口：其中高潮时期的签到楼层和赛车楼层与特殊时期不同，所以这两个floor放在s2文件目录下：然后配置stage对应的activity信息：执行命令yarndeploy--name=diststage=1和yarndeploy--name=diststage=2区分打包部署相应阶段的操作。使用上述方法可以保证每个阶段都对应指定的入口文件和指定的运行命令，尽可能避免迭代错误。小结场馆开发大促是指在短时间内开发、上线大量场馆。同时大促上线时间长，运营策略肯定会动态调整。停留和成本。因此，适合快速迭代、高效开发、高效协作方式的技术框架是支撑我们使命的基础。结束语每年的618活动对我们来说都是一个巨大的挑战。高效的开发模式、优雅的协作方式、可靠的容灾解决方案是我们一直追求的目标。精良的技术。我们相信只有充足的技术储备才能为京东618保驾护航，成为京东618连续创佳绩的基石。以上就是我们研发团队对于618事件的开发方式和详细考虑。希望我们可以互相学习，共同成长。
