一、先看一个十堰本地的真实案例

2026年上半年，我们给十堰一家汽车零部件企业做了一套内部管理 APP，功能不算复杂：工单派发、质检拍照上传、库存查询、消息通知。开发完成后打出来的 Android 安装包是 86.4MB，iOS 包是 112MB。上线第一周就收到投诉：车间工人用手机流量下载，装到一半失败；外地驻场的销售装了三次都没成功；应用市场审核还提示"包体过大，建议优化"。

我们把这个包拆开做了体积分析，问题一目了然：

体积构成	优化前	优化后
so 动态库（含 4 种 CPU 架构 + 未裁剪的 OpenCV）	38.2MB	9.6MB
图片与字体资源（PNG 图标、三套字体）	21.5MB	4.1MB
三方 SDK（推送、地图、统计、人脸识别）	14.3MB	8.7MB
业务代码与 Dex	8.9MB	6.2MB
其他（配置、证书、冗余文件）	3.5MB	2.4MB
合计	86.4MB	31.0MB

最终包体下降 64%，首次下载成功率从 71% 提升到 96%。这篇文章把十堰 APP 开发团队在这个项目里用到的减包手段按顺序拆开讲，每一条都能直接落地。

二、减包第一步：先量，再砍

不做分析的优化都是瞎猜。减包前必须先拿到一份准确的体积报告，否则你永远不知道最大的那块在哪里。

2.1 Android：APK Analyzer

在 Android Studio 里依次点击 Build → Analyze APK，选择打出来的 apk 文件，就能看到按文件、按目录、按方法数三个维度的体积分布。重点看三个数字：lib/ 目录多大、res/ 目录多大、Dex 里哪个包的方法数最多。

如果项目已经改造成 AAB，用 bundletool 生成一份体积报告：

bundletool build-apks --bundle=app-release.aab \
  --output=app.apks --mode=default
bundletool get-size total --apks=app.apks

这条命令会分别输出 min、max 和平均下载体积，比自己估算准确得多。

2.2 iOS：App Thinning Size Report

iOS 不能只看本地 Archive 出来的 ipa。正确做法是在 Xcode Organizer 里选择 Distribute App → App Store Connect → Export，导出完成后目录里会生成一个 App Thinning Size Report.txt。这个文件列出每个设备型号实际下载的体积，比如 iPhone 15 下载 42MB、iPhone SE 下载 38MB。很多团队看到这个报告才发现，用户在 App Store 里看到的体积远小于自己本地的 ipa——但这不代表可以不做优化，因为 Android 渠道和国内分发场景没有这层"瘦身"。

三、Android 减包的五把斧

3.1 第一把：用 AAB 替代通用 APK

Google Play 从 2021 年 8 月起就要求新应用必须使用 Android App Bundle 提交。AAB 的核心价值是按需分发：Google Play 会根据用户设备的 CPU 架构、屏幕密度、系统语言，只下发对应的那一份资源。一个包含 arm64-v8a、armeabi-v7a、x86_64 三种架构和四套密度图片的包，用户实际只会拿到其中一份，体积能直接砍掉 30% 到 40%。

需要注意的是，国内华为、小米、OPPO、vivo 等应用市场目前主流仍然接收 APK 文件。所以实际项目里的常见做法是双轨：面向海外用 AAB 上传 Google Play，面向国内市场用 bundletool 从同一个 AAB 导出分架构的 APK 分别上传。

// app/build.gradle
android {
  bundle {
    density { enableSplit true }
    abi { enableSplit true }
    language { enableSplit true }
  }
}

3.2 第二把：R8 代码压缩与资源压缩

很多团队在 release 包里把 minifyEnabled 关掉了，理由是"怕混淆出问题"。这是最亏的一种省事。打开 R8 之后，未使用的类、方法、字段会被整体移除，类名和方法名被缩短，Dex 体积通常能减少 20% 到 35%。

android {
  buildTypes {
    release {
      minifyEnabled true
      shrinkResources true
      proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),
                    'proguard-rules.pro'
    }
  }
}

配套要做两件事：一是把反射、JNI 调用、JSON 序列化用到的类写进 proguard-rules.pro 的 -keep 规则；二是打开资源压缩后，必须检查 res/raw 里通过字符串拼接动态获取的文件名，这类资源会被误删，需要在 res/raw/keep.xml 里白名单声明。

3.3 第三把：图片资源治理

图片往往是第二大体积来源。我们在十堰这个项目里做的三件事：

