一次 Android APK 体积优化实录

现状及问题 #

最近工作上有些变动，新接手的项目中发现 apk 的 Debug 包有 170 多 MB，Release 包也要 140 MB。 仔细看项目内容，其实并没有那么多东西。想要减小体积，首先得搞清楚从哪里下手，于是决定先分析一下应用的体积构成。

分析 #

将打包后的 apk 拖到 Android Studio 里，就能看到各部分的体积占比。

ABI #

lib 的体积挺惊人，占了 92.9MB。 这个目录是放 native 库的，来源通常有两种：

1. 自己写的 native 代码（为了性能、安全或通用性）；
2. 第三方库自带的 native 文件。

第三方库为了支持更多设备，会同时包含多个 ABI。 先从这里下手，初步猜测是没过滤 ABI。

果然，ABI 支持得很全，连不用的都打进去了。

ABI（Application Binary Interface）指的是“应用二进制接口”， 也就是应用（或其原生库）与系统或其他模块在二进制层面所遵循的规则，比如指令集、函数调用约定、数据对齐、库格式、命名修饰（mangling）等。 简单来说，ABI 就是 CPU 支持的指令集。

当前架构情况（2025） #

• ARMv8-A（64 位）

  • ABI：arm64-v8a
  • 市场占比超过 90%
  • 特点：支持 AArch64/AArch32 双指令集，兼容性好
  • 代表芯片：骁龙 8 Gen4、天玑 9400、Exynos 2400

• ARMv7-A（32 位）

  • ABI：armeabi-v7a
  • 适用：老旧中低端设备（2015–2020）
  • 现状：新机基本不再使用，仅残留于部分 IoT 设备

• x86 / x86_64

  • 主要用于安卓模拟器和少量平板
  • 市场占比低于 3%

当前手机基本都是 64 位 ARM 架构，许多 armv8 设备都已经卡得不行，更不用说更早的 armv7。 过滤 ABI 很简单，在模块级 gradle 中加上：

1

abiFilters 'arm64-v8a'

省掉了 66.86MB。

资源 #

第二大块体积来自资源。 Android 资源包含：图片、布局、字体、字符串、颜色、属性。 打包时通常会开启 isShrinkResources 去掉未使用资源，但正在使用的图片仍然会占据相当大空间。

图片体积往往以 MB 计，尤其是大尺寸 PNG。 常见格式有：

• PNG：无损压缩，清晰但体积大；
• JPG：有损压缩，体积小但容易模糊；
• WebP：压缩率更高，但存在兼容性顾虑。

几种优化方式 #

1. 算法压缩（TinyPNG、pngquant 等） 不影响质量，能显著减小体积。
2. 降低质量 减小体积，但大图可能会糊。
3. 改用 WebP 压缩率高，但部分旧系统仍有兼容风险。

三种方式中，第一种几乎没有副作用。 综合稳定性和收益，我选择了算法压缩。

我用 TinyPNG 来处理图片。 它的效果不错，但免费账号有调用限制，只能一次次通过网页上传压缩。

压缩前后效果对比：

从 32.5MB 缩减至 16.9MB，缩减 48% 。

代码 #

代码层面最常见的方式是 混淆。 混淆不仅能减小体积，也能提高反编译难度，可谓一举两得。

配置也很简单：

1

isMinifyEnabled true

大多数项目都会默认开启，这里不再赘述。

实操 #

当前阶段的优化主要是：

• 过滤 ABI，只保留 arm64-v8a；
• 图片压缩；
• 确认开启代码混淆。

这些操作后，应用从 140.3MB → 58.3MB，整体缩减 58% ，效果明显。

回顾 #

上面这些是最基础、最常规的优化，不需要额外依赖，也不会影响功能。 除此之外，还可以考虑以下两种更深入的做法：

1. 资源动态下发 除启动图、占位图、错误图外，其他资源可由服务端下发。 优点是包更轻，缺点是首启依赖网络。
2. 插件化 / 模块拆分 只保留首页等必要模块，把购买、订单、播放等拆成独立 apk 以插件形式按需下载。 效果好，但工程量大。

防劣 #

ABI 配置一般不会变，但图片最容易劣化。 随着业务迭代，不断有新图片被引入。 为了防止包体积回涨，最好不要依赖人工检查，而是让持续集成自动化完成。

可以这样做：

• 构建阶段批量压缩图片；
• 只处理新增文件（或将压缩文件直接提交到 Git 仓库）；
• 定期记录包体积，若超过阈值（例如 +5MB）则触发警告。

这样既能保证体积稳定，又不会明显增加构建时间。