口红 5年磨一剑|优酷Android包瘦身治理思路全解( 二 )



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) 。

经验总结扩展阅读