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