APP 包大小统计方案

管理学大师彼得德鲁克曾经说过“你如果无法度量它，就无法管理它” (It you can’t measure it, you can’t manage it) 。要想有效管理，就难以绕开度量的问题。我们如果想优化 app 的大小第一步就是准确有效得测量统计它。我们将整理 App 统计的有效方案。

需求背景

随着版本的迭代，App 包大小与日递增，已经接近 App Store 限制的200MB 流量下载阈值。虽说伴随着 App 功能的增加，包大小的增加或许不可避免，但是现在没有一套完整的系统能监控到安装包到底在哪些功能点、模块上增加的具体数据，因而无法着重去优化某些模块的大小，也无法去判断某个功能点是不是值得占用这么多包体积。

产品目标

根本的目标是需要明确知道每个版本增加、减少的包大小到底在哪些模块中，评估其增减量相对于其自身价值是否正常。其次还有助于开发养成不乱复制代码、不瞎分模块的好习惯。

统计 arm64

可视化展示某个包中各个可执行文件、资源文件的大小
可视化展示任意两个包的内容差异
相邻两个版本增长、减少 TOP 10
包大小日报（develop、最新release）
每个模块登记相关负责人（模块 / 公用）
- 主工程文件监控（是否允许增加新文件，新增文件必须走登记流程）
- Module中文件监控

用户想知道的

想知道某个分支包大小波动较大的原因
想知道每个版本相对于上个版本的 release 体积变化
每个模块在每个包中（不区分branch）的体积变化
资源文件在每个包中（不区分branch）的体积变化
单个文件/模块被调用的地方

功能

技术方案

LinkMap 分析

打包之后相应架构的 LinkMap 文件复制到打包目录中，待包大小系统读取分析。
包大小系统收到打包成功通知后，拷贝 LinkMap 文件到本地服务器进行分析，分析结果按照 Moudle 为第一层，其子文件为第二层进行存储，方便调取，比对。

Assets 分析

Assets 进行切割（分离2X，3X）之后计算实际大小，使用 iOS 13，iPhone11标准。

Bundle 资源分析

因为苹果不会对bundle资源进行“优化”，所以直接进行大小统计