应用大小是指移动应用占用的存储空间，通常会在应用从下载到实际使用的不同生命周期阶段进行衡量。了解并管理应用大小对移动开发者至关重要，因为它会直接影响用户获取、留存以及应用的整体性能。应用大小涵盖多个维度，包括下载大小（从应用商店传输的压缩数据）、安装大小（安装后解压的数据）以及存储大小（实际使用期间占用的总空间，包括缓存和用户数据）。
应用大小的重要性远不止一个数字。研究表明，应用大小会直接影响转化率和用户行为。应用大小每增加 6MB，安装转化率大约会下降 1%。这意味着体积较大的应用在下载过程中面临更高的放弃率，尤其是在新兴市场，因为当地用户往往使用存储空间有限的旧设备，网络连接速度也较慢。考虑到新兴市场约占全球人口的 85%，优化应用大小对于覆盖尽可能广泛的用户群体至关重要。
应用大小还会对环境产生影响。移动应用通过更新和下载产生大量网络流量。数十亿次应用下载和更新的累积影响会转化为显著的电力消耗和碳排放。即使将应用大小减少 1MB，也可能显著降低年度碳足迹，因此应用大小优化不仅是技术责任，也是环境责任。
什么是应用大小？
应用大小并不是一个单一且固定的指标，而是包含四种不同的大小衡量方式。每种方式对应应用生命周期的不同阶段，并分别服务于开发者、用户和平台提供商的不同需求。
下載大小 代表使用者從應用程式商店下載應用程式時，透過網際網路傳輸的壓縮後資料量。應用程式商店會對應用程式進行壓縮，以盡量減少頻寬使用並縮短下載時間。這是使用者在 App Store 或 Google Play 商店的應用程式列表中看到的尺寸，並會直接影響其下載決策，特別是在使用行動數據或面臨儲存空間限制時。
安裝大小 指應用程式在裝置上安裝完成後立即佔用的磁碟空間。與下載大小不同，安裝大小反映的是未壓縮的應用程式資料，包含應用程式運作所需的所有程式碼、資產及資源。安裝大小總是比下載大小大，也是使用者在安裝完成後於裝置儲存空間設定中看到的數值。
儲存空間大小 指應用程式在活躍使用期間所佔用的總空間，其中包含安裝大小以及快取、已下載內容、使用者建立的檔案和暫存資料等額外資料。隨著使用者持續使用該應用程式，此大小會隨時間增加，並可能遠超過最初的安裝大小。
更新大小 指的是下載應用程式更新時所傳輸的資料量。現代應用程式商店採用增量更新機制，僅下載已變更的組件而非整個應用程式，因此根據應用程式修改的範圍，更新大小可能比初次下載時更小。
这些大小指标会以不同方式影响用户。与网络相关的影响主要出现在下载和更新过程中，尤其会影响带宽有限或有流量上限的用户。与存储相关的影响则会左右用户决定保留哪些应用，尤其是在设备存储容量受限的情况下。
为什么应用大小很重要？
应用大小会显著影响应用成功的多个关键方面，从用户获取到环境可持续性。了解这些影响有助于开发者合理确定应用大小优化工作的优先级。
应用大小最直接的影响体现在安装转化率上。数据持续表明，应用越大，从应用商店页面浏览到成功安装的转化率就越低。存储空间有限的用户可能必须先删除其他内容才能安装大型应用。使用按流量计费网络或身处网速较慢地区的用户，也可能因为下载耗时过长而放弃安装。即使用户实际上拥有足够的资源，看到较大的下载大小本身也可能形成心理障碍，使他们打消安装念头。
对于新兴市场的用户而言，应用大小问题尤为突出。许多人仍在使用只有 16GB 或更少存储空间的旧款智能手机，而其中一部分空间已经被操作系统占用。这些用户必须谨慎选择设备上保留哪些应用，因此更倾向于使用能够提供价值、同时不会占用过多空间的小型应用。如果不针对这些用户优化应用大小，就意味着会失去全球市场中相当大的一部分用户。
应用大小还会影响参与度和留存指标。用户经常会检查设备的存储使用情况，并在空间不足时卸载体积较大的应用。如果应用因缓存不断累积或功能持续增加而随时间显著变大，其卸载率通常也会更高。相反，能够保持较小体积并有效管理存储占用的应用往往具有更好的留存表现。
应用大小对性能的影响并不仅限于安装阶段。较大的应用通常启动时间更长，运行时占用更多内存，并且在资源有限的旧设备上可能表现得更慢。这些性能特征会直接影响用户满意度和应用评分。
从商业角度来看，应用大小还会影响成本和可持续性。较大的应用在分发和更新过程中需要消耗更多带宽，因此对于服务数百万用户的公司而言，会带来更高的基础设施成本。这类分发所产生的环境影响，包括电力消耗和碳排放，既关系到企业责任，也越来越成为监管层面的考量因素。
Android 应用大小
Android 应用采用专门的打包格式，以优化不同设备配置下的分发和安装。了解这些格式有助于开发者在构建和分发应用时做出更合理的决策。
.apk（Android Package）
自 Android 平台推出以来，APK 一直是传统的 Android 应用程序包格式。当开发者使用 Gradle 等标准工具构建 APK 时，默认情况下会生成一个通用二进制文件，其中包含所有受支持设备类型、屏幕密度、CPU 架构和语言所需的资源。
通用 APK 可以确保最大的兼容性，并能够安装在任何受支持的 Android 设备上，但这种便利会显著增加文件大小。例如，一款同时支持 32 位和 64 位处理器、多种屏幕密度以及多种语言的应用，会将所有这些版本都包含在同一个文件中。即使某台设备只使用 ARM64 架构、特定屏幕密度和英语，它仍然需要下载并存储其他所有配置对应的资源。
通用 APK 在开发和测试流程中仍具有重要用途。开发者可以通过 Orbit 等工具共享它们，也可以直接使用 ADB 安装，而无需考虑接收方设备是否符合特定配置。不过，对于通过应用商店进行分发而言，通用 APK 效率较低，并且会造成不必要的体积膨胀。
.aab（Android App Bundle）
Android App Bundle 格式代表了 Google 现代化的应用分发方式。AAB 的推出旨在解决通用 APK 效率低下的问题。开发者可以上传一个包含所有设备配置的单一构建产物，同时由 Google Play 根据每位用户的具体设备生成经过优化的 APK。
当用户下载通过 AAB 分发的应用时，Google Play 会分析其设备特征，包括 CPU 架构、屏幕密度和语言设置。随后，应用商店会生成并提供一个仅包含该设备相关资源的定制 APK。与通用 APK 相比，这可以显著减小下载大小。
从开发者角度来看，AAB 简化了构建和分发流程。开发者无需针对不同设备配置生成多个 APK 变体，只需构建一个 AAB 并上传到 Google Play。平台会负责生成针对特定设备的构建版本，确保用户无需开发者投入额外工作即可获得优化版本。
所有提交到 Google Play 的新应用都必须使用 AAB 格式。这一要求可确保整个 Android 生态系统中的用户享受到更小的下载大小和更高效的存储空间利用。
Google Play 最大大小限制
Google Play 对 Android 应用的不同组成部分设定了特定的大小限制。这些限制适用于上传后由 Play Console 计算得出的压缩下载大小。了解这些限制有助于开发者合理规划应用结构和内容分发策略。
| 元件 | 最大壓縮下載大小 |
|---|---|
| 基础模块 | 200 MB |
| 单个功能模块 | 每个模块 200 MB |
| 单个资源包 | 每个资源包 1.5 GB |
| 所有模块和安装时资源包的总大小 | 4 GB |
| 按需/快速跟进资源包总大小（标准开发者） | 4 GB |
| 按需/快速跟进资源包总大小（Level Up 计划成员和 Android XR 应用） | 30 GB |
标准应用的最大压缩下载总大小为 8 GB。加入 Google Play Level Up 计划的游戏以及 Android XR 应用可以通过额外的按需资源包，使总大小最高达到 34 GB。
关于这些限制，需要注意以下几点：
- 超过 1 GB 的应用必须将 Android Lollipop（API level 21）或更高版本设为最低 SDK 版本
- 对于以 Android Oreo（API level 26）或更高版本为目标的应用，建议功能模块数量最多为 100 个；对于更低 SDK 版本，建议最多为 50 个
- 每个 app bundle 最多可以包含 100 个资源包
- 通过移动数据连接下载超过 200 MB 应用的用户会看到一个非阻塞式对话框，提示应用体积较大
- 使用旧版 APK 分发方式的应用仍受此前 APK 最大 100 MB 的大小限制
Google 强烈建议应用大小远低于这些最大限制，以提高安装转化率并提供最佳用户体验。
iOS 应用大小
iOS 应用在开发和分发的不同阶段会采用不同的打包格式。这些格式在 iOS 生态系统中具有各自特定的用途，了解其特点对于有效管理应用大小至关重要。
.app（iOS application bundle）
.app 格式是实际的 iOS 应用程序包，其中包含运行应用所需的全部代码、资源和元数据。开发者在 iOS Simulator 或开发设备上测试应用时，使用的就是 .app bundle。
App bundle 可以针对特定架构进行构建，也可以构建为包含多种处理器类型代码的通用二进制文件。.app bundle 的大小并不能准确反映用户最终从 App Store 下载的大小，因为它尚未经过应用商店提交过程中执行的优化和处理。
在开发流程之外，开发者无法直接将 .app 文件安装到实体 iOS 设备上。因此，这种格式主要用于开发和测试，而不是面向最终用户的分发。
.ipa（iOS App Store Package）
IPA 文件是压缩归档文件（本质上是 ZIP 文件），其中包含 .app bundle 以及不同 iOS 应用分发方式所需的其他资源。IPA 格式支持多种分发渠道，包括 App Store 正式发布、TestFlight 构建、Ad Hoc 分发和 Enterprise 部署。
除了应用程序包本身，IPA 还包括代码签名信息、provisioning profiles 和 entitlements 等安全元素，用于验证应用的真实性和权限。App Store 会处理上传的 IPA 文件，为不同设备类型生成经过瘦身优化的变体，并针对每种配置仅提取相关资源。
IPA 文件的大小并不代表用户实际经历的下载大小。App Store 会将通用 IPA 处理为针对特定设备的版本，并移除各目标设备不需要的资源。例如，一个通用 IPA 可能为 100 MB，但经过 App Store 优化后，使用特定设备的用户实际可能只需下载 40-50 MB。
Apple App Store 最大大小限制
Apple 对上传至 App Store 的 iOS 应用设定了最大大小限制。这些限制旨在确保分发基础设施可控，并使应用对用户设备存储空间的需求保持在合理范围内。这些限制适用于针对特定设备配置进行 app thinning 后测得的未压缩应用大小。
| 元件 | 最大尺寸 |
|---|---|
| 未压缩应用总大小 | 4 GB |
| 蜂窝网络下载限制（无线下载） | 200 MB |
| Apple Watch 应用 | 75 MB |
| App Clips（瘦身后） | 因 iOS 版本而异 |
| Mach-O 可执行文件（所有 __TEXT section 的总大小） | 500 MB |
| 每个架构 slice 的 Mach-O 可执行文件 | 500 MB |
4 GB 限制指的是 iOS 应用的未压缩总大小，包括所有资源和可执行代码。自 Apple 于 2015 年将该限制从 2 GB 提高以来，这一上限一直保持不变，而这也是自 App Store 于 2008 年推出以来唯一一次提高应用大小限制。
对于通过蜂窝网络下载的应用，Apple 将下载大小限制为 200 MB，以防止用户意外消耗大量移动数据。该限制在 2017 年从 150 MB 提高，而在此之前为 100 MB。超过 200 MB 的应用需要连接 Wi-Fi 或通过电脑同步进行下载。虽然这一措施可以保护用户免受意外流量费用影响，但对于使用不限流量套餐的用户而言可能造成不便，因为他们无法手动绕过该限制。
由于手表的存储容量有限，Apple Watch 应用面临更严格的大小限制，最大为 75 MB。App Clips 是针对特定任务设计的轻量级应用体验，其大小限制会根据最低 iOS 部署目标而有所不同。
开发者可以利用 On-Demand Resources 和 Background Assets，将较大的内容与主应用程序包分开托管。这些资源会在需要时下载，而不是包含在初始安装包中，从而让应用在遵守大小限制的同时仍能提供丰富内容。对于以 iOS 18 及更高版本为目标的应用，经过 app thinning 后，每个 On-Demand Resources 资源包最大可达到 8 GB。
如何优化应用大小？
优化应用大小需要采用系统化方法，针对影响总体大小的多个组成部分进行处理。有效的优化需要在减小体积与功能、性能和代码可维护性之间取得平衡。
静态资源
静态资源包括图片、音频文件、视频、字体以及其他资源，通常是应用大小中占比最大的部分。这些资源既可能来自应用自身，也可能来自集成到项目中的第三方库。
优化应从审核应用中包含的所有资源开始。使用特定平台的工具检查构建产物并识别体积较大的资源。对于 Android，可以使用 Android APK Analyzer 和 apktool 等工具详细查看 APK 内容。对于 iOS，可以将 IPA 重命名为 .zip 并解压以检查资源，同时使用 macOS 工具 assetutil 对 Assets.car 文件进行详细分析。
图片优化通常能够显著减小应用大小。应根据不同使用场景选择合适的图片格式：照片使用 JPEG，需要透明效果的图片使用 PNG，而 WebP 相比前两者通常能够提供更高的压缩率。确保图片尺寸与实际显示场景相匹配，而不是在运行时缩小过大的图片。删除未使用的图片以及开发过程中积累的重复资源。
使用 SVG（Scalable Vector Graphics）格式的矢量图形通常比位图更节省空间，尤其适用于图标和简单图形。矢量图形可以无损缩放到任意大小，而且通常比针对多个分辨率准备多份位图资源占用更少空间。
音频和视频压缩需要在文件大小与质量之间谨慎取得平衡。音频可使用 AAC，视频可使用 H.264 或 H.265 等现代编解码器，在保持可接受质量的同时实现出色的压缩效果。应从生产构建中移除仅供开发或测试使用的高质量资源。
字体优化包括仅保留所需的字符集和字重。如果应用使用自定义字体，应根据支持的语言仅包含必要的 glyph，而不是包含完整的 Unicode 范围。
JavaScript bundle
对于使用 React Native、Flutter 或其他采用 JavaScript 或类似脚本语言框架构建的应用，bundle 大小会显著影响应用大小和性能。现代 JavaScript 应用可能会因为依赖项和功能不断增加而累积大量代码。
使用 bundle 分析工具了解 JavaScript bundle 的具体组成。对于 React Native 应用，Expo Atlas 等工具可以详细可视化 bundle 结构，显示哪些库对 bundle 大小的贡献最大。这类分析经常能够发现意外庞大的依赖项，或者已经不再使用但仍被包含在 bundle 中的库。
实施代码拆分，将应用划分为多个较小的代码块，并在需要时按需加载，而不是将所有内容都放入初始 bundle。这样既可以减少应用启动时需要加载的代码量，又能在需要时保持全部功能可用。
Tree shaking 会在构建过程中移除未使用的代码。确保构建配置已启用 tree shaking，并合理组织代码，使无效代码能够被有效消除。与较旧的 CommonJS 格式相比，ES6 modules 更有利于实现高效的 tree shaking。
在生产构建中对 JavaScript 代码进行最小化和压缩。现代构建工具可以删除注释、缩短变量名，并执行其他不会影响功能的体积优化处理。启用 gzip 或 Brotli 等压缩算法还可以进一步减小大小。
定期检查依赖项并删除未使用的库。每个依赖项都会增加 bundle 大小，而由已放弃功能或实验遗留下来的依赖项可能会在不提供任何价值的情况下显著增加应用大小。对于体积较大的库，还应考虑是否存在更轻量的替代方案。
动态功能分发
Android 和 iOS 平台都提供动态分发应用内容的机制，无需将所有内容都打包到初始下载中。这些功能使应用能够在保持较小初始大小的同时提供丰富功能。
Android App Bundles 支持动态功能模块，可以在应用完成初始安装后按需安装。功能模块包含特定功能所需的代码和资源，而这些功能并非所有用户都会使用。例如，一款照片编辑应用可以将高级滤镜作为动态功能模块，仅在用户访问该功能时才进行下载。
Android 上的 asset packs 提供了另一种动态内容分发方式。Asset packs 可以包含游戏关卡、高分辨率纹理或视频内容等大型资源。三种分发模式可满足不同场景：install-time 资源包会与应用一起下载，fast-follow 资源包会在安装完成后自动下载，而 on-demand 资源包只有在明确请求时才会下载。
iOS On-Demand Resources 提供类似功能，允许开发者将资源托管在 App Store，并在需要时下载。系统会自动管理这些资源，在需要时下载，并在存储空间不足时清除。这既能确保用户始终可以访问必要资源，又能让可选内容只在实际使用时占用空间。
iOS 上的 Background Assets 可以将大型内容与主应用程序包分开托管和管理。对于需要庞大媒体库或可下载内容包，同时又希望保持较小初始大小的应用而言，这一功能尤其有用。
实现动态分发需要谨慎规划哪些内容对初始体验至关重要，哪些内容可以延后加载。还应考虑用户的带宽限制，并确保在可选内容不可用或正在下载时，应用仍能正常、顺畅地运行。