微信小程序自推出以来，逐渐发展，目前正受到越来越多的青睐。其中很重要的一点得益于小程序的轻量级特性，每个小程序最多不超过2MB，招之即来挥之即去，相比于几十上百兆的APP，用户进入小程序，或者说，小程序获取新用户，的成本大大降低。
但与之相应的，是开发资源的限制。由于轻量级特性，小程序的代码包体积、可用内存空间、可用存储空间等均受限制。如何在有效支持业务逻辑的同时，尽量减少资源占用，在小程序开发环境中显得尤为重要。代码包体积是其中的一个重要方面，本文将就此进行分析与探讨。
背景本文内容基于小程序“转转官方”经验总结，部分内容与开发环境密切相关，因而此处进行简要介绍。
“转转官方”是一个重量型小程序，移植了转转APP的绝大部分功能，从商品发布、浏览、搜索、下单、跟进等交易逻辑，到留言、私信、红包、推荐、运营活动、个人中心、圈子社区等扩展能力均已支持，目前代码包体积约为1.5MB。
“转转官方”采用wepy框架进行开发。该框架类似vue，支持组件化开发、ES678语法、less语法等，源码经编译、压缩后才生成实际代码。目前线上使用版本为1.5.8。框架介绍：像VUE一样写微信小程序-深入研究wepy框架
意义控制代码包大小主要意义：
避开大小限制
小程序代码包体积存在大小限制，一开始为1MB，后来改为2MB，代码包体积超过此上限时将无法进行预览/上传/发布。
降低用户获取成本
减小代码包体积，可以降低小程序下载时长&首次加载时长，降低新用户流失率；同时减少下载流量和本地空间占用，提升用户体验。
开发维护
保持代码包干净整洁，一定程度上有利于代码的长期维护。
控制代码包大小主要策略：
搬
能搬的尽量搬。图片、音频、数据、甚至页面，很多都可以搬至服务端，需要时再通过网络载入。将非核心非必要的内容移出代码包可以大幅度释放代码包空间。
删
搬不了的尽量删。已下线、已废弃、无关、冗余等不需要/不再需要的内容应及时清理，避免持续占用代码包空间。
压缩
删不了的尽量压缩。图片、js、wxss、wxml等均存在压缩空间。很多时候，适当程度的压缩，能在几乎不影响功能体验的同时，有效减少空间占用。
合并
压缩不了的尽量合并。功能类似的资源可以归一化，在需求/设计/实现层面减少资源的重复消耗。
其它
其它压缩策略。
资源外置
非核心不紧急的资源文件，特别是图片、音频、视频等体积较大的媒体文件，可以移至cdn服务器，需要时再通过网络载入。
这常常是小程序前期膨胀的主要原因和最有效压缩方式，比如我们的“手机30秒快卖”小程序，将图片资源移出代码包后，体积从约2MB直接降到了195KB。
数据外置
非核心不紧急的数据内容，包括城市地区等大段数据，标签映射等大段配置，使用条约、服务说明等大段文案，可以移至数据服务器或本地storage，需要时再予以载入。
有些内容体积会比想象中大，比如我们的“转转使用条约”，移出代码包后，释放了约40KB空间。
功能外置
非核心自定义属性不强烈、不紧急可以异步处理的功能，可以移至外部实现。如选择地址、查看大图等功能可以交由小程序原生接口实现，编码解码等功能可以交由服务端实现。
页面外置
非核心不紧急的页面，可以考虑移至服务端。从基础库1.6.4起，小程序开始支持内嵌网页，非核心页面可以考虑适当往web服务器迁移。
[wepy] 清理残留文件
目前wepy编译时不会自动清理上次编译残留的文件，导致历史资源持续积累。
e.g. 7个页面,npm run build, 172KB -> 删掉6个页面, npm run build, 依然 172KB。
因而应当修改build脚本，在编译前增加清空dist步骤，或在编译前手动删除dist目录。
清理无关文件
应避免代码包中混入运行无关的文件，如readme、doc、demo、测试用例等。
可以通过设计合理的文件结构避免无关文件混入代码目录，wepy框架下也可以配置.wepyignore自动按类型/目录过滤文件（项目目录-新建.wepyignore文件-编辑-语法参考.gitignore）。
清理已下线/已弃用文件
已下线/已弃用的文件资源应及时清理，包括npm包、组件、页面、媒体资源等。若后续需要重新上线/重新使用，可以通过git等版本控制工具找回。这部分资源不需要持续占用代码包空间。
IDE的查看引用、范围搜索等功能可以为清理过程提供一定的便利。
资源都移至cdn之后，这部分空间可能就是最可观的了。“转转官方”小程序代码包体积从2MB出头降到了约1.5MB，主要就是由清理残留文件、清理已下线/已弃用文件释放的。