EAS 更新工作原理的概念性概述。

---

EAS 更新是一项服务，可让你在开发下一个应用商店版本时立即向用户提供小错误修复和更新。使更新可用于构建涉及在构建和更新之间创建链接。

¥EAS Update is a service that allows you to deliver small bug fixes and updates to your users immediately as you work on your next app store release. Making an update available to builds involves creating a link between a build and an update.

要在构建和更新之间创建链接，我们必须确保更新可以在构建上运行。我们还希望确保可以创建一个部署流程，以便在准备就绪时可以向某些构建公开某些更新。

¥To create a link between a build and an update, we have to make sure the update can run on the build. We also want to make sure we can create a deployment process so that we can expose certain updates to certain builds when we're ready.

为了说明构建和更新如何交互，请看下图：

¥To illustrate how builds and updates interact, take a look at the following diagram:

构建可以被认为是两层：内置于应用二进制文件中的原生层和可与其他兼容更新交换的更新层。这种分离允许我们将错误修复发送到构建，只要错误修复的更新可以在构建内的原生层上运行。

¥Builds can be thought of as two layers: a native layer that's built into the app's binary, and an update layer, that is swappable with other compatible updates. This separation allows us to ship bug fixes to builds as long as the update with the bug fix can run on the native layer inside the build.

为了确保更新可以在构建上运行，我们必须设置各种属性，以便我们可以确保我们的构建可以运行更新。当我们创建项目的构建时，这一切就开始了。

¥To make sure the update can run on the build, we have to set a variety of properties so that we can be sure our builds can run our updates. This starts when we create a build of our project.

概念概述

¥Conceptual overview

分发构建

¥Distributing builds

当我们准备好创建 Expo 项目的构建时，我们可以运行 eas build 来创建构建。在构建过程中，该过程将在构建中包含一些对于更新很重要的属性。他们是：

¥When we're ready to create a build of our Expo project, we can run eas build to create a build. During the build, the process will include some properties inside the build that are important for updates. They are:

• 渠道：通道是我们可以为多个构建指定的名称，以便轻松识别它们。它在 eas.json 中定义。例如，我们可能有一个 Android 和一个 iOS 版本，其通道名为 "production"，而我们还有另一对版本，其通道名为 "staging"。然后，我们可以将 "production" 渠道的构建分发到公共应用商店，同时将 "staging" 构建保留在 Play Store Internal Track 和 TestFlight 上。稍后当我们发布更新时，我们可以首先将其提供给具有 "staging" 通道的构建；然后，一旦我们测试了我们的更改，我们就可以通过 "production" 通道将更新提供给构建。

  ¥Channel: The channel is a name we can give to multiple builds to identify them easily. It is defined in eas.json. For instance, we may have an Android and an iOS build with a channel named "production", while we have another pair of builds with a channel named "staging". Then, we can distribute the builds with the "production" channel to the public app stores, while keeping the "staging" builds on the Play Store Internal Track and TestFlight. Later when we publish an update, we can make it available to the builds with the "staging" channel first; then once we test our changes, we can make the update available to the builds with the "production" channel.

• 运行时版本：运行时版本描述了由运行应用更新层的原生代码层定义的 JS 原生接口。它在项目的应用配置 (app.json/app.config.js) 中定义。每当我们对原生代码进行更改以更改应用的 JS 原生界面时，我们都需要更新运行时版本。了解更多。

  ¥Runtime version: The runtime version describes the JS-native interface defined by the native code layer that runs our app's update layer. It is defined in a project's app config (app.json/app.config.js). Whenever we make changes to our native code that change our app's JS-native interface, we'll need to update the runtime version. Learn more.

• 平台：每个构建都有一个平台，例如 "安卓" 或 "iOS 系统"。

  ¥Platform: Every build has a platform, such as "Android" or "iOS".

如果我们使用名为 "staging" 和 "production" 的通道进行两组构建，我们可以将构建分发到四个不同的位置：

¥If we made two sets of builds with the channels named "staging" and "production", we could distribute builds to four different places:

此图只是一个示例，说明如何创建构建并为其通道命名，以及可以将这些构建放置在何处。最终，这取决于你设置的通道名称以及将这些构建放在哪里。

¥This diagram is just an example of how you could create builds and name their channels, and where you could put those builds. Ultimately it's up to you which channel names you set and where you put those builds.

发布更新

¥Publishing an update

创建构建后，我们可以通过发布更新来更改项目的更新层。例如，我们可以更改 App.js 中的一些文本，然后我们可以将该更改作为更新发布。

¥Once we've created builds, we can change the update layer of our project by publishing an update. For example, we could change some text inside App.js, then we could publish that change as an update.

