承接上一篇《序列化与传输体积：Protobuf 的取舍》讲完的传输层压缩，这一篇转向交付物本身。安装包体积不是一个纯技术指标：它直接决定用户是否放弃下载、决定应用商店的分发效率、决定弱网环境下的安装成功率。更麻烦的是，包体积是三类成本的叠加——资源（图片、字体、raw 目录）、代码（DEX 与符号）、原生库（so 与多 ABI 拆分）。三者的分析工具、压缩手段、坑的形态都不相同，混在一起谈就容易得出\”优化了但没效果\”的结论。
先说结论：包体积优化必须先测量、再归因、后动手，顺序反了就是无效功。 这一篇给出的是方法论与决策框架，后续几篇分别展开三条线。
先建立体积构成视图
Android 构建产物的构成可以用 buildozer 或 AAB 的统计直接看到。以一个典型中等规模 App 为例（下列数字是常见量级，用于说明结构而非某项目实测）：
| 资源 res/ | 35%~50% | 图片（PNG/WebP）、字体、动画布局、raw/ 音视频 |
| 代码 DEX | 20%~35% | classes.dex< |
