EAS 更新调试

了解如何使用基本调试技术修复更新问题。

本指南展示了如何验证我们的配置，以便我们能够找到类似应用未显示已发布更新的问题的根源。能够随时了解我们应用的当前状态非常重要，因此 EAS Update 就是基于这一点构建的。一旦我们知道哪些更新正在运行在哪些构建上，我们就可以进行调整，使我们的应用处于预期的状态。

🌐 This guide shows how to verify our configuration so that we can find the source of problems like an app not showing a published update. It's important to tell the current state of our app at any given time, so EAS Update was built with this in mind. Once we know which updates are running on which builds, we can make changes so that our apps are in the state we expect.

如何调试 EAS 更新

在本次 Expo 调试教程中，你将学习如何调试构建未更新的情况。

如果我们没有使用 EAS Build，部署页面将为空。请改为按照在不使用 EAS Build 时调试配置指南进行操作。

进入部署页面

🌐 Go to the Deployments page

EAS 网站有一个部署页面，显示我们应用的当前状态。术语部署指一组构建及其相应的更新。如果我们使用 EAS 进行了构建和更新，我们可以在网站的部署标签中查看项目的状态。

🌐 The EAS website has a Deployments page that shows the current state of our app. The term deployment refers to a group of builds and their corresponding updates. If we've made builds and updates with EAS, we can see our project's status on the website in the Deployments tab.

常见问题

🌐 Common problems

以下部分介绍了常见问题及其解决方法。下面是 EAS 更新的工作示意图，以及在查找问题根本原因时值得检查的位置。在接下来的部分中，我们将检查并验证这些位置及更多内容。

🌐 The following section describes common problems and how to fix them. Below is a diagram of how EAS Update works and the spots that are useful to inspect when finding the root cause of an issue. In the following sections, we'll inspect and verify these spots and more.

意想不到的通道

🌐 Unexpected channel

如果部署渠道异常，说明我们的构建没有使用正确的渠道。要解决此问题，请配置我们的渠道并重新构建应用。

🌐 If the deployment channel is unexpected, it means our build was not built with the correct channel. To fix this, configure our channel and rebuild our app.

意外的运行时版本

🌐 Unexpected runtime version

如果部署运行时版本不符合预期，这意味着我们的构建没有使用正确的运行时版本。要解决此问题，请配置我们的运行时版本并重新构建应用。

🌐 If the deployment runtime version is unexpected, it means our build was not built with the correct runtime version. To fix this, configure our runtime version and rebuild our app.

意想不到的分支

🌐 Unexpected branch

如果部署出现意外的分支，我们需要将我们的通道映射到正确的分支。

🌐 If the deployment has an unexpected branch, we need to map our channel to the correct branch.

缺少更新

🌐 Missing updates

所显示的部署没有任何更新。要解决此问题，请向该分支发布更新。如果更新已经发布，请检查更新页面以确保其与我们构建的运行时版本匹配。

🌐 The displayed deployment does not have any updates. To fix this, publish an update to the branch. If an update was already published, check the Updates page to make sure it matches the runtime version of our build.

缺少分支

🌐 Missing branch

显示的部署有正确的渠道，但它未链接到任何分支。要解决此问题，请将渠道映射到正确的分支。

🌐 The displayed deployment has the correct channel, but it is not linked to a branch. To fix this, map the channel to the correct branch.

缺少部署

🌐 Missing deployment

如果我们的部署没有显示，这意味着我们的构建没有正确配置以使用 EAS 更新。要解决此问题，请配置我们的通道、配置我们的运行时版本并验证我们的通用配置。在进行这些更改后，我们需要重新构建应用。

🌐 If our deployment is not displayed, it means our build is not configured properly for EAS Update. To fix this, configure our channel, configure our runtime version and verify our general configuration. We'll need to rebuild our app after making these changes.

更新崩溃时自动回滚

🌐 Automatic roll back when an update crashes

