京喜首页（微信购物入口）跨端开发与优化实践

　　京喜首页（微信购物入口）跨端开发与优化实践

　　背景介绍—

　　随着今年的双十一落下帷幕，京喜（原京东拼购）也迎来了首捷。双十一前夕微信购物一级入口切换为京喜小程序，项目顺利通过近亿级的流量考验，在此与大家分享一点自己参与的工作。

　　在接手项目前，京喜业务已在线上稳定运行较长时间。但经过一段时间迭代维护后，发现首页存在以下问题：

　　H5 版本首页针对不同渠道开发了多套页面，对开发者维护和内容运营来说存在较大挑战，需投入大量人力成本；项目技术栈不统一，分别有传统 H5 开发、原生小程序开发、wqVue 框架开发，严重影响项目复杂度，迭代过程苦不堪言；H5、小程序以及 RN 三端存在各自构建和发布流程，涉及较多工具及复杂系统流程，影响业务交付效率。

　　综上所述，京喜迎来一次改版契机。

　　改版目标—

　　从前端角度来看，本次改版要实现以下目标：

　　技术选型—

　　京喜业务拥有非常丰富的产品形态，涵盖了 H5、微信小程序以及独立 APP 三种不同的端，对支持多端的开发框架有着天然的需求。

　　

　　京喜丰富的产品形态

　　在技术选型上，我们选择团队自研的 Taro[1] 多端统一开发解决方案。

　　Taro 是一套遵循 React 语法规范的多端开发解决方案。

　　现如今市面上端的形态多种多样，Web、React-Native、微信小程序等各种端大行其道，当业务要求同时在不同的端都有所实现的时候，针对不同的端去编写多套代码的成本显然非常高，这时候只编写一套代码就能够适配到多端的能力就显得极为需要。

　　使用 Taro，我们可以只书写一套代码，再通过 Taro 的编译工具，将源代码分别编译出可以在不同端（微信/百度/支付宝/字节跳动/小程序、快应用、H5、React-Native 等）运行的代码。

　　选它有两个原因，一来是 Taro 已经成熟，内部和外部都有大量实践，内部有京东 7FRESH、京东到家等，外部有淘票票、粤省事等多个案例，可以放心投入到业务开发；二来团队成员都拥有使用 Taro 来开发内部组件库的经验，对业务快速完成有保障。

　　

　　组件库开发实录—

　　由于首页改版的开发排期并不充裕，因此充分地复用已有基础能力（比如像请求、上报、跳转等必不可少的公共类库），能大量减少我们重复的工作量。话虽如此，但在三端统一开发过程中，我们仍遇到不少问题，同时也带来解决方案，以下我们一一阐述。

　　H5 篇

　　我们所有的页面都依赖现有业务的全局公共头尾及搜索栏等组件，这就不可避免的需要将 Taro 开发流程融入到现有开发和发布流程中去。同时公共组件都是通过 SSI[2] 的方式引入和维护的，为了能在运行 npm run dev:h5 时预览到完整的页面效果，需要对 index.html 模版中的 SSI 语法进行解析，index.html 模版文件代码结构大致如下：

　　<br /><br /><br /> <br /> <br /> 京喜<br /> <br /><br /><br /> <br /> <br /> <br /> <br /> <br /> <br /> <br /><br /><br />

　　可以看到模版中存在很多类似 格式的代码，这些就是通过 SSI 方式引入的 H5 公共组件，它的 virtual 属性指向的文件不存在于本地而是存在于服务器上的，所以我们遇到的第一个问题就是在本地解析这些文件，确保能预览到完整的页面效果，不然开发调试起来就非常的低效。好在 Taro 有暴露出 webpack 的配置，我们可以通过引入自定义加载器（这里就叫 ssi-loader）来解析这些代码的路径，然后请求服务器上的文件内容并进行替换即可，要实现这个功能只需在项目的 config/dev.js 中加入如下代码即可：

