[Android 从零到一] APK 瘦身与混淆：让安装包更小、更安全、更易维护

APK 瘦身与混淆：让安装包更小、更安全、更易维护

为什么安装包体积值得认真治理

Android 应用越做越大很常见：功能模块增加、图片越来越多、三方 SDK 越接越多、历史代码没有清理、ABI 包含过全、资源重复散落在各个模块。体积增长看起来只是“包大一点”，但对用户和业务都有实际影响。

安装包越大，下载等待越久，弱网失败率越高，应用商店转化率也可能下降。对于存储空间紧张的设备，用户还会更倾向于卸载体积大的应用。对研发团队来说，包体积失控通常也意味着依赖边界不清、资源管理混乱、构建配置缺少约束。

APK 瘦身不是上线前临时压一压图片，而是一套持续治理流程：先知道体积花在哪里，再减少不必要的资源和代码，最后用混淆、裁剪和自动检查守住结果。

先看清体积构成

优化之前，不要直接猜。Android Studio 自带 APK Analyzer，可以打开 APK 或 AAB，查看各目录和文件占比。常见体积来源包括：

• res/：图片、布局、动画、raw 资源。
• classes.dex：业务代码、三方库代码、Kotlin 运行时相关代码。
• lib/：不同 ABI 下的 native so 文件。
• assets/：离线包、字体、模型、配置、前端资源。
• resources.arsc：资源索引表。
• META-INF/：签名和元信息。

一个实用习惯是每次版本发布前导出体积报告，记录 APK、AAB、各 ABI 安装包、dex、res、lib 的大小变化。如果某个版本突然增加几 MB，能及时追到是哪次依赖或资源引入导致的。

命令行也可以快速查看 APK 内容：

unzip -l app-release.apk | sort -nr | head -40

这能帮助你快速发现大文件，比如误放进 assets/ 的调试数据、未压缩的长图、重复字体或不该进入线上包的视频文件。

资源瘦身：先处理最容易膨胀的部分

很多应用包体积增长最快的不是代码，而是资源。图片、字体、动效、离线文件一旦缺少规范，很容易变成“谁都不敢删”的历史包袱。

清理无用资源

Gradle 可以开启资源裁剪，让构建过程移除没有被引用的资源：