如果在部署页面上所有内容看起来都正确，但你的应用仍然显示以前的更新或与构建一起嵌入的代码，那么你的新更新代码可能正在崩溃。这可能发生在应用下载并应用新更新后，新更新在根组件渲染之前就崩溃了。

🌐 If everything looks correct on the Deployments page, but your app still shows the previous update or the code embedded with the build, your new update's code may be crashing. This can happen when this new update crashes before the root component renders after the app downloads and applies the new update.

EAS 更新旨在在检测到新更新在启动后不久就崩溃时，自动回滚到之前的更新版本。有关详细信息，请参见 EAS 更新如何检测崩溃并回滚到之前可用版本。

🌐 EAS Update is designed to automatically roll back to the previous update if it detects that a new update crashed shortly after launch. See how EAS Update detects crashes and rolls back to a previous working version for more information.

要诊断导致更新崩溃的错误：

🌐 To diagnose the error causing the update crash:

请参阅运行时问题故障排除指南以采用策略来识别错误。
识别错误后，发布修复崩溃的新更新以解决问题。

新更新无法工作而嵌入代码可以工作的一个常见原因是缺少环境变量。有关更多信息，请参见环境变量在 EAS 更新中的工作方式。

🌐 A common reason a new update does not work but embedded code does is due to a missing environment variable. See how environment variables work with EAS Update for more information.

无法加载所有资源

🌐 Failed to load all assets

如果你的用户看到“无法加载所有资源”错误，这意味着应用能够下载清单文件，但无法下载运行更新所需的所有资源。如果某个资源在原始构建中不存在，就需要下载该资源。常见的错误原因有：

🌐 If your users are seeing a "Failed to load all assets" error, it means that the app was able to download the manifest but could not download all of the assets required for the update to run. An asset will need to be downloaded if it is not present in the original build. Common reasons for error are:

更新中添加了许多大型资源，由于网络问题，应用无法全部下载。
用户的网络连接状况不佳。
用户所在的国家/地区屏蔽或限制了 Cloudflare IP 地址，而 EAS Update 会使用这些 IP 地址来提供资源。

要诊断资源加载问题：

🌐 To diagnose the asset loading issue:

通过查看资源列表来验证用户下载了哪些资源及其大小。
在你自己的设备上重现该问题，并检查来自本地层的 expo-updates 日志条目。
如果你已在 Sentry 等服务中记录了此错误，请检查遇到此错误的用户的 IP 地址，并确认该用户不在已知会阻止或限制 Cloudflare IP 地址的国家/地区。

解决方案

🌐 Solutions

配置通道

🌐 Configure channel

要验证构建是否具有特定的渠道，请确保我们在 eas.json 中的构建配置文件具有 channel 属性：

🌐 To verify that a build has a specific channel, make sure our build profile in eas.json has a channel property:

eas.json

{
  "build": {
    "preview": {
      "distribution": "internal",
      "channel": "preview"
    },
    "production": {
      "channel": "production"
    }
  }
}

然后，我们可以运行类似 eas build --profile preview 的命令来创建一个名为“preview”的通道的构建。

🌐 Then, we can run a command like eas build --profile preview to create a build with a channel named "preview".

配置运行时版本

🌐 Configure runtime version

为了验证我们的运行时版本，我们需要确认应用配置（app.json/app.config.js）中具有 runtimeVersion 属性：

🌐 To verify our runtime version, we make sure our app config (app.json/app.config.js) has a runtimeVersion property:

app.json

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

默认情况下，它是 { "policy": "appVersion" }，但我们可以更改运行时以使用不同的策略或特定版本。然后，我们可以运行像 eas build --profile preview 这样的命令来创建一个具有预期运行时版本的构建。

🌐 By default, it is { "policy": "appVersion" }, but we can change our runtime to use a different policy or a specific version. Then, we can run a command like eas build --profile preview to create a build with the runtime version we expect.

