运行时版本和更新

编辑页面

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

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

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

可以将构建版本理解为两层：一层是内置于应用二进制文件中的原生层，另一层是可与其他兼容更新互换的更新层。通过这种分离，只要包含修复的更新能够在构建版本内的原生层上运行，我们就可以向构建版本推送 bug 修复。"runtimeVersion" 属性使我们能够保证某个更新与特定构建版本的原生代码兼容。

由于更新必须与构建版本的原生代码兼容，因此每当原生代码更新时，我们都必须先制作一个新的构建版本，然后才能发布更新。有些开发者只会在升级到新的 Expo SDK 时更新原生代码，而另一些开发者可能会在不同构建版本之间或其他时间间隔更新原生代码。下面将解释一些可能适合你项目的不同情况和配置。

设置 `"runtimeVersion"`

为了让在构建版本和更新之间管理 "runtimeVersion" 属性更容易，我们创建了若干策略，可根据项目中已存在的另一项信息推导出 runtime version。如果这些策略不符合项目的开发流程，也可以选择手动设置 "runtimeVersion"。

Runtime version 策略

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

自定义 runtime version

你也可以设置一个符合 runtime version 格式要求的自定义 runtime version：

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

对于希望手动管理 runtime version、并将其与项目 app config 中存在的其他版本号分开管理的开发者来说，这个选项很合适。它让开发者能够完全控制哪些更新与哪些构建版本兼容。

平台特定的 runtime version

你也可以按平台设置 runtime version，例如

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

或者：

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

当同时设置了顶层 runtime 和平台特定 runtime 时，平台特定的设置优先生效。

避免不兼容的更新

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

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

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

使用会在原生代码更新时自动更新 runtime version 的策略

"appVersion" 策略会在 app version 增加时同步增加 runtime version，但如果你在更改原生 runtime 时忘记提升 app version，就会导致 runtime version 不匹配。如果你想让不兼容更新的可能性极低，代价是需要更频繁地创建构建版本，那么可以使用 "fingerprint" 策略。它会在任何可能影响原生 runtime 的内容发生变化时增加 runtime version（了解更多关于 fingerprinting 的信息）。

手动递增 runtime version

每当安装或更新原生代码时，在项目的 app config 中手动递增 "runtimeVersion" 属性。

逐步发布更新

如果你不确定新更新的影响，可以先向一小部分用户发布。使用 rollouts 将更新发布给一小部分用户，并在 EAS 控制台上监控该更新的错误率。如果你发现错误率较高，就取消 rollout。如果你已经完全发布了它，那么就回滚它。

用更小的用户群手动验证更新

当你部署到生产环境时，创建一个使用相同 runtime 但指向不同 channel 的预览构建版本。在将更新推广到生产环境之前，先在这些构建版本上测试你的更新（在部署指南中了解更多）。或者，你也可以通过在运行时覆盖更新参数，让应用中的某些用户接收该更新（了解更多）。