微信程序自推出以来，逐渐发展起来，目前受到越来越多的青睐。 其关键在于小程序的轻量性。 每个小程序最多2MB，无法立即离开。 与几十、百兆的APP相比，用户进入小程序或小程序获取新用户的成本将大幅降低。
但是，相应的，是开发资源的限制。 由于重量轻，小程序的软件包大小、可用内存容量、可用存储容量等都有限制。 如何在applet开发环境中有效支持业务逻辑的同时最大限度地减少资源消耗尤为重要。 码包体积是其中的一个重要方面，本文对此进行分析和探讨。
本文内容基于对小程序“跑官”经验的总结，部分内容与开发环境密切相关，现简要介绍如下。
“轮转式”是一个重量型小程序，移植了轮转APP的大部分功能，从发布、浏览、搜索、下单、跟进等交易逻辑，到消息、私信、红包、推荐、运输
“回转公式”采用wepy框架开发。 此框架类似于vue，支持组件化开发、ES678语法、less语法等，在编译并压缩源代码之后生成实际的代码。 当前的在线使用版本为1.5.8。 框架介绍：深入研究像VUE一样写微信小程序的wepy框架
3359 MP.weixin.QQ.com/s/R2 iloz la 9mb _ xevdxaitdw
控制语义代码包大小的主要含义：
避开大小限制
小程序包大小有限，最初为1MB，但后来更改为2MB。如果代码包大小超过此限制，将无法预览/上载/发布。
降低用户获取成本
通过减小代码组的大小，可以缩短小程序的下载时间和首次加载时间，降低新用户的流失率； 同时减少下载流量和本地空间占用，提高用户体验。
开发维护
保持代码包的清洁在一定程度上有利于代码的长期维护。
策略控制代码包大小主要策略：
搬
能搬的东西尽量搬。 许多图片、音频、数据甚至页面都可以移动到服务器端，并根据需要通过网络加载。 将非核心不需要的内容从代码包中移出会大大释放代码包的空间。
删
搬不动的尽量删除。 立即清理不需要的/不需要的内容，如脱机、已处置、无关或冗馀的内容，不要继续占用代码包的空间。
压缩
不能删除的尽量压缩。 图像、js、wxss、wxml等中存在压缩空间。 在许多情况下，适当压缩可以有效地减少空间占用，而几乎不影响功能体验。
合并
不能压缩的尽量合并。 通过将具有类似功能的资源规范化，可以在需求/设计/实施级别减少资源的重复消耗。
其它
其他压缩策略。
方案资源外置
非核心非紧急资源文件，特别是图像、音频、视频等大型媒体文件，可以移动到cdn服务器并根据需要通过网络加载。
这常常是小程序前期膨胀的主要原因和最有效的压缩方式，比如我们的“手机30秒卖快”小程序，在将图片资源移出编码包后，体积从约2MB直接降至195KB。
数据外置
非核心非紧急数据的内容包括城市地区等的大致数据、标签映射等的大致配置，可以使用条约、服务说明等的大致副本移动到数据服务器或本地存储，并根据需要加载。
有些内容比想象的要大。 例如，我们的《周转使用条约》在退出软件包后，释放了约40KB的空间。
功能外置
非核心定制属性不强、可进行非紧急异步处理的功能可以迁移到外部实现。 地址选择、大图片显示等功能可以通过小程序原生界面实现，代码解码等功能可以在服务端实现。
页面外置
非核心非紧急页面考虑移动到服务器端。 从基础库1.6.4开始，小程序支持嵌入式页面，非核心页面可以适当考虑迁移到web服务。
[wepy] 清理残留文件
当前，编译wepy时上次编译并保留的文件没有自动清理，而是持续积累历史资源。
e.g. 7页，npm run build，删除第172KB-6页，npm run build，仍然为172kb。
因此，必须修改build脚本，在编译前添加清空dist的步骤，或者在编译前手动删除dist目录。
清理无关文件
请勿将与执行无关的文件(如自述文件、doc、demo和测试用例)混入代码包中。
通过设计合理的文件结构，可以避免无关的文件混入代码目录中。 还可以在wepy框架下设置. wepyignore，以自动按类型/目录过滤文件。 (项目目录-新建. wepyignore文件-编辑-语法参考. gitignore )。
清理已下线/已弃用文件
ong>已下线/已弃用的文件资源应及时清理，包括npm包、组件、页面、媒体资源等。若后续需要重新上线/重新使用，可以通过git等版本控制工具找回。这部分资源不需要持续占用代码包空间。
IDE的查看引用、范围搜索等功能可以为清理过程提供一定的便利。
资源都移至cdn之后，这部分空间可能就是最可观的了。“转转官方”小程序代码包体积从2MB出头降到了约1.5MB，主要就是由清理残留文件、清理已下线/已弃用文件释放的。
[wepy]清理多余wxml文件
目前wepy编译时会将组件的dom部分拼合到页面中，而不生成单独的wxml文件。
但若组件所在文件路径不含'/components/'，则编译环节wepy不会识别其为组件，会按'Other'类型处理，从而生成多余的wxml文件和json文件。
确保组件都放在components目录下可以避免这部分多余空间消耗。
清理大文件
大文件常常存在较大的压缩空间，值得重点排查和处理。
查找大文件tip：资源管理器 - 代码目录 - 搜索'*' - 右键 - 排序方式：大小，即可将代码包内所有文件按大小排序展示
资源压缩
大部分资源都可以进行适当压缩，常常可以在保证功能体验的同时，有效地减少空间占用。参考工具：
js压缩: 配置wepy-plugin-uglifyjs插件
json、wxml压缩： 配置wepy-plugin-filemin插件
less压缩： 配置wepy-compiler-less插件
图片压缩： 配置wepy-plugin-imagemin插件、TinyPNG
其中TinyPNG工具压缩效果非常可观，400KB的图片压到40KB不足为奇，并且画质感知上几乎无损。
资源合并
功能类似的资源可以归一化，减少重复空间占用。
需求层面，比如不同运营活动可以采用统一模板，而不每次增加单独页面等；
样式层面，比如可以统一弹窗规范，而不引入五花八门的零碎弹窗组件等；
设计开发层面，比如可以尽量解耦合抽取公共组件，减少重复造轮子等。
[wepy]清理组件DOM冗余拷贝？
观察发现，目前wepy的组件实现中，编译后页面对组件js、wxss的引用是通过require、@import的形式实现的，而对组件dom的引用则是直接拼合到页面wxml文件中。
这导致，当一个组件被多处引用时，其dom内容会有多份冗余拷贝。
e.g. 10个页面引用了组件A => 编译出的10个页面wxml各含一份A的dom，A的template部分在代码包中被原模原样重复了10次
如果修改wepy编译过程，将组件dom引用过程改为使用include或原生组件（基础库1.6.3开始支持）实现，应当可以节省这部分冗余开销。
[wepy]压缩自动生成的代码量？
观察发现，代码包中除了手动维护的业务代码之外，也有不少框架/插件自动生成的代码。如源码编译过程中生成的辅助代码、兼容ES678语法引入的垫片代码、兼容各运行环境引入的css前缀代码等。
通过对框架和插件进行修改/配置，应当可以一定程度减少这部分空间开销。比如对babel插件进行规则配置、对auto-prefix插件进行最低版本配置，应当可以牺牲部分不必要的兼容性，从而减少垫片代码的生成量等。诸如此类。
只是笔者未及尝试，尚不确定这部分开销是否有可观的压缩空间。
压缩额外文件空间？
观察发现，代码包大小总是比代码内容总大小大得多（上传后详情面板中“上次上传”、“上次预览”总是比“本地代码”大得多）。
这部分额外大小应当也是存在压缩空间的。比如将细碎图片、细碎js文件、细碎less文件拼合成雪碧图、js库、less库等较大文件，应当可以减少由于文件最小存储单元引入的额外空间开销等。诸如此类。
只是笔者未及尝试，尚不确定这部分开销是否有可观的压缩空间。
总结
由于轻量级特性，小程序开发环境中，对代码包体积的控制是十分必要且十分有意义的。
本文介绍了代码包体积压缩的一些策略、方案和几个未及实践的思路。总的来说，就是尽量精简，尽量只将最核心最必要最紧急的内容放在代码包内。其它资源过多占用代码包空间时，则考虑通过搬移/删除/压缩/合并等方式予以释放。
拙劣之处欢迎不吝赐教。