将通道映射到分支

🌐 Map channel to branch

如果通道未映射到我们期望的分支，我们可以使用以下命令更改链接：

🌐 If the channel is not mapped to the branch we expect, we can change the link with:

Terminal

# eas channel:edit [channel-name] --branch [branch-name]
# Example

- eas channel:edit production --branch release-1.0

如果我们的分支未列出，我们可以使用 eas branch:create 创建一个新分支。

🌐 If our branch is not listed, we can create a new branch with eas branch:create.

发布更新

🌐 Publish update

要创建并发布更新，我们可以运行以下命令：

🌐 To create and publish an update, we can run the following command:

Terminal

- eas update

发布后，输出将显示分支和运行时版本。这些信息可以帮助我们验证是否正在使用预期的配置创建更新。

🌐 After publishing, the output will display the branch and the runtime version. This information can help us verify that we're creating an update with the configuration we expect.

一般策略

🌐 General strategies

在使用本指南中提到的更具体的策略之前，请先尝试这些策略。

🌐 Try these strategies before using the more specific ones mentioned in this guide.

使用 `expo-dev-client`

🌐 Use expo-dev-client

创建我们的构建的开发版本。它将帮助我们在有问题的构建中预览已发布的更新。

🌐 Create a development version of our build. It will help us preview published updates inside a problematic build.

应用内调试

🌐 In-app debugging

expo-updates 库导出多种函数，用于在应用已经运行时与更新进行交互。在某些情况下，调用获取更新并看到错误消息可以帮助我们缩小根本原因范围。我们可以制作该项目的模拟器构建版本，并手动检查是否有可用更新，或者在获取更新时是否出现错误。

🌐 The expo-updates library exports a variety of functions to interact with updates once the app is already running. In certain cases, making a call to fetch an update and seeing an error message can help us narrow down the root cause. We can make a simulator build of the project and manually check to see if updates are available or if there are errors when fetching updates.

打印 Update.Constants 以验证我们的配置。
检查日志条目来自原生层。
获取并手动加载更新。

配置问题

🌐 Configuration issues

尽管我们按照基础指南操作，我们的应用仍未收到预期的更新。

🌐 Our app is still not receiving the expected update despite following the basic guide.

`expo-updates` 配置

🌐 expo-updates configuration

expo-updates 库运行在终端用户的应用中，并向更新服务器发送请求以获取最新更新。

🌐 The expo-updates library runs inside an end-user's app and makes requests to an update server to get the latest update.

验证应用配置

🌐 Verifying app configuration

当我们设置 EAS Update 时，我们很可能运行了 eas update:configure 来配置 expo-updates 以配合 EAS Update 使用。此命令会对我们的应用配置（app.json/app.config.js）进行更改。以下是我们预计会看到的字段：

🌐 When we set up EAS Update, we likely ran eas update:configure to configure expo-updates to work with EAS Update. This command makes changes to our app config (app.json/app.config.js). Here are the fields we'd expect to see:

runtimeVersion 应该被设置。默认情况下，它是 { "policy": "appVersion" }。如果我们的项目有 android 和 ios 目录，我们将不得不手动设置 runtimeVersion。
updates.url 应该是类似 https://u.expo.dev/your-project-id 的值，其中 your-project-id 与我们项目的 ID 相匹配。我们可以在我们的网站上看到这个 ID。
updates.enabled 不应该是 false。如果未指定，默认是 true。

最后，确保 expo-updates 已包含在 package.json 中。如果没有，运行：

🌐 Finally, make sure that expo-updates is included in package.json. If it's not, run:

Terminal

- npx expo install expo-updates

预构建后检查 expo-updates 配置

🌐 Inspecting expo-updates configuration after prebuild

每当我们运行 eas build 时，npx expo prebuild 命令会在我们的项目上在 EAS 服务器上执行，用于解压包含原生文件的 android 和 ios 目录。这使得 EAS Build 可以构建任何项目，无论它是否包含原生文件。