　　module.exports = {<br /> h5: {<br /> webpackChain(chain, webpack) {<br /> chain.merge({<br /> module: {<br /> rule: {<br /> ssiLoader: {<br /> test: /\.html/,<br /> use: [<br /> {<br /> loader: 'html-loader'<br /> },<br /> {<br /> loader: 'ssi-loader',<br /> options: {<br /> locations: {<br /> include: 'https://wqs.jd.com'<br /> }<br /> }<br /> }<br /> ]<br /> }<br /> }<br /> }<br /> })<br /> }<br /> }<br />}<br />

　　这样就解决了本地开发调试难点，然后开开心心的进行页面开发。

　　当页面开发完成之后，接下来遇到的问题就是如何将前端资源部署到测试和生产环境。由于现有开发和发布流程都是基于内部已有的平台，我们临时定制一套也不太现实，所以需要将它融入到 Taro 的流程中去，这里我们引入了 gulp 来整合各种构建和发布等操作，只要构建出符合发布平台规范的目录即可利用它的静态资源构建、版本控制及服务器发布等能力，这样我们就打通了整个开发和发布流程。

　　这套拼凑起来的流程还存在不少的问题，对于新接手的同学有一点小繁琐，有着不少改善的空间，这也是接下来的重点工作方向。另外 Taro 的 H5 端之前是基于 SPA 模式，对于有着多页开发需求的项目来说不太友好，当时反馈给 Taro 团队负责 H5 的同学，很快得到了响应，目前 Taro 已支持 H5 多页开发模式，支持非常迅速。

　　小程序篇

　　由于开发完 H5 版之后，对应的业务逻辑就已经处理完了，接下来只需要处理小程序下的一些特殊逻辑（比如分享、前端测速上报等）即可，差异比较大的就是开发和发布流程。

　　这里讲一下如何在一个原生小程序项目中使用 Taro 进行开发，因为我们的 Taro 项目跟已有的原生小程序项目是独立的两个项目，所以需要将 Taro 项目的小程序代码编译到已有的原生小程序项目目录下，第一步要做的就是调整 Taro 配置 config/index.js，指定编译输出目录以及禁用 app 文件输出防止覆盖已有文件。

