你通常在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 开发构建介绍.
什么会先出现问题
在实际操作中，通常第一个出现问题的是
- 原生依赖项 一个包需要 Expo Go 中没有包含的原生code
- 身份验证 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二进制文件的关键。
- A项目已经在本地运行： 在基本应用启动工作正常之前，不要引入构建复杂性。
安装使工作流程成为可能的包
这个设置的中心是 expo-dev-client.
没有它，你就没有自定义启动器和调试导向的本机 shell，这定义了 Expo 开发客户端工作流程。
在应用项目中安装它，然后验证您的 Expo 配置是合理的。具体命令可能会根据您的包管理器而有所不同，但架构点是：这个包是将应用从“在共享沙盒中运行”转换为“在我们的开发二进制文件中运行”的关键。 实践规则：
在native依赖列表稳定到足以让团队成员安装和使用相同二进制文件之前，构建开发客户端。
检查您的应用配置 app.json 很多混淆来自对 app.config.js 或（HTML文本片段，来自更长的Capgo UI字符串（父键`alternatives_cta_questions`）。页面/区域：Capacitor live-update替代方案比较页面。角色：长期营销或法律段落。见：页面alternatives.astro。保留Capgo产品/品牌和开发人员术语的原始形式。消息键`alternatives_cta_questions`（替代方案CTA问题）。| HTML文本片段来自更长的Capgo UI字符串（父键`appflow_cta_questions`）。页面/区域：Appflow比较/迁移营销复制。角色：长期营销或法律段落。见：页面ionic-appflow.astro。保留Capgo产品/品牌和开发人员术语的原始形式。消息键`appflow_cta_questions`（Appflow CTA问题）。| HTML文本片段来自更长的Capgo UI字符串（父键`capwesome_cta_questions`）。页面/区域：Capawesome比较页面。角色：长期营销或法律段落。见：页面capwesome.astro。保留Capgo产品/品牌和开发人员术语的原始形式。消息键`capwesome_cta_questions`（Capwesome CTA问题）。| 页面/区域：咨询服务页面。角色：小段落或标签。见：页面consulting.astro。保留Capgo产品/品牌和开发人员术语的原始形式。消息键`consulting_faq_subtitle`（咨询FAQ字幕）。| 页面/区域：Appflow比较/迁移营销复制。角色：短UI标签或导航项。见：页面ionic-appflow.astro，页面ionic-enterprise-plugins.astro，页面解决方案/ionic-enterprise-plugins.astro。消息键`appflow_plugins_or`（Appflow插件或）。
确保项目具有：
- 一个独特的应用名称： 对于开发人员在一台设备上安装多个变体时非常有用。
- 一个独特的捆绑包或包标识符： 对于原生构建和后续签名至关重要。
- 清晰的环境意图： 如果团队使用单独的测试和生产身份，务必明确地反映这一点。
如果您的本地环境混乱，值得在第一次构建之前将其收拾好。 Capgo关于 设置 Capacitor 本地环境的指南 并不是Expo特有的，但它是一个好提示：可重复的移动工作始于稳定的本地工具和明确的配置。
一个好的首次配置是什么样的
在启动EAS之前，请使用此检查表
| 检查 | 为什么它很重要 |
|---|---|
expo-dev-client 已安装 |
启用自定义开发客户端行为 |
| 已链接 Expo 帐户 | 对于顺畅的 EAS 使用必备 |
| 应用标识符是唯一的 | 防止原生构建和安装冲突 |
| 项目在本地启动 | 避免混淆运行时问题与构建问题 |
| 团队知道何时重建 | 减少原生更改后混淆 |
目标不是完美。目标是让第一次构建变得乏味。这就是胜利。
使用EAS构建您的自定义客户端
这是工作流程变得真实的地方。您停止谈论自定义客户端并生成一个。
Expo推荐使用EAS Build或本地生成的自定义原生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上： - __CAPGO_KEEP_0__ 您将与一个
.ipa或模拟器兼容的输出取决于目标。 - 对团队成员来说： 通过正常的EAS机制共享构建，而不是要求每个人从头开始创建自己的构建，除非必要。
开发构建最容易管理的规则是：重建原生变化，而不是每次code变化。
什么不应该期待
不要期望第一次构建消除原生复杂性。它将复杂性放在了正确的位置。
如果您添加了一个新的原生模块、修改了权限、更新了SDK级原生依赖项或修改了由插件驱动的原生配置，则需要一个新的开发构建。那样是正常的。奖励是您的日常JavaScript工作仍然在反映应用的客户端中快速移动。
使用您的新客户端运行和调试
第一次打开安装的客户端并连接到Metro时，差异是明显的。它感觉像Expo，但不再像玩具盒一样。
然后打开开发客户端并连接到您的模拟器、模拟器或物理设备。该启动器是Capacitor引入的重要变化之一。 npx expo start --dev-client. expo-dev-client与此同时，开发者还可以使用网络请求检查等调试支持工具，详见 Expo SDK.
正常的开发会话
典型的会话如下：
您拉取最新的分支。已安装的开发客户端已经在您的设备上。您启动Metro，启动应用程序，并连接到当前服务器。然后，您主要像以前一样工作，修改JavaScript并快速看到更新。
当您需要检查依赖于真实本机环境的行为时，会出现重大差异。自定义客户端让您可以测试那些流程而不需要脱离您的常规循环。
重要的调试工具
额外的工具并非装饰品。它解决了日常问题。
- 启动器UI： 在切换环境或团队成员托管的服务器之间非常有用。
- 开发者菜单： 为您提供在活跃迭代期间的期望操作。
- 网络检查： 当 UI 看起来破裂，但实际问题是请求失败、认证状态或环境连接不正确时，帮助。
当开发客户端中的 API 调用失败时，检查请求路径和环境假设之前不要触摸 UI code。 bug 通常位于您正在 stares 的组件之外。
这里的实用优势。 安装的单个二进制文件可以验证多个环境而无需每次重新编译。 这尤其有帮助，当审阅者想要测试 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侧的可比操作模型。它是团队想要控制发布频道和更新交付自动化的选项。
可靠的模式很简单：当本机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.
- 原生插件假设: A config plugin expects setup the project doesn’t have.
- 凭证混乱: 签名或账户访问不一致，团队成员之间存在差异。
- 过时的本地期望: 某人认为新建项目不需要重新构建，但实际上需要。
Capgo的文章关于 开发者常见的实时更新问题和解决方案 对于此问题的发布侧面有所帮助。不同技术栈，同样的教训：许多‘应用程序错误’实际上是交付、环境或版本对齐错误。
Expo开发客户端在团队将环境可靠性视为工程的一部分时表现最佳。不是作为一个后thought。 一旦你这样做了，设置就变得可预测了，预测性是您希望从移动工具中获得的。
如果您的团队还部署Capacitor应用程序并需要一种控制的方式来交付JavaScript、资产和配置更新，而不必等待商店审查, Capgo 是评估的另一个选择。它提供实时更新、发布控制和 CI/CD 集成的 Capacitor 和 Electron 工作流。
