包体积优化-包体积监控

包体积监控

关于包体积，如果一直放任不管，几个版本之后就会给你很大的 “ 惊喜 “。我了解到一些应用对包体积卡得很紧，任何超过 100KB 的功能都需要审批。对于包体积的监控，通常有下面几种：

对于包体积的监控，通常有下面几种：

• 大小监控。这个非常好理解，每个版本跟上一个版本包体积的对比情况。如果某个版本体积增长过大，需要分析具体原因，是否有优化空间。
• 依赖监控。每一版本我们都需要监控依赖，这里包括新增 JAR 以及 AAR 依赖。这是因为很多开发者非常不细心，经常会不小心把一些超大的开源库引进来。
• 规则监控。如果发现某个版本包体积增长很大，我们需要分析原因。规则监控也就是将包体积的监控抽象为规则，例如无用资源、大文件、重复文件、R 文件等。比如微信使用 ApkChecker 实现包体积的规则监控。 包体积的监控最好可以实现自动化与平台化，作为发布流程的其中一个环节。不然通过人工的方式，很难持续坚持下去。

Apk 瘦身如何实现长效治理（防止劣化）？

1、发版之前与上个版本包体积对比，超过阈值则必须优化

在大型项目中，最好的方式就是结合 CI，每个开发同学在往主干合入代码的时候需要经过一次预编译，这个预编译出来的包对比主干打出来的包大小，如果超过阈值则不允许合入，需要提交代码的同学自己去优化去提交的代码

2、推进插件化架构改进

针对项目的架构，我们可以做插件化的改造，将每一个功能模块都改造成插件，以插件的形式来支持动态下发，这样应用的包体积就可以从根本上变小了。

配合 CI，监控上个版本的包

如何统计 apk 每个库的大小？

CI 监控每个版本包体积的变化

增量自动分析

通过将包分析能力的工具集成到打包脚本，在每次包构建成功时，也会同步产出基础的包内容信息，再通过进一步的分析后获得包中每个文件/模块的大小情况。当代码改动触发重新打出新包后，文件/模块通过一一对比的方式，找出哪些有新增，哪些被删除，哪些内容发生变动，以及变动产生的大小，并产出对比报告邮件。通过这样的方式让开发对代码增量有一个直观感受。
如何让包增量分析工具能在日常开发中持续稳定发挥作用呢？需要增量卡口设计

增量卡口设计

在之前，包大小差异通常都在拉出集成分支，打出版本 release 包时才发现，经常会震惊于这个版本的包又比上一个版本要大几 M，然后再紧急去寻找是什么需求集成导致的巨大增量。但这时发现包大小的问题已经非常滞后了，版本马上就要发布，这个时候即使抓到了剧增的源头，也很难在短时间内进行优化。
因此需要增加需求集成卡口，测试通过后在合入主分支之前，经过包增量确认再集成，而不是在集成后打出 release 包时。现在的做法如下，开发只需要提交代码，即可自动获得包增量分析报告。
其中包增量对比邮件内容，会包含与主分支最新构建、当前分支前一次构建，当前分支最初一次构建包的包大小和增量的对比结果。此外为了数据的准确性，需要开发在拉出开发分支后先构建一个基准包，并在提测和集成前合并一把主干，这样报告数据才会更准确。
最后是提测部分，开发同学发送提测邮件时需要标注本次提测包增量及图片压缩情况，若需求增量大于 100 K，根据超出范围情况，需要备注原因和老板确认。bug 修复期间不免也会有代码改动，在测试完成后集成前，会再确认一次包增量情况再集成。

提交时做图片大小检查

• 提交的图片大于 30 K，给个企微提醒
• 本地编译不过