存量用户运营企业微信的“用户端小程序”优化方案

企业微信端产品“C端用户小程序”，是一款服务于vivo线下代理、门店和导购，帮助导购链接用户，快速与用户进行沟通的工具。基于“C端小程序”的PU/UV量较为庞大，为了更加极致的用户体验，因此提高小程序性能优化是必然。

1、业务现状

1.1 存量用户运营企业微信“用户端小程序”

存量用户运营企业微信“用户端小程序”主要是服务于vivo代理、线下门店和导购，帮助导购链接用户的工具。

• 用户群：vivo线下用户。
• 主要功能：vivo新机预售，新用户注册。

看下“用户端小程序”的“新用户注册”，“新机预售”的页面，以下：

vivo新用户注册 

 

vivo新机预售

1.2 性能数据

一图胜千言，看下存量用户运营“用户端小程序”在没作优化以前，从“小程序数据助手”中获取到的“代码包下载量，打开耗时分布，网络请求延迟，网络流量消耗”等数据。以下：

从图中咱们能够看到，下载小程序代码包主要集中在2-5秒，此外，部分http请求接口的时间延迟很长，会影响到总体页面的渲染效果。因而可知，存量用户运营“用户端小程序”还有很大的优化空间。

2、性能指标

2.1 怎么定义高性能？

单纯的快是不行的。咱们不该该单纯考虑速度指标而忽略用户的感知体验，而应该全方位衡量用户在使用过程当中能感知到的与应用加载相关的每一个节点。

2.2 性能指标关键术语

FCP：白屏加载结束

FMP：首屏渲染完成

TTI：全部内容加载完成

2.3 咱们优化须要达到的指标

小程序官方指标：

1. 首屏时间不超过 5 秒。
2. 渲染时间不超过 500ms。
3. 每秒调用 setData 的次数不超过 20 次。
4. setData 的数据在 JSON.stringify 后不超过 256kb。
5. 页面 WXML 节点少于 1000 个，节点树深度少于 30 层，子节点数不大于 60 个。
6. 全部网络请求都在 1 秒内返回结果。

存量用户运营”用户端小程序“须要达到的指标：

1. 首屏时间不超过 2.5 秒。
2. setData 的数据量不超过 100kb。
3. 全部网络请求都在 1 秒内返回结果。
4. 组件滑动、长列表滚动无卡顿感。

 

3、小程序的一些基本概念

3.1 小程序底层框架

小程序的最终渲染载体依然是浏览器内核，而不是原生客户端。启用了双线程模型：

1. 视图层：也就是webview线程，负责启用不一样的 webview 来渲染不一样的小程序页面。
2. 逻辑层：一个单独的线程执行 JS 代码，能够控制视图层的逻辑。

 

3.2 小程序的启动步骤

1. 准备运行环境。

• 在小程序启动前，微信会先启动双线程环境，并在线程中完成小程序基础库的初始化和预执行。

小程序基础库包括 WebView 基础库和 AppService 基础库，前者注入到视图层中，后者注入到逻辑层中，分别为所在层级提供其运行所需的基础框架能力。

2. 下载小程序代码包。

3. 加载小程序代码包。

• 在此阶段，主包内的全部页面 JS 文件及其依赖文件都会被自动执行。

在页面注册过程当中，基础库会调用页面 JS 文件的 Page 构造器方法，来记录页面的基础信息（包括初始数据、方法等）。

4. 初始化小程序首页。 

• 在小程序代码包加载完以后，基础库会根据启动路径找到首页，根据首页的基础信息初始化一个页面实例，并把信息传递给视图层，视图层会结合 WXML 结构、WXSS 样式和初始数据来渲染界面。

3.3 小程序开发工具——体验评分工具audits

(ps:小程序开发者工具的评分插件audits能够对小程序的性能，使用体验，实践，UI样式，http请求等多个维度进行综合评分，建议小程序开发者在项目开发中使用。)

4、小程序优化技术方案

4.1 针对小程序启动太慢的方案

方案1：无用的文件，函数，wxss样式剔除，不须要的import砍掉。

方案2：减小代码包中的静态资源文件。

除了部分图片必须放在代码包（譬如网络异常提示）以外，建议开发者把图片、视频等静态资源都放在 CDN 上。

方案3：逻辑后移，精简业务逻辑。

尽可能把业务逻辑写在后端，若是一旦出现线上问题，小程序发版须要腾讯审核，然后端能够及时发布代码。

方案4：分包加载与分包预下载。

• 可参考小程序开放平台文档
• 独立分包
• 分包预下载

方案5：部分页面h5化。