　　const config = {<br /> // 自定义输出根目录<br /> outputRoot: process.argv[3] === 'weapp' ? '../.temp' : 'dist',<br /> // 不输出 app.js 和 app.json 文件<br /> weapp: {<br /> appOutput: false<br /> }<br />}<br />

　　由于京喜以前是主购小程序的一个栏目，后面独立成了独立的小程序，但是核心购物流程还是复用的主购小程序，所以这让情况变得更加复杂。这里还是通过 gulp 来进行繁琐的目录文件处理，比如我们的小程序页面和组件都需要继承主购小程序的 JDPage 和 JDComponent 基类，所以在进行文件复制之前需要进行代码替换，代码如下：

　　// WEAPP<br />const basePath = `../.temp`<br />const destPaths = [`${basePath}/pages/index/`, `${basePath}/pages/components/`]<br />const destFiles = destPaths.map(item => `${item}**/*.js`)<br /><br />/*<br /> * 基类替换<br /> */<br />function replaceBaseComponent (files) {<br /> return (<br /> gulp<br /> .src(files || destFiles, { base: basePath })<br /> .pipe(<br /> replace(<br /> /\b(Page|Component)(\(require\(['"](.*? "'"")\/npm\/)(.*)(createComponent.*)/,<br /> function(match, p1, p2, p3, p4, p5) {<br /> const type =<br /> (p5 || '').indexOf('true') != -1 ||<br /> (p5 || '').indexOf('!0') != -1<br /> ? 'Page'<br /> : 'Component'<br /> if (type == 'Page') p5 = p5.replace('))', '), true)') // 新：page.js基类要多传一个参数<br /> const reservedParts = p2 + p4 + p5<br /> // const type = p1<br /> // const reservedParts = p2<br /> const rootPath = p3<br /><br /> const clsName = type == 'Page' ? 'JDPage' : 'JDComponent'<br /> const baseFile = type == 'Page' ? 'page.taro.js' : 'component.js'<br /><br /> console.log(<br /> ` Replace with \`${clsName}\` successfully: ${this.file.path.replace(<br /> /.*?wxapp\//,<br /> 'wxapp/'<br /> )}`<br /> )<br /> return `new (require("${rootPath}/bases/${baseFile}").${clsName})${reservedParts}`<br /> }<br /> )<br /> )<br /> .pipe(gulp.dest(basePath))<br /> )<br />}<br /><br />// 基类替换<br />gulp.task('replace-base-component', () => replaceBaseComponent())<br />

　　还有很多类似这样的骚操作，虽然比较麻烦，但是只需要处理一次，后续也很少改动。

　　RN 篇

　　对于 RN 开发，也是第一次将它落地到实际的业务项目中，所以大部分时候都是伴随着各种未知的坑不断前行，所以这里也友情提示一下，对于从未使用过的技术，还是需要一些耐心的，遇到问题勤查勤问。

　　由于京喜 APP 是复用京东技术中台的基础框架和 JDReact 引擎，所以整个的开发和部署都是遵循 JDReact 已有的流程，画了一张大致的流程图如下：

　　

　　京喜开发发布流程

　　JDReact 平台是在 Facebook ReactNative 开源框架基础上，进行了深度二次开发和功能扩展。不仅打通了 Android/iOS/Web 三端平台，而且对京东移动端基础业务能力进行了 SDK 级别的封装，提供了统一、易于开发的 API。业务开发者可以通过 JDReact SDK 平台进行快速京东业务开发，并且不依赖发版就能无缝集成到客户端(android/iOS)或者转换成 Web 页面进行线上部署，真正实现了一次开发，快速部署三端。

　　由于京喜 APP 的 JDReact 模块都是独立的 git 仓库，所以需要调整我们 Taro 项目配置 config/index.js 的编译输出路径如下：

　　rn: {<br /> outPath: '../jdreact-jsbundle-jdreactpingouindex'<br />}<br />

　　这样，当我们运行 yarn run dev:rn 进行本地开发时，文件自动编译到了 JDReact 项目，接下来我们就可以用模拟器或者真机来进行预览调试了。当我们在进行本地开发调试的时候，最高效的方式还是推荐用 Taro 官方提供的 `taro-native-shell`[3] 原生 React Native 壳子来启动我们的项目，详细的配置参照该项目的 README 进行配置即可。

　　由于 React Native 官方提供的 Remote Debugger[4] 功能非常弱，推荐使用 React Native Debugger[5] 来进行本地 RN 调试，提供了更为丰富的功能，基本接近 H5 和小程序的调试体验。

　　

　　React Native Debugger 界面

　　这样我们就拥有了一个正常的开发调试环境，接下来就可以进行高效的开发了，由于我们前面在 H5 和小程序版本阶段已经完成了绝大部分的业务逻辑开发，所以针对 RN 版本的主要工作集中在 iOS 和安卓不同机型的样式和交互适配上。

　　在样式适配这块，不得不提下 Taro 针对我们常见的场景提供了一些最佳实践，可以作为布局参考：

　　Taro RN 最佳实践集锦

　　在实际开发过程中也遇到不少兼容性问题，这里整理出来以供大家参考：

　　跨平台开发JS 文件1、文件拆分的方式

　　要"完美"的编译出三端代码，首先要解决的是公共类库的适配问题，好在兄弟业务团队已经沉淀有完成度较高的三端公共类库，利用 Taro 提供的跨平台开发能力，抹平三端方法名和参数不统一的情况，即可很好的解决公共类库的适配问题，如下所示：

　　.<br />├── goto.h5.js<br />├── goto.rn.js<br />├── goto.weapp.js<br />├── request.h5.js<br />├── request.rn.js<br />├── request.weapp.js<br />└── ...<br />

　　以 request 公共组件为例，三端代码如下：

　　request.h5.js

　　import request from '@legos/request'<br />export { request }<br />

　　request.rn.js

　　import request from '@wqvue/jdreact-request'<br />export { request }<br />

　　request.weapp.js（由于小程序的公共组件没有发布至 npm，这里引用的本地项目源文件）

　　import { request } from '../../../common/request/request.js'<br />export { request }<br />

　　如遇到需要适配的方法参数不一致或者增加额外处理的情况，可进行再包装确保最终输出的接口一致，如下：

　　goto.rn.js

　　import jump from '@wqvue/jdreact-jump'<br /><br />function goto(url, params = {}, options = {}) {<br /> jump(url, options.des || 'm', options.source || 'JDPingou', params)<br />}<br /><br />export default goto<br />

　　文件引入的时候我们正常使用就好，Taro 在编译的时候为我们编译对应的平台的文件

　　import goto from './goto.js'<br />

　　2、条件编译的方式

　　解决了公共类库适配之后，接下来就可以专注于业务代码开发了，同样业务代码在三端也可能存差异的情况，可以用 Taro 提供的环境变量来达到目的，示例代码如下：

　　if (process.env.TARO_ENV === 'h5') {<br /> this.speedReport(8) // [测速上报] 首屏渲染完成<br />} else if (process.env.TARO_ENV === 'weapp') {<br /> speed.mark(6).report() // [测速上报] 首屏渲染完成<br />} else if (process.env.TARO_ENV === 'rn') {<br /> speed.mark(7).report() // [测速上报] 首屏渲染完成<br />}<br />

　　CSS 文件

　　以上是 js 的代码处理方式，对于 css 文件及代码，同样也有类似的处理。

　　1、文件拆分的方式

　　比如 RN 相对于 H5 和小程序的样式就存在比较大的差异，RN 支持的样式是 CSS 的子集，所以很多看起来很常见的样式是不支持的，可以通过以下方式进行差异化处理：

　　├── index.base.scss<br />├── index.rn.scss<br />├── index.scss<br />

　　这里以 index.base.scss 作为三端都能兼容的公共样式（名字可以任取，不一定为 xxx.base.scss），index.rn.scss 则为 RN 端独特的样式，index.scss 则为 H5 和小程序独特的样式，因为 H5 和小程序样式基本上没有什么差异，这里合为一个文件处理。

　　2、条件编译的方式

　　Taro 也支持样式文件内的条件编译，语法如下：

　　/* #ifdef %PLATFORM% */<br />// 指定平台保留<br />/* #endif */<br /><br />/* #ifndef %PLATFORM% */<br />// 指定平台剔除<br />/* #endif */<br />

　　%PLATFORM% 的取值请参考 Taro 内置环境变量[6]

　　以下为示例代码：

　　.selector {<br /> color: #fff;<br /> /* #ifndef RN */<br /> box-shadow: 1px 1px 1px rgba(0, 0, 0, .1);<br /> /* #endif */<br />}<br />

　　编译为 H5 和小程序的样式为：

　　.selector {<br /> color: #fff;<br /> box-shadow: 1px 1px 1px rgba(0, 0, 0, .1);<br />}<br />

　　RN 的样式为：

　　.selector {<br /> color: #fff;<br />}<br />

　　两种方式选其一即可，这样就能开开心心的编写业务代码了。

　　有些许遗憾的是产品经理对这次新版首页有着明确的上线优先级：先 H5 版，再微信小程序版，最后是 RN 版，这就为后续 RN 版本跟 H5 和 小程序版本分道扬镳埋下了伏笔，条件允许的话建议优先以 RN 版本为基准进行开发，以免开发完成 H5 和小程序之后发现对结构和样式进行大的调整，因为 RN 对样式确实会弱一些。

　　性能优化图片优化

　　电商性质的网站，会存在大量的素材或商品图片， 往往这些会对页面造成较大的性能影响。得益于京东图床服务，提供强大的图片定制功能，让我们在图片优化方面省去大量工作。以引入商品图片 "!q70.dpg.webp" 为样本，我们对图片应用做了部分优化：

　　为 Image 标签设置 lazyload 属性，这样可以在 H5 和小程序下获得懒加载功能。

　　接口聚合直出

　　起初京喜首页的首屏数据涉及的后端接口多达 20 余个，导致整体数据返回时间较长；为了解决此项痛点，我们联合后端团队，独立开发首屏专用的聚合直出接口。一方面，将众多接口请求合并成一个，减少接口联动请求带来的性能损耗；另一方面，将复杂的业务逻辑挪到后端处理，前端只负责视图渲染和交互即可，减少前端代码复杂度；通过此项优化，页面性能和体验得到极大改善。

　　缓存优先策略

　　由于京喜业务主要围绕下沉市场，其用户群体的网络环境会更加复杂，要保障页面的性能，减少网络延时是一项重要措施。

　　为了提升用户二次访问的加载性能，我们决定采用缓存优先策略。即用户每次访问页面时所请求的主接口数据写入本地缓存，同时用户每次访问都优先加载缓存数据，形成一套规范的数据读取机制。通过优先读取本地缓存数据，可让页面内容在极短时间内完成渲染；另外，本地缓存数据亦可作为页面兜底数据，在用户网络超时或故障时使用，可避免页面空窗的情景出现。

　　

　　缓存优先策略高性能瀑布流长列表

　　首页紧接着首屏区域的是一个支持下滑加载的瀑布流长列表，每次滑到底部都会异步拉取 20 条数据，总计会拉取将近 500 条数据，这在 iOS 下交互体验还比较正常。但是在配置较低的安卓机型下，当滑动到 2 到 3 屏之后就开始出现严重卡顿，甚至会闪退。

　　针对这种场景也尝试过用 FlatList 和 SectionList 组件来优化，但是它们都要求规则等高的列表条目，于是不得不自己来实现不规则的瀑布流无限滚动加载。其核心思路是通过判断列表的条目是否在视窗内来决定图片是否渲染，要优化得更彻底些的话，甚至可以移除条目内所有内容只保留容器，以达到减少内容节点以及内存占用，不过在快速进行滑动时比较容易出现一片白框，算是为了性能损失一些体验，整体上来说是可以接受的。

　　由于 RN 下在获取元素坐标偏移等数据相对 H5 和小程序要麻烦得到，具体的实现细节可以查看抽离出来的简单实现Taro 高性能瀑布流组件（for RN）[7]。

　　写在最后—

　　三端达到像素级别的还原

　　这篇文章从技术选型、开发实录再到性能优化三个维度对京喜首页改版做了简单总结。整个项目实践下来，再一次证实 Taro 开发框架已完全具备投入大型商业项目的条件。虽在多端开发适配上耗费了一些时间，但仍比各端独立开发维护工作量要少；在前端资源匮乏的今天，选择成熟的开发工具来控制成本、提升效率，已是各团队的首要工作目标。同时，京喜作为京东战略级业务，拥有千万级别的流量入口，我们对页面的体验优化和性能改进远不止于此，希望每一次微小的改动能为用户带来愉悦的感受，始终为用户提供优质的产品体验。

　　参考资料[1]

　　Taro:

　　[2]

　　SSI:

　　[3]

　　Taro-native-shell:

　　[4]

　　Remote Debugger: #chrome-developer-tools

　　[5]

　　React Native Debugger:

　　[6]

　　Taro 内置环境变量:

　　[7]

　　Taro 高性能瀑布流组件（for RN）: