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的分析制定和执行。另外,这一阶段在技术上的