跳至主内容

旧金山见面会回顾

· 1 分钟阅读
Héctor Ramos
Héctor Ramos
Former Developer Advocate @ Facebook
非官方测试版翻译

本页面由 PageTurner AI 翻译（测试版）。未经项目官方认可。 发现错误？ 报告问题 →

上周我有幸参加了在 Zynga 旧金山办公室举办的 React Native 见面会。现场约有 200 人参加，这是一个绝佳的机会，让我结识了附近同样对 React Native 感兴趣的其他开发者。

我特别想了解 Zynga、Netflix 和 Airbnb 等公司如何使用 React 和 React Native。当晚的议程安排如下：

  • React 中的快速原型设计

  • 为 React Native 设计 API

  • 弥合鸿沟：在现有代码库中使用 React Native

不过活动开始前，我们先进行了简短介绍和近期动态回顾：

  • 你知道吗？React Native 已是 GitHub 上最热门的 Java 仓库

  • rnpm 现已并入 React Native 核心！现在你可以使用 react-native link 替代 rnpm link 来安装带原生依赖的库

  • React Native 见面会社区正在快速壮大！目前全球各地的聚会小组已有超过 4,800 名开发者参与

如果这些聚会在你附近举办，我强烈建议参加！

Zynga 的 React 快速原型实践​

新闻分享环节后，当晚的东道主 Zynga 进行了简短介绍。Abhishek Chadha 分享了他们如何利用 React 在移动端快速原型设计新体验，并演示了一款类 Draw Something 应用的快速原型。他们采用与 React Native 类似的方法，通过桥接机制访问原生 API。当 Abhishek 调用设备摄像头拍摄观众照片并在某人头上绘制帽子时，这一点得到了生动展示。

Netflix 的 React Native API 设计之道​

接下来是当晚的首场主题演讲。Netflix 高级软件工程师 Clarence Leung 分享了为 React Native 设计 API 的经验。他首先指出开发者可能构建的两类库：标签栏/日期选择器等组件库，以及相机相册/应用内支付等原生服务访问库。在构建 React Native 库时，主要有两种实现路径：

  • 提供平台特定组件

  • 构建跨平台库（Android/iOS 保持相似 API）

每种方案各有考量，具体选择取决于你的实际需求。

方案一

Clarence 以 React Native 核心的 DatePickerIOS 和 DatePickerAndroid 为例说明平台特定组件。iOS 的日期选择器作为 UI 元素直接嵌入视图，而 Android 则以模态框形式呈现。这种情况下提供独立组件是合理的设计选择。

方案二

另一方面，照片选择器在 Android 和 iOS 上的处理方式类似。存在一些细微差异——例如 Android 不会像 iOS 那样将照片分组到"自拍"等文件夹中——但这些差异可以通过 if 语句和 Platform 组件轻松处理。

无论您选择哪种方法，最小化 API 表面并构建特定于应用的库都是明智之举。例如，iOS 的应用内购买框架支持一次性消耗性购买以及可续订订阅。如果您的应用仅需支持消耗性购买，您可以在跨平台库中直接省略订阅功能。

Clarence 演讲结束后进行了简短的问答环节。其中透露的一个有趣细节是：Netflix 为这些库编写的 React Native 代码中，约 80% 可在 Android 和 iOS 平台共享。

弥合差距：在现有代码库中使用 React Native​

当晚的最后一场演讲来自 Airbnb 的 Leland Richardson，聚焦于在现有代码库中使用 React Native。我深知使用 React Native 从零开发新应用非常便捷，因此对 Airbnb 在现有原生应用中集成 React Native 的经验格外感兴趣。

Leland 首先介绍了 greenfield 应用与 brownfield 应用的区别。Greenfield 指无需考虑历史包袱的全新项目，而 brownfield 项目则需要兼顾现有工程需求、开发流程及多团队协作等复杂因素。

开发 greenfield 应用时，React Native CLI 会为 Android 和 iOS 创建统一仓库。Airbnb 面临的第一个挑战是：他们的 Android 和 iOS 应用分属独立仓库。采用多仓库结构的公司在引入 React Native 前需跨越这一障碍。

为此，Airbnb 首先为 React Native 代码建立了专属仓库。他们通过持续集成服务器将 Android/iOS 仓库镜像至此新仓库，测试运行并构建 bundle 后，再将产物同步回原仓库。这样移动工程师可在不改变开发环境的前提下处理原生代码——无需安装 npm、运行打包服务或手动构建 JavaScript bundle。而编写 React Native 的工程师则直接在专属仓库工作，无需操心跨平台代码同步。

该方案存在明显缺陷：无法实现原子更新。涉及原生和 JavaScript 联动的变更需拆分成三个独立 PR，且必须谨慎协调合并顺序。为避免冲突，若主分支在构建期间发生变化，CI 将中止向 Android/iOS 仓库的同步。这在高频提交时期（如版本发布阶段）会导致严重延迟。

Airbnb 现已转向单仓库方案。值得庆幸的是该方案已在规划中，当 Android/iOS 团队熟悉 React Native 工作流后，便欣然推动了单仓库迁移进程。

这基本解决了分仓库方案的问题。Leland 也指出单仓库会给版本控制系统带来更大压力，小型公司需评估此影响。

导航难题​

Leland 演讲的后半段聚焦于 React Native 的核心痛点：导航解决方案。他剖析了丰富的导航库生态（包括官方和第三方方案），特别提到 NavigationExperimental 看似前景广阔，最终却未能满足其实际需求。

实际上，现有的导航库似乎都无法很好地支持遗留应用（brownfield app）。这类应用要求导航状态完全由原生应用掌控。例如，当用户会话在 React Native 视图展示期间过期时，原生应用应能随时接管并弹出登录界面。

Airbnb 还希望避免在过渡期间用 JavaScript 实现的导航栏替换原生导航栏，因为这种切换可能产生割裂感。最初他们仅限模态视图使用 React Native，但这显然限制了 React Native 在整个应用中的推广范围。

因此他们决定开发专属库 airbnb-navigation。由于该库深度耦合 Airbnb 的代码库，目前尚未开源，但他们计划在今年年底前发布。

此处不深入解析库的 API 设计，但核心要点包括：

  • 必须预先注册所有场景（scene）

  • 每个场景都在独立的 RCTRootView 中渲染，并通过各平台原生方式呈现（例如 iOS 使用 UINavigationController）

  • 场景中的主 ScrollView 需包裹在 ScrollScene 组件内，从而支持点击状态栏自动回滚等原生行为

  • 场景转场由原生系统处理，无需担心性能损耗

  • 自动支持 Android 返回键操作

  • 通过无界面的 Navigator.Config 组件实现基于视图控制器的导航栏样式配置

同时也需注意以下限制：

  • 导航栏作为原生组件难以通过 JavaScript 深度定制（这是该库的硬性要求）

  • 通过桥接传递的 ScreenProps 需序列化/反序列化，传递大量数据时需谨慎

  • 导航状态由原生应用管控（核心设计原则），因此 Redux 等方案无法操作导航状态

演讲后的问答环节中，Airbnb 表示对 React Native 整体满意。他们计划采用 Code Push 实现热修复以绕过应用商店审核，工程师们尤其推崇 Live Reload 功能——无需重新编译原生应用即可实时查看代码改动。

活动尾声​

活动结束时分享了更多 React Native 动态：

技术沙龙是向社区开发者学习交流的绝佳机会。期待未来参与更多 React Native 线下聚会。若您也参加相关活动，欢迎随时交流探讨如何让 React Native 更好地服务您的开发需求！