运行时版本和更新

了解不同的运行时版本策略以及它们如何适合你的项目。

运行时版本是保证构建的原生代码和更新之间的兼容性的属性。当项目被制作成构建时，构建将包含一些无法通过更新更改的原生代码。因此，更新必须与构建的原生代码兼容才能在构建上运行。

¥Runtime versions are a property that guarantees compatibility between a build's native code and an update. When a project is made into a build, the build will contain some native code that cannot be changed with an update. Therefore, an update must be compatible with a build's native code to run on the build.

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

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

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

¥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. The "runtimeVersion" property allows us to guarantee that an update is compatible with a specific build's native code.

由于更新必须与构建的原生代码兼容，因此每次更新原生代码时，我们都需要在发布更新之前进行新的构建。一些开发者仅在升级到新的 Expo SDK 时更新原生代码，而其他开发者可能会在构建之间或以其他时间间隔升级原生代码。以下是对可能适合你的项目的不同情况和配置的说明。

¥Since updates must be compatible with a build's native code, any time native code is updated, we're required to make a new build before publishing an update. Some developers only update native code when upgrading to a new Expo SDK, while others may upgrade native code between builds or at other intervals. Below is an explanation of different situations and configurations that may suite your project.

设置 "runtimeVersion"

¥Setting "runtimeVersion"

为了在构建和更新之间更轻松地管理 "runtimeVersion" 属性，我们创建了从项目中已存在的另一条信息中派生运行时版本的策略。如果这些策略与项目的开发流程不匹配，还可以选择手动设置 "runtimeVersion"。

¥To make managing the "runtimeVersion" property easier between builds and updates, we've created policies that derive the runtime version from another piece of information already present in your project. If these policies do not match the development flow of a project, there's also an option to set the "runtimeVersion" manually.

服务器组件

¥Runtime version policies

可用的策略记录在 expo-updates 库文档 中。

¥The available policies are documented in the expo-updates library documentation.

自定义运行时版本

¥Custom runtime version

你还可以设置满足 运行时版本格式要求 的自定义运行时版本：

¥You can also set a custom runtime version that meets the runtime version formatting requirements:

{
  "expo": {
    "runtimeVersion": "1.0.0"
  }
}

对于想要手动管理运行时版本（与项目应用配置中存在的任何其他版本号分开）的开发者来说，此选项非常有用。它使开发者可以完全控制哪些更新与哪些版本兼容。

¥This option is good for developers who want to manage the runtime version manually, separately from any other version numbers present in a project's app config. It gives the developer complete control over which updates are compatible with which builds.

平台特定运行时版本

¥Platform-specific runtime version

你还可以为每个平台设置运行时版本，例如

¥You can also set runtime version per-platform, for example

{
  "expo": {
    "android": {
      "runtimeVersion": "1.0.0"
    }
  }
}

或者：

¥Or:

{
  "expo": {
    "android": {
      "runtimeVersion": {
        "policy": "appVersion"
      }
    }
  }
}

当同时设置顶层运行时和特定于平台的运行时时，特定于平台的运行时优先。

¥When both a top level runtime and a platform specific runtime are set, the platform specific one takes precedence.

避免不兼容的更新

¥Avoiding incompatible updates

发布更新时可能出现的主要问题是更新可能依赖于其运行的版本不支持的原生代码。例如，假设我们使用 "1.0.0" 的运行时版本进行了构建。然后，我们将该版本提交给应用商店并向公众发布。

¥The main issue that can arise when publishing updates is that the update could rely on native code that the build it's running on does not support. For instance, imagine we made a build with a runtime version of "1.0.0". Then, we submitted that build to the app stores and released it to the public.

后来，假设我们开发了一个依赖于新安装的原生库的更新，例如 expo-camera 库，并且我们没有更新 "runtimeVersion" 属性，因此它仍然是 "1.0.0"。如果我们发布更新，使用 "runtimeVersion" 或 "1.0.0" 的构建会认为具有相同运行时版本的传入更新是兼容的，并且会尝试加载更新。由于更新会调用构建中不存在的代码，expo-updates 可能会检测到错误并尝试回滚到之前正常工作的更新 (了解更多关于错误恢复行为的信息)。

¥Later on, imagine that we developed an update that relied on a newly installed native library, like the expo-camera library, and we did not update the "runtimeVersion" property, so that it is still "1.0.0". If we published an update, the builds with the "runtimeVersion" of "1.0.0" would think the incoming update with the same runtime version was compatible and it would attempt to load the update. Since the update would make calls to code that does not exist inside the build, expo-updates may detect an error and attempt to roll back to the previously working update (learn more about error recovery behavior).

以下是一些避免部署与构建原生代码不兼容的更新的策略。

¥The following are some strategies to avoid deploying updates that are incompatible with a build's native code.

使用运行时版本策略，在原生代码更新时自动更新运行时版本

¥Use a runtime version policy that automatically updates the runtime version when native code is updated

"appVersion" 策略会在应用版本升级时同步更新运行时版本，但如果你在更改原生运行时时忘记更新应用版本，则会导致运行时版本不匹配。如果你想以更频繁地创建版本为代价，尽可能减少不兼容的更新，那么你可以使用 "fingerprint" 策略。每当发生任何可能影响原生运行时 (了解更多关于指纹识别的信息) 的更改时，这将递增运行时版本号。

¥The "appVersion" policy will increment the runtime version whenever the app version is incremented, but if you forget to bump the app version when changing the native runtime, then you'll have a runtime version mismatch. If you want to make incompatible updates extremely unlikely, at the cost of making it necessary to create builds more often, then you can use the "fingerprint" policy. This will increment the runtime version whenever anything that may impact the native runtime changes (learn more about fingerprinting).

手动增加运行时版本

¥Manually increment the runtime version

每当安装或更新原生代码时，手动增加 "runtimeVersion" 属性 都会在项目的 应用配置 中生效。

¥Whenever installing or updating native code, manually increment the "runtimeVersion" property in the project's app config.

逐步推出更新

¥Roll out the update gradually

如果你不确定新更新的影响，可以先将其推广到一小部分用户。使用 rollouts 将更新发布给一小部分用户，并在 EAS 控制面板上监控更新的错误率。如果你发现错误率很高，请取消部署。如果你已经完全部署了 回滚。

¥If you're not sure about the impact of a new update, you can roll it out to a small group of users first. Use rollouts to publish the update to a small percentage of users and monitor the error rate for the update on the EAS dashboard. If you are noticing high error rates, then cancel the rollout. If you already rolled it out fully, then roll it back.

手动与较小用户组验证更新

¥Manually verify updates with a smaller group of users

部署到生产环境时，请创建一个使用相同运行时但指向不同渠道的预览构建。在将这些更新发布到生产环境之前，请先在这些版本上测试你的更新（更多信息请参阅 部署指南）。或者，你可以通过在运行时覆盖更新参数 (了解更多)，选择让应用的某些用户接收更新。

¥When you deploy to production, create a preview build that uses the same runtime but points to a different channel. Test your updates on those builds before promoting them to production (learn more about this in the deployment guide). Alternatively, you can opt-in certain users of your app to receive the update by overriding update parameters at runtime (learn more).