🌐 Whenever we run eas build, the npx expo prebuild command is run on our project on EAS servers to unpack the android and ios directories that contain native files. This makes it so EAS Build can build any project, whether it includes the native files or not.

如果我们的项目没有 android 或 ios 目录，我们可以提交任何现有更改，然后运行 npx expo prebuild 来检查 EAS Build 将基于的项目状态。运行此命令后，请查找以下文件：android/app/src/main/AndroidManifest.xml 和 ios/your-project-name/Supporting/Expo.plist。

🌐 If our project does not have android or ios directories, we can make commit any existing changes, then run npx expo prebuild to inspect the project state that EAS Build will act on. After running this, look for the following files: android/app/src/main/AndroidManifest.xml and ios/your-project-name/Supporting/Expo.plist.

在每个文件中，我们预计会看到 EAS 更新 URL 和运行时版本的配置。以下是我们期望在每个文件中看到的属性：

🌐 In each, we expect to see configuration for the EAS Update URL and the runtime version. Here are the properties we'd expect to see in each file:

AndroidManifest.xml

%%placeholder-start%%... %%placeholder-end%%
<meta-data android:name="expo.modules.updates.EXPO_RUNTIME_VERSION" android:value="your-runtime-version-here"/>
<meta-data android:name="expo.modules.updates.EXPO_UPDATE_URL" android:value="https://u.expo.dev/your-project-id-here"/>
%%placeholder-start%%... %%placeholder-end%%

Expo.plist

%%placeholder-start%%... %%placeholder-end%%
<key>EXUpdatesRuntimeVersion</key>
<string>your-runtime-version-here</string>
<key>EXUpdatesURL</key>
<string>https://u.expo.dev/your-project-id-here</string>
%%placeholder-start%%... %%placeholder-end%%

无需 EAS 构建的配置

🌐 Configuration without EAS Build

如果我们没有使用 EAS Build，本节将介绍如何调试我们项目中 EAS Update 的状态。我们需要查看系统中的多个位置。下面是 EAS Update 的工作原理图以及在查找问题根本原因时有用的检查点。在接下来的章节中，我们将检查并验证这些点以及更多内容。

🌐 If we aren't using EAS Build, this section will walk through debugging the state of EAS Update in our project. We'll need to look at multiple spots in the system. Below is a diagram of how EAS Update works and the spots that are useful to inspect when finding the root cause of an issue. In the sections following, we'll inspect and verify these spots and more.

验证构建配置

🌐 Verify build configuration

按照本地构建指南配置我们应用的渠道和运行时版本。我们还需要确保通用配置是正确的。

🌐 Follow the Building Locally guide to configure our app's channel and runtime version. We'll also need to make sure our general configuration is correct.

验证通道

🌐 Verify the channel

构建有一个名为 channel 的属性，EAS Update 使用它来链接到一个分支。一个通道通常会分配给多个特定平台的构建。例如，我们可能有一个 Android 构建和一个 iOS 构建，它们都有一个名为 "production" 的通道。

🌐 Builds have a property named channel, which EAS Update uses to link to a branch. A channel is often given to multiple platform-specific builds. For instance, we might have an Android build and an iOS build, both with a channel named "production".

一旦构建有了渠道名称，我们可以通过检查渠道页面来确保 EAS 服务器知道它。

🌐 Once a build has a channel name, we can make sure that EAS servers know about it by checking the Channels page.

我们希望页面显示与我们构建相同的通道名称。如果没有，我们可以在 EAS 服务器上创建该通道，命令如下：

🌐 We'd expect the page to display the same channel name that our build has. If it's not there, we can create the channel on EAS servers with:

Terminal

# eas channel:create [channel-name]
# Example

- eas channel:create production

验证通道/分支映射

🌐 Verify the channel/branch mapping

开发者在渠道和分支之间定义了一个链接。当渠道和分支被链接时，带有该渠道的应用将获得链接分支上最新的兼容更新。

