企业微信端产品“C端用户小程序”，是一款服务于vivo线下代理、门店和导购，帮忙导购连贯用户，疾速与用户进行沟通的工具。基于“C端小程序”的PU/UV量较为宏大，为了更加极致的用户体验，所以晋升小程序性能优化是必然。

一、业务现状

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

存量用户经营企业微信“用户端小程序”次要是服务于vivo代理、线下门店和导购，帮忙导购连贯用户的工具。

用户群：vivo线下用户。
次要性能：vivo新机预售，新用户注册。

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

vivo新用户注册

vivo新机预售

1.2 性能数据

一图胜千言，看下存量用户经营“用户端小程序”在没做优化之前，从“小程序数据助手”中获取到的“代码包下载量，关上耗时散布，网络申请提早，网络流量耗费”等数据。如下：

从图中咱们能够看到，下载小程序代码包次要集中在2-5秒，此外，局部http申请接口的时间延迟很长，会影响到整体页面的渲染成果。由此可见，存量用户经营“用户端小程序”还有很大的优化空间。

二、性能指标

2.1 怎么定义高性能？

单纯的快是不行的。咱们不应该单纯思考速度指标而疏忽用户的感知体验，而应该全方位掂量用户在应用过程中能感知到的与利用加载相干的每个节点。

2.2 性能指标要害术语

FCP：白屏加载完结
FMP：首屏渲染实现
TTI：所有内容加载实现

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

小程序官网指标：

首屏工夫不超过 5 秒。
渲染工夫不超过 500ms。
每秒调用 setData 的次数不超过 20 次。
setData 的数据在 JSON.stringify 后不超过 256kb。
页面 WXML 节点少于 1000 个，节点树深度少于 30 层，子节点数不大于 60 个。
所有网络申请都在 1 秒内返回后果。

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

首屏工夫不超过 2.5 秒。
setData 的数据量不超过 100kb。
所有网络申请都在 1 秒内返回后果。
组件滑动、长列表滚动无卡顿感。

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

3.1 小程序底层框架

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

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

3.2 小程序的启动步骤

1. 筹备运行环境。

在小程序启动前，微信会先启动双线程环境，并在线程中实现小程序根底库的初始化和预执行。

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

2. 下载小程序代码包。

3. 加载小程序代码包。

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

在页面注册过程中，根底库会调用页面 JS 文件的 Page 结构器办法，来记录页面的根底信息（包含初始数据、办法等）。

4. 初始化小程序首页。

在小程序代码包加载完之后，根底库会依据启动门路找到首页，依据首页的根底信息初始化一个页面实例，并把信息传递给视图层，视图层会联合 WXML 构造、WXSS 款式和初始数据来渲染界面。

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

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

四、小程序优化技术计划

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 联合实现页面渲染。

小程序的渲染损耗次要在数据通信和节点树创立及更新的流程中，晋升渲染性能优化的方向：

升高线程间通信频次。
缩小线程间通信的数据量。
缩小 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.1 看下audis下的得分

优化之前得分如下：

优化之后得分如下：

由此可见，依照以上步骤做小程序性能优化之后，audis的综合评分是有一个显著的提高的。

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

六、总结

小程序性能优化和H5优化一样，是一个依据多样性用户场景做继续迭代的过程，也是咱们日常做web开发挥之不去的准则和主题。本文探讨了小程序优化的各种场景和计划，心愿在当前的我的项目开发过程中，可能继续优化，打造出更好的产品。

作者：vivo-Fu Weilang