本文介绍了58同城在aar包大小统计监控的实践。
《春晓 》
春眠不觉晓，处处闻啼鸟。
夜来风雨声，花落知多少？
-孟浩然
背景
随着业务版本不断的迭代，apk变得越来越大，每个版本上线后需要产出各个业务所占大小分析报告，以便实现对各业务包大小增长曲线的监控，方便为减少包大小提供有力依据，目前业内并没有一个很好的办法计算aar在apk中的大小。为什么不直接看AAR文件大小？因为aar中可能包含多架构so，实际应用并不会使用多架构so。
问题
由于58app可以通过全aar依赖，app工程只是一个壳工程，所以我们可以获取依赖树后在一个demo工程中依赖待计算的aar，然后计算依赖前后的大小差产出aar大小，但如果待计算的AAR有pom依赖其他AAR时，移除pom依赖后可能由于资源缺失导致打包失败。这时便无法计算出指定aar在apk中所占大小。
这里的资源缺失包含两个问题：一是图片等资源的缺失，二是清单文件中的placeholder的缺失。
解决方案
从报错日志可以看出，如果缺失资源aapt2在执行link过程中会报资源找不到，由于我们只是想计算出aar在apk中所占大小，并不关注产出的apk能否运行，所以我们可以通过修改aapt2源码在资源找不到时统一修改为从demo工程查找固定名称的资源，如果我们在编译时出现报错无法找到相关资源时，只需要在demo工程创建同类型的固定名称占位资源(ids.xml)即可。关于aapt的编译请查看自己动手编译全平台aapt
关于第二个问题清单文件中的placeholder的缺失，可以通过修改gradle插件源码，给placeholder指定固定值来解决。
在Demo工程中配置需要的cpu架构和远程仓库，然后在Demo工程中先打出一个基础apk并获取大小，再将aar依赖添加到Demo工程中获取对应aar包的大小。为了简化这一流程可以先获取原工程的依赖树后，在Demo工程通过使用Python脚本自动化。
业务的独有依赖
由于实际情况是根据业务来统计大小的，通过依赖树并不能完全正确分析出aar所属业务，考虑到每个版本的aar变动较小，所以我们是通过配置文件手动根据实际情况将业务aar归属到同一分组中，最终产出该业务所占大小以及包含的aar列表。
本地产出结果
根据上述步骤我们实现了在终端执行一行python脚本命令便可以自动化产出所有业务大小：
最终成果
为了方便监控和快速产出每个版本的数据，我们做了一个简单易用的可视化平台，通过在远程服务器执行打包最后将产出的数据上传到后台，可以自动产出报告并发送邮件，极大提升了产出报告的效率。
图一 各版本包大小统计图
图二 业务大小曲线图
图三 版本aar包大小详情
在详情页面可以查看每个业务的大小及对应包含的aar详情列表，也可以选择版本进行对比查看增量大小。
总结
通过修改aapt源码和gradle插件源码解决了由于资源缺失导致的打包失败问题，通过获取依赖树在Demo工程中使用python脚本自动化产出aar大小数据，最后通过可视化平台极大提升了包大小报告产出的效率。
如需Demo工程源码，微信搜索关注“于卫国”公众号回复“aar”获取。
