摘要

文章探讨了微信小程序包体积的限制与痛点，阐述了常规、结合业务的优化方案以及发布系统管理机制，以平衡包体积、提升小程序性能和用户体验。

一、背景与痛点

微信小程序为保证体验和性能，限制主包不超 2M。哈啰小程序业务增长中，主包体积面临问题，存在痛点：

1. 阻塞业务需求排期。
2. 人肉搜索包体积增长点，无法根本解决。
3. 缺乏包体积统一管理平台。
4. 包体积大导致加载慢、体验差。

二、包体积优化

（一）常规优化方案

1. 启动性能优化

• 启动流程
  • 资源准备
    • 小程序相关信息准备：微信客户端从后台获取基本信息并缓存更新。
    • 环境预加载：受多种因素影响，微信客户端会预加载运行环境。
    • 代码包准备：从后台获取地址、下载代码包并校验，微信做了如压缩、增量更新等优化。
  • 小程序代码注入：启动时读取配置和代码注入到 JavaScript 引擎，视图层和逻辑层并行注入，V8 引擎有缓存技术。
  • 首屏渲染：视图层和逻辑层并行初始化，有信号交互后渲染首页并触发事件。
• 优化方案
  • 控制包体积
    • 降低代码包大小影响下载耗时，可采用分包、清理无用代码等手段，分包还有预下载、异步化等优化。
  • 代码注入优化
    • 按需引入会注入未使用代码，用时注入可指定部分组件不在启动时注入。
  • 首屏渲染优化
    • 启用初始渲染缓存可提前展示，数据预拉取、周期性更新能减少等待时间，骨架屏可提升体验。

2. 运行时性能优化

• 优化方案
  • 合理使用setData，因为逻辑层和视图层通讯耗时与数据量有关。
  • 页面切换优化，如请求前置。
  • 安卓上控制预加载下个页面的时机，避免阻塞当前页面渲染。

（二）结合业务优化方案

1. 第三方组件库异步分包

• 主包被限 2M，npm 库管理问题使主包被占空间大。可从vendor.js拆分，主包使用异步引入第三方库。
• 若使用taro和webpack编译有问题，解决方法有自定义插件替换require关键字或用__non_webpack_require__代替。
• 注意点：同步引用代码需改造，分包加载失败可设重试机制。

2. 封面方案

• 把业务抽离到分包，主包只保留基础库和公共文件，启动时跳转承载业务的分包页面，可控制主包体积并提升性能。

三、长期控制包体积机制

（一）业务线管理机制

• 后台集临时资源申请和图标展示，可临时申请资源，要说明申请原因等，有审批流程，还有最长使用路径、临时申请最大包体积限制，到期有通知和限制。

（二）发布系统管理机制

• 开发者merge分支时触发gitlab钩子函数，触发jenkins的job编译计算体积，与申请体积比对，超出则通知并限制发布。