微信小程序自推出以来，逐步发展，目前越来越受欢迎。其中最重要的一点是由于小程序的轻量级特性。每个小程序最大不超过2MB。也就是说，小程序获取新用户的成本大大降低。

但相应的，开发资源也受到限制。由于其轻量级的特性，小程序的代码包大小、可用内存空间、可用存储空间等都受到限制。如何有效支持业务逻辑，同时最大限度地减少资源占用，在小程序开发环境中显得尤为重要。代码包体积是一个重要的方面，本文将对其进行分析和讨论。

背景

本文内容根据小程序“转转官方”的经验总结。有些内容与开发环境密切相关，所以这里简单介绍一下。

“转转官方”是一款重磅小程序，移植了转转APP的大部分功能，从商品发布、浏览、搜索、下单、跟进等交易逻辑，到留言、私信、红包、推荐、运营、活动、个人中心、圈子社区等扩展能力均支持，目前代码包大小约为1.5MB。

《转转官方》是使用wepy框架开发的。该框架与Vue类似，支持组件开发、语法、less语法等。源代码在生成实际代码之前进行编译和压缩。目前在线版本是1.5.8。框架介绍：

像VUE一样编写微信小程序——深入学习wepy框架

1. https: //mp.weixin.qq.com/s/R2IlOzlA9Mb_XevDXAITdw

意义

控制代码包大小的主要意义是：

绕过尺寸限制

小程序代码包的大小有限制。最初是1MB，后来改为2MB。当代码包大小超过此限制时，将无法预览/上传/发布。

降低用户获取成本

减小代码包大小可以减少小程序的下载时间和首次加载时间，降低新用户的流失率；它还减少了下载流量和本地空间占用，提高了用户体验。

开发和维护保持代码包干净整洁，这在一定程度上有利于代码的长期维护。

战略

控制代码包大小的主要策略：

计划

外部资源

非核心、非紧急的资源文件，尤其是图片、音频、视频等大型媒体文件，可以在需要时通过网络加载到CDN服务器上。

这往往是小程序初期扩展的主要原因，也是最有效的压缩方法。比如我们的“手机30秒卖掉”小程序，将图片资源移出代码包后，大小直接从2MB左右缩小了。

数据外部

非核心、非紧急的数据内容，包括城区等大段数据，标签映射等大段配置，使用合同、服务描述等大段文案，可以移至数据服务器或本地并在需要时再次加载。

有些内容会比预期的要大，比如我们的《转让使用协议》。移出代码包后，释放了约40KB的空间。

外部功能

具有非核心自定义属性、不强或不紧急且可以异步处理的函数可以移至外部实现。选择地址、查看大图等功能可以由小程序原生接口实现，编码、解码等功能可以由服务器实现。

页面外部

非核心、非紧急的页面可以考虑搬到服务器上。从基础库1.6.4开始，小程序开始支持嵌入网页，非核心页面可以适当迁移到Web服务器上。

[wepy] 清理残留文件

目前wepy在编译时，不会自动清理上次编译剩余的文件，导致历史资源不断积累。

例如 7 页，npm run，-> 删除 6 页，npm run，仍然。

因此，应该修改脚本，在编译前添加清除dist的步骤，或者在编译前手动删除dist目录。

清理无关文件

避免将与执行无关的文件混入代码包中，如doc、demo、测试用例等。

通过设计合理的文件结构，可以避免不相关的文件混入代码目录。还可以在wepy框架下配置自动按类型/目录过滤文件（项目目录-新建.文件-编辑-语法参考。）。

清理离线/废弃的文件

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

IDE的查看引用、范围搜索等功能可以为清理过程提供一定的便利。

所有资源都搬到CDN之后，这部分空间可能是最可观的。 “转转官方”小程序代码包大小从刚刚超过2MB下降到1.5MB左右，主要通过清理残留文件和清理离线/废弃文件来释放。

[wepy] 清理多余的wxml文件

目前wepy编译时，组件的DOM部分会合并到页面中，而不会生成单独的wxml文件。

但是，如果组件的文件路径不包含'//'，wepy在编译过程中不会将其识别为组件，而是将其作为''类型处理，从而生成多余的wxml文件和json文件。

确保将组件放置在目录中以避免额外的空间消耗。

清理大文件

大文件往往具有较大的压缩空间，值得仔细调查和处理。

查找大文件的技巧：资源管理器-代码目录-搜索“*”-右键-排序依据：大小显示按大小排序的代码包中的所有文件。

资源压缩

大多数资源都可以适当压缩，这往往可以在保证功能体验的同时有效减少空间占用。参考工具：

其中，该工具的压缩效果非常可观。图像被压缩到40KB并不奇怪，而且图像质量几乎无损。

资源合并

具有相似功能的资源可以标准化，以减少重复的空间使用。

[wepy] 清理组件 DOM 的冗余副本？

观察发现，目前wepy的组件实现中，编译后的页面对组件js和wxss的引用是通过@的形式实现的，而对组件dom的引用则直接拼接到页面wxml文件中。

这就导致当一个组件被多个地方引用时，它的 DOM 内容将会有多个冗余副本。

例如10个页面引用组件A => 这10个页面编译后的wxml各包含一份A的dom，A的部分在代码包中重复了10次。

如果修改wepy编译流程，将组件dom引用流程改为使用或原生组件（从基础库1.6.3开始支持），这部分冗余开销应该可以省掉。

[wepy] 压缩自动生成的代码量？

观察发现，代码包中除了手动维护的业务代码外，还有很多框架/插件自动生成的代码。比如源码编译过程中生成的辅助代码、兼容语法引入的shim代码、兼容各运行环境的CSS前缀代码等。

通过修改/配置框架和插件，这个空间开销应该会在一定程度上减少。比如配置插件规则、配置自动插件的最低版本应该能够牺牲一些不必要的兼容性，从而减少shim代码的生成量。等等。

只是我还没有尝试过，所以不确定这部分成本是否还有相当大的压缩空间。

压缩额外的文件空间？

观察发现，代码包的大小始终远大于代码内容总大小（上传后详情面板中的“上次上传”和“上次预览”始终远大于“本地代码”）。

这个额外的尺寸还应该有压缩空间。例如，将小图片、小js文件、小less文件组合成精灵图、js库、less库等较大的文件，应该能够减少文件最小存储单元带来的额外空间开销。等等。

只是我还没有尝试过，所以不确定这部分成本是否还有相当大的压缩空间。

总结

由于其轻量级的特性，在小程序开发环境中，控制代码包的大小是非常必要和有意义的。

本文介绍了代码包体积压缩的一些策略、解决方案以及几个未实践的想法。总的来说，尽量精简，尽量只把最核心、必要、紧急的内容放在代码包中。当其他资源占用代码包空间过多时，可以考虑通过移动/删除/压缩/合并的方式释放它们。

有不懂的地方请多多指教。