This documentation is available as Markdown for AI agents and LLMs. See the full Markdown index or append .md to any documentation URL.
估计带宽使用情况
了解如何估算 EAS 更新的带宽使用情况。
了解更新带宽使用情况
🌐 Understanding update bandwidth usage
EAS 更新使应用能够通过空中传输更新其非原生部分（如 JavaScript、样式和图片）。本指南解释了带宽的使用情况以及如何优化带宽消耗。
🌐 EAS Update enables an app to update its own non-native pieces (such as JavaScript, styling, and images) over-the-air. This guide explains how bandwidth is consumed and how consumption can be optimized.
带宽计算细目
🌐 Bandwidth calculation breakdown
每个订阅计划都包括每月账单周期内的预定义带宽分配，以及每月活跃用户（MAU）分配（了解有关 MAU 计算方式的更多信息）。超出标准分配的 MAU 将按按使用量计费的费率收取费用，每增加一个额外的 MAU，你的标准带宽分配将增加 40 MiB。此带宽决定了你的用户在被收取额外带宽使用费用之前可以下载的更新数量。
🌐 Each subscription plan includes a predefined bandwidth allocation per monthly billing period in addition to its monthly active user (MAU) allocation (learn more about how MAU are calculated). MAU's beyond the standard allocation are billed at usage-based pricing rates, and each of those additional MAU add an extra 40 MiB to your standard bandwidth allocation. This bandwidth determines the number of updates your users can download before being charged for additional bandwidth usage.
以下是如何估计每次更新的带宽使用量：
🌐 Here's how to estimate bandwidth usage per update:
-
更新大小： 带宽消耗的关键因素是设备上尚未存在的更新资源的大小。如果一次更新仅修改了应用的 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，它包含 50,000 个 MAU 和 每月 1 TiB（1,024 GiB）带宽。通过按使用量计费购买的额外 10,000 个 MAU 会获得每个 MAU 额外 40 MiB 的带宽。可以下载的总更新数量为：
🌐 Given a bandwidth allocation, we estimate how many updates can be downloaded in a monthly billing period before additional bandwidth charges apply. For example, if you have 60,000 MAUs on a production plan, it includes 50,0000 MAU and 1 TiB (1,024 GiB) of bandwidth per month. An additional 10,000 MAUs purchased through usage-based pricing receives an additional 40 MiB of bandwidth per MAU. The total number of updates that can be downloaded is:
(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
测量你的实际更新大小
🌐 Measuring your actual update size
首先使用以下命令生成未压缩的生产包：
🌐 Start by generating your uncompressed production bundle with the following command:
然后，查看 dist/_expo/static/js 目录。里面会有 android 和 ios 目录，每个目录中都有一个 .hbc 文件。.hbc 文件的大小就是你的 Hermes bundle 的未压缩大小。请注意，Android 和 iOS 的 bundle 大小可能不同，尤其是在你使用平台特定的代码文件时。
🌐 Then, look inside the dist/_expo/static/js directory. There will be android and ios directories with a .hbc file in each. The size of the .hbc file is the uncompressed size of your Hermes bundle. Note that Android and iOS bundles may differ in size, especially if you make use of platform-specific code files.
这些文件的文件名很长，并且包含哈希值。在此示例中，将你想要分析的文件重命名为 bundle.hbc。
🌐 These files have long names that include a hash. For this example, rename the file you would like to analyze to bundle.hbc.
要确定 Hermes 包的实际压缩大小，即应用用户下载时的大小，请运行以下命令：
🌐 To determine the actual compressed size of your Hermes bundle, which is how large it will be when downloaded by app users, run the following commands:
这将生成你的 Hermes 包的 Brotli 和 Gzip 压缩 版本（bundle.hbc.br 和 bundle.hbc.gz）并显示它们的大小。你可以使用它来根据应用的实际更新大小优化带宽计算。
🌐 This will generate Brotli- and Gzip-compressed versions of your Hermes bundle (bundle.hbc.br and bundle.hbc.gz) and display their sizes. You can use this to refine bandwidth calculations based on your app's real-world update sizes.
估算打包差异补丁大小
🌐 Estimating bundle diff patch size
如果你的项目使用包差异化，大多数用户下载的是补丁而不是完整的包。补丁只包含设备上已有包和新包之间的差异，所以通常比完整更新小得多。考虑包差异化的影响可以让你对带宽使用量有一个更实际的估计。
🌐 If your project uses bundle diffing, most users download a patch rather than the full bundle. A patch contains only the differences between the bundle already on the device and the new bundle, so it is usually much smaller than the full update. Incorporating the impact of bundle diffing can give you a more realistic estimate for bandwidth usage.
EAS 更新使用 bsdiff 算法 生成补丁。你也可以在本地运行相同的算法来比较自己两个包。首先，安装 bsdiff：
🌐 EAS Update generates patches with the bsdiff algorithm. You can run the same algorithm locally to compare two of your own bundles. First, install bsdiff:
接下来，将你的应用导出两次：一次是你用户当前运行的版本，一次是带有你新改动的版本。每次导出后，运行 npx expo export 在 dist 文件夹内生成 bundle。将两个 .hbc 文件重命名为 old.hbc 和 new.hbc。
🌐 Next, export your app twice: once at the version your users currently run, and once with your new changes. For each export, run npx expo export to generate the bundle inside the dist folder. Rename the two .hbc files to old.hbc and new.hbc.
然后生成补丁并检查它的大小：
🌐 Then generate the patch and check its size:
patch.bin 的大小大致就是用户从旧包迁移到新包时需要下载的大小。补丁已经压缩好了，所以你不用考虑压缩算法的影响。
🌐 The size of patch.bin is the approximate download size for a user who moves from the old bundle to the new one. The patch is already compressed, so you do not need to factor in the compression algorithm.
每个补丁都不同。尝试一系列小范围和大范围的代码修改，看看 bundle 差异对你自己的应用有什么影响。
🌐 Every patch is different. Try a range of smaller and larger code changes to see the impact of bundle diffing on your own app.
在正常情况下，大多数用户会下载补丁而不是完整包，但在某些情况下，EAS 更新可能会回退为提供完整包（参见 当前限制）。完整包差异化的实际影响也会根据嵌入包是否启用了差异化而有所不同。
🌐 Under normal circumstances, most users download patches instead of full bundles, but EAS Update may fall back to serving the full bundle in some cases (see current limitations). The actual impact of bundle diffing also varies based on whether diffing is enabled for the embedded bundle.
影响带宽消耗的因素
🌐 Factors that affect bandwidth consumption
实际带宽使用情况因以下因素而异：
🌐 Actual bandwidth usage varies due to:
- **用户行为：**理论计算假设每个用户都会下载每一个更新。然而，许多用户只有在重新打开应用时才会获取更新，经常会跳过中间的更新。因此，实际使用的带宽通常远低于理论最大值。
- 缺失的资源： 如果更新包含设备上尚未存在的资源，如字体和图片（无论是从版本构建还是之前下载的更新中），也需要下载这些资源。
优化带宽使用
🌐 Optimizing bandwidth usage