你通常在Expo Go開始撒謊的那一刻準備好使用Expo開發客端了。
該應用程式在沙盒中運行。快速刷新感覺很棒。然後你添加一個原生依賴項、設定推送通知、測試OAuth流程或嘗試鏡像你的生產應用程式啟動。突然間差距就變得明顯了。你不再是在debug你的應用程式了。你是在debug一個簡化的環境中。
那就是Expo開發客端改變工作流程的地方。它保留了Expo中人們喜歡的快速JavaScript迴圈，但將測試轉移到一個自訂的原生二進位檔中，這個二進位檔的行為更像你最終要發佈的應用程式。對於單人開發者來說，這意味著在周期末期會有更少的意外。對於團隊來說，這意味著一個可以支持共享建置、QA、預覽環境和更新驗證的開發流程，而不必假裝Expo Go可以覆蓋一切。
目錄
为什么需要超越 Expo Go
Expo Go 在开始时很有用。它消除了设置的摩擦,快速启动了一个 React Native 项目,并给出了快速的反馈循环。这就是为什么许多团队会从那里开始的原因。
问题出在应用程序停止成为原型时。Expo 文档将 Expo Go 描述为一个 "sandbox"，并指出它无法准确模拟一些本机功能，如通知或 OAuth 认证，而开发构建模型则围绕 "和定位为一个 "Debug" 构建用于生产级应用程序" sandbox "和" expo-dev-client "“Debug” 构建用于生产级应用程序" Expo 开发构建介绍 Expo Go 和 Expo 开发客户端工具的关键差异和限制比较表 在实践中，第一个断裂通常是其中之一：.
一个包需要本机 __CAPGO_KEEP_0__，而 Expo Go 不包括
一个包需要本机 __CAPGO_KEEP_0__，而 Expo Go 不包括
- 一个包需要本机 __CAPGO_KEEP_0__，而 Expo Go 不包括 一个包需要本机 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__层开始.
Start with the account and CLI layer
Expo__CAPGO_KEEP_0__访问
- ExpoCLI访问
- EAS CLI access
在终端中，您还需要登录您的Expo账户。团队经常会忽略这一点，因为本地命令看起来可能正常，直到出现第一个远程构建或凭据提示时才会出现问题。
一个干净的设置通常包括：
- 您的Expo账户会话： 这使本地工作与远程构建服务和项目所有权相关联。
- EAS CLI 已安装： EAS 是将您的项目转换为可共享的iOS或Android二进制文件的关键。
- 一个本地运行的项目： 不要在基本应用启动工作之前引入构建复杂性。
安装使工作流程成为可能的包
这个设置的中心是 expo-dev-client。没有它，您就没有自定义启动器和调试定向本机 shell，这定义了Expo开发客户端工作流程。
在应用项目中安装它，然后验证Expo配置是合理的。具体命令可能会因您的包管理器而异，但架构上的点是：这个包就是将应用从“在共享沙盒中运行”转变为“在我们自己的开发二进制文件中运行”的关键。
实用规则： 在native依赖列表稳定到足够让团队成员安装并使用相同二进制文件之前，先构建开发客户端。
尽早检查应用配置
很多混淆都是因为把 app.json 或 app.config.js 当作元数据而已。它们不是。这些文件定义了身份。
确保项目具有：
- 一个独特的应用名称： 当开发者在一台设备上安装多个变体时很有帮助。
- 一个独特的捆绑包或包标识符： 对于native构建和后续签名至关重要。
- 清除环境意图： 如果团队使用单独的测试和生产身份，务必明确反映这一点。
如果您的本地环境混乱，值得在第一次构建之前进行整理。Capgo关于 设置Capacitor本地环境 的指南不是Expo特有的，但它是一个好提示，重现性移动工作始于稳定的本地工具和明确的配置。
一个好的首次配置是什么样的
在启动EAS之前，请使用此检查清单：
| 检查 | 为什么它很重要 |
|---|---|
expo-dev-client 已安装 | 启用自定义开发客户端行为 |
| Expo账户已链接 | Required for smooth EAS usage |
| App identifiers 是唯一的 | Prevents native build and install conflicts |
| 项目从本地开始 | 避免混合 runtime 问题与构建问题 |
| 团队知道何时重建 | 减少本地更改后混淆 |
目标不是完美。目标是让第一次构建变得无聊。这就是胜利。
使用 EAS 构建您的自定义客户端
这是工作流程变得真实的地方。您停止谈论自定义客户端并生成一个。
Expo 推荐用于具有自定义本机 code: 安装的应用程序的开发构建工作流程 expo-dev-client, 生成本地或使用 EAS Build 的本机应用程序，然后运行 npx expo start --dev-client. Expo 也注意到在 "workflow overview" 中，JavaScript-only 的更改保持快速，而 native-__CAPGO_KEEP_0__ 的更改需要一个新的开发构建。 工作流程概述 native-code 的更改需要一个新的开发构建。
基本的 EAS 流程
序列是简单的，即使第一次运行也会感到陌生：
- 安装并使用 EAS CLI 进行身份验证
- 初始化或确认构建配置
- 创建一个开发构建配置
- 触发 iOS 或 Android 的构建
- 在设备或模拟器上安装结果的二进制文件
EAS 给你的是一致性。相比于每个开发者在本地进行 native 构建状态的即兴表演，团队可以从一个共享的构建定义中产生二进制文件。
What your build profile is really doing
A development profile 不仅仅是一个标签。它告诉构建系统，这个二进制文件是用于活跃开发，而不是商店分发。
通常意味着安装的应用程序应该：
- 包含开发客户端行为
- 为开发人员和测试人员提供便利的启动方式
- 在日常工作中连接到 Metro 服务器
- 保持可重用性，直到原生依赖项发生变化
这也是 CI 开始变得实用的地方。一旦存在可预测的构建配置文件，您就可以自动化它。
如果您的团队正在思考 React Native 在更广泛的现代化工作中的作用，Wonderment Apps 提供了一个有用的观点 React Native for AI modernization。它相关，因为开发客户端通常成为团队在移动表面上频繁推送产品变化时的操作基层。
如果您想看到流程的实时演示，一个简短的引导可以帮助您：
安装结果
一旦构建完成，处理输出就像处理真正的应用程序二进制文件一样，因为它就是那样。
- 在 Android 上： 您通常会在
.apk物理设备或模拟器上安装一个 - 在 iOS 上： 您将与一个
.ipa或模拟器兼容的输出进行工作，具体取决于目标。 - 对于团队成员： 通过正常的 EAS 机制共享构建结果，而不是要求每个人都从头开始创建一个，除非必要。
开发构建在团队成员同意一个规则时最容易管理：重建原生变化，不要为每个 code 变更重建。
What not to expect
不要期望第一次构建能消除原生复杂性。它将复杂性放在了正确的位置。
如果您添加了新的原生模块、修改了权限、更新了SDK级别的原生依赖或修改了插件驱动的原生配置，则需要重新生成开发构建。那样是正常的。每天的JavaScript工作仍然在反映应用的客户端中快速进行。
运行和调试您的新客户端
第一次打开已安装的客户端并连接到Metro时，差异是明显的。它感觉像Expo，但不再像玩具盒一样。
首先使用 npx expo start --dev-client然后在模拟器、模拟器或物理设备上打开开发客户端并通过启动器UI连接。该启动器是由 expo-dev-client引入的重要变化之一，伴随着调试支持，如网络请求检查，详见 Expo SDK开发客户端页面.
正常的开发会话
典型的会话如下：
You pull the latest branch. The installed development client is already on your device. You start Metro, launch the app, and connect to the current server. Then you work mostly as you did before, changing JavaScript and seeing updates quickly.
当您需要检查依赖于真实本地环境的行为时，会出现大差异。自定义客户端让您可以在不脱离常规循环的情况下测试这些流程。
调试工具
额外的工具不是装饰性的。它解决了日常问题。
- 启动器 UI: 在切换环境或同事托管的服务器之间时很有用。
- 开发菜单: 在活跃迭代期间给予您期望的操作。
- 网络检查: 当 UI 看起来破损，但实际问题是请求失败、认证状态或环境连接错误时会很有用。
当 API 在开发客户端中调用失败时，请检查请求路径和环境假设之前触摸 UI code。 bug 通常位于您正在 stares 的组件之外。
这是实际优势。一个安装的二进制文件可以验证多个环境而无需每次重新编译。尤其是在审阅者想要测试 PR 预览、QA 工程师想要测试环境和开发人员想要测试本地分支时，这尤其有用。
如果您的团队还部署了基于Web的移动壳，Capgo’s Capacitor应用的终极调试指南 值得阅读的更广泛的调试思维方式。工具不同，但纪律相似：检查传输、环境和运行时行为之前猜测。
什么有效，什么不有效
什么有效：
| 情况 | 为什么开发客户端有帮助 |
|---|---|
| 测试认证重定向 | 本机应用行为更接近生产 |
| 验证API集成 | 网络检查缩短了反馈循环 |
| 切换环境 | 避免不必要的重建 |
| 团队QA使用同一二进制文件 | 每个人都测试相同的本机设置 |
不太好用的地方是：
- 将客户端视为可丢弃的： 如果团队不维护它，混乱就会迅速出现。
- 忽视本机重建边界： 本机依赖项发生变化后，过时的客户端会浪费时间。
- 假设所有连接故障都是应用程序错误： 许多只是本地环境问题。
与CI/CD和实时更新集成
Expo开发客户端在停止成为个人设置并成为团队运营的一部分时，变得更加有价值。
一个成熟的工作流程通常会分离关注点。原生变化产生一个新的开发构建。JavaScript 和资产变化通过一个更快的更新路径。审阅者和 QA 不需要问他们是否正在测试正确的东西，因为团队已经同意了通道、构建配置和更新目的地。
CI/CD 的适用场景
开发客户端与 CI 很好地协作，因为它为自动化提供了一个稳定的目标。
一个常见的模式如下：
- 拉取请求变化： CI 创建或验证一个开发构建，当原生依赖项发生变化时。
- 基于分支的环境： 不同分支映射到不同的更新通道或服务器目标。
- 共享测试者工作流： QA 安装一个或多个已知的开发客户端并切换上下文通过启动器和更新配置。
这种结构减少了不确定性。开发者知道他们需要重新构建。测试者知道他们是否正在验证原生变化还是在现有二进制文件上推送的更新。
__CAPGO_KEEP_0__
开发客户端经常使团队能够节省最多的操作时间。开发客户端是验证更新行为在发布之前的强大位置，因为它可以在生产环境中切换开发服务器和发布的更新，正如前面在 Expo 文档中所描述的那样。
这打开了一个有用的分裂：
| 类型 | 发布路径 |
|---|---|
| 新本机模块或权限更改 | 新开发构建 |
| JavaScript 行为修复 | 发布更新 |
| 复制或资产调整 | 发布更新 |
| 环境验证 | 切换已安装客户端的频道或服务器 |
对于Expo更新栈外的团队 Capgo的CI/CD集成指南 展示了与Capacitor侧的可比操作模型。它是团队想要控制发布频道和更新交付自动化的选项。
可靠的模式很简单。 当本地code发生变化时，构建。 当已安装的二进制文件已经包含所需的所有更改时，发布。
预防混乱的团队习惯
技术设置很重要，但运营规则更重要：
- 明确频道名称：
staging,production预览名称应该很明显。 - 记录重建触发器： 新插件、权限更改或本地SDK更新不应成为判断的依据。
- 保持一个环境中的可安装客户端策略： 太多的变体会产生支持噪音。
- 使更新验证明确： 有人应该验证更新是否应用并在团队期望的同一二进制文件中启动。
在这个阶段，Expo开发客户端不再是开发人员的便利工具，而成为发布基础设施。
常见问题和解决方案
大多数Expo开发客户端问题在你知道哪里寻找之后是普通的。它们看起来神秘，因为失败通常发生在界限之间：笔记本电脑到设备，Metro到应用，native配置到JavaScript运行时。
一个最常见且被低调讨论的问题是无法连接到Metro的物理设备，因为本地网络隔离、VPN或企业和分布式团队环境中的防火墙规则，一个在这个 Expo Dev Client故障排除视频.
当客户端无法连接到Metro时
这是一个耗时最多的问题，因为它看起来像是一个故障的应用程序，而应用程序通常是正常的。
首先检查这些：
- 相同的网络假设： 设备和笔记本可能会显示连接状态，但实际上它们位于隔离的网络段中。
- VPN 干扰： 公司或个人 VPN 可能会重定向流量，Metro 不支持这种方式。
- 防火墙规则： 安全工具可能会阻止本地开发流量，但不会明显提示。
- 公司设备政策： 管理设备可能会限制开发工具依赖的流量模式。
如果项目在模拟器中正常运行，但在物理设备上不正常，请先怀疑网络问题，而不是 React code。
不要从应用内部调试连接问题。确认设备是否可以正常访问运行 Metro 的机器。
重建时出现的随机问题
另一个常见的问题是，某些更改似乎立即生效，而其他更改则坚持不变。
这通常意味着团队还没有理解重建边界：
| 症状 | 可能原因 | 修复 |
|---|---|---|
| JavaScript 更新正常应用 | 预期行为 | 继续在现有客户端中工作 |
| 新本机依赖项未显示 | 本机层发生了变化 | 创建一个新的开发构建 |
| 权限相关行为不一致 | 本机配置发生了变化 | 重新构建并重新安装 |
| 团队成员看到的行为不同 | 安装的客户端二进制文件不同 | 在同一构建上保持一致 |
这不是工作流程的缺陷。它只是做了它应该做的事情。
构建失败和团队偏离
当构建失败时，根源原因通常是这些之一：
- 依赖不匹配： 一个包版本与项目的其他部分不一致。
- 本机插件假设： 一个配置插件期望的设置项目没有。
- 凭证混淆： 签名或账户访问不一致于团队。
- Stale local expectations: Someone assumes a fresh build isn’t needed when it is.
Capgo的文章关于 开发者常见的实时更新问题和解决方案 对解决本问题的发布侧有所帮助。不同堆栈，同样的教训：许多“应用程序错误”实际上是交付、环境或版本对齐错误。
Expo开发客户端在团队将环境可靠性视为工程的一部分时表现最佳。不是一个后thought。 一旦你这样做，设置就变得可预测了，预测性是您希望从移动工具中获得的。
如果您的团队还部署Capacitor应用程序并需要一种控制的方式来交付JavaScript、资产和配置更新而不必等待商店审查， Capgo 是您可以评估的一种选择。它提供实时更新、滚动控制和Capacitor和Electron工作流的CI/CD集成。
