背景

我们都知道微信小程序有包大小限制。整个小程序所有子包大小不能超过20M，单个子包/主包大小不能超过2M。但面对业务的不断更新和迭代，代码和资源会越来越多。如果不尽早规划包裹量的管理，有一天必然会阻碍业务的发展。因此，在小程序开发环境中，如何有效支撑业务逻辑，同时最小化资源占用就显得尤为重要。

代码包体积是一个重要的方面，本文将对其进行分析和讨论。

动态化传统治理策略和资源

这种方法往往是小程序体积早期膨胀的主要原因，也是最有效的压缩方法。

一些非核心、非紧急的资源文件，尤其是图片、音频、视频等大型媒体文件，可以移至CDN服务器上，在需要时下载。

页面动态化

将非核心、非紧急页面转换为h5并显示。一页和两页没有什么区别，但是如果有10页和8页就很明显了，至少可以节省几十kb。

静态数据在线

有时在开发过程中，我们会把一些没有变化的数据放入小程序项目中，比如城市地址信息、服务条款等。此类数据可以尽量移到线上，首次加载后可以缓存在本地时间。

及时清理废弃资源

已经下线或者废弃的文件资源要及时清理，包括npm包、组件、页面、媒体资源等。如果后期需要上线/复用，可以通过git等版本控制工具找回。这些资源不需要继续占用代码包空间。

删除重复代码

你可以用它来分析项目代码，找出哪些代码是重复的，可以进行相应的优化。

提取公共模块

业务实现应该是通用的，应该提取通用的业务组件。例如，不同的活动可以使用统一的模板和相同的组件，而不必每次都添加新的代码。

风格层面保持统一，使用统一的基础组件。例如，可以统一弹窗规范，而无需引入各种零散的弹窗组件。

减少设计和开发层面的重复，提取更多通用模块，减少重复造轮子。

谨慎使用第三方插件

尽量少用第三方插件。比如你可能只需要它的1%的功能，一个曲线图，但是你要把它封装起来，这使得整个项目的规模急剧增大。

配置分包（普通分包）

分包是类似于小程序给出的web异步引入的解决方案。一些初次进入时不需要的页面可以放入分包中，跳转到相应页面后才下载分包。这些页面及其附件将资源放入子包中可以有效减小主包的大小。

.png 配置独立分包

独立子包是小程序中的一种特殊类型的子包，可以独立于主包和其他子包运行。从独立子包页面进入小程序时，无需下载主包。只有当用户进入普通子包或主包页面时才会下载主包。

我们可以根据需要将某些具有一定功能独立性的页面配置成独立的子包。小程序从普通分包页面启动时，需要先下载主包；独立分包可以不依赖主包运行，可以大大提高分包页面的启动速度。

.png 分包细化

该策略主要是控制和减少主包的体积，优化主包体积，防止主包的一些未使用的资源放入主包中，占用主包体积。

体积分析

遇到主包太大之后，我们需要弄清楚主包里装的是什么？它们为什么这么大？

您可以使用原生小程序开发者工具自带的分析工具，也可以使用类似的插件进行辅助分析。它可以直观地分析打包文件包含的内容、大小比例、模块包含关系、依赖关系和文件。无论是重复还是压缩后大小是多少，我们都可以做有针对性的优化。

.png 终极大招激活图

启动图片最常见于应用程序中。虽然它们在小程序上很少见，但它们是一个非常好的解决方案。

这也是滴滴小程序的优化方案。为小程序分配启动图片。页面渲染完成后，会立即跳转到其他分包页面。主包只有启动图片页面和整个项目用到的基础库。这样，主包的大小就基本固定了，不断的业务迭代也不会增加主包的大小。

虽然这个解决方案是有效的，但您需要评估它是否适合您自己的业务以及这种体验是否可以接受。

不过笔者来回体验了滴滴小程序的启动和页面的外观，感觉非常不错。

.png 逻辑动态

这被认为是终极之举，但技术实现也非常具有挑战性。就是把代码放到远程，然后运行时把代码拉到本地执行，然后渲染页面。这样只需要构建一个 sdk来执行远程js代码，业务代码放在远程就不会占用包体积。

当然，这种方案目前业界很少使用，社区里也有一些相关的参考资料，但不是太多，而且需要大量的基础设施。有兴趣的朋友可以自己研究一下。

总结

由于其轻量级的特性，在小程序开发环境中，控制代码包的大小是非常必要和有意义的。常规的体积优化策略是尽量只将最核心、必要、紧急的内容放入代码包中。当其他资源占用代码包空间过多时，可以考虑通过移动/删除/压缩/合并的方式释放它们。

但随着业务的不断迭代，代码量会不断增加，仍然无法突破小程序的限制，因此仍然存在隐藏的体量风险。

当然，有一些特殊的处理方法可以更大程度地解决这个隐患，主要是启动图方案和大招的动态逻辑（突破限制）。

不知道你用过什么优化方案，可以留言交流。

参考：