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

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

由专项式到常态化，首先要做的转变是将关注点从“事”转移到“人”：每一个Byte都是由人（开发者）添加的，对产生的原因（技术、流程、心理等）进行全面分析，并给出有效解决方案，才能够实现专项式到常态化的跃变。这个解决方案，主要包括技术支撑、治理策略两方面，二者相辅相成缺一不可。
2.2 技术支撑
整个技术支撑体系的核心是包大小精准分析，即对apk内任意实体元素（类、资源、so等）获取其在apk文件中实际占用值。因为编译过程会进行各种合并、裁剪、优化、格式转换等，同时apk中不同类型元素的压缩率也不相同，如果使用原始大小作为度量标准，会在包大小治理的整个链路引入较大误差，导致难以抓住瘦身重点，也无法提前精准预判瘦身效果，这对常态治理过程具有非常大的负面影响。
第一点可瘦身项，是指类、资源、so等元素中的“不合理”项，对其进行改造或优化就可以降低包大小。这些可瘦身项细碎并且不易被人工发现，但是累积起来却不容小觑，通过工具化的分析能力可以快速找出这些可瘦身项，一方面提供瘦身指导：为逐步降低包大小提供更多“方向”和“空间” ，另一方面用来评判：一个功能/业务/团队，在这段时间内减少/增加了哪些可瘦身项，当前是否已经瘦无可瘦。
第二点归属聚合，是指将apk大小拆解到有效的责任实体，根据app涉及到的研发团队和迭代模式不同，责任实体可以是组织结构中具体的团队，也可以是业务/功能/模块负责人。总之，拆解的目的是明确责任，即团队/业务/功能/模块对apk大小的“贡献”分别是多少。
第三点研发流程，是代码上线的“必经之路” ，在这个过程中需要具备及时的增量感知，以及超限后的拦截阻断能力。只有这样才能实现低（人力）成本持续管控，另外这也是去中心化策略的重要技术支撑，可以避免很多低效的增量定位排查、沟通、跟进等工作。
第四点辅助工具，是为研发同学对代码进行瘦身提供一系列切实有效的工具，用来提高效率以及降低风险。目前在优酷已经沉淀了引用分析、代码归属/热度分析、模块下载/版本号同步查询对比、progaurd对比（mapping、usage）分析、apk信息查询/对比/反编译等共计十几项工具。
上述技术支撑体系在具体实现上，主要由“分析工具”和“包大小卡口能力“承载，后面会做具体介绍。
2.3 治理策略
常态化治理模式下，治理策略的核心是去中心化。尤其是对于多团队参与研发的app ，对每个功能最熟悉的人一定是日常直接负责的（团队）同学，因此最高效的方式其实正是“各家自扫门前雪”的分布式治理模式。其中阈值划分，是实现分布式治理的第一步，即圈定“每家所负责的范围，以及最多允许存在多少雪” 。而灵活协作，目的是打造合理、公开、透明、高效、低成本的可持续治理局面，在为业务增长和创新提供更多包大小空间的同时，将整包大小控制在预期范围内。
分析技术分析技术，是秉承Byte级“较真儿”精神，以包大小真实占用为指导原则，公平公正童叟无欺，实现对不同颗粒度（元素、功能、业务、团队）的包体积占用度量，并在此之上提供切实有效的可瘦身项分析能力，用于指导和评判瘦身情况。先来回答一个问题：分析工具为什么很重要，很重要？
首先，既然要进行包瘦身，那么各种不同的“大小”就如影随形，例如：“xxx模块多大？”、“xx功能/业务占多大”、“最新版本apk相对上个版本增加了1MB ，不同功能的变更带来的大小变化分别是多少？”、“我今年的目标是将apk减少10MB ，可以通过哪些瘦身Action来达成目标？” 。工程领域有几句著名论断：“无度量不改进”、“无度量不管理” ，包大小分析工具的核心价值之一就是提供这个度量：各种不同颗粒度的度量，小到一个java类、资源、so ，继而到一个模块（jar/aar）、再到一个独立功能、业务、甚至是团队。由此衍生开来，既然有了度量，那么就可以进行有效的责任归属、瘦身目标制定、效果预估等，是不是豁然开朗？