🌐 There is a link that is defined by the developer between a channel and a branch. When a channel and branch are linked, an app with a channel will get the most recent compatible update on the linked branch.

通道页面将显示通道到分支的映射（如果存在）。

🌐 The Channels page will display the channel to branch mapping if it exists.

如果通道未链接到我们期望的分支，我们可以使用以下命令更改链接：

🌐 If the channel is not linked to the branch we expect, we can change the link with:

Terminal

# eas channel:edit [channel-name] --branch [branch-name]
# Example

- eas channel:edit production --branch release-1.0

验证更新

🌐 Verify the update

每个分支都包含一个更新列表。当构建请求更新时，我们会找到该构建的渠道，然后找到与该渠道关联的分支。一旦找到分支，EAS 将返回该分支上最新的兼容更新。当构建和更新具有相同的运行时版本和平台时，它们是兼容的。

🌐 Every branch contains a list of updates. When a build makes a call for an update, we find the channel of the build, then the branch linked to that channel. Once the branch is found, EAS will return the most recent compatible update on that branch. A build and an update are compatible when they share the same runtime version and platform.

要查看某个分支上的更新，我们可以前往分支页面并选择我们感兴趣的分支。

🌐 To inspect which updates are on a branch, we can go to the Branches page and choose our branch of interest.

分支详情页面将显示更新列表及其运行时版本和平台。通过该列表，我们应该能够确定哪个更新应适用于给定的构建，通过将构建的运行时版本和平台与更新的运行时版本和平台进行匹配。与之兼容的最新更新将可供构建下载和执行。

🌐 The Branch Detail page will show us a list of updates and their runtime versions and platforms. From this list, we should be able to figure out which update should apply to a given build, by matching the build's runtime version and platform to update's runtime version and platform. The most recent update that is compatible will be available for a build to download and execute.

List of updates on the Branch Detail page

调试 EAS 更新

🌐 Debugging EAS Update

在验证了 expo-updates 和 EAS 更新配置之后，我们可以继续调试项目如何与更新进行交互。

🌐 After verifying expo-updates and EAS Update configurations, we can move on to debugging how our project is interacting with updates.

应用内调试

🌐 In-app debugging

expo-updates 库导出了多种函数，用于在应用已经运行后与更新进行交互。在某些情况下，调用获取更新并看到错误信息可以帮助我们缩小根本原因的范围。我们可以制作项目的模拟器版本，并手动检查是否有可用更新或在获取更新时是否出现错误。请参见代码示例以手动检查更新。

手动检查构建

🌐 Inspecting a build manually

在将一个项目构建成应用时，可能会有多个步骤会改变 npx expo prebuild 的输出。完成构建后，可以打开构建的内容并检查本地文件，以查看其最终配置。

🌐 When building a project into an app, there can be multiple steps that alter the output of npx expo prebuild. After making a build, it is possible to open the build's contents and inspect native files to see its final configuration.

以下是检查 macOS 上的 iOS 模拟器版本的步骤：

🌐 Here are the steps for inspecting an iOS Simulator build on macOS:

使用 EAS Build 创建应用的 iOS 模拟器版本。这可以通过在构建配置文件中添加 "ios": { "simulator": true } 来完成。
构建完成后，下载结果并解压缩。
然后，右键点击该应用并选择“显示包内容”。
从那里，我们可以查看 Expo.plist 文件。

在 Expo.plist 文件中，我们预计会看到以下配置：

🌐 Inside the Expo.plist file, we expect to see the following configurations:

Expo.plist

%%placeholder-start%%... %%placeholder-end%%
<key>EXUpdatesRequestHeaders</key>
<dict>
  <key>expo-channel-name</key>
  <string>your-channel-name</string>
