This documentation is available as Markdown for AI agents and LLMs. See the full Markdown index or append .md to any documentation URL.

估算带宽使用量

编辑页面

了解如何估算 EAS Update 的带宽使用量。


了解更新带宽用量

EAS Update 使应用能够通过空中下载更新自身的非原生部分(例如 JavaScript、样式和图片)。本指南将解释带宽是如何消耗的,以及如何优化消耗。

带宽计算拆解

每个订阅计划除了每月活跃用户(MAU)额度外,还包含每个按月计费周期预先设定的带宽配额(了解 MAU 如何计算)。超出标准配额的 MAU 将按按用量计费费率收费,而每增加 1 个此类 MAU,都会额外增加 40 MiB 的标准带宽配额。该带宽决定了在产生额外带宽费用之前,用户可以下载多少次更新。

下面是估算每次更新带宽用量的方法:

  • 更新大小: 带宽消耗的关键因素是设备上尚未存在的更新资源大小。如果某次更新只修改了应用的 JavaScript 部分,用户只会下载新的 JavaScript。先举个例子,假设导出时生成的未压缩 JavaScript 部分为 10 MB。压缩会进一步减小其大小。

  • 压缩比: 压缩级别取决于文件类型。JavaScript 和 Hermes 字节码(React Native 应用中常用)可以被压缩,而图片和图标不会被自动压缩。在上面的例子中,一个 Hermes 字节码包大约可达到 2.6× 压缩比,将实际下载大小降低为:

    10 MB / 2.6 ≈ 3.85 MB update bandwidth size

给定带宽配额后,我们可以估算在一个月度计费周期内,在产生额外带宽费用之前最多可以下载多少次更新。例如,如果你的生产计划有 60,000 个 MAU,它包含 500,000 个 MAU 和每月 1 TiB(1,024 GiB) 的带宽。通过按用量计费额外购买的 10,000 个 MAU 会获得额外 每个 MAU 40 MiB 的带宽。可下载的更新总数为:

(1,024 GiB × 1,024 MiB/GiB) + (10,000 MAU × 40 MiB/MAU) = 1,448,576 MiB per month 1,448,576 MiB / 3.85 MiB ≈ 376,254 updates

测量你实际的更新大小

先使用以下命令生成未压缩的生产构建包:

Terminal
- npx expo export
- yarn expo export
- pnpm expo export
- bun expo export

然后,查看 dist/_expo/static/js 目录。其中会有 android 和 ios 目录,每个目录里都有一个 .hbc 文件。.hbc 文件的大小就是你的 Hermes 包的未压缩大小。请注意,Android 和 iOS 包的大小可能不同,尤其是在你使用平台特定代码文件时。

这些文件的名称很长,并包含哈希值。在此示例中,将你想分析的文件重命名为 bundle.hbc。

要确定你的 Hermes 包实际压缩后的大小,也就是应用用户下载时的大小,请运行以下命令:

Terminal
- brotli -5 -k bundle.hbc
- gzip -9 -k bundle.hbc
- ls -lh bundle.hbc.br bundle.hbc.gz

这将生成你的 Hermes 包的 Brotli 和 Gzip 压缩版本(bundle.hbc.br 和 bundle.hbc.gz)并显示它们的大小。你可以利用这些数据,基于应用在真实场景中的更新大小来优化带宽计算。

估算 bundle diff 补丁大小

如果你的项目使用了 bundle diffing,大多数用户下载的是补丁,而不是完整的 bundle。补丁仅包含设备上已有的 bundle 与新 bundle 之间的差异,因此通常比完整更新小得多。将 bundle diffing 的影响纳入考量,可以更准确地估算带宽用量。

EAS Update 使用 bsdiff 算法生成补丁。你可以在本地运行相同的算法来比较自己的两个 bundle。首先,安装 bsdiff:

Terminal
- brew install bsdiff

接下来,导出应用两次:一次使用用户当前运行的版本,另一次使用包含新更改的版本。对于每次导出,运行 npx expo export,在 dist 文件夹中生成 bundle。将两个 .hbc 文件分别重命名为 old.hbc 和 new.hbc。

然后生成补丁并查看其大小:

Terminal
- bsdiff old.hbc new.hbc patch.bin
- ls -lh patch.bin

patch.bin 的大小大致相当于用户从旧 bundle 更新到新 bundle 时的下载大小。补丁已经经过压缩,因此无需考虑压缩算法的影响。

每个补丁都不一样。尝试进行各种幅度较小或较大的代码更改,看看 bundle diffing 对你自己的应用有什么影响。

在正常情况下,大多数用户下载的是补丁,而不是完整 bundle,但在某些情况下,EAS Update 可能会回退为提供完整 bundle(参见当前限制)。bundle diffing 的实际影响还会因内嵌 bundle 是否启用了 diffing 而有所不同。

影响带宽消耗的因素

实际带宽用量会因以下因素而有所不同:

  • 用户行为: 理论计算假设每个用户都会下载每次更新。然而,许多用户只会在重新打开应用时获取更新,往往会跳过中间更新。因此,实际带宽用量通常远低于理论最大值。
  • 缺失的资源: 如果某次更新包含字体和图片等资源,而这些资源在当前构建或之前下载的更新中尚未存在于设备上,那么它们也需要被下载。

优化带宽用量

  1. 先监控用量: 管理带宽最简单的方法是跟踪你的用量指标,并找出任何异常峰值或低效之处。
  2. 优化资源大小: 使用本指南减小资源体积。
  3. 在需要时排除资源: 使用资源选择减少每次更新中包含的资源数量。这是一种高级优化,应优先尝试其他方法。