android {
    buildTypes {
        release {
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

注意 shrinkResources 依赖代码压缩结果，通常需要和 minifyEnabled 一起使用。它只能删除构建系统能判断为无用的资源，动态拼接资源名、反射访问资源、WebView 中引用本地资源等场景可能需要额外保留。

如果项目里存在动态资源访问，比如：

val id = resources.getIdentifier(iconName, "drawable", packageName)

构建工具很难知道这些资源实际会被使用。此时可以通过 res/raw/keep.xml 保留资源：

<resources xmlns:tools="http://schemas.android.com/tools"
    tools:keep="@drawable/icon_level_*,@raw/startup_config" />

这类规则不要写得太宽，否则会抵消资源裁剪收益。

优化图片格式和尺寸

图片通常是资源瘦身的主战场。建议按用途选择格式：

• 图标和简单插画优先考虑 VectorDrawable。
• 普通位图优先考虑 WebP。
• 需要透明通道时使用带透明的 WebP 或谨慎保留 PNG。
• 照片类大图避免放入 APK，优先走远端下发或按需下载。

把大图直接放进 drawable-xxhdpi 并不等于适配。更稳妥的做法是按显示尺寸裁切资源，确保图片真实像素和页面需求匹配。一个只显示 48dp 的图标，不应该用几百 KB 的大图承担。

Android Studio 可以批量转换 WebP。转换后要人工检查透明、渐变、边缘锯齿和深色模式下的显示效果。体积优化不能以视觉损坏为代价。

控制多密度资源

如果某些图片只在固定尺寸容器内显示，可以考虑保留必要密度，避免每个密度目录都放一份超大图。对于矢量图标，优先使用 VectorDrawable 减少多份位图资源。

但不要机械删除密度资源。启动图、大尺寸运营图、复杂插画如果只保留低密度版本，高端设备上会明显模糊。资源瘦身的目标是匹配使用场景，而不是盲目减少文件数量。

处理语言资源

三方库可能带来大量本地化字符串。如果应用只支持少数语言，可以在 Gradle 中限制打包语言：

android {
    defaultConfig {
        resourceConfigurations += listOf("zh", "en")
    }
}

这个配置会影响最终打进包里的资源。使用前要确认产品支持范围，避免误删实际需要的语言。

代码瘦身：减少无效依赖和未使用代码

代码体积主要体现在 dex 中。业务代码增长不可避免，但很多 dex 膨胀来自依赖失控。

审视三方库

引入一个 SDK 之前，至少要问清楚：

• 是否只用到其中很小一部分能力。
• 是否有更轻量的替代方案。
• 是否会额外引入大量传递依赖。
• 是否包含 native so、资源、字体或离线文件。
• 是否影响启动链路。

可以用 Gradle 查看依赖树：

./gradlew app:dependencies --configuration releaseRuntimeClasspath

如果某个库只是为了一个小工具方法，却引入了大量依赖，就应该考虑替换。对于传递依赖，可以按需排除：

implementation("com.example:sdk:1.0.0") {
    exclude(group = "com.example.unused", module = "big-module")
}

排除前要跑完整回归。传递依赖有时不是“看起来没用”就真的没用。

拆分可选能力

不是所有功能都必须内置在基础包里。大型离线资源、低频能力、特定地区功能，可以考虑远端下载、动态特性模块或服务端配置控制。

如果使用 Android App Bundle，Google Play 可以按设备配置分发资源和 native 库，让用户只下载自己设备需要的部分。对于非 Google Play 渠道，也可以按 ABI、屏幕密度或渠道策略生成不同包。

控制 native so

lib/ 目录经常是体积大户。常见问题包括：

• 同时打入 armeabi-v7a、arm64-v8a、x86、x86_64。
• 三方 SDK 带入未使用的 so。
• debug 符号或无关文件进入 release 包。

如果线上只支持 ARM，可以限制 ABI：

android {
    defaultConfig {
        ndk {
            abiFilters += listOf("armeabi-v7a", "arm64-v8a")
        }
    }
}

更推荐结合渠道和分发方式决策。对于需要模拟器测试或特殊设备支持的项目，不要把 ABI 过滤写死到所有构建变体里。

R8 与混淆：压缩、优化和保护代码

Android release 构建通常使用 R8。它做的不只是“把类名改短”，还包括代码缩减、优化、混淆和 dex 生成。开启后，未使用的类、方法、字段会被移除，部分代码会被内联或简化，类名和成员名也会被压缩。

基础配置通常如下：

android {
    buildTypes {
        release {
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

开启混淆后，必须重点关注反射、序列化、JNI、路由、注解处理、WebView JSBridge 等场景。它们可能依赖类名、方法名或字段名，一旦被改名或删除，就会在线上出问题。

Keep 规则要精确

很多项目的 proguard-rules.pro 会越写越宽，比如：

-keep class com.example.** { *; }

这条规则几乎等于告诉 R8：业务代码都别动。短期看省事，长期看会让代码压缩和混淆收益大幅下降。

更好的方式是只保留真正需要稳定名称的部分。例如 Gson 反射解析的模型可以按注解保留字段：

-keepclassmembers class * {
    @com.google.gson.annotations.SerializedName <fields>;
}

如果某个类需要被 JNI 按名字查找，可以只保留对应类和 native 方法：

-keepclasseswithmembernames class * {
    native <methods>;
}

如果路由框架、数据库框架或三方 SDK 提供官方规则，优先使用官方文档给出的配置，再结合项目实际收窄。

数据模型不要随便混淆字段名

网络 JSON、数据库字段、跨进程 Bundle、持久化缓存都可能依赖字段名称。建议对外部数据结构显式声明序列化名称：

data class UserProfile(
    @SerializedName("user_id") val userId: String,
    @SerializedName("nickname") val nickname: String
)

这样即使 Kotlin 属性名被混淆，JSON 字段仍然稳定。Room、Moshi、kotlinx.serialization 等框架也有各自规则，重点是不要让“代码字段名”隐式成为线上协议。

保留 mapping 文件

混淆后线上崩溃堆栈会变成短类名和短方法名。没有 mapping 文件，排查会非常痛苦。每次 release 构建都应该保存对应 mapping，并上传到崩溃平台。

mapping 文件通常位于：

app/build/outputs/mapping/release/mapping.txt

它和 APK 版本强绑定。不要只保留最新一份，否则旧版本崩溃无法还原。

发布前验证：别让瘦身变事故

APK 瘦身和混淆都有破坏性风险。资源可能被误删，反射代码可能失效，SDK 初始化可能异常，WebView 本地资源可能找不到。因此 release 包必须经过足够验证，而不是只跑 debug 包。

建议至少覆盖这些检查：

• 使用 release 构建安装到真机。
• 首次启动、登录、首页、核心业务流程完整走通。
• 图片、图标、动效、深色模式显示正常。
• 分享、支付、推送、地图、扫码等 SDK 功能可用。
• WebView、路由、反射、序列化相关功能可用。
• 崩溃平台能正确反混淆堆栈。
• APK Analyzer 对比体积变化，确认没有异常新增。

可以把体积检查加入 CI，比如超过阈值就阻断合并或发出告警。阈值不要过于理想化，建议按模块和历史增长趋势设置。

一套落地流程

实际项目可以按这个顺序推进：

• 用 APK Analyzer 找出主要体积来源。
• 清理明显无用的大资源和误入包的文件。
• 转换合适的图片格式，压缩过大的位图。
• 限制不需要的语言、ABI 和密度资源。
• 审查三方依赖，移除或替换重依赖。
• 开启 R8、资源裁剪和必要的优化配置。
• 收窄 Keep 规则，避免全包保留。
• 保存 mapping，并接入崩溃平台反混淆。
• 用 release 包做核心流程回归。
• 在 CI 中记录体积并设置增长提醒。

这套流程不要求一次做完。更现实的做法是先处理收益最大的几项，再把体积变化纳入日常发布检查。

常见误区

只压缩图片，不治理依赖

图片优化通常见效快，但如果三方库和 native so 持续膨胀，包体积仍然会反弹。资源、代码、依赖、构建配置要一起看。

Keep 规则越宽越安全

宽规则确实能减少混淆问题，但也会削弱 R8 的优化效果。正确做法是让规则服务于具体场景：哪里需要稳定名称，就保留哪里。

debug 包正常就说明 release 包正常

debug 包通常不开启混淆和资源裁剪，很多问题只会在 release 包出现。所有和混淆、资源、签名、渠道相关的验证，都必须基于 release 构建。

体积越小越好

体积优化也有边界。过度压缩图片会损害视觉质量，过度拆分资源会增加运行时复杂度，过度延迟下载会影响离线体验。目标是让包体积合理，而不是为了数字牺牲产品体验。

小结

APK 瘦身与混淆是一项工程治理工作。资源瘦身解决图片、语言、密度和无用文件问题；代码瘦身解决依赖、dex 和 native so 问题；R8 混淆在压缩代码的同时提升逆向门槛；发布验证则确保这些优化不会破坏真实功能。

真正稳定的做法，是把体积分析、规则审查、release 回归和 mapping 归档纳入日常流程。这样安装包不会在长期迭代中失控，团队也能在功能增长和体验成本之间保持清醒。