</dict>
<key>EXUpdatesRuntimeVersion</key>
<string>your-runtime-version</string>
<key>EXUpdatesURL</key>
<string>https://u.expo.dev/your-project-id</string>
%%placeholder-start%%... %%placeholder-end%%

手动检查清单

🌐 Inspecting manifests manually

当通过 EAS Update 发布更新时，我们会创建一个清单供终端用户应用请求。清单包含的信息包括加载更新所需的资源和版本。我们可以通过在浏览器中访问特定的 URL 或使用 curl 来检查清单。

🌐 When an update is published with EAS Update, we create a manifest that end-user app's request. The manifest has information like which assets and versions are needed for an update to load. We can inspect the manifest by going to a specific URL in a browser or by using curl.

在我们项目的应用配置 (app.json/app.config.json) 中，我们可以 GET 的 URL 位于 updates.url 下。

🌐 Inside our project's app config (app.json/app.config.json), the URL we can GET is under updates.url.

这个 url 是 EAS 的 "https://u.expo.dev" 域名，后面跟着项目在 EAS 服务器上的 ID。如果我们直接访问这个 URL，会看到一个关于缺少头信息的错误。我们可以通过向 URL 添加三个查询参数来查看清单：runtime-version、channel-name 和 platform。如果我们发布了一个运行时版本为 1.0.0、渠道为 production、平台为 android 的更新，我们可以访问的完整 URL 类似如下：

🌐 This url is EAS' "https://u.expo.dev" domain, followed by the project's ID on EAS servers. If we go to the URL directly, we'll see an error about missing a header. We can view a manifest by adding three query parameters to the URL: runtime-version, channel-name, and platform. If we published an update with a runtime version of 1.0.0, a channel of production and a platform of android, the full URL we could visit would be similar to this:

https://u.expo.dev/your-project-id?runtime-version=1.0.0&channel-name=production&platform=android

查看网络请求

🌐 Viewing network requests

识别问题根本原因的另一种方法是查看应用发送到 EAS 服务器的网络请求，然后查看响应。我们建议使用类似 Proxyman 或 Charles Proxy 的程序来监控我们应用的网络请求。

🌐 Another way to identify the root cause of an issue is to look at the network requests that the app is making to EAS servers, then viewing the responses. We recommend using a program like Proxyman or Charles Proxy to watch network requests from our app.

无论使用哪种程序，我们都需要按照它们的指示来安装 SSL 证书，以便程序能够解码 HTTPS 请求。一旦在模拟器或真实设备上完成设置，我们就可以打开应用并观察请求。

🌐 With either program, we'll need to follow their instructions for installing an SSL certificate, so that the program can decode HTTPS requests. Once that's set up in a simulator or on an actual device, we can open our app and watch requests.

我们感兴趣的请求来自 https://u.expo.dev 和 https://assets.eascdn.net。来自 https://u.expo.dev 的响应将包含一个更新清单，该清单指定应用运行更新所需获取的资源。来自 https://assets.eascdn.net 的响应将包含更新运行所需的资源，例如图片、字体文件等。

🌐 The requests we're interested in are from https://u.expo.dev and https://assets.eascdn.net. Responses from https://u.expo.dev will contain an update manifest, which specifies which assets the app will need to fetch to run the update. Responses from https://assets.eascdn.net will contain assets, like images, font files, and so on, that are required for the update to run.

在检查对 https://u.expo.dev 的请求时，我们可以查看以下请求头：

🌐 When inspecting the request to https://u.expo.dev, we can look for the following request headers:

Expo-Runtime-Version：这应该成为我们构建和更新的运行时版本。
expo-channel-name：这应该是 eas.json 构建配置文件中指定的通道名称。
Expo-Platform：这应该是“android”或“ios”之一。

对于所有请求，我们希望看到 200 响应代码，或者如果没有任何变化，则看到 304。

🌐 As for all requests, we expect to see either 200 response codes, or 304 if nothing has changed.

下面是显示成功更新清单请求的屏幕截图：

