Your Guide to the Expo Development Client
通常在 Expo Go 开始欺骗你时，你就准备好使用 Expo 开发客户端了。
应用程序在沙盒中工作。快速刷新感觉很好。然后你添加一个本机依赖项、连接推送通知、测试 OAuth 流或尝试镜像你的生产应用程序启动方式。突然间差距变得明显。你不再在调试你的应用程序了。你在调试一个简化的环境。
这就是 Expo 开发客户端改变工作流程的地方。它保留了人们喜欢的快速 JavaScript 循环，但将测试转移到一个自定义的本机二进制文件中，这个二进制文件的行为更像你最终将要部署的应用程序。对于 solo 开发者来说，这意味着在周期末期减少惊喜。对于团队来说，这意味着一个可以支持共享构建、QA、预览环境和更新验证的开发过程，而不必假装 Expo Go 可以覆盖一切。
为什么需要超出Expo Go
Expo Go在开始时很有用。它消除了设置的摩擦，快速启动一个React Native项目，并给出了快速的反馈循环。正是因为这个原因，很多团队都从那里开始。
问题出在应用程序停止成为原型时。Expo将Expo Go描述为 沙盒 并指出它无法准确模拟一些本机功能，如通知或OAuth认证，而开发构建模型则围绕 expo-dev-client 和定位为 “Debug” build for production-grade apps “Debug” 用于生产级应用程序的.
Expo开发构建介绍中
在实践中，第一个断裂通常是这些之一：
- 原生依赖： 一个包需要原生code，Expo Go 不包含。
- 身份验证： OAuth 流程在应用程序使用真实原生配置后会有所不同。
- 通知和设备功能： 沙盒不能反映生产应用程序如何请求权限或接收事件。
- 团队 QA： 测试者需要一个稳定的二进制文件来代表应用程序的真实原生设置。
这些不是边缘案例。它们是真实移动项目中的正常阶段。
Expo Go 很好地证明了一个界面。它是一个弱点来验证生产行为。
为什么开发客户端是正确的下一步
Expo 开发客户端为您提供一个自定义的应用程序二进制文件，内置了 Expo 的开发工具。这意味着您可以保留强大的开发人员体验，但原生层现在属于您。安装的客户端成为您的团队测试的东西，而不是依赖于一个通用容器。
这种转变比听起来更重要。一旦您切换到自定义客户端，问题从“这个应用程序在 Expo Go 中是否可以运行？”变成了“这个应用程序在我们正在构建的应用程序中是否可以工作？”这是正确的问题。
如果您还在比较更广泛的应用程序交付模型，Capgo关于 Expo 的 替代方案
的写作是有用的背景信息，因为它突出了团队开始超出沙盒式工作流程的时刻。
思维模式的变化
我看到的最大错误是把 Expo 开发客户端当作一次性设置任务。它不是。
| 它是一种工作流程选择。 | 您接受一个权衡来获得控制： | 工作流程 |
|---|---|---|
| 什么保持快速的速度 | 基本 JavaScript 迭代 | 依赖原生现实的任何内容 |
| Expo 开发客户端 | 在自定义应用程序内部的 JavaScript 变化 | 原生依赖项变化和原生配置变化 |
在专业应用程序开发中，这是一个很好的交易。您停止优化最容易的演示，并开始优化可靠的交付。
前置条件和项目配置
在您构建任何内容之前，将项目置于可以承受可重复构建的状态。最终的首次尝试失败的原因往往是忽略基本配置，而不是 Expo 本身。
Expo 的文档和生态系统指导描述开发构建为一个 “完全功能的开发环境” 这代表了一个真正的生产环境，一旦应用程序依赖于自定义原生 code 或生产级 QA，如 Draftbit 对 Expo 开发工具和开发构建的概述所述 Expo 开发工具和开发构建.
从账户和CLI层开始
在应用层变得重要之前，您需要两个东西工作：
- Expo CLI访问
- EAS CLI访问
您还希望从终端登录您的Expo账户。团队经常忽略这一点，因为本地命令看起来可能很好，直到出现第一个远程构建或凭据提示时。
通常包括：
- 您的Expo账户会话： 这将本地工作与远程构建服务和项目所有权联系起来。
- EAS CLI已安装： EAS是将您的项目转换为可共享的iOS或Android二进制文件的关键。
- 一个已经在本地运行的项目： 不要在基本应用启动工作之前引入构建复杂性。
安装使工作流程成为可能的包
这个设置的中心是 expo-dev-client没有它，你就没有定制启动器和调试导向的本机 shell，这定义了 Expo 开发客户端工作流程。
在应用项目中安装它，然后验证您的 Expo 配置是合理的。具体命令可能会因您的包管理器而异，但架构点是：这个包是将应用从“在共享沙盒中运行”转换为“在我们的开发二进制文件中运行”的关键。
实践规则： 在本机依赖项列表稳定到足够让团队成员安装和使用相同二进制文件之前，构建开发客户端。
尽早检查应用配置
很多混淆都是把 app.json 或 app.config.js 当作元数据处理。它们不是。这些文件定义了身份。
确保项目具有：
- 一个独特的应用名称： 当开发者在一台设备上安装多个变体时，很有帮助。
- 一个独特的包或包标识符： 对于原生构建和后续签名至关重要。
- 清晰的环境意图： 如果团队使用单独的测试和生产身份，务必明确反映这一点。
如果您的本地环境混乱，值得在第一次构建之前整理一下。Capgo关于Capgo本地环境的指南 setting up a Capacitor local environment 一个好的首次配置是什么样的
在EAS启动之前，使用此清单
检查
| 为什么它很重要 | Why it matters (Why it matters) |
|---|---|
expo-dev-client __CAPGO_KEEP_0__已安装 |
启用自定义开发客户端行为 |
| 已链接Expo账户 | EAS平滑使用所需 |
| 应用标识符是唯一的 | 防止原生构建和安装冲突 |
| 项目从本地开始 | 避免混淆运行时问题与构建问题 |
| 团队知道何时重建 | 减少原生更改后混淆 |
目标不是完美。目标是让第一次构建变得无聊。这就是胜利。
使用EAS构建您的自定义客户端
这是工作流程变得真实的地方。您停止讨论自定义客户端并生成一个。
Expo建议为具有自定义本机code的应用程序使用开发构建工作流程 expo-dev-client，生成一个本机应用程序使用EAS Build或本地，然后运行 npx expo start --dev-client。Expo还在 工作流程概述 中指出，仅使用JavaScript的更改保持快速，而本机code的更改需要新的开发构建。
基本EAS流程
序列是直接的，即使第一次运行感觉陌生：
- 安装并使用EAS CLI进行身份验证
- 初始化或确认构建配置
- 创建开发构建配置文件
- 触发 iOS 或 Android 的构建
- 在设备或模拟器上安装结果的二进制文件
EAS 给你的是一致性。相比于每个开发者在本地进行 native 构建状态的即兴表演，团队可以从共享的构建定义中产生二进制文件。
你的构建配置文件到底在做什么
A development 配置文件并不是仅仅是一个标签。它告诉构建系统，这个二进制文件是用于活跃开发，而不是商店分发。
这通常意味着安装的应用程序应该：
- 包含开发客户端行为
- 对开发者和测试人员来说容易启动
- 在日常工作中连接到 Metro 服务器
- 直到 native 依赖项发生变化之前保持可重用
这也是 CI 开始变得实用的地方。一旦存在可预测的构建配置文件，你就可以自动化它
如果您的团队正在思考React Native如何融入更广泛的现代化工作中，Wonderment Apps对此有一个有用的观点： React Native用于AI现代化。它的相关性在于开发客户端通常会成为团队在移动表面上频繁发布产品变更时的运营基础层的一部分。
如果您想看到流程的实践效果，一个简短的导览可能会有所帮助：
安装结果
当构建完成时，请将输出视为一个真正的应用程序二进制文件，因为它就是这样一个文件。
- 在Android上： 您通常会在一个
.apk上安装一个物理设备或模拟器。 - 在iOS上： 您将与一个
.ipa或模拟器兼容的输出进行工作，具体取决于目标。 - For teammates: 通过正常的EAS机制共享构建，而不是要求每个人从头开始创建自己的构建，除非必要。
开发构建在团队达成一致的规则时最容易管理：对于本地变化重建，不要为每个code变化重建。
什么不应该期待
不要期望第一次构建消除本地复杂性。它将复杂性放在了正确的位置。
如果您添加了新的本机模块、修改了权限、更新了SDK级别的本机依赖项或修改了插件驱动的本机配置，则需要一个新的开发构建。那样是正常的。每天的JavaScript工作仍然在反映应用的客户端中快速移动的奖励是如此。
使用新客户端进行运行和调试
第一次打开安装的客户端并连接到Metro时，差异是明显的。它感觉像Expo，但不再像玩具盒一样。
然后打开模拟器、模拟器或物理设备上的开发客户端并通过启动器UI连接。该启动器是由 npx expo start --dev-client，一同提供了调试支持，如网络请求检查，详见 expo-dev-clientExpo __CAPGO_KEEP_0__开发客户端页面 Expo SDK page for dev client.
正常的开发过程
典型的开发过程大致如下：
您拉取最新的分支。已安装的开发客户端已经在您的设备上。您启动Metro，启动应用程序，并连接到当前服务器。然后，您主要像以前一样工作，修改JavaScript并快速看到更新。
当您需要检查依赖于真实本机环境的行为时，会出现重大差异。自定义客户端让您可以在不脱离常规循环的情况下测试这些流程。
您关心的调试工具
额外的工具不是装饰性的。它解决了日常问题。
- 启动器UI： 在切换环境或团队成员托管的服务器时很有用。
- 开发者菜单： 在活跃迭代期间给您期望的操作。
- 网络检查： 帮助UI看起来破碎但实际问题是请求失败、认证状态或环境连接不正确时
在开发客户端中，当API调用失败时，检查请求路径和环境假设之前不要动UIcode。 bug通常在您正在查看的组件之外
这里的实用优势。 安装的单个二进制文件可以验证多个环境而无需每次重新编译。 这尤其有帮助，当审阅者想要测试PR预览时，QA工程师想要测试阶段，而开发人员想要测试本地分支时
如果您的团队还部署了基于Web的移动壳，Capgo的 Capacitor应用的 ultimate调试指南 是值得阅读的，因为它提供了更广泛的调试思维方式。 工具可能不同，但纪律是相同的：检查传输、环境和运行时行为之前不要猜测
什么有效什么不
什么有效
| 情况 | 为什么开发客户端有帮助 |
|---|---|
| 测试认证重定向 | 原生应用行为更接近生产环境 |
| 验证API集成 | 网络检查缩短了反馈周期 |
| 切换环境 | 启动器UI避免了不必要的重建 |
| 团队QA在一个二进制文件中 | 每个人都测试相同的本机设置 |
不太好用的地方：
- 把客户端当作可丢弃的东西： 如果团队不维护它，混乱就会迅速出现。
- 忽视本机重建边界： 一旦本机依赖项发生变化，过时的客户端就会浪费时间。
- 假设所有连接故障都是应用程序错误： 许多只是本地环境问题。
与CI/CD和实时更新集成
当Expo开发客户端不再是个人设置，而成为团队运营的一部分时，它变得更加有价值。
成熟的工作流程通常会分离关注点。
审阅者和QA不需要问他们是否正在测试正确的东西，因为团队已经同意了通道、构建配置和更新目的地。
专业团队在CI/CD管道自动化工作流程上合作的大型办公室显示屏幕上。
CI/CD在哪里
- 开发客户端与CI一起工作得很好，因为它给自动化提供了一个稳定的目标。 一个常见的模式如下:
- 拉取请求更改: CI创建或验证开发构建时原生依赖项发生了变化。
- 共享测试流程: QA 安装一个或多个已知的开发客户端，并通过启动器和更新配置切换上下文。
这种结构减少了不确定性。开发人员知道何时需要重新构建。测试人员知道他们是否正在验证原生更改还是在现有二进制文件上发布的更新。
实时更新的作用
开发客户端通常可以节省最多的操作时间。开发客户端是验证更新行为在发布之前的强大位置，因为它可以在生产环境中模拟的应用程序外壳中切换开发服务器和发布的更新，正如前面在 Expo 文档中描述的那样。
这打开了一个有用的分裂:
| 更改类型 | 传递路径 |
|---|---|
| 新原生模块或权限更改 | 新开发构建 |
| JavaScript 行为修复 | 发布更新 |
| 资源或资产调整 | 发布更新 |
| 环境验证 | 已安装客户端中切换频道或服务器 |
对于Expo更新栈外的团队来说 Capgo的CI/CD集成指南 Capacitor侧展示了一个可比的运营模型。它是团队想要控制发布频道和更新交付自动化的选项。
The reliable pattern is simple. Build when native code changes. Publish when the installed binary already contains everything the change needs.
当原生__CAPGO_KEEP_0__发生变化时，构建
当已安装的二进制文件已经包含所需的所有更改时，发布
- 预防混乱的团队习惯
staging,production技术设置很重要，但运营规则更重要： - Document rebuild triggers: 新插件、权限变更或本地SDK更新不应成为判断的依据。
- 保持一个可安装的客户端策略： 太多变体会产生支持噪音。
- 更新验证显式化： 有人应该验证更新是否应用并在团队期望的同一个二进制文件中启动。
在这个阶段，Expo开发客户端不再是开发人员的便利工具，而成为发布基础设施。
常见问题和解决方案
大多数Expo开发客户端问题在你知道哪里寻找时是普通的。它们感到神秘，因为失败通常发生在界限之间：笔记本电脑到设备，Metro到应用，native配置到JavaScript运行时。
一个最常见且被低调讨论的问题是连接到Metro的物理设备失败，原因是本地网络隔离、VPN或企业和分布式团队环境中的防火墙规则，一个在这个 Expo Dev Client故障排除视频.
当客户端无法连接到Metro时
这是耗时最多的问题，因为它看起来像是一个破损的应用程序，而实际上应用程序通常是正常的。
首先检查这些：
- 相同的网络假设： 设备和笔记本电脑可能会显示连接状态，而实际上它们可能位于隔离段上。
- VPN干扰： 企业或个人VPN可能会重定向流量，Metro无法容忍这种方式。
- 防火墙规则： 安全工具可能会阻止本地开发流量，而不明显地阻止。
- 企业设备策略： 管理设备有时会限制开发工具依赖的流量模式。
如果项目在模拟器中正常工作，但在物理设备上不正常，首先怀疑网络，而不是怀疑你的React code。
不要从应用程序内部首先调试连接故障。确认设备是否可以实际访问运行Metro的机器。
当重建看起来像随机的
另一个常见的烦恼是有些变化似乎立即出现，而其他人则顽固地不出现。
这通常意味着团队还没有内化重建边界：
| 症状 | 可能原因 | 解决方案 |
|---|---|---|
| JavaScript 更新正常应用 | 预期行为 | 继续在现有客户端中工作 |
| 新本机依赖项不出现 | 本机层发生了变化 | 创建一个新的开发构建 |
| 权限相关行为不一致 | 原生配置已更改 | 重新构建并重新安装 |
| 一名团队成员看到的行为不同 | 安装了不同客户端二进制文件 | 在相同的构建上齐一 |
这不是工作流程的缺陷。它正在做它应该做的事情。
构建失败和团队偏差
当构建失败时，根源原因通常是这些之一：
- 依赖不匹配： 一个包版本与项目的其他部分不一致
- 原生插件假设： 一个配置插件需要设置项目没有。
- 凭证混乱： 签名或帐户访问不一致的团队。
- 陈旧的本地期望： 有人认为新建项目不需要更新，但实际上需要。
Capgo的文章关于 开发者常见的实时更新问题和解决方案 对于此问题的发布侧有用补充阅读。不同的堆栈，同样的教训：许多“应用程序错误”实际上是交付、环境或版本对齐错误。
Expo开发客户端在团队将环境可靠性视为工程的一部分时，表现最佳。不是一个后thought。 一旦你这样做，设置就变得可预测了，预测是你期望的移动工具。
如果您的团队还部署Capacitor应用程序并需要一种控制的方式来交付JavaScript、资产和配置更新，而不必等待商店审查， Capgo 是要评估的一种选择。它提供实时更新、滚动控制和Capacitor和Electron工作流程的CI/CD集成。
