腾讯|5年磨一剑｜优酷Android包瘦身治理思路全解( 二 ) VR|马晓轶|社交

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水位。
【腾讯|5年磨一剑｜优酷Android包瘦身治理思路全解】
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）。