APP 内测分发时安装包体积太大怎么办？优化下载体验的 5 个实用方法

内测阶段的安装包往往比正式版更大——带着调试符号、未压缩的资源文件、甚至多套架构的二进制。当测试用户在弱网或移动数据下扫码安装时，动辄 200 MB 以上的包体直接导致下载失败、安装中断，反馈还没开始就卡在了第一步。

本文从打包侧和分发侧两个方向，整理出 5 个切实可行的方法，帮你在不影响测试覆盖率的前提下，把内测安装体验拉到及格线以上。

为什么内测包体积经常失控

在定位解决方案之前，先看清问题来源：

Debug 符号未裁剪：Xcode 默认在 Debug 构建中保留完整 dSYM 和 DWARF 信息，APK 的 debuggable=true 也会带入额外元数据。
多架构打包：iOS 的 arm64 + armv7、Android 的 armeabi-v7a + arm64-v8a + x86 全部塞进一个包，体积翻倍。
未压缩的资源：高分辨率切图、未转 WebP 的 PNG、未裁剪的字体文件、内嵌的视频引导页。
第三方 SDK 冗余：集成了多个推送、统计、广告 SDK，部分仅在生产环境使用，内测时完全多余。
构建配置混用：直接拿 Release + Debug 混合配置出包，既大又慢。

在 Xcode 中新建一个 InternalTest Build Configuration，基于 Release 但关闭 Bitcode（如已弃用则忽略）、开启 STRIP_INSTALLED_PRODUCT。
Android 项目在 build.gradle 中新增 internalTest productFlavor，设置 minifyEnabled true 并使用专用的 ProGuard 规则文件，保留崩溃日志所需的映射。
CI/CD 脚本中把内测出包指向该配置，避免每次手动切换。

建议：即使是内测包，也推荐开启代码混淆和资源压缩，这两项通常能减少 15%～30% 的体积，同时不影响功能验证。

Android：使用 abiFilters 只保留 arm64-v8a（目前绝大多数测试设备的架构），或通过 App Bundle 方式导出再用 bundletool 生成特定架构的 APK。
iOS：在 Xcode Archive 时选择 "Build Active Architecture Only = Yes"（仅限内测场景），或在导出 IPA 时勾选 "Rebuild from Bitcode" 以剥离非目标架构切片。

拆分后单包体积通常可减少 30%～50%，测试设备覆盖率几乎不受影响。

图片批量转换：PNG → WebP（Android）、PNG → HEIF 或 Asset Catalog 压缩（iOS），工具可用 cwebp 或 Xcode 自带的 Asset Catalog 优化。
字体子集化：如果 APP 仅使用中文常用 6763 字 + ASCII，用 fonttools 的 pyftsubset 裁剪字体文件，一个 12 MB 的中文字体可压到 2 MB 以下。
移除未引用资源：Android 使用 shrinkResources true；iOS 可借助开源工具 FengNiao 或 Xcode 的 "Find unused resources" 插件扫描。

包体优化有极限，但分发链路的下载速度同样影响体验。几个关键指标：

以虾分发为例，上传 app.apk 或 app.ipa 后即走全国多节点 CDN 分发，不设带宽上限，对于 100 MB 以上的内测包，下载体验明显优于自建单机服务器或网盘直链方案。

如果团队迭代频率高（如每天出包），测试用户每次全量下载 200 MB 显然不合理。可以考虑：

Android：接入 archive-patcher（Google 开源的 bsdiff 方案），CI 自动生成差分包，用户端仅下载变更部分。
iOS：目前系统层面不支持第三方增量安装，但可以在 APP 内部实现资源热更新（如 React Native 的 CodePush、Flutter 的 Shorebird），把高频变动的业务逻辑和资源从主包中剥离。

建议：增量方案的接入成本较高，适合日活测试人数超过 50 人、日均出包 2 次以上的团队；小团队优先做好方法一到方法四即可。

内测包体积问题的本质是「构建配置未针对内测场景做裁剪」加上「分发链路缺少加速能力」。五个方法按优先级排列：先调构建配置和架构拆分（成本最低、收益最高），再清理资源，然后选一个 CDN 能力靠谱的分发平台如虾分发来兜底下载体验，最后在团队规模和迭代频率都上来后再考虑增量方案。

把包体从 250 MB 压到 80 MB、把下载耗时从 3 分钟降到 30 秒，测试用户的第一步体验顺了，后续的 Bug 反馈率和测试覆盖率自然跟着提升。