要发布更新，我们可以运行 eas update --auto。此命令将在我们项目的 dist 目录中创建本地更新包。一旦创建了更新包，它就会将该包上传到 EAS 服务器上名为分支的数据库对象中。分支具有名称并包含更新列表，其中最新更新是分支上的活动更新。我们可以将 EAS 分支视为 Git 分支。正如 Git 分支包含提交列表一样，EAS 分支包含更新列表。

¥To publish an update, we can run eas update --auto. This command will create a local update bundle inside the dist directory in our project. Once it's created an update bundle, it will upload that bundle to EAS servers, in a database object named a branch. A branch has a name and contains a list of updates, where the most recent update is the active update on the branch. We can think of EAS branches just like Git branches. Just as Git branches contain a list of commits, EAS branches contain a list of updates.

匹配更新和构建

¥Matching updates and builds

与构建一样，分支上的每个更新都包含目标运行时版本和目标平台。通过这些字段，我们可以确保更新将在具有更新策略的构建上运行。EAS 的更新政策如下：

¥Like builds, every update on a branch includes a target runtime version and target platform. With these fields, we can make sure that an update will run on a build with something called an update policy. EAS' update policy is as follows:

• 构建的平台和更新的目标平台必须完全匹配。

  ¥The platform of the build and the target platform of an update must match exactly.

• 构建的运行时版本和更新的目标运行时版本必须完全匹配。

  ¥The runtime version of the build and the target runtime version of an update must match exactly.

• 通道可以链接到任何分支。默认情况下，通道链接到同名的分支。

  ¥A channel can be linked to any branch. By default, a channel is linked to a branch of the same name.

让我们关注最后一点。每个构建都有一个通道，作为开发者，我们可以将该通道链接到任何分支，这将使分支上的最新兼容更新可用到链接的通道。为了简化此链接，默认情况下我们自动将通道链接到同名的分支。例如，如果我们使用名为 "production" 的通道创建构建，我们可以将更新发布到名为 "production" 的分支，并且我们的构建将从名为 "production" 的分支获取更新，即使我们没有手动链接任何内容。

¥Let's focus on that last point. Every build has a channel, and we, as developers, can link that channel to any branch, which will make its most recent compatible update available on the branch to the linked channel. To simplify this linking, by default we auto-link channels to branches of the same name. For instance, if we created builds with the channel named "production", we could publish updates to a branch named "production" and our builds would get the updates from the branch named "production", even though we did not manually link anything.

如果你的部署过程中有多个一致的 Git 和 EAS 分支，则此默认链接非常有效。例如，我们可以在 Git 和 EAS 上有一个 "production" 分支和一个 "staging" 分支。与 GitHub 行动 配对，我们可以做到每次提交推送到 "staging" Git 分支时，我们都会发布到 "staging" EAS 更新分支，这将使该更新适用于我们使用 "staging" 通道的所有构建。一旦我们测试了暂存版本的更改，我们就可以将 "staging" Git 分支合并到 "production" Git 分支，这将在 "production" EAS 更新分支上发布更新。最后，"production" EAS 更新分支上的最新更新将适用于使用 "production" 通道的构建。

¥This default linking works great if you have a deployment process where you have multiple consistent Git and EAS branches. For instance, we could have a "production" branch and a "staging" branch, both on Git and on EAS. Paired with a GitHub Action, we could make it so that every time a commit is pushed to the "staging" Git branch, we publish to the "staging" EAS Update branch, which would make that update apply to all our builds with the "staging" channel. Once we tested changes on the staging builds, then we could merge the "staging" Git branch into the "production" Git branch, which would publish an update on the "production" EAS Update branch. Finally, the latest update on the "production" EAS Update branch would apply to builds with the "production" channel.

这个流程使得我们可以推送到 GitHub，然后查看我们的构建更新，而无需任何其他干预。

¥This flow makes it so that we can push to GitHub, then see our builds update without any other interventions.

虽然此流程适用于许多开发者，但我们可以完成另一个流程，因为我们能够更改通道和分支之间的链接。想象一下，我们将分支命名为 "版本-1.0"、"版本-2.0" 和 "版本 3.0"。我们可以将 "版本-1.0" EAS 更新分支链接到 "production" 通道，以使其可用于我们的 "production" 版本。我们还可以将 "版本-2.0" EAS 更新分支链接到 "staging" 通道，以供测试人员使用。最后，我们可以创建一个尚未链接到任何构建的 "版本 3.0" EAS 更新分支，只有开发者才能使用开发构建进行测试。

