1.1专项治理年：三次两反弹
自年初至00年9月这年时间，共经历三次专项治理以及两次反弹。.05-.0，第一次专项治理。在瘦身效果上，从最高点7MB降低到51MB，瘦身比例约0%，这次瘦身专项的最大价值，是积累了宝贵的实践经验：技术手段。由于当时几乎没有积累，采用的技术手段相对常规且具有单点性，主要包括：分析并下线无用业务/功能模块、远程化边缘业务、图片压缩矢量化等。治理策略。缺乏整体目标掌控和拆解，对于头部问题进行单点改造。组织形式。比较松散，涉及范围窄，参与人数少。.04-.09，第一次反弹期。期间使用“模块级”包大小卡口作为管控手段，由于缺少相关分析技术支撑，申请方和审批方对存量增量情况都缺少清晰一致认知，导致管控逐渐流于形式。与此同时，包瘦身治理优先级降低，前面负责治理的架构同学撤出，虽然架构团队依然负责跟进相关事项，但几乎没有主动投入治理，包大小接近自然状态下的“野蛮生长”。.10-.0，第二次专项治理。在瘦身效果上，从最高点80MB降低至40MB，瘦身比例50%，除了实践经验的持续积累，在技术手段上呈现出主动探索、初步沉淀几个特征：技术手段。远程化大规模使用：远程Bundle、远程so，几乎所有能远程部分都进行了相关改造；业界瘦身手段尝试：代码系列瘦身（混淆精简、同功能模块统一、无用功能模块下线）、资源系列瘦身（裁减、混淆）、整包瘦身（apk的7z压缩、R文件合并裁减），对其中约一半技术手段进行了应用；单点分析技术探索：主要集中在资源方面，包括无用、重复、相似、大尺寸、无透明度png、图片矢量化、多维度，利用分析结果作为瘦身点改造和分发的输入。治理策略。中心式任务拆解、并行式承接落地。组织形式。集中时间人力，核心业务基本都参与了进来。.0-00.0，第二次反弹期。在这一时期的管控上，基于虚拟功能组概念（多个模块聚合）建立了包大小卡口能力，但是未能与研发流程有效结合，无法做到及时感知以及关键的超限拦截阻断，同时申请方和审批方缺少对“一个功能/业务，占用多大合理？有多少可瘦身点，分别具体是什么，瘦身空间是多少？”这些关键问题的共识性认知，导致沟通、推进、瘦身改造等成本居高不下，半年之后的管控开始举步维艰。从增长曲线来看，明显可以分为两段：.09之前的6个月时间，属于缓慢增长（虽然中间有一个增长波峰，但很快就得到控制回落），一方面得益于围绕卡口的持续管控，另一方面也因为这段时间没有大型新框架、新能力、新业务接入；.10之后的6个月，由于Flutter等新框架的集中爆发式引入，导致包大小出现“疯狂飙升”，在00.0甚至达到历史最高的16MB水位。00.04-00.09，第三次专项治理。在瘦身效果上，最终将包大小降至MB以下。虽然这次依然是专项模式，但与第二次专项治理完全不同的是：参与团队更广泛，不仅仅是核心业务团队，而是所有客户端团队；牵头同学和参与同学之间的协作方式，由“中心化分配”与“被动完成”（包工队模式），转变为辅助与输出（PVP战队模式），即牵头同学提供更全面、更具体、更具有指导性的分析能力、工具，以及用于降低改造成本和上线风险的各类辅助工具，各团队同学在为自己瘦身目标负责前提下，具有极高的过程自由度，可以集中火力进行瘦身Action的分析制定和执行。另外，这一阶段在技术上的