🌐 Below is a screenshot showing the request of a successful update manifest request:

运行时问题

🌐 Runtime issues

我们能够加载预期的更新，但我们的项目显示出意外的行为。

🌐 We are able to load the expected update but our project is displaying unexpected behavior.

通过 expo-updates 加载应用时调试原生代码

🌐 Debugging of native code while loading the app through expo-updates

默认情况下，我们需要为 expo-updates 进行发布构建，以使其启用并加载更新，而不是从开发服务器读取。这是因为调试构建的行为类似于普通的 React Native 项目调试构建。

🌐 By default, we need to make a release build for expo-updates to be enabled and to load updates rather than reading from a development server. This is because debug builds behave like normal React Native project debug builds.

为了更容易在更接近生产环境的环境中测试和调试本地代码，请按照以下步骤创建启用了 expo-updates 的应用调试版本。

🌐 To make it easier to test and debug native code in an environment that is closer to production, follow the steps below to create a debug build of the app with expo-updates enabled.

我们还提供了一份逐步指南，让你在本地开发环境中快速尝试 EAS 更新，可以使用 Android Studio 或 Xcode，并支持应用的发布版或调试版构建。

🌐 We also provide a step-by-step guide to try out EAS Update quickly in a local development environment using Android Studio or Xcode, with either release or debug builds of the app.

Android 本地构建

🌐 Android local builds

设置调试环境变量：export EX_UPDATES_NATIVE_DEBUG=1
确保在你的 AndroidManifest.xml 中设置了所需的渠道
使用 Android Studio 或通过命令行执行应用的调试版本。

iOS 本地构建

🌐 iOS local builds

设置调试环境变量：export EX_UPDATES_NATIVE_DEBUG=1
使用 npx pod-install 重新安装 pods。expo-updates podspec 现在会检测这个环境变量，并进行相应修改，从而绕过通常从 Metro 打包器加载的调试代码，并使用 EXUpdates 包及加载 EAS 更新所需的其他依赖来构建应用。
确保在我们的 Expo.plist 中设置所需的通道
修改应用 Xcode 项目文件，以强制在发布和调试构建中打包应用的 JavaScript：
Terminal
- sed -i '' 's/SKIP_BUNDLING/FORCE_BUNDLING/g;' ios/<project name>.xcodeproj/project.pbxproj
使用 Xcode 或从命令行执行应用的调试版本。

EAS 构建

🌐 EAS Build

或者，我们可以使用 EAS 创建一个启用了 expo-updates 的调试构建。环境变量在 eas.json 中设置，如下面的示例所示：

🌐 Alternatively, we can use EAS to create a debug build where expo-updates is enabled. The environment variable is set in eas.json, as shown in the example below:

eas.json

{
  "build": {
    "preview_debug": {
      "env": {
        "EX_UPDATES_NATIVE_DEBUG": "1"
      },
      "android": {
        "distribution": "internal",
        "withoutCredentials": true,
        "gradleCommand": ":app:assembleDebug"
      },
      "ios": {
        "simulator": true,
        "buildConfiguration": "Debug"
      },
      "channel": "preview_debug"
    }
  }
}

发布问题

🌐 Publishing issues

我们无法发布更新，或者部分更新未按预期发布。

🌐 We are not able to publish an update, or parts of our update are not being published as expected.

检查本地最新更新

🌐 Inspecting the latest update locally

当我们使用 EAS Update 发布更新时，它会在本地项目的根目录下创建一个 /dist 目录，其中包含作为更新一部分上传的资源。

🌐 When we publish an update with EAS Update, it creates a /dist directory in the root of our project locally, which includes the assets that were uploaded as a part of the update.

查看更新中包含的所有资源

🌐 Viewing all assets included in an update

查看我们更新包中包含了哪些资源可能会很有帮助。我们可以在更新详情页面看到一个已命名资源的列表：

🌐 It may be helpful to see which assets are included in our update bundle. We can see a list of named assets from the Updates Detail page:

