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

其次，在具备度量能力基础上，站在长远角度考虑，实际瘦身治理过程中还需要能够回答“这个app是不是已经瘦到极限，还有哪些地方可以瘦身？”
分析工具需要具备的另外两个重要价值是：指导和评判。这二者其实是一个事务的不同视角，即：对主动者给予指导，对被动者给予评判，在瘦身前用于指导，在瘦身后用于评判。

一个满足有效的度量、指导和评判需求的包大小分析工具，该具备怎样的自我修养，这就是本章所要探讨的内容以及会给出的答案。在优酷，这个Android端包大小分析工具的名字是franky ，潦草诞生于2020年初，逐步迭代完善/增强至今已2年有余，趋于成熟，仍在前行，目前正在筹备开源中，希望能给Android包瘦身治理带来一些帮助。
3.1 方案设计
本章将围绕“度量、指导、评判”这几个核心价值进行方案设计。首先不妨采用问答的方式，来进行具体分析和拆解的推导过程。
度量的对象是谁？度量的值又是一个什么样的值？在包瘦身不同场景，关注的对象也不一样，颗粒度最细的是apk中各种元素（java类、java资源、十几种不同类型的Android资源、动态链接库so），再往上层的是模块（jar/aar），继续往上层则是功能（由多个模块组成的独立完整功能）、业务（由多个功能组成的完整业务）、团队（组织架构中一个团队负责的所有业务），再继续往上就是apk了（这个没有什么意义，一个文件的大小根本不用什么分析工具），当然一个小型app可能在模块之上仅需要一层功能聚合就足够了。至于度量的值，则是在apk中的真实大小占用，即删除后apk可以减少的大小，对于某些元素原始大小和对apk大小的真实占用之间，存在着非常大的差距，这个差距会导致对瘦身Action的效果评估出现不可忽视的误差，从而使瘦身Action的优先级排序、指导和评判失去根基。由此得到“度量”的需求拆解结果是：提供元素、模块、功能等不同颗粒度，在apk中真实占用大小的度量。
指导的内容有多具体？评判的依据又是否公平、透明？瘦身的指导，如果只提供一个大概的方向，是远远不够的，需要非常明确、具体、可操作。举个例子：如果我只告诉你“充分利用proguard ，精简优化keep规则，让更多的类被裁减和混淆，就可以有效瘦身” ，那么如何让参与app开发的所有同学，都能够据此高效的完成这项瘦身任务？但是如果能够给出“你负责的业务/功能/模块，类未混淆率是80% ，数量是600个” ，相比前者显然更具有指导性，更进一步，假设还能够给出“每个未混淆类，是被哪些keep规则所影响” ，是不是实际瘦身过程变得更加有迹可循，相信任何一名开发同学都能够很好的完成这项工作。再举个例子：“缩减或远程化大尺寸图片，可以有效瘦身” ，与“你负责的这个模块，对apk真实大小占用超过10KB的图片，一共有10个，分别是xxxx” ，这二者相比显然后者更具指导性。再来说说瘦身的评判，不能依靠人的能力和判断力，这样很难做到公平、透明，需要通过可量化的数据作为依据。由此得到“指导评判”的需求拆解结果是：提供明确、具体、可量化、可操作的可瘦身项分析，用于对瘦身过程进行指导和评判。
此外，还有两个非常现实的问题，也不可避而不谈。分析覆盖率（能够找到模块归属的元素大小之和，占apk大小的百分比）能够做到多少？对于分析覆盖率，理论值就应该是100% ， apk构建过程没有magic ，所有在apk中存在的元素皆有来源。当一个元素（比如资源、so）被多个模块（这里的模块是广义上的模块，例如app工程、subproject工程）包含时，这个元素归属到每个模块的大小怎么计算？从公平的角度，多模块包含的重复元素，归属到每个模块的大小应该是等比例分担（Proportional Set Size）的。根据上面的推导过程，我们来进行提炼和总结：