优酷 Android 包瘦身治理思路全解

稳定性、性能、包大小，在移动端基础用户体验领域“三分天下”，是app承载业务获得稳定、高效、低成本、快速增长的重要基石。其中，包大小对下载转化率、拉新拉活成本等方面的影响至关重要，这在业界已经成为共识，近年来头部app针对下沉市场的极小包策略，更是将包大小的价值提升到了极致。

优酷在Android包大小领域，有长达5年的持续投入、实践和积累，尤其是在近2年逐步进入低成本可持续治理的健康状态。现将这些思考、方案设计、技术建设、治理实践统一汇总整理成文并分享出来，希望能够帮助更多同学在所负责或参与的app中，更好的进行包大小治理。

本文聚焦于整体治理思路，以治理实践为依托，讲述瘦身技术、治理模式、治理策略，以及背后的思考与取舍。

五年治理回顾 

作为开篇，先给出优酷近5年包大小变化情况：

以2020年9月为分水岭，从治理模式角度，可以将前后划分为两个“风格迥异”的阶段：专项治理、常态治理。包瘦身治理也属于一种软件工程，接下来围绕“术”、“道”、“人”三个维度，展开回顾和总结：

1.1 专项治理3年：三次两反弹

自2017年初至2020年9月这3年时间，共经历三次专项治理以及两次反弹。

2017.05 - 2018.03，第一次专项治理。在瘦身效果上，从最高点73MB降低到51MB，瘦身比例约30%，这次瘦身专项的最大价值，是积累了宝贵的实践经验：

• 技术手段。由于当时几乎没有积累，采用的技术手段相对常规且具有单点性，主要包括：分析并下线无用业务/功能模块、远程化边缘业务、图片压缩&矢量化等；

• 治理策略。缺乏整体目标掌控和拆解，对于头部问题进行单点改造；

• 组织形式。比较松散，涉及范围窄，参与人数少。

2018.04 - 2018.09，第一次反弹期。期间使用“模块级”包大小卡口作为管控手段，由于缺少相关分析技术支撑，申请方和审批方对存量&增量情况都缺少清晰一致认知，导致管控逐渐流于形式。与此同时，包瘦身治理优先级降低，前面负责治理的架构同学撤出，虽然架构团队依然负责跟进相关事项，但几乎没有主动投入治理，包大小接近自然状态下的“野蛮生长”。

2018.10 - 2019.02，第二次专项治理。在瘦身效果上，从最高点80MB降低至40MB，瘦身比例50%，除了实践经验的持续积累，在技术手段上呈现出主动探索、初步沉淀几个特征：

• 技术手段。远程化大规模使用：远程Bundle、远程so，几乎所有能远程部分都进行了相关改造；业界瘦身手段尝试：代码系列瘦身（混淆精简、同功能模块统一、无用功能模块下线）、资源系列瘦身（裁减、混淆）、整包瘦身（apk的7z压缩、R文件合并裁减），对其中约一半技术手段进行了应用；单点分析技术探索：主要集中在资源方面，包括无用、重复、相似、大尺寸、无透明度png、图片矢量化、多维度，利用分析结果作为瘦身点改造和分发的输入；

• 治理策略。中心式任务拆解、并行式承接落地；

• 组织形式。集中时间&人力，核心业务基本都参与了进来。

2019.03 - 2020.03，第二次反弹期。在这一时期的管控上，基于虚拟功能组概念（多个模块聚合）建立了包大小卡口能力，但是未能与研发流程有效结合，无法做到及时感知以及关键的超限拦截阻断，同时申请方和审批方缺少对“一个功能/业务，占用多大合理？有多少可瘦身点，分别具体是什么，瘦身空间是多少？”这些关键问题的共识性认知，导致沟通、推进、瘦身改造等成本居高不下，半年之后的管控开始举步维艰。

从增长曲线来看，明显可以分为两段：2019.09之前的6个月时间，属于缓慢增长（虽然中间有一个增长波峰，但很快就得到控制回落），一方面得益于围绕卡口的持续管控，另一方面也因为这段时间没有大型新框架、新能力、新业务接入；2019.10之后的6个月，由于Flutter等新框架的集中爆发式引入，导致包大小出现“疯狂飙升”，在2020.03甚至达到历史最高的126MB水位。

2020.04 - 2020.09，第三次专项治理。在瘦身效果上，最终将包大小降至100MB以下。虽然这次依然是专项模式，但与第二次专项治理完全不同的是：参与团队更广泛，不仅仅是核心业务团队，而是所有客户端团队；牵头同学和参与同学之间的协作方式，由“中心化分配”与“被动完成”（包工队模式），转变为辅助与输出（PVP战队模式），即牵头同学提供更全面、更具体、更具有指导性的分析能力、工具，以及用于降低改造成本和上线风险的各类辅助工具，各团队同学在为自己瘦身目标负责前提下，具有极高的过程自由度，可以集中火力进行瘦身Action的分析制定和执行。另外，这一阶段在技术上的关注点，更多的聚焦到分析&辅助技术，而不是那些能够直接减小包大小的技术：

