You’re usually ready for the Expo development client at the exact moment Expo Go starts lying to you.
The app works in the sandbox. Fast refresh feels great. Then you add a native dependency, wire up push notifications, test an OAuth flow, or try to mirror the way your production app launches. Suddenly the gap becomes obvious. You aren’t debugging your app anymore. You’re debugging a simplified environment.
That’s where the Expo development client changes the workflow. It keeps the fast JavaScript loop people like about Expo, but moves testing into a custom native binary that behaves much more like the app you’ll eventually ship. For solo developers, that means fewer surprises late in the cycle. For teams, it means a development process that can support shared builds, QA, preview environments, and update validation without pretending Expo Go can cover everything.
目录
Why You Need to Move Beyond Expo Go
Expo Go 在开始阶段是有用的。它减少了设置的摩擦，快速启动一个 React Native 项目，并给你一个快速的反馈循环。正是因为这样，很多团队都从那里开始。
问题出在 app 不再是原型时。Expo 将 Expo Go 描述为一个 "sandbox"，并指出它无法准确模拟一些本机功能，如通知或 OAuth 认证，而开发构建模型则围绕 "Debug" 构建为生产级应用而设计。 在 Expo 开发构建介绍中，Expo 将其描述为 "Debug" 构建用于生产级应用 __CAPGO_KEEP_0__ expo-dev-client __CAPGO_KEEP_0__ __CAPGO_KEEP_0__ __CAPGO_KEEP_0__ __CAPGO_KEEP_0__.
什么会先崩溃
在实践中，第一个崩溃通常是其中之一：
- 原生依赖项： 一个包需要原生code，Expo Go 不包含。
- 身份验证： OAuth 流程在使用真实原生配置的应用程序中会有所不同。
- 通知和设备功能： 沙盒不会反映生产应用程序如何请求权限或接收事件。
- 团队 QA： 测试者需要一个稳定的二进制文件，代表应用程序的真实原生设置。
这些不是边缘案例。它们是真实移动项目中的正常阶段。
Expo Go用于证明接口很好。它是一个弱点，用于验证生产行为。
为什么开发客户端是下一个正确的步骤
Expo开发客户端为您提供了一个自定义的应用程序二进制文件，内置了Expo的开发工具。因此，您可以保留强大的开发人员体验，但原生层现在属于您。安装的客户端成为您的团队测试的东西，而不是依赖于一个通用的容器。
这意味着比听起来更重要的变化。 一旦您切换到自定义客户端，问题从“Expo Go是否运行？”变为“我们正在构建的应用程序中是否有效？”这是正确的问题。
如果您还在比较更广泛的应用程序交付模型，Capgo关于 Expo替代方案 的写作是有用的上下文，因为它突出了团队开始超越沙盒式工作流程的时刻。
思维模式的变化
我看到的最大错误是把Expo开发客户端当作一次性设置任务。它不是。它是一个工作流选择。
您接受一个权衡来获得控制：
| 工作流 | 什么保持快速 | 需要更多的礼仪 |
|---|---|---|
| Expo Go | 基本的JavaScript迭代 | 依赖于原生现实的任何东西 |
| Expo开发客户端 | 在自定义应用程序中更改JavaScript | 原生依赖项更改和原生配置更改 |
在专业应用程序开发中，这是一个不错的交易。您停止优化最容易的演示，并开始优化可靠的交付。
先决条件和项目配置
在您构建任何东西之前，将项目置于可以承受可重复构建的状态。最常见的第一次尝试失败来自跳过基本配置，而不是Expo本身。
Expo的文档和生态系统指导描述开发构建为 “fully featured development environment” 当应用程序依赖于自定义本机code或生产级QA时，代表真实生产环境的应用程序将是这样的，正如Draftbit对本地应用程序概述中所述 Expo开发工具和开发构建.
首先使用帐户和CLI层
在应用层变得重要之前，您需要两个东西工作：
- ExpoCLI访问
- EASCLI访问
您还希望从终端登录您的Expo帐户。团队经常忽略这一点，因为本地命令看起来很好，直到出现第一个远程构建或凭据提示时才会出现问题
一个干净的设置通常包括：
- 您的Expo帐户会话： 这将本地工作与远程构建服务和项目所有权联系起来。
- EASCLI已安装： EAS是将您的项目转换为可共享的iOS或Android二进制文件的关键。
- 一个已经在本地运行的项目： 在基本应用启动工作正常之前，不要引入构建复杂性。
安装使流程可能的包
这个设置的中心是 expo-dev-client没有它，你就没有自定义启动器和调试导向的本机 shell，这定义了 Expo 开发客户端工作流程。
在应用项目中安装它，然后验证你的 Expo 配置是合理的。具体命令可能会根据你的包管理器而有所不同，但架构上的点是：这个包是将应用从“在共享沙盒中运行”转换为“在我们的开发二进制文件中运行”的关键。
实用规则： 在本机依赖列表稳定到足以让团队成员安装和使用相同二进制文件之前，构建开发客户端。
尽早检查你的应用配置
很多混淆都是因为把 app.json 或 app.config.js 当作元数据而已。它们不是。这些文件定义了身份。
确保项目具有：
- 一个独特的应用程序名称： 对于开发人员在一台设备上安装多个变体时非常有用。
- 一个独特的捆绑包或包标识符： 对于原生构建和后续签名至关重要。
- 清晰的环境意图： 如果团队使用单独的测试和生产身份，请故意反映这一点。
如果您的本地环境混乱，值得在第一次构建之前清理它。Capgo关于 设置Capacitor本地环境的指南 并不是Expo特有的，但它是一个好提示，重复性移动工作始于稳定的本地工具和明确的配置。
什么是一个好的首次配置
在启动EAS之前使用此清单
| 检查 | 为什么它很重要 |
|---|---|
expo-dev-client __CAPGO_KEEP_0__已安装 |
启用自定义开发客户端行为 |
| 已链接 Expo 帐户 | EAS 平滑使用所必需 |
| 应用标识符是唯一的 | 防止本机构建和安装冲突 |
| 项目从本地开始 | 避免混淆运行时问题与构建问题 |
| 团队知道何时重建 | 减少本机更改后混淆 |
目标不是完美。目标是让第一次构建变得乏味。这才是胜利。
使用 EAS 构建您的自定义客户端
这是工作流程变得真实的地方。您停止谈论自定义客户端并生成一个。
Expo 建议为具有自定义本机 code 的应用程序使用开发构建工作流程：安装 expo-dev-client使用 EAS Build 或本地生成一个本机应用程序，然后运行 npx expo start --dev-clientExpo 还在工作流程概述中指出 JavaScript-only 的更改保持快速，而本机 __CAPGO_KEEP_0__ 的更改需要新的开发构建。 使用 EAS code 工具构建 Expo 开发客户端的四步流程图。
顺序是明确的，即使第一次运行感觉陌生：
安装并使用 EAS __CAPGO_KEEP_0__ 进行身份验证
- Install and authenticate with EAS CLI
- 初始化或确认构建配置
- 创建开发构建配置文件
- 触发 iOS 或 Android 的构建
- 在设备或模拟器上安装构建结果
EAS 给你的是一致性。相比之下，开发者不再需要各自的本地原生构建状态，而团队可以从共享的构建定义中产生二进制文件。
你的构建配置文件到底在做什么
A development 配置文件并不是仅仅是一个标签。它告诉构建系统，这个二进制文件是用于活跃开发，而不是商店发布。
这通常意味着安装的应用程序应该：
- 包含开发客户端行为
- 易于开发者和测试人员启动
- 在日常工作中连接到 Metro 服务器
- 保持可重用的直到原生依赖发生变化
CI 也开始变得实用。这时你可以自动化它，
如果您的团队正在思考React Native如何融入更广泛的现代化工作中，Wonderment Apps对 React Native用于AI现代化的观点很有用。它的相关性在于开发客户端通常会成为团队在移动表面频繁推送产品变更时的操作基础层的一部分
如果您想看到流程的实践效果，可以看一下一个简短的教程：
安装结果
当构建完成时，请将输出视为一个真正的应用程序二进制文件，因为它就是这样一个文件
- 在Android上： 您通常会在一个物理设备或模拟器上
.apk安装一个 - 在iOS上： You’ll work with an
.ipa或模拟器兼容的输出取决于目标. - For teammates: 通过正常的EAS机制共享构建，而不是要求每个人从头开始创建自己的构建，除非必要.
开发构建在团队达成一致时最容易管理：重建原生变化，不要为每个code变化重建.
What not to expect
不要期望第一次构建消除原生复杂性。它将复杂性放在了正确的位置.
如果您添加了新的原生模块、修改了权限、更新了SDK级原生依赖或修改了插件驱动的原生配置，则需要一个新的开发构建。这是正常的。每天的JavaScript工作仍然在反映应用的客户端中快速进行.
Running and Debugging with Your New Client
第一次打开已安装的客户端并连接到Metro时，差异就明显了。它感觉像Expo，但不再像玩具盒一样.
使用 npx expo start --dev-client启动服务器。然后在模拟器、模拟器或物理设备上打开开发客户端并通过启动器UI连接。该启动器是Capacitor引入的重要变化之一。 expo-dev-client与调试支持如网络请求检查，详见 Expo SDK 页面中的开发客户端.
正常的开发会话
典型的会话如下：
您拉取最新的分支。已安装的开发客户端已经在您的设备上。您启动Metro，启动应用程序，并连接到当前服务器。然后，您主要像以前一样工作，修改JavaScript并快速看到更新。
当您需要检查依赖于真实本机环境的行为时，会出现重大差异。自定义客户端让您测试那些流程而不需要脱离您的常规循环。
重要的调试工具
额外的工具不是装饰性的。它解决了日常问题。
- 启动器UI： 在切换环境或同事托管服务器时很有用。
- 开发菜单： Gives you the actions you expect during active iteration.
- 网络检查： 当 UI 看起来破损，但实际问题是请求失败、认证状态或环境连接不正确时，__CAPGO_KEEP_0__会提供帮助。
当开发客户端中的 API调用失败时，检查请求路径和环境假设之前再去触摸 UI code。 bug 通常在您正在查看的组件之外。
这里的实用优势。 安装的单个二进制文件可以验证多个环境而无需每次重新编译。 这尤其有帮助，当审阅者想要测试 PR 预览、QA 工程师想要测试环境和开发人员想要测试本地分支时。
如果您的团队还部署了基于 Web 的移动壳，Capgo的 Capacitor 应用程序的 ultimate 调试指南 值得一读的更广泛的调试思维方式。 工具不同，但纪律相同：检查传输、环境和运行时行为之前猜测。
什么有效，什么不有效
什么有效：
| 情况 | 为什么开发客户端有帮助 |
|---|---|
| 测试认证重定向 | 原生应用行为更接近生产环境 |
| 验证API集成 | 网络检查缩短了反馈周期 |
| 切换环境 | 启动器UI避免不必要的重建 |
| 团队QA在一个二进制文件中 | 每个人都测试相同的原生设置 |
不太好用的地方：
- 把客户端当作可丢弃的东西： 如果团队不维护它，混乱会迅速蔓延。
- 忽视原生重建边界： 当原生依赖发生变化时，过时的客户端会浪费时间。
- 假设所有连接故障都是应用程序错误： 许多只是本地环境问题。
与CI/CD和实时更新集成
Expo开发客户端在停止成为个人设置并成为团队操作时变得更加有价值。
成熟的工作流程通常会分离关注点。原生变化产生新的开发构建。JavaScript和资产变化通过更快的更新路径进行。审阅者和QA不需要问他们是否正在测试正确的内容，因为团队已经同意通道、构建配置和更新目的地。
CI/CD适合的地方
开发客户端与CI一起工作得很好，因为它为自动化提供了一个稳定的目标。
一个常见的模式如下：
- 拉取请求更改： CI创建或验证开发构建时原生依赖发生变化。
- 分支环境: 不同分支映射到不同的更新频道或服务器目标。
- 共享测试流程: QA 安装一个或多个已知的开发客户端并切换上下文通过启动器和更新配置。
这种结构减少了不确定性。开发人员知道何时需要重新构建。测试人员知道他们是否验证了本机更改还是在现有二进制文件上发布的更新。
实时更新的作用
开发客户端通常可以让团队节省最多的时间操作。开发客户端是验证更新行为在发布之前的强大位置，因为它可以在开发服务器和发布的更新之间切换，具有生产环境的应用程序外壳，正如前面在 Expo 文档中描述的那样。
这打开了一个有用的分裂:
| 变更类型 | 传递路径 |
|---|---|
| 新本机模块或权限更改 | 新开发构建 |
| JavaScript行为修复 | 发布更新 |
| 复制或资产调整 | 发布更新 |
| 环境验证 | 切换已安装客户端中的通道或服务器 |
对于Expo更新堆栈外的团队来说， Capgo的CI/CD集成指南 Capacitor侧展示了一个可比的运营模型。它是团队想要控制发布通道和更新交付自动化的选项。
可靠的模式很简单。根据native code的变化进行构建。发布时，已安装的二进制文件已经包含了所需的所有更改。
预防混乱的团队习惯
技术设置很重要，但运营规则更重要：
- 明确显示频道名称：
staging,production和预览名称应该很明显。 - 文档重建触发器： 新插件、权限变更或本机SDK更新不应成为判断的依据。
- 保持一个可安装的客户端策略： 太多变体会产生支持噪音。
- 使更新验证明确： 有人应该验证更新是否适用并在同一二进制文件中启动团队期望的应用程序。
在这个阶段，Expo开发客户端不再是开发人员的便利工具，而成为发布基础设施。
常见问题和解决方案
大多数Expo开发客户端问题在你知道哪里寻找时是普通的。它们看起来神秘，因为失败通常发生在界限之间：笔记本电脑到设备、Metro到应用程序、本机配置到JavaScript运行时。
一个最常见且被低调讨论的问题是无法连接到Metro物理设备的本地网络隔离、VPN或企业和分布式团队环境中的防火墙规则，一个在此处提出的问题。 Expo Dev Client调试视频.
当客户端无法连接到Metro时
这是一个耗时最多的问题，因为它看起来像是一个破损的应用程序，而实际上应用程序经常是正常的。
首先检查这些:
- 同一网络假设: 设备和笔记本电脑可能会在隔离段上显示连接状态。
- VPN干扰: 企业或个人VPN可能会将流量重定向到Metro无法容忍的方式。
- 防火墙规则: 安全工具可能会阻止本地开发流量而不明显。
- 企业设备策略: 管理设备有时会限制开发工具依赖的流量模式。
如果项目在模拟器中正常工作，但在物理设备上不正常工作，首先怀疑网络问题，而不是怀疑你的 React code。
不要在应用程序内部首先调试连接故障。确认设备是否可以实际访问运行 Metro 的机器。
当重建似乎是随机的
另一个常见的烦恼是，感觉一些更改立即出现，而其他人顽固地不出现。
这通常意味着团队还没有内化重建边界：
| 症状 | 可能原因 | 解决方案 |
|---|---|---|
| JavaScript 更新正常应用 | 预期行为 | 继续在现有客户端中工作 |
| 新本机依赖项不显示 | 原生层改变 | 创建一个新的开发构建 |
| 权限相关行为不一致 | 原生配置改变 | 重新构建并重新安装 |
| 一名团队成员看到的行为不同 | 安装了不同的客户端二进制文件 | 在同一构建上齐一 |
这不是工作流程的缺陷。它只是工作流程正在做它应该做的事情。
构建失败和团队偏离
当构建失败时，根源原因通常是这些之一：
- 依赖项不匹配： 项目中的包版本不一致。
- 原生插件假设： 配置插件需要设置项目中没有设置。
- 凭证混乱： 签名或账户访问不一致，团队成员之间。
- 过时的本地期望： 有人认为新建项目不需要更新，但实际上需要。
Capgo关于 开发者常见的实时更新问题和解决方案的文章 对于解决发布问题有用补充阅读。不同的堆栈，同样的教训：许多“应用程序错误”实际上是交付、环境或版本对齐错误。
Expo开发客户端在团队将环境可靠性视为工程的一部分时，表现最佳。不是作为一个后thought。一旦你这样做了，设置就变得可预测了，预测性是您希望从移动工具中获得的。
如果您的团队还部署Capacitor应用程序并需要一种控制的方式来交付JavaScript、资产和配置更新，而不必等待商店审查, Capgo 这是一个评估的选项。它提供实时更新、滚动控制和CI/CD集成来支持Capacitor和Electron工作流。
