Android 应用体积分析与资源治理

摘要：应用体积影响下载、安装和更新体验。缩减体积应先分析构成，再处理重复资源、图片格式、代码收缩和可选功能。

一、建立体积基线

记录不同构建变体的包体积，并区分下载包、安装后占用和更新增量。架构、语言和屏幕密度拆分也会影响不同用户实际下载的内容。

比较前要使用相同构建类型和压缩配置。调试符号、资源压缩选项不同，会让前后数据失去可比性。

二、分析主要组成

检查代码、原生库、图片、字体、音频和资源表占比。优先处理最大项，再查找重复依赖和未使用文件。构建报告比凭经验猜测更容易发现真实来源。

不同版本的相同依赖可能携带重复内容。依赖冲突应明确版本来源，不能只按文件名简单排除。

三、优化图片和媒体

根据照片、插画和透明图标选择适当格式，并检查压缩后的视觉质量。优先输出实际展示需要的尺寸，避免包内保存远超显示分辨率的大图。

矢量资源能减少某些重复位图，但复杂矢量也可能增加低端设备的绘制成本。字体子集化必须保留产品实际支持的字符范围。

四、配置代码与资源收缩

发布构建可启用代码优化和资源移除。反射、序列化和 JNI 可能依赖名称或资源，需要声明保留规则并覆盖运行时路径。保留过多会降低缩减效果，保留不足则可能在运行时崩溃。

动态按名称查找的资源需要明确保留。调整规则后，应在发布变体验证关键流程，而不是只检查能否编译。

五、评估可选功能

低频或大型能力可以考虑延迟交付，但会增加安装状态、失败恢复和分发管理复杂度。首屏关键功能不应仅为缩小初始包而变得不可用。

按语言和设备密度拆分可以降低部分用户下载量，但需确认应用分发渠道和自建安装流程支持预期形式。

六、检查原生库

检查原生库是否带入无用架构、调试符号或重复运行时。移除架构前确认目标设备覆盖范围。崩溃分析符号应单独保存，不必与用户安装包一同交付。

七、优化流程

1. 生成体积报告并标记最大组成。
2. 每次只处理一个主要来源。
3. 比较体积变化与运行时行为。
4. 在发布变体验证反射、资源和原生功能。
5. 记录对构建和分发流程的影响。

八、总结

体积治理应以构建报告为依据，逐项处理大资源、重复依赖和无用代码。保留运行时需要的资源与架构支持，并在发布变体验证，才能兼顾体积和稳定性。