作者简介
携程前端框架团队，为携程集团各业务线在PC、H5、小程序等各阶段提供优秀的Web解决方案。产品涉及各类前端/Node端应用框架、研发工作台、前端中台化、静态资源发布系统等。当前主要专注方向包括：新一代研发模式探索，Rust构建工具链路升级、Serverless应用框架开发、在线文档系统开发、低代码平台搭建、适老化与无障碍探索等。
一、背景
众所周知，无论是微信小程序、支付宝小程序或者其他类型的小程序，代码包都是有大小限制的。目前微信官方规定，整个小程序不超过20M，单个分包或主包大小不超过2M。之所以这样限制，是对小程序启动速度的考虑，微信希望用户在使用任何一款小程序时，都能获得一种”秒开“体验，这也正是小程序的优势所在，但同时也对开发人员提出了更高的要求。
携程小程序涉及30+条业务线，上百个开发人员，目前包体积已经向着微信限制的20M迈进，包体积过大必将导致新增业务受限、启动慢等问题，这些都给用户带来了不好的使用体验，因此对Size的治理势在必行。
为了能够合理有效的利用有限的Size，我们设计了一套自己独有的Size治理方案，如图1所示：
图1 携程小程序Size治理
从图中可以看出，Size治理包括Size监控机制和主包文件管理机制，这两个机制的实现离不开小程序管理平台的支持。小程序管理平台是携程内部用于管理各类小程序（微信、百度、支付宝等）的官方系统，是一个集小程序配置、发布、审批、数据统计于一体的系统。接下来我们将对其进行详细的介绍。
二、Size监控机制
2.1 Size分配
在《携程微信小程序如何协同开发》一文中我们提到过，携程将整个小程序划分数十条业务线（即Bundle），每个Bundle可以拥有多个分包。我们为每个Bundle设置一个约定好的阈值，该值包括两部分：永久Size + 临时Size。顾名思义，永久Size是Bundle的固有Size，临时Size是指到了约定日期将自动回收的Size，这些信息都在小程序管理平台系统中进行配置，如图2所示：
图2 Size分配
从图中可以看出，pages/train 的Size为：1888KB(永久Size) + 155KB(临时Size)。在到达约定日期之前，该Bundle的开发人员必须调整代码至永久Size大小(即1888KB)，否则该Bundle提交新的代码时，将不能通过Size检查阶段。
2.2 Size检测
每当业务方提交代码至发布分支时，都会自动触发pipeline的构建，此时会对当前Bundle的实际Size进行检测，如果超过约定的Size值，会强制中断构建过程，并发送失败信息至相关发布群及开发人员，强制不让代码提交至发布分支，以此实现Size检测的能力，报错信息如图3所示：
图3 Size检测结果通知
通过Size分配和Size检查，强制业务方主动优化代码、自行下线流量较少的老业务代码，为新业务提供空间。同时，我们也提供了Size申请审批流程，业务方可通过申请临时Size获取额外的Size空间，如果临时Size达到了内部相关要求，也可以申请转换为永久Size。
2.3 Size申请审批
当Bundle必须通过申请临时Size才能上线新的需求时，Bundle Owner可以在小程序管理平台上创建临时Size申请单，由相关委员会审批后决定是否通过临时Size申请。如果以后想将临时Size转换为永久Size，需要理由足够充分，并且约定好业绩指标，才可以申请永久Size。申请平台如图4所示：
图4 Size申请审批
通过提高Size的申请成本，促使业务方更合理的利用有限的Size，防止无限制的代码堆砌、造成代码冗余。
2.4 Size提醒
为了督促各业务方能够按时归还临时Size，防止Size不足导致发布失败，我们设计了一套Size提醒机制，每天会给满足以下任意一条的Bundle Owner发送消息提醒：
含有临时Size的Bundle；
临时Size到期的Bundle；
Size超限的Bundle。
提醒消息如图5-6所示：
图5 临时Size倒计时提醒
图6 Size超限提醒
通过消息提醒，促使Bundle Owner合理排期优化代码、缩减Size，起到了预警、监督、告示的作用，防止临时Size的回收致使新业务无法正常发布的情况。
2.5 Size数据统计
在小程序管理平台中，我们也提供了数据统计的功能，可以多维度的展示Size的趋势变化，比如BU维度的、Bundle维度、分包维度等；也可以查看小程序中各个BU的Size占比情况等，如图7-8所示。通过统计可以让我们直观的了解各个业务线的活跃程度以及Size的分配情况。
图7 BU总体Size趋势图
图8 Bundle Size趋势图
三、主包文件管理机制
每个小程序必定都有一个主包，所谓的主包，即放置默认启动页面或TabBar 页面，以及一些所有分包都需用到公共资源。小程序启动并进入非独立分包页面时，默认会下载主包，并且自动执行主包的脚本，主包的体积直接影响首屏渲染性能，关乎用户初次使用的体验，因此对主包文件的管理有着重要的意义。接下来，我们将从主包文件的管理和检查两方面进行详细介绍。
3.1 主包文件管理
小程序管理平台提供了对主包文件的可视化管理功能，主包文件的查看、增加、删除操作均可在管理平台上进行配置，如图9所示：
图9 主包文件管理
通过管理平台，我们可以快速获取主包中的文件内容以及文件的归属情况，配置后的数据将作为参照用于主包文件的检查。
3.2 主包文件检查
每当代码提交进行pipeline构建时，我们会通过微信的规则筛选出可能会打包到主包中的文件，将该列表与小程序管理平台上配置过的主包文件列表进行对比，如果存在未配置过的文件，会强制中断构建过程，并将构建结果发送至相关发布群即开发人员，以此实现主包文件的管理，报错信息如图10所示：
图10 主包文件检查
通过对主包文件进行清理，并对主包中的文件进行严格限制之后，主包Size下降了46.5%，如图11所示，目前已趋于稳定状态。主包管理机制防止业务线随意向主包中添加文件，做到了可感知、可控制，同时对提升首屏渲染性能有着重大意义。
图11 主包文件Size变化趋势图
三、总结
综上所述，携程小程序Size治理方案主要包括Size管控机制和主包文件管理机制，实现了对Size的分配、检测、申请、提醒、统计能力，该方案在微信小程序中被充分地实践着，小程序的Size去向、占比都更加直观透明的展示出来，防止随意滥用。目前微信小程序的Size已趋于稳定状态，后续将逐步应用于其他类型的小程序中。
【推荐阅读】
“携程技术”公众号
分享，交流，成长
1440
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