或在本地运行：

🌐 Or run locally:

Terminal

- npx expo export

缓解措施

🌐 Mitigation steps

一旦我们找到了问题的根本原因，就可能需要采取各种缓解措施。最常见的问题之一是发布了包含错误的更新。当这种情况发生时，我们可以重新发布之前的更新来解决问题。

🌐 Once we've found the root cause of the issue, there are various mitigation steps we might want to take. One of the most common problems is pushing an update that has a bug inside it. When this happens, we can re-publish a previous update to resolve the issue.

重新发布之前的更新

🌐 Re-publishing a previous update

撤销错误发布的最快方式是重新发布已知良好的更新。假设我们有一个包含两个更新的分支：

🌐 The fastest way to "undo" a bad publish is to re-publish a known good update. Imagine we have a branch with two updates:

Terminal

branch: "production"updates: [ update 2 (id: xyz2) "fixes typo" // bad update update 1 (id: abc1) "updates color" // good update]

如果“更新 2”结果是一个糟糕的更新，我们可以用如下命令重新发布“更新 1”:

🌐 If "update 2" turned out to be a bad update, we can re-publish "update 1" with a command like this:

Terminal

# eas update:republish --group [update-group-id]# eas update:republish --branch [branch-name]
# Example

- eas update:republish --group abc1

- eas update:republish --branch production

上面的示例命令将产生一个现在如下所示的分支：

🌐 The example command above would result in a branch that now appears like this:

Terminal

branch: "production"updates: [ update 3 (id: def3) "updates color" // re-publish of update 1 (id: abc1) update 2 (id: xyz2) "fixes typo" // bad update update 1 (id: abc1) "updates color" // good update]

由于“更新 3”现在是“生产”分支上最新的更新，所有将来查询更新的用户将收到“更新 3”，而不是有问题的“更新 2”。

🌐 Since "update 3" is now the most recent update on the "production" branch, all users who query for an update in the future will receive "update 3" instead of the bad update, "update 2".

虽然这将防止所有新用户看到有问题的更新，但已经收到有问题更新的用户将会继续运行它，直到他们能够下载最新更新。由于移动网络并不总是能够下载最新更新，有时用户可能会长时间运行有问题的更新。在查看我们应用的错误日志时，随着用户的应用获取最新更新或版本，看到残留的长尾错误是正常的。当我们看到错误率显著下降时，就说明我们解决了这个漏洞；然而，如果我们的用户群跨越许多地点和移动网络，它可能不会完全消失。

🌐 While this will prevent all new users from seeing the bad update, users who've already received the bad update will run it until they can download the latest update. Since mobile networks are not always able to download the most recent update, sometimes users may run a bad update for a long time. When viewing error logs for our app, it's normal to see a lingering long tail of errors as our users' apps get the most recent update or build. We'll know we solved the bug when we see the error rate decline dramatically; however, it likely will not disappear completely if we have a diverse user base across many locations and mobile networks.

EAS 更新调试

进入部署页面

常见问题

意想不到的通道

意外的运行时版本

意想不到的分支

缺少更新

缺少分支

缺少部署

更新崩溃时自动回滚

无法加载所有资源

解决方案

配置通道

配置运行时版本

将通道映射到分支

发布更新

一般策略

使用 expo-dev-client

应用内调试

配置问题

expo-updates 配置

验证应用配置

预构建后检查 expo-updates 配置

无需 EAS 构建的配置

验证构建配置

验证通道

验证通道/分支映射

验证更新

调试 EAS 更新

应用内调试

手动检查构建

手动检查清单

查看网络请求

运行时问题

通过 expo-updates 加载应用时调试原生代码

Android 本地构建

iOS 本地构建

EAS 构建

发布问题

检查本地最新更新

查看更新中包含的所有资源

缓解措施

重新发布之前的更新

使用 `expo-dev-client`

`expo-updates` 配置