16、构建产物分析：APK Analyzer使用、APK瘦身策略、构建报告分析
各位同学，今天我们来聊聊构建产物的分析。说白了，就是看看你辛辛苦苦打出来的 APK 到底长什么样，里面塞了多少“赘肉”。
我见过太多团队，APK 动不动就 50MB、80MB，用户一看下载包体就跑了。其实很多时候，这些体积都是可以“减”下来的。今天我就把压箱底的经验掏出来，跟大家好好聊聊。
16.1 APK Analyzer：解剖你的 APK
Android Studio 自带了一个神器——APK Analyzer。你想想看，一个 APK 就是一个压缩包，里面塞了 dex、资源、so 库等等。APK Analyzer 能帮你把这些东西拆开，看看谁最“胖”。
怎么打开？
很简单，两种方式：
- 直接把 APK 文件拖到 Android Studio 的编辑窗口
- 菜单栏：Build → Analyze APK
它能告诉你什么？
- 原始文件大小 vs 下载大小：这两个数字往往不一样，因为 Google Play 会做压缩。但原始大小才是你优化的目标。
- dex 文件：这里面是你的代码。如果 dex 很大，说明你的代码量多，或者引用了太多库。
- resources.arsc：这是资源索引表。如果它很大，说明你的字符串、颜色、布局定义太多了。
- lib/ 目录：这里面是 so 库。每个架构（armeabi-v7a、arm64-v8a、x86）都会有一份。如果你全打进去，体积直接翻倍。
我的经验：有一次我接手一个项目，APK 有 60MB。用 APK Analyzer 一看，好家伙，lib/ 目录占了 35MB！原来他们把 x86、x86_64 的 so 库全打进去了。实际上，现在市面上 99% 的设备都是 arm 架构，x86 的库完全可以去掉。去掉之后，APK 直接降到 35MB。
16.2 APK 瘦身策略：从资源、代码、库三个维度下手
瘦身这件事，说白了就是“断舍离”。我们分三个维度来聊。
16.2.1 资源瘦身
资源是 APK 体积的“大头”。我见过有人把一张 5MB 的图片直接塞进 drawable 里，这简直是灾难。
- 使用 WebP 格式：WebP 比 PNG 小 25%-35%，而且 Android 4.0+ 就支持了。我个人习惯把所有 PNG 都转成 WebP。
- 移除未使用的资源：用 Android Studio 的 Refactor → Remove Unused Resources。但要注意，有些资源是通过反射或第三方库引用的，别误删了。
- 使用矢量图：对于图标，尽量用 VectorDrawable。它只存路径，不存像素，体积几乎可以忽略。
- 资源混淆：使用 AndResGuard 这类工具，把资源文件名从
ic_launcher.png变成a.png。虽然对体积影响不大，但能增加逆向难度。
避坑指南：我曾经用 AndResGuard 混淆资源，结果某个第三方 SDK 通过资源名来加载图片，混淆后直接崩溃。所以，用之前一定要测试所有第三方 SDK 的兼容性。
16.2.2 代码瘦身
代码瘦身，核心就是“减少 dex 体积”。
- 启用 ProGuard/R8：这是必须的。R8 能移除未使用的代码、混淆类名和方法名。我建议在 release 构建中强制开启。
- 检查依赖库：很多库你只用了其中一小部分功能，但整个库都被打包进来了。比如你只用了 Retrofit 的网络请求，但它依赖了 OkHttp、Okio 等一堆东西。可以考虑用更轻量的替代方案。
- 避免使用枚举：枚举在 Java 中本质上是类，每个枚举值都是一个对象。如果你有大量枚举，建议用
@IntDef或常量替代。
// 不推荐：枚举
public enum Status {
SUCCESS, FAILURE, LOADING
}
// 推荐：使用 @IntDef
public class Status {
public static final int SUCCESS = 0;
public static final int FAILURE = 1;
public static final int LOADING = 2;
}16.2.3 库瘦身
库是体积的“隐形杀手”。你加一个库，可能就多了几百 KB 甚至几 MB。
- 按需引入：比如 Google Play Services，不要整个引入，只引入你需要的模块。例如只需要地图，就只引入
play-services-maps。 - ABI 拆分：在
build.gradle中配置splits，只打包你需要的架构。或者使用abiFilters。 - 动态下发：对于大型功能模块（比如 AR、AI 模型），可以考虑使用 Play Feature Delivery，让用户按需下载。
android {
...
splits {
abi {
enable true
reset()
include 'armeabi-v7a', 'arm64-v8a'
universalApk false
}
}
}16.3 构建报告分析：Build Analyzer
除了 APK 本身，构建过程也值得分析。Android Studio 的 Build Analyzer 能帮你找出构建慢的原因。
怎么打开？
构建完成后，点击右下角的 “Build” 窗口，然后点击 “Build Analyzer” 标签。
它能告诉你什么？
- 构建耗时分布：哪些 task 最耗时？是 Java 编译、Dex 打包，还是资源处理？
- 增量构建 vs 全量构建：如果增量构建和全量构建时间差不多，说明你的构建缓存没生效。
- 配置建议：Build Analyzer 会给出一些优化建议，比如开启
--offline模式、增加 JVM 堆内存等。
注意：Build Analyzer 只在 Android Studio 4.0+ 中可用。如果你用的是旧版本，建议升级。
16.4 知识体系总览
为了让大家更直观地理解本章的知识结构，我画了一张图。
16.5 实战建议
好了，理论说完了，咱们来点实际的。我建议你按以下步骤来优化你的 APK：
- 先用 APK Analyzer 看看现状：哪个模块最大？是资源、代码还是 so 库？
- 从最大的模块开始优化：如果资源最大，先做资源瘦身；如果 so 库最大，先做 ABI 拆分。
- 每次优化后重新分析：看看效果如何。我习惯把每次优化前后的体积记录下来，做成表格。
- 用 Build Analyzer 检查构建速度：瘦身的同时，别让构建变慢。
| 优化项 | 预期效果 | 风险 |
|---|---|---|
| WebP 转换 | 减少 25%-35% 图片体积 | 低 |
| ABI 拆分 | 减少 30%-50% so 库体积 | 中（需测试兼容性） |
| R8 混淆 | 减少 10%-20% dex 体积 | 低（需配置 keep 规则） |
| 移除未使用资源 | 减少 5%-15% 资源体积 | 中（可能误删） |
我的习惯：每次发版前，我都会用 APK Analyzer 对比一下当前版本和上一个版本的体积。如果体积增加了，我会追查原因。这已经成了我的“肌肉记忆”。
嗯，关于构建产物分析，今天就聊这么多。记住，APK 瘦身不是一蹴而就的事，而是一个持续优化的过程。你每次加一个新功能、一个新库，都要想想它对 APK 体积的影响。这样，你的用户才会愿意下载你的 App。