¥While this flow works for many developers, there's another flow we can accomplish since we have the ability to change the link between channels and branches. Imagine we name our branches like "version-1.0", "version-2.0", and "version-3.0". We could link the "version-1.0" EAS Update branch to the "production" channel, to make it available to our "production" builds. We could also link the "version-2.0" EAS Update branch to the "staging" channel to make it available to testers. Finally, we could make a "version-3.0" EAS Update branch that is not linked to any builds yet, that only developers are testing with a development build.

一旦测试人员验证 "版本-2.0" EAS 更新分支上的更新已准备好用于生产，我们就可以更新 "production" 通道，以便将其链接到 "版本-2.0" 分支。为了实现这一点，我们可以运行：

¥Once testers verify that the update on the "version-2.0" EAS Update branch is ready for production, we can update the "production" channel so that it's linked to the "version-2.0" branch. To accomplish this, we could run:

在此状态之后，我们就准备开始测试 "版本 3.0" EAS 更新分支。与上一步类似，我们可以使用以下命令将 "staging" 通道链接到 "版本 3.0" EAS 更新分支：

¥After this state, we'd be ready to start testing the "version-3.0" EAS Update branch. Similarly to the last step, we could link the "staging" channel to the "version-3.0" EAS Update branch with this command:

实用概述

¥Practical overview

现在我们已经熟悉了 EAS 更新的核心概念，我们来谈谈这个过程是如何发生的。

¥Now that we're familiar with the core concepts of EAS Update, let's talk about how this process occurs.

当构建包含 expo-updates 的 Expo 项目时，包含的原生 Android 和 iOS 代码负责管理、获取、解析和验证更新。

¥When an Expo project that includes expo-updates is built the included native Android and iOS code is responsible for managing, fetching, parsing, and validating updates.

当库检查更新并下载更新时，它们是 configurable。默认情况下，该库将在打开时检查更新。如果发现比当前正在运行的更新更新的更新，它将下载并运行较新的更新。如果库没有找到较新的更新，它将运行最新下载的更新，如果尚未下载，则回退到构建时嵌入应用内的更新。

¥When the library checks for updates and when it downloads them, they are configurable. By default, the library will check for an update when it is opened. If an update newer than the currently running update is found, it will download and run the newer update. If the library does not find a newer update, it will instead run the newest downloaded update, falling back to the update that was embedded inside the app at build time if none have been downloaded.

expo-updates 分两个阶段下载更新。首先，它下载最新的更新清单，其中包含有关更新的信息，包括运行更新所需的资源列表（图片、JavaScript 打包包、字体文件等）。其次，库会下载清单中指定的尚未从之前的更新中下载的资源。例如，如果更新包含新图片，则库将在运行更新之前下载新图片资源。为了帮助终端用户快速可靠地获得更新，更新应尽可能小。

¥expo-updates downloads updates in two phases. First, it downloads the most recent update manifest, which contains information about the update including a list of assets (images, JavaScript bundles, font files, and so on) that are required to run the update. Second, the library downloads the assets specified in the manifest that it has not yet downloaded from prior updates. For instance, if an update contains a new image, the library will download the new image asset before running the update. To help end-users get updates quickly and reliably, updates should be kept as small as possible.

如果库能够在 fallbackToCacheTimeout 设置之前下载清单（第 1 阶段）和所有必需的资源（第 2 阶段），则新更新将在启动后立即运行。如果库无法在 fallbackToCacheTimeout 内获取清单和资源，它将继续在后台下载新更新，并在下次启动时运行它。

¥If the library is able to download the manifest (phase 1) and all the required assets (phase 2) before the fallbackToCacheTimeout setting, then the new update will run immediately upon launch. If the library is not able to fetch the manifest and assets within fallbackToCacheTimeout, it will continue to download the new update in the background and will run it upon the next launch.

包起来

¥Wrap up

通过 EAS 更新，我们可以快速向用户提供小型、关键的错误修复，并为用户提供最佳体验。这是通过构建的运行时版本、平台和通道来设置的。有了这三个约束，我们就可以为特定的构建组提供更新。这使我们能够在部署过程中投入生产之前测试我们的更改。根据我们设置部署流程的方式，我们可以优化速度。我们还可以优化我们的部署，使其尽可能安全、无错误。部署的可能性是巨大的，几乎可以匹配你喜欢的任何发布过程。

¥With EAS Update, we can quickly deliver small, critical bug fixes to our users and give users the best experience possible. This is set up with a build's runtime version, platform, and channel. With these three constraints, we can make an update available to a specific group of builds. This allows us to test our changes before going to production within a deployment process. Depending on how we set up our deployment process, we can optimize for speed. We can also optimize our deployments to be as safe a bug-free as possible. The deployment possibilities are vast and can match nearly any release process you prefer.