• 技术手段。分析技术成型：包大小分析工具franky即诞生于此时期，初步实现“对apk大小真实贡献”的分析能力，以及结合模块图谱数据将apk大小拆分到各研发团队，多个可瘦身项检测也逐步沉淀到分析工具中；源头深度瘦身：无论是比较常规的无用和冗余性业务、功能、模块、甚至是方法级代码，还是franky包含的若干可瘦身项，都逐步在源头代码层面，以更细粒度更治本的方式展开；

• 治理策略。中心化拆解，分布式治理。借助分析工具，将瘦身目标逐一拆解到不同团队和业务，各自根据实际情况合理安排人员、方案、进度；

• 组织形式。专项模式，几乎覆盖客户端所有团队和业务。

1.2 常态治理2年：稳重持续降

2020年9月至今（准确的说是1年半多一点），进入常态治理阶段，包大小从期初100MB，逐步降低到2022年3月底的64.9MB（截止本文完成的5月份为64.4MB）。

在这个阶段，包大小卡口能力完成了一次关键进化：与研发流程实现无缝结合，对超限情况实现及时感知，以及拦截阻断，这让整体管控成本得到极大降低。同时，对分析技术、瘦身技术的迭代、探索和应用，始终没有停下脚步：dex排布优化、7z压缩、D8、R8等整体瘦身技术陆续上线，so无用导出符号等可瘦身项持续加入分析工具franky，相关技术也开始得到阿里内部更多app使用，这进一步促进了功能快速发展和丰富。另一方面，治理策略也在逐步完善，客户端各研发团队围绕自己的包大小阈值，把包大小提升为与稳定性、性能一样的日常研发迭代基础考量指标。

治理模式

前面通过术、道、人三个维度对历史进行了回顾，通过对比不难发现它们有着截然不同的特征，据此可以将包瘦身治理分为两种模式：专项式、常态化，前者以短时间快速瘦身为目标，后者以长时间可持续维持为目标（甚至逐步降低）。看到这里，或许会提出一个疑问：治理模式和“术、道、人”三维度有什么关系？如果一定要进行区分，我认为既可以看作不同的思考视角，也可以认为前者是后者的更高层次抽象：“术”的能力所达到的水平，“道”的选择所遵循的原则、“人”的排布所提供的保障，共同决定了当前处于什么样的治理模式；反过来也适用，即治理模式对“术、道、人”的内容和边界，都有明确的要求。 

2.1 专项式vs常态化

专项式治理，一般是在包大小持续上升至某个值后，成立专门项目集中时间治理。一般会有多团队多人员参与，同时会有明确的项目负责人，来制定严格且固定的里程碑。此时的apk包由于经过一段时间积累，会存在较多以无用和冗余功能为代表的可瘦身项，相对容易识别和解决，因此一般瘦身见效快，当然专项结束后如果缺乏有效的可持续管控，包大小反弹几乎是必然的。

专项式治理的“精神内核”是目标优先，这当然没有任何问题，但在这个过程中，往往很容易忽视瘦身改造所带来的其它负面影响，例如不适当的远程化改造会带来用户体验受损、apk构建过程中采用大量“瘦身黑科技”导致打包耗时明显增加等。这里面的取舍和平衡之道，没有标准答案，只有综合判断“此时此地此景”后作出的选择。

常态化治理，是指在长期的版本迭代过程中始终能够控制好增量，并在维持住当前包大小水位前提下实现“稳中有降”。一般在常态化治理阶段，头部问题已经基本不存在，需要在业务功能和代码源头进行更全面、精细、深入的分析和思考，从而在版本迭代过程中逐步“消化掉”可以瘦身的地方。在治理所需人力投入上，具有较低的整体管控投入，并形成团队、业务、功能的开发者自治局面。在治理节奏上，整体包瘦身目标调整周期较长，同时不再进行细粒度的瘦身里程碑制定，采用相对宽松和灵活的方式，把自主权给到具体负责的团队和开发者。

在瘦身效果上，可以较好维持住当前水位而不发生反弹，甚至是缓慢降低。常态化治理的“精神内核”是体验优先，将包瘦身这件事“融入”到日常研发迭代过程，与稳定性（crash/bug等）、性能（启动速度/页面切换/流畅度等）一样，共同成为研发团队（同学）在业务需求和功能之外关注并考量的技术项。

在时间、人力、节奏、效果、精神“内核”这五个纬度上，二者的对比情况汇总如下：

常态化和专项式的关系并非简单的“优于”就能够说清楚，首先二者具有演进关系，类似人类文明的“石器、青铜、农业、工业”等代际进化，常态化治理也是在生产力（分析&瘦身技术）不断提高的情况下，促使生产关系（治理模式）等发生变革（嗯，这个比喻不一定准确）。

其次，二者有着不同的适用情况，专项式治理用于快速降低包大小，而常态化治理用于低成本可持续维持或者缓降。如果app无论与同类竟品还是自身相比，都明显处于较高的包大小水位，那显然需要先通过专项治理将包大小快速降低下去，然后再衔接上常态化治理来获得“长治久安”；如果app已经处于常态化治理模式，但是由于某些原因需要进一步快速降低，那么就需要切换到专项式治理模式，达成目标后再继续回到常态化治理模式。

常态化治理相对专项式治理，更需要当作一个系统化工程来看待，整体治理思路如下：