PNG 全量转 WebP：同一张 1200×800 的产品图，PNG 是 480KB，质量 80 的有损 WebP 只有 62KB，肉眼几乎看不出差别。整个项目转完省了 14MB。
只保留一套密度：很多项目同时放了 mdpi、hdpi、xhdpi、xxhdpi 四套图，其实只要保留 xxhdpi，让系统在低密度设备上自动缩放就够了，体积能减 60% 以上。
图标改用矢量图：纯色图标全部换成 VectorDrawable，一个图标从 3KB 降到不到 1KB，而且放大不糊。

3.4 第四把：so 库裁剪

这个项目 38MB 的 so 库里，有一半是 OpenCV 全量包。处理方式有两层：

只保留 arm64-v8a 和 armeabi-v7a，去掉 x86 和 x86_64。2026 年市面上还在跑的 x86 Android 设备基本只剩模拟器，没有必要为用户覆盖率提升不到 0.3% 而多带一份库。
如果只是用到 OpenCV 的图片裁剪、灰度化、二维码识别，就换成按模块编译的精简版，或者干脆用 ML Kit 的条码识别替代，so 从 19MB 降到 4MB。

defaultConfig {
  ndk {
    abiFilters 'arm64-v8a', 'armeabi-v7a'
  }
}

3.5 第五把：把低频功能拆成动态模块

Android 的 Dynamic Feature Module 允许把"年假申请""培训考试"这类一个月用一次的功能打成按需下载的模块。用户首次安装只拿到主包，点进对应入口时才触发下载。这个项目把三个低频模块拆出去之后，主包又瘦了 6MB。

四、iOS 减包的关键动作

4.1 图片走 Asset Catalog

直接拖进项目的 PNG 不会参与 App Thinning。放进 Asset Catalog 并正确设置 1x/2x/3x 之后，App Store 才会按设备下发对应的那一份。这一步几乎是零成本，但很多外包项目根本没做。

4.2 打开 Strip Swift Symbols 与 Dead Code Stripping

在 Build Settings 里确认 Strip Swift Symbols 为 YES、Dead Code Stripping 为 YES、Deployment Postprocessing 为 YES。Swift 项目的符号表体积不小，strip 之后通常能省 2 到 5MB。

4.3 清理无用语言与架构

如果 APP 只面向国内用户，把 CFBundleLocalizations 精简到只留 zh-Hans，可以去掉几十种语言的本地化字符串。同时确认 Architectures 只包含 arm64，Excluded Architectures 里加上 arm64 模拟器配置，避免误把调试架构打进发布包。

4.4 注意 bitcode 的变化

bitcode 从 Xcode 14 起已被标记为废弃，新项目不需要再为它做特殊配置。网上一些老教程还在教你"开启 bitcode 让苹果帮你重新编译瘦身"，这条建议在 2026 年已经过时，照做反而可能卡在提交环节。

五、减包之后还要注意什么

包体小了不等于体验就好了。十堰本地的实际网络环境和一线城市差别很大：厂区、山区、地下车库经常只有 2G/3G 信号，弱网才是真正的敌人。所以在减包之外，我们在这个项目里还补了三件事：

首次启动不下载大资源：把 3MB 的启动动画和引导图改成运行时按需拉取，主包只保留一张占位图。
接口做本地缓存：工单列表、库存数据缓存 15 分钟，断网时显示上次的数据并标注"离线状态"，而不是直接白屏。
差分升级：内部渠道分发用 bsdiff 生成差分包，86MB 到 31MB 的一次升级，差分补丁只有 4.8MB，车间 WiFi 环境下 10 秒装完。

六、落地检查清单

用 APK Analyzer 或 App Thinning Size Report 拿到基线数据，写进项目文档。
release 包开启 R8、shrinkResources，并补齐 keep 规则与 keep.xml。
图片转 WebP，只留一套密度，图标矢量化。
so 库只保留 arm64-v8a，第三方 SDK 逐个评估是否可替换。
低频功能拆成 Dynamic Feature，主包只放核心链路。
iOS 资源全部走 Asset Catalog，打开 strip 相关选项。
每次发版对比包体变化，超过 2MB 的增长必须在 code review 时说明原因。

减包不是一次性运动，而是一个需要长期盯住的指标。十堰 APP 开发团队在接手老项目时，见过太多"每次发版大一点、三年后 200MB"的案例。把包体当成和崩溃率、启动速度同等重要的质量指标，才是真正的解法。

十堰APP开发实战：安装包从86MB瘦到31MB，Android AAB与iOS减包完整指南（2026版）