【 1.1 京东LBS门详业务介绍 】

【 1.2 面临的挑战 】

该部分首先重点介绍一下总结果概览，然后详细阐述一下页面启动和交互结果。

【 2.1 结果概览 】

当我们识别到上述的四类问题之后，进行了整体的问题的分析，识别出的需要高优优化的环节分别是：启动耗时、交互体验、能耗优化以及埋点；整体优化完成上线后，我们验证的结果如下：

① 门详加载速度整体提升了约50%；

同一网络环境下，同款机型优化前后的数据对比如下：

【 2.2 启动结果 】



② 同5G环境，同门店，机型是iphone14pro，优化后和原生做个对比：左侧是京东到家app原生；右侧是优化后的京东门详小程序。

【 2.3 交互结果 】

左侧是京东到家原生app，右侧是门详的效果。



下图是小程序的启动过程：

【 3.1 小程序信息接口异步化功能 】

问题：启动小程序会同步获取小程序信息接口，小程序打开过程存在耗时。

目标：减少小程序信息接口请求耗时。

行动：

1.通过将小程序信息同步接口信息提前缓存；

结果：接口改为并行后，平均数据减少158ms左右。

【 3.2 小程序按需加载功能 】

1.编译改造：将渲染层、逻辑层注入内容只保留业务公共框架的部分，页面的JS代码剥离到对应页面中；

2.启动改造：启动时只注入公共框架与当前页面相关的代码，减少注入额外内容；

3.改变包大小【具体操作可见3.3部分门详包瘦身】

结果：优化前：6MB+ 数据，优化后：注入2.7MB数据， 使用小米11手机测试启动性能，未使用按需加载功能的启动时间为：1200ms左右，使用按需加载功能的启动时间是：800ms左右，性能显著提升。

【 3.3  门详包瘦身 】

【 3.4 应用启动耗时减少：（首屏渲染 、 接口预请求）】

问题：由于我们是基于LBS的门详业务，首页接口请求完成后，才能进行页面的整体渲染，所以首页主接口请求的耗时时长也成为我们loading时间长的原因之一；另外接口和地址获取串行的逻辑也加长了整体的数据链路；

一般来说小程序首屏的可交互时间都会受代码包注入执行时间影响，在代码执行完毕后才能开始业务网络请求，请求数据返回后才能开始真正的内容渲染，为了解决这一痛点，京东小程序Clips是一种通过三线程架构实现的特色能力，可以在小程序启动过程中注入一个轻量化代码片段，提前做初始化数据，网络请求等非UI功能，当小程序主环境准备好后，可直接将数据送给逻辑层，实现小程序业务预热能力。

2、Recoil的颗粒度可以根据独立的业务模块设定，减少频繁无效的设置值，对象变更提前做好数据比对；

3、组件只需要改变状态，不需要依赖状态时：推荐写法：const setName = useSetRecoilState(nameAtom);

【 3.5 整体启动过程对比示意图 】



以下是美团外卖、京东到家app门详和门详小程序的滑动效果对比分析：

通过分析得出以下3个关键交互体验问题：

① 手势体验问题；

② 商品列表列表留白，分类切换不流畅、二级列表偶现闪动的问题；

③ 内存占用高；

4.1.1 整个货架手势的支持

前期我们做了支持手势的调研：

② 页面存在多层吸顶和吸底动画交互效果，需要有合理的替代方案；

原有支持自动吸顶，我们通过动态设置外层scrollTop替换原动画方案

// 这个 View 组件会绑定 catchtouchmove 事件而不是 bindtouchmove<View catchMove={catchMove}></View>



封装小程序原生组件：<view id="container"  catchtouchmove="{{catchMove}}">  <slot></slot></view>

原生组件嵌套Taro组件：<native-container catchMove={catchMove}>  嵌套Taro组件</native-container>

const categroyNodeObserver = createIntersectionObserver(Taro.getCurrentInstance().page, { observeAll: true })categroyNodeObserver.observe('#app >>> .className', result => {    // 1、通过class获取列表再遍历查找对应元素    const vnodes = document.getElementsByClassName('className') as unknown as HTMLCollectionOf<Element>[];    const target = vnodes.find(vnode => vnode.uid == result.id)
    // 2、通过id直接获取元素    const target = document.getElementById(result.id);})

通过对比：第2种获取元素的耗时在个位数毫秒级，第一种耗时高达上百毫秒。

数据结构优化 - 树结构分类扁平化处理

4.1.3 支持列表补足功能

【 4.2 门详二级页面/购物车卡片/门详弹窗优化 】

实测：门详商品列表滑动50页左右，手机明显发烫，耗电严重，所以高能耗也是我们需要高优解决的问题。

【 5.1 静止状态下的消耗 】

能耗的结果：

静止情况：能耗由高降为低。

在滑动情况下：我们做了滚动防抖和图片大小优化，滑动瞬时能耗降低了20%，在滑动

70页后开始发热，在dom节点数量以及节点深度上还有优化的空间，后续我们会继续分享。

我们总结了能耗优化的一些方向，并放到了我们的开发规范中：

我们在9月份最后一个版本上线了全站的埋点方案的整改。其中包含底层埋点（PV CLICK EP）埋点参数的逻辑优化，以及所有业务上报埋点的机制与时机处理。整改之前，埋点存在部分问题：

① 曝光埋点的上报时机有误，不可用；

② PV埋点和点击埋点缺少规范，业务添加埋点不规范，成本高；

③ 曝光请求未聚合，导致频繁发起埋点请求；

整改之后，我们输出了门详的整体埋点开发规范；重新整理了所有曝光埋点的上报时机与整体方案；目前门详埋点可用率达到95%以上；为业务数据提供了更加准确的方向。

① 能耗层面的继续探索与优化；

虚拟列表的支持：目前门店列表支持多分类的加载联动，且在同一个分类下进行了组件复用与回收；下一步，我们将继续进行跨分类的组件复用与回收，将门详列表的回收渲染机制形成统一性的解决方案。

嵌套层级过深导致的性能消耗：进一步减少门详组件嵌套的问题，从内到外进行整体组件嵌套层级的优化，减缓手机发热发烫的问题。