小程序性能优化的一些实践

关于小程序性能优化的尝试及分析总结

背景

在项目推广前期，小程序凭借其轻量级的安装下载方式很容易被用户接受。同时，依赖于微信、QQ自身的庞大流量的支撑，也是不错的引流方案。但是，在我们的项目实际落地推广时，从微信提供的数据显示来看，用户在启动页流失数量巨大，有时甚至可高达50%及以上。通过性能监控助手我们可以发现，在2-3s的时间段中用户流失比例最高。依据微信官方给出数据，首屏时间不超过 5 秒，但实际情况是用户可能无法接受这样的等待时长。

怎样进行性能优化

为解决这一问题，我们首先需要分析在小程序启动时都经历了哪些过程。

其中 资源准备、开发者代码注入为主要耗时流程。其中小程序运行环境准备受限于平台差异性较大，我们的性能优化方案不便于从此处入手。因此选择从

• 减少包体积
• 优化代码逻辑、结构

这两方面着手进行启动性能优化。

减少包体积

小程序为了给用户提供更轻便的服务体验，因此对包的体积大小做了限制：不得超过2M。在实际的开发过程中我们很容易就“超重”了，这会直接影响到我们的真机预览、调试模块。减包迫在眉睫，我们主要从以下方面入手进行减包尝试：

• 静态资源文件上传CDN
  最初的代码包中，仅图片资源就占据接近1M空间，极大的影响了下载时长。并且小程序平台提供的压缩方式对于图片资源来说效果非常低。因此，在体验可接受的前提下，可以将部分文件上传至CDN，（提示：tabbar中的icon配置在json文件中，因此这类资源文件最好保留在本地）
• 做分包加载
  查阅文档我们可以发现，目前提供了两种分包的策略：1. 独立分包 2. 普通分包

独立分包： 在这种分包模式下，主包与分包独立，无复用模块。

其中A为主包 B为独立分包，模块间无依赖关系

使用独立分包需要注意的是，独立分包页面简单 不依赖整体功能，适合做单独的活动页进行投放推广。如果修改现有的项目的启动展示页为独立分包则需要考虑渠道推广以及相关微信广告投放配置的页面路径，涉及到的改动较大。 同时，安卓机型上会显示加载主包时的loading框加载动画，适度降低用户体验。因此独立分包方案更适合项目初期设定或不影响项目其他推进的情况。
在投放时，指定进入路径为独立分包页面（eg: pages/moduleB/pear），则会先下载独立分包（往往体积较小，页面结构简单），速度很快，给人“秒开”的感觉。

分包下载： 这种分包方式，即分为 主包 + 功能相对独立的分包 模式。依据微信要求，主包内必须包含页面主体的tab页，因此 这里可以分出去的 多为各主功能模块的非tab页面且功能不依赖于其他分包模块。
这里的模块之间引用原则如下：

packageA 无法 require packageB JS 文件，但可以 require app、自己 package 内的 JS 文件
packageA 无法 import packageB 的 template，但可以 require app、自己 package 内的template
packageA 无法使用 packageB 的资源，但可以使用 app、自己 package 内的资源

文档中未明确提到关于主包引用分包的情况，这里进过实践测试及社区讨论后得出
用户打开小程序 --> 加载主包 --> 加载完立即渲染展示 --> 空闲时预加载分包
渲染主包的时候，如果主包引用了分包的内容，但分包可能未加载完成，就会造成启动失败。由于这个特性，所以建议将各公共模块统一放入到主包当中，便于引用。

• 相关文件压缩
  在微信开发者工具中我们可以看到 它在上传代码时为我们提供了UglifyJs进行压缩混淆。
  但是需要注意的是 超过500kb的代码开发者工具将不会对它们进行压缩，需要我们自己进行处理。

优化代码逻辑、结构

• 无用代码删除
• 降低线程间通信频次；
• 减少线程间通信的数据量；
• 减少 WXML 节点数量；