稳定性、性能、包大小，在移动端基础用户体验领域“三分天下”，是app承载业务获得稳定、高效、低成本、快速增长的重要基石。其中，包大小对下载转化率、拉新拉活成本等方面的影响至关重要，这在业界已经成为共识，近年来头部app针对下沉市场的极小包策略，更是将包大小的价值提升到了极致。优酷在Android包大小领域，有长达5年的持续投入、实践和积累，尤其是在近2年逐步进入低成本可持续治理的健康状态。现将这些思考、方案设计、技术建设、治理实践统一汇总整理成文并分享出来，希望能够帮助更多同学在所负责或参与的app中，更好的进行包大小治理。
本文聚焦于整体治理思路，以治理实践为依托，讲述瘦身技术、治理模式、治理策略，以及背后的思考与取舍。
五年治理回顾作为开篇，先给出优酷近5年包大小变化情况：
以2020年9月为分水岭，从治理模式角度，可以将前后划分为两个“风格迥异”的阶段：专项治理、常态治理。包瘦身治理也属于一种软件工程，接下来围绕“术”、“道”、“人”三个维度，展开回顾和总结：
1.1 专项治理3年：三次两反弹
自2017年初至2020年9月这3年时间，共经历三次专项治理以及两次反弹。
2017.05 - 2018.03，第一次专项治理。在瘦身效果上，从最高点73MB降低到51MB，瘦身比例约30%，这次瘦身专项的最大价值，是积累了宝贵的实践经验：
- 技术手段。由于当时几乎没有积累，采用的技术手段相对常规且具有单点性，主要包括：分析并下线无用业务/功能模块、远程化边缘业务、图片压缩&矢量化等。
- 治理策略。缺乏整体目标掌控和拆解，对于头部问题进行单点改造。
- 组织形式。比较松散，涉及范围窄，参与人数少。
2018.04 - 2018.09，第一次反弹期。期间使用“模块级”包大小卡口作为管控手段，由于缺少相关分析技术支撑，申请方和审批方对存量&增量情况都缺少清晰一致认知，导致管控逐渐流于形式。与此同时，包瘦身治理优先级降低，前面负责治理的架构同学撤出，虽然架构团队依然负责跟进相关事项，但几乎没有主动投入治理，包大小接近自然状态下的“野蛮生长”。
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）。
在这个阶段，包大小卡口能力完成了一次关键进化：与研发流程实现无缝结合，对超限情况实现及时感知，以及拦截阻断，这让整体管控成本得到极大降低。同时，对分析技术、瘦身技术的迭代、探索和应用，始终没有停下脚步：dex排布优化、7z压缩、D8、R8等整体瘦身技术陆续上线，so无用导出符号等可瘦身项持续加入分析工具franky，相关技术也开始得到阿里内部更多app使用，这进一步促进了功能快速发展和丰富。另一方面，治理策略也在逐步完善，客户端各研发团队围绕自己的包大小阈值，把包大小提升为与稳定性、性能一样的日常研发迭代基础考量指标。
治理模式前面通过术、道、人三个维度对历史进行了回顾，通过对比不难发现它们有着截然不同的特征，据此可以将包瘦身治理分为两种模式：专项式、常态化，前者以短时间快速瘦身为目标，后者以长时间可持续维持为目标（甚至逐步降低）。看到这里，或许会提出一个疑问：治理模式和“术、道、人”三维度有什么关系？如果一定要进行区分，我认为既可以看作不同的思考视角，也可以认为前者是后者的更高层次抽象：“术”的能力所达到的水平，“道”的选择所遵循的原则、“人”的排布所提供的保障，共同决定了当前处于什么样的治理模式；反过来也适用，即治理模式对“术、道、人”的内容和边界，都有明确的要求。
2.1 专项式vs常态化
专项式治理，一般是在包大小持续上升至某个值后，成立专门项目集中时间治理。一般会有多团队多人员参与，同时会有明确的项目负责人，来制定严格且固定的里程碑。此时的apk包由于经过一段时间积累，会存在较多以无用和冗余功能为代表的可瘦身项，相对容易识别和解决，因此一般瘦身见效快，当然专项结束后如果缺乏有效的可持续管控，包大小反弹几乎是必然的。专项式治理的“精神内核”是目标优先，这当然没有任何问题，但在这个过程中，往往很容易忽视瘦身改造所带来的其它负面影响，例如不适当的远程化改造会带来用户体验受损、apk构建过程中采用大量“瘦身黑科技”导致打包耗时明显增加等。这里面的取舍和平衡之道，没有标准答案，只有综合判断“此时此地此景”后作出的选择。
常态化治理，是指在长期的版本迭代过程中始终能够控制好增量，并在维持住当前包大小水位前提下实现“稳中有降”。一般在常态化治理阶段，头部问题已经基本不存在，需要在业务功能和代码源头进行更全面、精细、深入的分析和思考，从而在版本迭代过程中逐步“消化掉”可以瘦身的地方。在治理所需人力投入上，具有较低的整体管控投入，并形成团队、业务、功能的开发者自治局面。在治理节奏上，整体包瘦身目标调整周期较长，同时不再进行细粒度的瘦身里程碑制定，采用相对宽松和灵活的方式，把自主权给到具体负责的团队和开发者。在瘦身效果上，可以较好维持住当前水位而不发生反弹，甚至是缓慢降低。常态化治理的“精神内核”是体验优先，将包瘦身这件事“融入”到日常研发迭代过程，与稳定性（crash/bug等）、性能（启动速度/页面切换/流畅度等）一样，共同成为研发团队（同学）在业务需求和功能之外关注并考量的技术项。
在时间、人力、节奏、效果、精神“内核”这五个维度上，二者的对比情况汇总如下：
常态化和专项式的关系并非简单的“优于”就能够说清楚，首先二者具有演进关系，类似人类文明的“石器、青铜、农业、工业”等代际进化，常态化治理也是在生产力（分析&瘦身技术）不断提高的情况下，促使生产关系（治理模式）等发生变革（嗯，这个比喻不一定准确）。其次，二者有着不同的适用情况，专项式治理用于快速降低包大小，而常态化治理用于低成本可持续维持或者缓降。如果app无论与同类竞品还是自身相比，都明显处于较高的包大小水位，那显然需要先通过专项治理将包大小快速降低下去，然后再衔接上常态化治理来获得“长治久安”；如果app已经处于常态化治理模式，但是由于某些原因需要进一步快速降低，那么就需要切换到专项式治理模式，达成目标后再继续回到常态化治理模式。
常态化治理相对专项式治理，更需要当作一个系统化工程来看待，整体治理思路如下：
由专项式到常态化，首先要做的转变是将关注点从“事”转移到“人”：每一个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）、再到一个独立功能、业务、甚至是团队。由此衍生开来，既然有了度量，那么就可以进行有效的责任归属、瘦身目标制定、效果预估等，是不是豁然开朗？
其次，在具备度量能力基础上，站在长远角度考虑，实际瘦身治理过程中还需要能够回答“这个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）的。根据上面的推导过程，我们来进行提炼和总结：
现在，如果让你来回答以下几个问题，是不是就可以信手拈来，轻松惬意？
- apk为什么这么大，不同模块/业务/团队，分别贡献了多少？
- 每个团队/业务/模块，有哪些可以瘦身的地方，进行删除、优化、改造后，apk能减少多少？
- 在日常迭代中，当前版本相对于上个版本，每个团队/业务/模块增加（减少）大小是多少？
实际上，优酷自研包大小分析工具Franky，几乎完全实现了上述拆解后的需求。只有一点尚未做到：apk中元素，目前还没有做到100%找到模块归属，在优酷apk中的分析覆盖率是99.8% ～ 99.9%（apk 100MB ～ 65MB）。
3.1.1 整体架构
Franky主要由两部分组成：用于application工程的gradle plugin，以及命令行（cli）分析工具。此外，还额外依赖（非必需）两个外部数据：模块图谱数据，用于将模块大小，向上聚合为功能/业务/团队的大小；代码覆盖数据，形成可瘦身项分析中的「代码 - 无用类」（SlimLady：类级别不插桩线上代码覆盖度统计框架[1]）。整体架构如下图所示：
franky-plugin的作用，是在apk构建过程中收集apk所有组成模块，以及模块中包含的各类元素，此外还包含类混淆映射关系、无用资源分析结果。这个分析结果数据与apk文件，共同构成了命令行工具franky（cli）的基础（必需）输入文件。接下来，执行cli命令进行最终的包大小分析， 产出具体的分析报告。
纵观这套方案，可能会有一个疑问，为什么要包含一个构建插件，如果能通过一个命令行（cli）工具直接对apk进行分析，使用更简单还能更具通用性，不是更好吗？这里面有一个非常关键的点在于，只有在apk构建过程中，才能够获取apk由哪些模块组成、每个模块又包含哪些元素，在apk构建完成后的apk文件中，这些信息已经丢失，所以构建插件必不可少。那如果是这样，为什么不把命令行工具的所有功能，都放在这个构建插件中来实现呢？这是一个好问题，目前的考虑是这样的：尽量将构建插件做的比较“薄”，这样可以减少构建耗时，而将主要分析功能放在独立工具，可以独立快速迭代，而不用频繁在app工程中升级plugin版本。
3.1.2 关键技术
分析工具看起来简单，但是为了获取真实大小，以及能够将apk中元素100%进行模块归属，在开发过程中还是会遇到不少棘手问题。
首先，应用于构建过程的plugin如何保障兼容性，并不是一个简单的问题。很多Android Gradle Plugin开发者不太重视兼容性，认为针对特定工程实现相关功能就万事大吉，这里不深入讨论此话题，直接给出franky-plugin考虑并实现的构建环境兼容性，或许更能够对这个问题获得直观的认知：
接下来的核心困难是，参与apk构建的原始元素，与最终apk元素之间，存在转换、新增、删除、不变这四种“变化”情况：
上图给出的是基本“变化”情况，还有一些特殊情况也需要考虑，例如java资源可以“伪装”为其它类型元素、Android资源包含api level大于等于22可用的android:xxx属性，且资源的api配置限定符小于22，导致生成“-v22”资源文件、AAPT内嵌资源生成独立资源文件等。对于删除和不变的元素，处理起来比较简单，转换和新增的处理则相对复杂一些：
- 新增。新增元素最大的问题在于“找到归属”，例如有些java8语法在脱糖后生成新的类。目前franky中基于生成类名称规则的方式，解决了lambda 表达式、默认和静态接口方法的归属情况，但是对于方法引用的生成类则暂时无法找到归属（后面计划通过代码Pattern分析来找归属）。
- 转换。发生转换变化的元素，如果还进行了“合并”处理（例如dex、resources.arsc），此时就需要将元素“拆”出来，核心原则是：拆出来后元素大小之和，等于拆之前文件大小。例如，将class从dex文件拆出来后，大小相加必需等于dex文件大小。这个事情的难度来自于两个方面：
- 各种字符串、类型共享池，需要进行按比例（PSS）分担计算。
- 各种二进制结构数据的Header、Padding，需要进行精准计算和归属。
除了这些变化，还有一个细节也要考虑：apk中各文件的真实大小占用如何计算？apk本质是一个zip压缩文件，其中每个文件均为一个zip entry，zip entry占用大小相加小于apk总大小，因此需要将用于记录每条zip entry的额外大小加进来（Local File Header、Central Directory Record），同时将共享部分进行按比例分担。以优酷为例，apk大小为65MB，zip entry压缩大小相加是63MB（97%），如果不计算额外数据大小，仅在计算apk中元素大小时，就已经损失了2MB的真实大小！
3.2 可瘦身项分析
可瘦身项是指导和评判价值的主要承载者，本章对franky包含的全部9个可瘦身项，讲解基本技术原理、分析效果、用于瘦身时的注意事项等。
第一项【代码】无用类，是指在运行时没有被使用到的类。当前无用代码的获取方法，是通过线上采样的方式，采集代码热度数据，并筛选出其中初始化次数为0的类（具体实现方案来自SlimLady：类级别不插桩线上代码覆盖度统计框架[2]，此处只是使用了前者的结果数据）。对于无用代码较多的模块，存在线上使用率低（或者完全无使用）的问题，应该安排下线或者使用H5等动态化方式实现。分析报告中的示例结果如下：
第二项【代码】未混淆类，是指由于keep规则存在，导致没有被混淆的类。混淆可以极大降低代码在apk中占用的大小，因此除了一些特殊使用场景，绝大部分类都可以进行混淆。对于未混淆类较多的模块，可能存在混淆keep配置过于宽泛问题。分析报告中的示例结果如下：
第三项【资源】超大，是指在apk中真实占用超过一定阀值的资源（可配置，优酷一直使用的是10KB）。超大资源，可以采用远程化、重新设计更小的等效资源、如果是图片还可以采用压缩率更高的图片格式（jpeg、webp）或者矢量图等方式来降低大小。分析报告中的示例结果如下：
第四项【资源】无用，是指没有被直接引用的资源。从资源整体使用情况来看，一个资源可能在三个地方进行直接引用：java代码，通过R.resourceType.resourceName方式引用（例如R.string.app_name），或者通过资源id方式直接引用（例如0x7fxxxxxx）；清单文件AndroidManifest.xml；其它资源。另外，资源还可以通过Resoruces.getIdentifier方式，通过传递资源名称和类型获取id值，运行时性能较差，因此官方并不推荐使用，需要注意的是，分析工具对这种方式会出现误检。对于无用资源，应该在确认未通过Resoruces.getIdentifier方式使用后，进行删除处理。分析报告中的示例结果如下：
第五项【资源】多维度，是指包含大于两个配置的资源。这种资源会在不同配置下，存在多份数据（文件），一些特殊纬度需要做额外考虑，例如：night、land & port。对于多维度资源，一些非必要的配置可以清理掉。分析报告中的示例结果如下：
第六项【资源】无透明度png图片，是指png图片中包含了alpha通道，但是无相关数据，或者数据中的透明度值均为完全不透明。对于这种类型的图片，一般可以通过使用不带透明度信息的其它图片格式（例如jpeg），来降低大小。分析结果中，已经排除了.9类型图片，在分析报告中的示例结果如下：
第七项【资源】相似，是指资源值的相似程度较高。当前分析只包含file-base类型资源（相对的，值仅存在于resources.arsc中的资源，称为value-base类型资源）。对于非图片文件资源，仅筛选出完全一样的资源（md5一致，相似度为1）。对于图片文件资源，额外计算了相似度，采用DHash算法计算图片指纹，然后计算hamming距离作为相似值。对于相似度为1的资源，内容完全一致，因此可以仅保留一份，对于相似度小于1的资源，由于有些图形简单的图片资源特征信息不明显，因此即使相似度较高，是否可互相替代的最终决策，仍然需要根据所在业务场景进行人工判断。分析报告中的示例结果如下：
第八项【so】不规范使用STL，是指动态链接库so对c STL库的不规范使用，包括两种情况：动态链接非统一STL，官方建议统一使用的STL为libc _shared.so，其它非统一STL包括libgnustl_shared.so、libstlport_shared.so；静态链接stl，通过改造为动态链接，可以实现较好的瘦身收益。分析报告中的示例结果如下：
第九项【so】无用导出符号。动态链接库的导出符号(exported symbol)，是指在so内定义的对象、方法、全局变量，被设置为可被外部代码引用（导入）。无用导出符号，则是指在依赖这个so的其它so中（apk范围内），未找到任何引用，当然这里存在以下情况需要特殊处理：JNI方法、通过dlsym方式加载并调用的符号。对于确实无用的导出符号，可以在编译so时设置为不导出。具体操作方式并不唯一，比较建议使用编译选项-fvisibility=hidden，同时显示对需要导出符号增加 attribute ((visibility ("default")))标记这套方案来实现，这样新增符号默认不会导出，不至于出现一段时间没人管，无用导出符号持续累积问题。分析报告中的示例结果如下：
3.3 卡口能力建设
后者在研发迭代过程中，低成本维持常态化治理模式的关键之一，其承载的三个核心价值如下：
去中心，需要能够对apk大小进行适当颗粒度的精准拆分，用于卡口阈值、检测以及不通过时进行拦截。
促前置。包大小和代码规范、bug等单点问题不同，无法通过就地修改来完成瘦身，往往需要通过“拆东墙补西墙”的方式，寻找存量可瘦身空间来弥补新功能带来的增量。所以，只有足够前置才能留出更多时间给瘦身治理，从而保障最终发布到用户手中的apk大小保持稳定。前置要求卡口必须在代码变更后“第一时间”发挥作用，识别到包大小变化，如果超过阈值则进行拦截。这个“第一时间”根据不同app迭代模式差异，选取适当的节点即可，例如优酷的一个版本迭代可以分为“提测-集成-灰度-发布”四个流程节点，那么就选择提测和集成两个节点部署卡口。
低成本。卡口是一个比较模糊的概念，1百个工程师可能会有1百个对卡口具体机制的理解和设计，对于包大小卡口本身一定要具备的是低成本维护，包括以下几个方面：
- 与研发流程结合。包大小卡口不是一套独立的流程，而是要融入到整个研发流程中，尽可能减少额外使用成本。
- 100%覆盖。一定是要对所有可能的增量来源，都能够覆盖到，不能存在某种方式，可以绕过卡口机制。一旦被绕过，会拉高后续的识别&治理成本。
- 100%自动化。这一点看起来有点像废话，卡口难道还能手动执行？现实情况是，有些场景下所谓的“卡口”，其实自动化程度较低，还需要不小的人工参与。
优酷在2018年就建立了包大小卡口能力，后续的演进和调整都是朝着更贴合上述核心价值的方向进行，直至2021年初才达到稳定有效的成熟状态。包大小卡口由分析工具franky、卡口能力平台、研发流程管控平台（CI/CD平台）三部分组成，示意图如下：
研发在使用流程（CI/CD）平台进行提测和集成时，都首先需要触发apk构建，franky-plugin作为包大小分析工具在构建期的一款gradle插件，会收集数据并将结果输出到构建产物。接下来，流程平台中的卡口插件负责收集apk和franky-plugin生成的文件，并上传到卡口平台备用。
之后，流程平台会执行准入检测，其中包大小卡口检测会触发能力平台中的包大小分析任务，通过调用franky对应的命令行工具，生成json格式的包大小分析报告。通过解析分析报告，并与预先设置的团队阈值和Buffer值进行对比，以此判定提测/集成单中包含模块所在的团队（1个或多个）是否超限。流程平台中的准入检测在获取检测结果后，通过或者阻断提测/集成流程。如果卡口未通过，可以通过进行瘦身改造来使卡口通过，但这一般无法在当前版本完成，这时可以申请带时限的Buffer来临时通过卡口，从而完成提测/集成。
瘦身技术前面讲了很多治理模式相关内容，看起来可能有些抽象，接下来会回到具体的瘦身技术，侧重点不在于深入技术原理和实现细节（大多会给出参考链接），而是尝试将每一项瘦身技术的优缺点进行一次概括性讲解和巡展，便于形成一个整体认知，在对具体app进行瘦身时，能够根据实际情况进行选择和优先级安排。瘦身技术，顾名思义，就是指可以用于包瘦身的任何技术（方案），按照所需技术、生效阶段、影响范围综合评判，将其划分为以下三种类型：
4.1 远程化
远程化是指将原本在apk中的功能，剥离出来放到服务器，app运行时进行下载、加载等一系列动作后，才能够正常使用功能的一种技术方案，其核心特点可以归纳为“本地剥离，远程下载”。远程化瘦身效果显著，也因此容易为了追求瘦身结果而被过度使用，但这并不是远程化本身的原罪，实际上一些边缘、非核心、实验性业务，都比较适合进行远程化改造。远程化框架涉及的关键技术，在业内已经有很成熟的解决方案，但是具体到代码实现，还是有不少需要仔细思考和反复打磨的地方，例如：apk构建体系的兼容性是否足够广泛，远程化改造的代码限制和改造难度是否足够低，app唤端、多进程、用户磁盘占用、下载线程占用、apk升级复用、下载带宽成本等。
按照远程化元素类型，以及业界普遍使用情况，将其分为远程so、远程bundle、远程资源三种。
首先来看远程so。动态链接库so与其它代码的耦合度低，在apk中具有较强的独立性，同时占用apk体积相对较大，因此单独将so进行远程化往往具有很高的瘦身投入产出比。
第二种远程bundle，一般是指可以完整的将一块功能进行远程化，远程部分相当于一个迷你apk（dex、resource、so）。远程bundle相关技术“历史悠久”，动态化、插件化、组件化等虽然有语境、功能以及设计思想上的区别，但在技术上有着很多相似的地方，随着新版本os加强了对系统API调用、拦截和替换等方面限制，这个领域的主流技术方案逐渐演变为对系统侵入越来越轻量的方向。相对于远程so，远程bundle在实现上要复杂很多：在运行时阶段，虽然对系统API的侵入性比较小，但是对唤端、组件路由跳转、后台Activity销毁重建等情况依然需要小心处理；在构建阶段，由于要“分离”出一个迷你apk，因此对构建体系的兼容非常困难，目前业界有一些同类框架，很多时候并不是运行时无法满足需求，而是在构建侧无法做到很好的兼容性和易用性。
最后一种远程资源，是指针对资源文件的远程化。可以通过将资源上传到文件托管平台，获取文件url后直接下载并使用（优酷采用的就是这种方式）。远程资源的实际应用场景较少，投入产出比也不高，所以目前优酷没有专门研发一个这样的框架。当然，如果有大量资源需要进行这种远程化改造，那可能有必要开发一个专用框架。
4.2 整包瘦身
整包瘦身，是指在apk构建阶段整体进行处理的一类瘦身技术，对全部apk元素均可生效（包括无源码的二、三方sdk），新增代码也可以立刻得到同样的处理，其核心特点可以归纳为“中间拦截，整体生效”。也正是由于上述特点，这类瘦身的影响范围较广，因此在首次应用到app时，如何控制好验证成本和线上风险变得非常关键，当然在瘦身效果上，一般可以立竿见影的获得较大收益。自定义的一些整包瘦身方案，往往容易出现处理逻辑考虑不周全而导致的稳定性问题，注意这不属于技术方案本身的特点，而是具体实现代码的问题。在工程效能方面，对代码质量无影响，构建耗时则一般会有增加，有些整包瘦身技术会改变apk中目标元素形态，因此对各类相关问题分析会带来一定程度的效率降低。
这里划分了14项整包瘦身技术，其中Android官方没有提供的能力，都已经沉淀到了优酷自研gradle plugin中，目前正在开源筹备中。
- 【代码】Proguard/R8。利用Proguard工具，对java代码进行裁剪、混淆、优化处理，从而实现无用代码删除、符号（类、变量、方法）混淆、代码逻辑优化，包体积降低效果非常显著。值得注意的是，google官方已经在近几年的Android Gradle Plugin中，使用自研的R8替代了java领域传统的Proguard工具，裁剪和优化效果更为强大，进一步压缩包大小的同时处理耗时更低，优酷从proguard切换到R8后，包大小降低约4.8%（3.2MB），构建耗时降低约25%（2min），当然这也和原progaurd的全局配置有关，尤其是优化次数-optimizationpasses。
- 【代码】D8。在apk构建过程中，java代码需要经历由jvm字节码到dalvik字节码的转换处理，DX/D8就是承担这个责任的工具。在优酷的具体实践中，由DX升级到D8后，包大小降低约9.5%（9.7MB），由于额外对dex合并进行了优化，dex数量降低，导致包大小收益出现一次跃升，因此比官方给出的Benchmark收益5%要更高。
- 【代码】R类合并。将所有<模块package>.R类移除，并将java代码中对前者的引用统一替换为.R类，以此来降低包大小的一种技术手段。在优酷当前情况下（模块800多个，dex24MB），R类裁剪可以减少80万个java类Field，带来近5MB包大小收益。由于每个dex中Field数量也受到65536限制，因此Field数量大幅减少所带来的dex数量减少，是瘦身收益的主要来源。进一步，可以把所有java代码中R..的引用，也全部替换为对应id值，这样.R类也可以删除，但是在已经完成R类合并的情况下，这个处理的收益比较有限，因此优酷并没有实际投入研发和使用，但是如果追求极致瘦身确实可以这么做！
- 【代码】Dex排布优化。Dex排布优化是指通过合理安排dex中包含的类，从而尽可能减少常量池冗余度以及dex数量，进而降低dex整体大小的一种瘦身技术。由于历史原因，Dalvik字节码中调用method和field指令的操作数是16位，因此一个dex中method和field数量上限均为65536，而现代app一般都会包含多个dex，dex数量过多会导致各类常量池冗余度变高，从而导致包大小增加。事实上，Dex排布优化不仅可以用于降低包大小，还可以通过选择不同的优化策略，来提升app运行时的性能，Facebook的Redex即是这一领域的著名开源框架。优酷并没有使用复杂的排布优化策略，而是自定义了简单的Dex合并能力，获得了约2MB左右的包瘦身收益。
- 【代码】字节码指令精简。准确的说这并不是一项瘦身技术，而是一类瘦身技术的集合。通过更精细的字节码上下文分析，以删除、合并、转换等方式精简指令序列，从而达到瘦身目的，例如删除冗余赋值指令（值与类型默认值一致）、access$xxx方法消除（修改private方法为public，避免access方法生成）、常量/短方法内联等等。不知道大家是不是会有个疑问，proguard/R8没有进行这些处理吗？这些“民间”自定义的字节码指令精简方案，可以看作是对前者的一种“极致性”扩展，因为前者在进行字节码优化时对正确性的要求极高，如果有些优化策略存在风险，或者违背原代码设计意图（比如修改private方法为public），那么就不会应用。当需要使用自定义的字节码指令精简之前，建议先把proguard/R8各种优化配置选项研究透彻并充分应用，可能你会发现通过配置就可以实现同样效果，并且处理过程更稳定、高效、可信，如果不得不走到需要进行自定义处理的境地，也一定要谨慎使用。
- 【资源】无用资源裁剪。ShrinkResources[3]是Android官方提供的无用资源裁剪功能，在apk构建时直接对无用资源进行删除。在app中除了通过http://R.xxx.xxx/0xffxxxxxx显式引用资源，还可以通过Resources.getIdentifier在参数中指定资源名称来引用，由于后者可以拼接甚至是动态下发字符串，因此会导致此类资源的引用关系无法被准确获取，对此ShrinkResources提供了两种模式：严格模式、正常（默认）模式。严格模式仅考虑显式引用关系，正常模式则会采用“安全优先原则”，如果资源名称以任何java代码中的常量字符串为前缀，那么会被标记为疑似引用而无法得到删除，还有其它几种“疑似性标记逻辑”不再列举。
- 【资源】多维度（备用）资源裁剪。Android资源可以配置不同维度，从而在运行时灵活适配各种不同情况（语言、屏幕尺寸、屏幕横竖状态、os版本等），这里的多维度（备用）资源裁剪，就是在apk构建期将不需要的维度裁剪掉，AndroidGradlePlugin提供了对应功能，通过android DSL配置（resConfigs）[4]即可直接完成。自研代码一般只会包含需要用到的资源，而二、三方sdk为了提高兼容性会包含尽可能多的维度，在优酷实践中对语言维度进行了裁剪（仅保留中文），瘦身收益约3%（2MB）。
- 【资源】图片压缩。图片压缩，是指在apk构建期批量对图片进行压缩，或者格式转换的一种瘦身技术。优酷自研turbo-plugin中包含了这项功能，在处理上的考量包括：提供配置项对压缩质量（quality）进行设置，这决定了压缩率（图片有损程度）；有些图片压缩后，尺寸反而会变大，通过检查压缩结果，当发现这种情况时对这些图片不使用压缩。在优酷实践中，图片压缩带来的瘦身收益约0.8MB，收益较低的原因，主要是有很多模块中的图片，提前已经进行了压缩处理。
- 【资源】resources.arsc压缩。resources.arsc文件在Android原生构建流程中不会进行压缩，而运行时os识别到resources.arsc被压缩后，存在兼容逻辑对其进行解压处理，所以可以通过压缩resources.arsc来进一步降低包大小。需要注意的是，os在运行时解压缩resources.arsc会导致资源查找耗时增加，官方也不建议这么做，并且当apk的targetSdkVersion大于等于30时，无法在Android11[5]及以上设备中安装。
- 【资源】去重。对于值相同的不同名资源仅保留一份，删除重复资源并将所有引用到的地方替换为保留下来的资源。和ShrinkResources一样，在应用这项技术时依然需要注意，通过Resources.getIdentifier以资源名称作为参数方式使用到的资源，不能进行去重处理。优酷曾经使用到了这项技术，瘦身收益在MB级别，现在已经通过对应的「单点瘦身」方案，在源码层面直接处理。
- 【资源】混淆。和java代码Proguard混淆类似，是通过缩短资源名称以及文件类型资源存放路径，实现包瘦身的一种技术方案。AndResGuard[6]是实现这项瘦身技术的一套开源框架，功能相对成熟且完备，后来也有些一些同类框架在基础的资源名称缩短之上，又进一步对resources.arsc、xml资源等进行了更精细化的瘦身处理，具体可以参考相关公开文章。在应用这项技术时，依然需要注意处理Resources.getIdentifier带来的问题。
- 【so】debug信息裁剪。debug信息裁剪，是指将so中携带的debug信息删除掉，这并不会影响so正常功能，只是会导致无法源码调试so。在Android官方apk构建过程中，默认有一项StripDebugSymbol的处理逻辑，正是用于对debug信息进行裁剪，之所以作为一项整包瘦身技术放在这里，是因为如果构建环境中未包含NDK（或者NDK未在可识别路径），那么这项处理就不会执行，但是apk还可以正常生成，这一点需要特别注意。
- 【so】abi分包。abi（application binary interface）是指应用二进制接口，不同Android设备使用不同的CPU，而不同CPU支持不同的指令集，CPU与指令集的每种组合都有专属的应用二进制接口 (ABI)。在Android生态中arm CPU是绝对主流，指令集按支持的CPU（指令寻址）位数可分为32位（armeabi、armeabi-v7a）和64位（arm64-v8a）两大类，32位设备只能运行32位的so，64位设备既可以运行32位so也可以运行64位so。虽然目前市场中64位设备已经成为绝对主流，但32位设备也还没到可以舍弃的量级，因此apk如何同时支持64和32位设备就成了一道选择题：合包，即apk中同时包含32和64位两套so；分包，即分为32位和64位两个apk，各自仅包含一套对应的so。显然，后者可以极大减小包体积，但也会带来app分发的一些问题，需要辅以额外处理逻辑。对于分包方案，在apk构建时应该保障一次构建直接生成两个分包的方式，这样可以避免多次构建不一致带来的32位和64位包代码差异问题。
- 【apk】7z压缩。7z是一种压缩格式，同时也是一个压缩工具。这里的7z压缩是使用7z工具替代Android工具链，使用可以被Android系统所兼容的压缩算法，对apk中（本质就是一个zip文件）原本就会压缩的文件进行效果更好的压缩处理，从而实现瘦身的一种技术方案。由于并未改变apk元素内容值本身，因此基本无需验证即可稳定上线使用。在优酷的实践中，包大小降低约4%（3.5MB）。
4.3 单点瘦身
单点瘦身，是指在源代码层面，通过去除无用、合并冗余、修正不合理等方式实现瘦身，其核心特点可以归纳为“源头处理，轻爽健康”。由于需要在源码级别操作，因此只能针对有源码工程的自研代码，对于无源码的二、三方SDK则无法实施（其实也可以在字节码层面改造sdk，非常规方案）。另外，之所以称为“单点”瘦身，是因为需要对每一个具体的可瘦身点进行改造、验证并上线，因此最好是对代码最熟悉并负责的同学直接上手改造，这类瘦身的应用难度整体较低，但是涉及研发同学范围很广，改造周期通常也非常之久，同时在瘦身效果上一般会比较缓慢。
这里划分了9个单点瘦身技术，在优酷自研的包大小分析工具中，均实现了对应的检测分析能力，具体可以参考前文「分析技术」章节，这里简单列出：
- 【代码】线上无用类
- 【资源】超大
- 【资源】无用
- 【资源】多维度
- 【资源】无透明度png图片
- 【资源】相似
- 【so】静态链接C STL
- 【so】链接非标准C STL
- 【so】无用导出符号
另外，无用和冗余的去除，本身就是一种代码质量的提升，也可以明显降低工程腐化程度，同时对构建耗时也会有正向收益。
还能做些什么包瘦身是移动app领域长期存在的一个工程问题，无论是否关注和治理，其影响始终客观存在。接下来聊聊一些相关的思考，希望能够给感兴趣的同学带来一些有价值的参考和启发。
5.1 决心
任何新需求迭代几乎不可能做到0代码增加，因此包大小天然是一个与代码增量“对抗”的事情，但又不像稳定性、性能一样可以产生立即、直接的影响，所以在写代码时很容易被忽视。如果包瘦身的重要性并没有在app全开发团队上下，获得一致性的认可以及足够的决心，即使相关技术、卡口能力、治理策略再怎么完善，也无法在这场“包瘦身持久战”中始终利于不败之地。
前文所属的常态化治理模式下，各种技术支撑以及治理策略，究其本质都是为了将“对包大小的考量”融入到每一名研发同学的代码思维中，这样才能够在coding阶段就尽可能减少包大小不友好代码的产生。“不产生”比“产生了再治理”，在对研发同学技术能力的要求上，恐怕要高出不止一个段位。在追求卓越工程师的路上，不妨把代码对包大小的影响也纳入进来吧。
5.2 以包大小为支点
“穷则独善其身，达则兼济天下”，当包瘦身治理已经处于良好的常态化治理局面时，由于包瘦身本质还是对app工程中不合理代码的改进，因此不妨以包大小为支点，撬动用户体验、工程（代码）质量等其它方面的提升。各种以瘦身作为“导火索”的代码清理、优化、改造，实际上是对app整体工程和代码健康度的有效提升，也是促使业务间功能复用的重要推动力量。而这些代码和业务功能设计层面的提高，长期来看也会对app稳定性、性能、研发效率等的全面提升，具有很好的促进作用。
5.3 探索实践永不止步
虽然优酷的包大小治理，已经处于可持续的常态化治理模式，但瘦身相关的技术探索，以及现有技术的完整落地实践，还没有到结束的时候。很多存量技术问题仍有待挖掘，例如：对于动态链接库so的检测分析技术，还有不少可以探索的方向；对于混淆规则精简，如何能够提供更有效的辅助工具，进一步降低分析、改造、验证的成本和风险，也是一件很有挑战的事情；对于各种中间件，如何能够作出对包大小更友好的设计和迭代，这也已经超出个人、单个组织所能够完成的范围，但是如何能够对此带来更好的影响和改变也值得思考。新技术的趋势和影响也需要及时关注：AndroidX包含的新组件、新开发模式，各种手机厂商的特色能力sdk不断引入等等，都会带来新的机遇和挑战。
参考文档：[1]https://baijiahao.baidu.com/s?id=1661744084264876433[2]https://baijiahao.baidu.com/s?id=1661744084264876433[3]https://developer.android.com/studio/build/shrink-code#shrink-resources[4]https://developer.android.com/studio/build/shrink-code#unused-alt-resources[5]https://developer.android.com/about/versions/11/behavior-changes-11#compressed-resource-file[6]https://github.com/shwenzhang/AndResGuard/blob/master/README.zh-cn.md
作者 | 谦风
原文链接：http://click.aliyun.com/m/1000346560/
本文为阿里云原创内容，未经允许不得转载。
,