• 小程序提供了 web-view 组件，支持在小程序内访问h5。若是小程序源码太大从而影响下载时间，能够考虑降级处理，把部分页面 h5 化。
• 具体可参考web-view文档。

4.2 针对小程序白屏时间过长的方案

小程序的白屏阶段：小程序代码包下载完（也就是启动界面结束）以后，页面完成首屏渲染的这一阶段，也就是 FMP (首次有效绘制)。

影响白屏的两个因素：

• 网络资源加载时间。
• 渲染时间。

方案1：启用本地缓存。

• 将请求接口中获取到的数据存储在storage里面，部分数据不须要每次发送http请求获取。

方案2：跳转页面时预拉取。

• 通常是在页面onload的时候去获取接口数据。
• 能够在调用wx.navigateTo以前先调用下一个页面的http接口，将数据存储在全局的promise里面，下一个页面onload的时候，直接从promise获取数据。

(ps:在A页面onHide或者onUnload的时候经过promise请求下一个页面B页面的http接口，在B页面onload或者onShow的时候从promise中获取数据。)

方案3：非关键渲染数据延迟请求。

• 将页面分为主体模块(骨架，列表数据)和非主体模块(弹窗等)。
• 非主体模块的数据请求能够延迟加载，使用setTimeout来请求接口。

方案4：分屏渲染。

• 将非主体模块分屏渲染。
• 以下图，咱们将A模块设置为主体屏，B,C模块设置为非主体屏，等A模块渲染完成后在渲染B,C模块。

方案5：骨架屏。

• 可使用尺寸稳定的骨架屏，来辅助实现真实模块占位和瞬间加载。

方案6：限制http请求数量。

• wx.request （HTTP 链接）的最大并发限制是 10 个。
• wx.connectSocket （WebSocket 链接）的最大并发限制是 5 个。

方案7：图片资源优化。

• 使用WebP格式。
• 图片裁剪，压缩，雪碧图
• 图片懒加载

4.3 提高渲染性能

概念：当调用 wx.navigateTo 打开一个新页面时，小程序框架会完成如下几步：

• 准备新的 webview 线程环境，包括基础库的初始化。
• 从逻辑层到视图层的初始数据通讯。
• 视图层根据逻辑层的数据，结合 WXML 片断构建出节点树（包括节点属性、事件绑定等信息），最终与 WXSS 结合完成页面渲染。

 

小程序的渲染损耗主要在数据通讯和节点树建立及更新的流程中，提高渲染性能优化的方向：

1. 下降线程间通讯频次。
2. 减小线程间通讯的数据量。
3. 减小 WXML 节点数量。

方案1：合并setData调用。

尽量地把屡次setData调用合并成一次。

只把与界面渲染相关的数据放在Data中。

方案2：去掉没必要要的事件绑定。

没必要要的click、touch、onPageScroll不要被触发。

方案3：去掉没必要要的节点属性。

组件节点支持附加自定义数据 dataset，当用户事件被触发时，视图层会把事件 target 和 dataset 数据传输给逻辑层。以下例：

<view class="tabbar-item" wx:for="{{list}}" wx:key="index"  item="item">
  <view @tap="tabFn" data-index="{{item}}">
  </view>
</view>
 
methods = {
  tabFn (e) {
    const item = e.currentTarget.dataset['item'];
    console.log(item);
  }
};

自定义数据量越大，事件通讯的耗时就会越长，因此尽可能减小自定义数据量，或者不用自定义数据。

4.4 解决小程序内存占用太高的问题

当小程序占用系统资源太高，就有可能会被系统销毁或被微信客户端主动回收，致使小程序挂掉。

方案1：回收页面的setTimeout和setInterval计时器。

小程序每个页面都会独立一个 webview 线程，但逻辑层是单线程的，也就是全部的 webview 线程共享一个 JS 线程，以致于跳转页面，计时器还在跑。

onHide或者onUnload的时候清除计时器。

方案2：避免频发事件中的重度内存操做。

• onPageScroll 事件回调使用节流。
• 避免 CPU 密集型操做，譬如复杂的计算。
• 避免调用 setData，或减少 setData 的数据量。

5、优化后的结果

5.1 看下audis下的得分

优化以前得分以下：

优化以后得分以下：

因而可知，按照以上步骤作小程序性能优化以后，audis的综合评分是有一个明显的进步的。

5.2 优化以后，“小程序数据助手”中的性能数据

6、总结

小程序性能优化和H5优化同样，是一个根据多样性用户场景作持续迭代的过程，也是咱们平常作web开发挥之不去的原则和主题。本文探讨了小程序优化的各类场景和方案，但愿在之后的项目开发过程当中，可以持续优化，打造出更好的产品。

做者：vivo-Fu Weilang