移动开发中的 App Size Optimization：基础、方法和实践

什么是 App Size Optimization

App Size Optimization — 移动开发中旨在最小化应用安装包大小的学科。包括删除死代码和资源、压缩图像、优化库、针对不同架构的编译碎片化以及使用按需交付技术。

应用大小 不均等地影响 不同的用户群体。在移动基础设施发达的地区（美国、欧洲、日本），50 MB 和 100 MB 之间的差异可能不易察觉。在发展中地区（印度、印尼、巴西），每增加一兆字节都会因为资费限制和移动互联网速度而降低安装转化率。Google Play 将 APK 大小限制为 200 MB，但建议保持大小在 100 MB 以下。

对于 iOS App Store，通过蜂窝网络下载的最大大小为 200 MB（2023 年之前为 150 MB）。如果 IPA 超过此限制，用户只能通过 Wi-Fi 安装应用。Apple 还支持 App Thinning，其中包括 Slicing、Bitcode 和 On-Demand Resources — 这些技术可在无需开发者干预的情况下自动减少特定设备上的安装大小。

为什么应用大小至关重要

应用大小 不仅影响安装转化率，还影响留存率、更新频率和首次启动速度。每增加一兆字节都是用户与使用您的产品之间的障碍。

对安装转化率的影响

根据 Google I/O 2024 的数据，将 APK 减少 10 MB 可使安装转化率平均提高 3.5%。对于 150+ MB 的应用，转化率可能比同类 50 MB 的应用低 20–30%。在 Google Play 中这种效果尤其明显，用户可以在安装前看到大小。在 App Store 中，大小显示在应用页面上，拥有有限资费的用户会 推迟 安装直到连接 Wi-Fi，之后常常忘记该应用。

更新频率和无线更新

大型应用通过无线更新的频率较低 — 用户将补丁下载推迟到 Wi-Fi，从而错过关键的安全修复。Google Play 允许使用 增量更新（最大 10 MB 的补丁），但完全重新安装仍然会下载完整的 APK 或 AAB。Apple App Store 使用 Delta Updates，仅传输更改的文件，但即使增量在资源更改时也可能很大。

首次启动和解包

大小直接影响首次启动时间：应用必须解包资源、编译代码（Android）或签署缓存（iOS）。200 MB 的应用在中等设备上可能比 50 MB 的应用晚启动 10–15 秒。这会恶化 上手体验 — 用户可能不等加载完成就关闭应用。

优化资源和素材

资源 — 图像、字体、声音、视频 — 占典型移动应用大小的 60–80%。资源优化以最小的投入带来最大的收益。主要方向：压缩、删除重复和未使用的素材、选择合适的格式。

图像优化

WebP — Google 的图像格式，在相同视觉质量下提供比 PNG 好 25–35% 的压缩率，比 JPEG 好 15–20%。Android 从 API 18 开始原生支持 WebP。对于 iOS，WebP 通过 SDWebImage 或 Kingfisher 库获得支持，从 iOS 17 开始提供原生支持。AVIF — 更现代的格式，相比 WebP 额外节省 10–15%，但解码速度较慢。

删除未使用的资源 — 减小大小的最简单方法。在 Android 中，使用 Android Studio 进行重构：Analyze → Run Inspection → Unused Resources。在 iOS 中 — Build Settings → Remove Unused Resources。项目中经常残留早期版本的精灵图、旧图标、未使用的启动屏幕图像，这些 膨胀了 大小却没有带来任何功能负担。

字体和声音优化

自定义字体 可能占用 5–15 MB，特别是如果连接了整个字体系列（所有样式：Regular、Bold、Italic、BoldItalic）。通过 子集化 仅使用必要的样式和字符子集 — 删除应用不支持的语言的字形。Google Fonts 和 Transfonter 等服务允许创建最小字符集。对于声音，使用 AAC/HE-AAC 代替 WAV 和未压缩格式 — 节省高达 90% 且不损失质量。

优化代码和库

代码 占应用大小的 20–40%，但其优化比资源更困难，因为它需要分析依赖关系、混淆和删除死代码而不冒破坏功能的风险。

Android 的 ProGuard 和 R8

ProGuard — 用于 Android 的工具，执行代码混淆、缩减和优化。R8 — 其继任者，内置于 Android Gradle Plugin 中，运行更快更高效。R8 删除未使用的类和方法，缩短变量名称并重写代码以减少指令数量。使用 R8 缩减 DEX 文件的典型大小为 30–50%。

// build.gradle — 配置 R8 以进行缩减
android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(
                'proguard-android-optimize.txt')
            shrinkResources true
        }
    }
}

优化库和依赖关系

库 — 大小膨胀的常见原因。一个库可能带来传递性依赖，使大小增加 5–20 MB 而对应用没有直接好处。使用 Gradle Version Catalog（Android）和 Swift Package Manager（iOS）明确声明依赖关系。使用 Android Studio 中的 Build Analyzer 或 Xcode Build Timeline 分析大小。用更轻量的替代品替换重库：例如 OkHttp（3 MB）代替 Apache HTTP（15 MB）。

在 iOS 中删除未使用的代码

死代码剥离 — 在 Xcode 的链接阶段自动删除未使用的方法和类。通过 Build Settings → Dead Code Stripping = YES 启用。Bitcode — 中间表示形式，Apple 可以针对不同架构重新编译，删除未使用的函数。但从 Xcode 14 开始，Bitcode 变得可选，其对大小缩减的贡献在 Objective-C 项目中为 5–15%，在 Swift 中则更少。

App Thinning 和按需交付

App Thinning — Apple 的技术，通过仅提供特定设备所需的资源来自动减小已安装应用的大小。由三个组件组成：Slicing、On-Demand Resources 和 Bitcode。在 Android 中，等效的是 Android App Bundle (AAB) 和 Dynamic Delivery。

Android App Bundle (AAB)

AAB — Google Play 中的发布格式，商店为每个设备单独生成 APK，仅包含其架构（armeabi-v7a、arm64-v8a）、屏幕密度（mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi）和语言所需的资源。从通用 APK 切换到 AAB 时，安装大小的典型减少量为 20–40%。Play Feature Delivery 允许按需下载模块，而 Install-time 模块则包含在基础安装中。

// build.gradle — 配置 AAB 和 Dynamic Features
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}

iOS 中的按需资源

按需资源 (ODR) — iOS 机制，其中资源（游戏关卡、高分辨率图像、视频）仅在用户真正需要时才从 Apple 服务器下载。初始安装的大小可以减少 50–80%。资源分为三类：Initial Install Tags（安装时下载）、Prefetched Tag Order（安装后在后台下载）和 On-Demand（仅在请求时下载）。Apple 建议将 ODR 用于 内容（不需要在首屏显示的内容：游戏关卡、附加内容、视频教程）。

SwiftUI 通过 Bundle.module 属性支持 ODR，UIKit 通过 NSBundleResourceRequest 支持。对于 Unity 和 Unreal Engine 上的游戏，ODR 在原生包装层面集成。主要限制 — 系统在空间不足时会删除 ODR 资源，因此关键的操作数据必须包含在主编译中。