你通常在 Expo Go 开始撒谎的那一刻就准备好使用 Expo 开发客户端了。
该应用程序在沙盒中工作。快速刷新感觉很好。然后你添加一个本机依赖项，连接推送通知，测试 OAuth 流程，或者尝试镜像你的生产应用程序启动方式。突然间差距变得明显。你不再在调试你的应用程序了。你在调试一个简化的环境。
这就是 Expo 开发客户端改变工作流程的地方。它保留了人们喜欢的快速 JavaScript 循环，但将测试转移到一个自定义的本机二进制文件中，这个二进制文件的行为与你最终将部署的应用程序更相似。对于个人开发者，这意味着在周期末期减少意外。对于团队来说，这意味着可以支持共享构建、QA、预览环境和更新验证的开发过程，而不必假装 Expo Go 可以覆盖一切。
目录
为什么需要超越Expo Go
Expo Go在开始时很有用。它消除了设置的摩擦，快速启动了一个React Native项目，并给出了快速的反馈循环。正是因为这样，很多团队都从那里开始。
问题出在应用程序不再是原型时。Expo将Expo Go描述为 沙盒 并指出它无法准确模拟一些本机功能，如通知或OAuth认证，而开发构建模型则围绕 expo-dev-client 和定位为 “生产级应用的Debug”构建 在 Expo开发构建简介.
什么会先崩溃
在实践中，第一个崩溃通常是以下之一:
- 原生依赖: 一个包需要原生code，而Expo Go不包含。
- 身份验证: OAuth流程在应用使用真实原生配置后会有所不同。
- 通知和设备功能: 沙盒不会反映生产应用如何请求权限或接收事件的方式。
- 团队QA： 测试者需要一个稳定的二进制文件，该二进制文件代表应用的真实本机设置。
那些不是边缘情况。它们是真实移动项目中的正常阶段。
Expo Go很好地证明了一个接口。它是一个弱点，验证生产行为不是一个好地方。
为什么开发客户端是正确的下一步
Expo开发客户端为您提供了一个带有Expo开发工具的自定义应用二进制文件。这意味着您可以保留强大的开发人员体验，但本机层现在属于您。安装的客户端成为您的团队测试的东西，而不是依赖于一个通用容器。
这意味着比听起来更重要。您一旦转移到自定义客户端，问题就会从“这个在Expo Go中运行吗？”转变为“这个在我们正在构建的应用中工作吗？”这是正确的问题。
如果您还在比较更广泛的应用交付模型，Capgo关于 Expo的替代方案 的写作是有用的背景，因为它突出了团队开始超出沙盒式工作流程的时刻。
思维模式的变化
我看到的最大错误是把Expo开发客户端当作一次性设置任务。它不是。它是一个工作流选择。
您正在接受一个权衡的结果：
| 工作流 | 什么保持快速 | 什么需要更多的仪式 |
|---|---|---|
| Expo Go | 基本的 JavaScript 迭代 | 依赖于原生现实的任何内容 |
| Expo 开发客户端 | JavaScript 内部的自定义应用程序 | 原生依赖项和原生配置项的变化 |
在专业应用程序开发中，这是一个很好的权衡。您停止优化最容易的演示，并开始优化可靠的交付。
前置条件和项目配置
在构建任何东西之前，确保项目可以在可重复的构建中生存。 大多数第一次尝试失败的原因是跳过基本配置，而不是Expo本身。
Expo的文档和生态系统指导描述开发构建为一个 “完全功能的开发环境” 代表真实生产环境的应用程序一旦依赖于自定义本机code或生产级QA，正如Draftbit在Expo开发工具和开发构建的概述中所述。 从账户和__CAPGO_KEEP_0__层开始.
从账户和CLI层开始
Expo__CAPGO_KEEP_0__访问
- EASCLI访问
- EAS CLI 访问
一个干净的设置通常包括：
您的Expo账户会话：
- 在构建任何东西之前，确保项目可以在可重复的构建中生存。 大多数第一次尝试失败的原因是跳过基本配置，而不是Expo本身。 这使本地工作与远程构建服务和项目所有权相关联。
- EAS CLI 安装: EAS 是将您的项目转换为可共享的 iOS 或 Android 二进制文件的关键。
- 一个已经在本地运行的项目: 在基本应用启动工作正常之前，不要引入构建复杂性。
安装使工作流程可能的包
这个设置的中心是 expo-dev-client。没有它，您就没有自定义启动器和调试导向的本机 shell，这定义了 Expo 开发客户端工作流程。
在应用项目中安装它，然后验证您的 Expo 配置是合理的。具体命令可能会因您的包管理器而异，但架构点是：这个包是将应用从“在共享沙盒中运行”转换为“在我们的开发二进制文件中运行”的关键。
实践规则: 在本机依赖列表稳定到足以让团队成员安装并使用相同二进制文件之前，构建开发客户端。
尽早检查您的应用配置
多來自於把 Expo 的開發客戶端當作一個完整的框架。 app.json 或 app.config.js 这些文件并不是仅仅作为元数据。它们定义了身份。
确保项目具有：
- 一个独特的应用程序名称： 对于开发人员在一台设备上安装多个变体时非常有用。
- 一个独特的捆绑包或包标识符： 对于原生构建和后续签名至关重要。
- 清晰的环境意图： 如果团队使用分离的测试和生产身份，务必故意这样做。
如果您的本地环境混乱，值得在第一次构建之前整理一下。Capgo的指南是如何设置Capgo本地环境的 设置本地Capacitor环境 不是Expo专有的，但这是一个好的提示：可复制的移动工作始于稳定的本地工具和明确的配置。
什么样的配置是好的第一步
在EAS开始之前，请使用此检查清单
| 检查 | 为什么它很重要 |
|---|---|
expo-dev-client 已安装 |
启用自定义开发客户端行为 |
| Expo账户已链接 | 对于smooth EAS使用必备 |
| 应用标识符是唯一的 | 防止本地构建和安装冲突 |
| 项目在本地启动 | 避免将运行时问题与构建问题混淆 |
| 团队知道何时重建 | 减少本地更改后混淆 |
目标不是完美。目标是让第一次构建变得无聊。这才是胜利。
使用EAS构建您的自定义客户端
这是工作流程变得真实的地方。您停止谈论自定义客户端并生成一个。
Expo推荐用于具有自定义本机code的应用程序的开发构建工作流程：安装 expo-dev-client，使用EAS Build或本地生成一个本机应用程序，然后运行 npx expo start --dev-client。 Expo还在 工作流程概述 中指出JavaScript-only更改保持快速，而本机code更改需要新的开发构建。
基本的EAS流程
流程顺序清晰，即使第一次运行也会感到陌生:
- 安装并使用EAS CLI进行身份验证
- 初始化或确认构建配置
- 创建开发构建配置文件
- 触发iOS或Android的构建
- 在设备或模拟器上安装生成的二进制文件
EAS给你的是一致性。相比于每个开发者在本地进行native构建状态的即兴表演，团队可以从共享的构建定义中生成二进制文件。
您的构建配置文件正在做什么
A development 配置文件不仅仅是一个标签。它告诉构建系统，这个二进制文件是用于活跃开发，而不是商店分发。
这通常意味着安装的应用程序应该:
- 包含开发客户端行为
- 让开发者和测试者轻松启动
- 在日常工作中连接到Metro服务器
- 直到原生依赖发生变化时仍然可重用
这也是CI开始变得实用的地方。 一旦有了可预测的构建配置，你就可以自动化它。
如果您的团队正在思考React Native如何融入更广泛的现代化工作中，Wonderment Apps对 React Native用于AI现代化的观点很有用。
它很相关，因为开发客户端通常会成为团队在移动表面上频繁推送产品变更时的操作基层。
如果您想看到流程的实际效果，一个短小的教程可以帮助您:
安装结果
- 在 Android 上： 您通常会在
.apk上安装一个 - 在iOS上： 您将与一个
.ipa或模拟器兼容的输出取决于目标。 - 对于团队成员： 通过正常的EAS机制共享构建，而不是要求每个人从头开始创建自己的构建，除非必要。
A development build is easiest to manage when the team agrees on one rule: rebuild for native changes, not for every code change.
什么不应该期待
不要期望第一次构建消除原生复杂性。它将复杂性放在了正确的位置。
If you add a new native module, change permissions, update SDK-level native dependencies, or modify plugin-driven native config, you’ll need a fresh development build. That’s normal. The reward is that your day-to-day JavaScript work still moves quickly inside a client that reflects your app.
在您的新客户端中运行和调试
当你第一次打开已安装的客户端并连接到Metro时，差异就显而易见。它感觉像Expo，但不再像玩具盒里的东西。
启动服务器并使用 npx expo start --dev-client。然后在模拟器、模拟器或物理设备上打开开发客户端并通过启动器UI连接。该启动器是由 expo-dev-client引入的重要变化之一，除此之外，还提供了调试支持，如网络请求检查，详见 Expo SDK.
一项正常的开发会话
典型的会话如下：
你pull最新的branch。已安装的开发客户端已经在你的设备上。启动Metro，启动应用程序，并连接到当前服务器。然后你大部分时间都像以前一样工作，修改JavaScript并快速看到更新。
当你需要检查依赖于真实本机环境的行为时，差异就显而易见。自定义客户端让你可以在不脱离常规循环的情况下测试那些流程。
调试工具
额外的工具并非是装饰品。它解决了日常问题。
- 启动器 UI: 切换环境或团队成员托管服务器时非常有用。
- 开发者菜单: 在活跃迭代期间给予您期望的操作。
- 网络检查: 当 UI 看起来破碎，但实际问题是请求失败、认证状态或环境连接错误时，帮助很大。
When API calls fail in a development client, inspect the request path and environment assumptions before touching UI code. The bug is often outside the component you’re staring at.
这里的实用优势在于：一个安装的二进制文件可以验证多个环境而无需每次重新编译。这在 reviewer 想要测试 PR 预览、 QA 工程师想要测试阶段、开发者想要测试本地分支时尤其有用。
如果您的团队还部署了基于 web 的移动壳，Capgo’s Capacitor 应用程序调试的终极指南 是值得阅读的，尤其是更广泛的调试思维方式。工具不同，但纪律相同：检查传输、环境和运行时行为之前猜测。
什么是有效的，什么是不有效的
什么有效:
| 情况 | 为什么开发客户端有帮助 |
|---|---|
| 测试认证重定向 | 原生应用行为更接近生产 |
| 验证API集成 | 网络检查缩短了反馈循环 |
| 切换环境 | 启动器UI避免不必要的重建 |
| 团队QA在一个二进制文件 | 每个人测试相同的原生设置 |
什么不有效:
- 以客户端为可丢弃的: 如果团队不维护它，混乱就会迅速出现。
- 忽视原生重建边界: 一旦原生依赖发生变化，过时的客户端会浪费时间。
- 假设所有连接故障都是应用程序错误: 许多只是本地环境问题。
与CI/CD和Live Updates集成
当开发客户端不再是个人设置时，它变得更加有价值。它成为团队运营的一部分。
成熟的工作流程通常会分离关注点。原生变化会产生一个新的开发构建。JavaScript和资产变化会通过更快的更新路径。审阅者和QA不需要问他们是否正在测试正确的东西，因为团队已经同意通道、构建配置和更新目的地。
CI/CD的位置
开发客户端与CI很好地协同工作，因为它给自动化提供了一个稳定的目标。
一个常见的模式如下：
- Pull request 变更: CI 在原生依赖发生变化时创建或验证开发构建。
- 分支环境： 不同分支映射到不同的更新频道或服务器目标。
- 共享测试流程： QA 安装一个或多个已知的开发客户端，并通过启动器和更新配置切换上下文。
减少了不确定性。开发者知道何时需要重新构建。测试者知道他们是否是在验证原生变化还是在现有二进制文件上推送的更新。
实时更新的作用
开发客户端经常使团队能够节省最多的操作时间。开发客户端是一个强大的地方来验证更新行为在发布之前，因为它可以在生产环境中模拟的应用程序外壳中切换开发服务器和发布的更新，正如前面在 Expo 文档中所描述的。
打开一个有用的分区：
| 类型变更 | 发布路径 |
|---|---|
| 新原生模块或权限变更 | 新开发构建 |
| JavaScript行为修复 | 发布更新 |
| 复制或资产调整 | 发布更新 |
| 环境验证 | 已安装客户端中切换频道或服务器 |
对于不在Expo更新堆栈中的团队 Capgo的CI/CD集成指南 Capacitor侧展示了一个可比的运营模型。它是团队想要控制发布频道和更新交付自动化的选项。
可靠的模式很简单。根据本地code的变化进行构建。发布时，已安装的二进制文件中已经包含了所有需要的变化。
防止混乱的团队习惯
技术设置很重要，但运营规则更重要：
- 明确地命名通道：
staging,production并且预览名称应该很明显。 - 记录重建触发器： 新插件、权限变更或本地SDK更新不应成为判断的依据。
- 保持一个可安装的客户端策略： 太多变体会产生支持噪音。
- 使更新验证明确： 有人应该验证更新是否适用并在预期的二进制文件中启动。
此时，Expo开发客户端不再是开发者便利工具，而成为发布基础设施。
常见问题排查和解决
了解哪里可以查找问题后，大多数Expo开发客户端问题都是普通的。它们看起来神秘，因为失败通常发生在界限之间：笔记本电脑到设备、Metro到应用、native配置到JavaScript运行时。
最常见且未被讨论的问题之一是由于企业和分布式团队环境中的局域网分段、VPN或防火墙规则导致无法连接到Metro的物理设备，这一点在本 Expo Dev Client排查视频.
当客户端无法连接到Metro时
这是一个耗时最长的问题，因为它看起来像是一个破损的应用，而实际上应用通常是正常的。
首先检查这些:
- 相同网络假设: 设备和笔记本电脑可能看起来连接在一起，但实际上它们可能位于隔离的分段中。
- VPN干扰: 企业或个人VPN可能会重定向流量，Metro不能很好地容忍这种情况。
- 防火墙规则: 安全工具可能会阻止本地开发流量，但不会明显提示。
- 企业设备政策： 管理设备有时会限制开发工具依赖的流量模式。
如果项目在模拟器中正常运行，但在物理设备上不正常，请先怀疑网络问题，而不是怀疑你的 React code。
不要从应用内部调试连接失败。确认设备是否可以实际访问运行 Metro 的机器。
当重建似乎是随机的
另一个常见的烦恼是有些变化似乎瞬间就出现了，而其他的则坚持不下来。
这通常意味着团队还没有内化重建边界:
| 症状 | 可能原因 | 解决方案 |
|---|---|---|
| JavaScript 更新正常应用 | 预期行为 | 继续在现有客户端中工作 |
| 新本机依赖项不显示 | 本机层发生了变化 | 创建一个新的开发构建 |
| 权限相关行为不一致 | 本机配置发生了变化 | 重新构建并重新安装 |
| 一位团队成员看到的行为不同 | 安装了不同的客户端二进制文件 | 在同一构建上达成一致 |
这不是工作流程的缺陷。它正在做它应该做的事情。
构建失败和团队偏离
当构建失败时，根源原因通常是以下之一：
- 依赖不匹配： 项目中某个包版本与其他部分不一致。
- 本机插件假设： 配置插件期望的设置项目中没有。
- 凭证混淆： 签名或账户访问不一致，团队成员之间。
- 本地过时期望： 某人认为新建构建不需要，但实际上需要。
Capgo的文章关于 开发人员的live update常见问题和解决方案 对于发布这一问题的另一方面，以下内容是有用的补充阅读。不同的堆栈，相同的教训：许多“应用程序错误”实际上是交付、环境或版本对齐错误。
Expo 开发客户端在团队将环境可靠性视为工程的一部分时表现最佳。不是作为一个后thought。 一旦你这样做了，设置就变得可预测了，预测性是您希望从移动工具中获得的。
如果您的团队还部署了Capacitor应用程序，并且需要一种控制方式来交付JavaScript、资产和配置更新，而不必等待商店审查 Capgo 它是评估的一种选择。它提供了实时更新、滚动控制和CI/CD集成功能，适用于Capacitor和Electron工作流。
