引言

我们总结无数的技术优缺点，同样认识到 RN 对于工程团队的影响。

适配 RN 比新增开源库或模式要复杂的多，而且给团队带来了挑战。

团队挑战不像技术问题可以解决或者有替代方案解决，它更难发现、修正和恢复。

庆幸的是，我们的移动团队文化很健康，但考虑使用 RN 仍然要考虑很多问题。

RN 正在走向极端

从我们的使用经验来看，采用 RN 的工程师有着截然不同的观点，有的认为 RN 是一枚银弹，统一三端，

有点则完全反对团队内使用 RN。同样的情形在使用 RN 后发生。

有些团队觉得很好，有点则完全后悔使用 RN, 直接回归原生。

根本原因归属

使用 RN 的过程中，有很多 bug、优点和性能问题。

• 1. RN 本身更新迅速
• 2. 我们完善基础设施，同时进行功能开发
• 3. 工程师们一起学习 RN，对每个人来说都很新
• 4. 针对开发调试和线上调试的文档和指南有时不全，导致难以理解

结果经常很难发现问题的根源，有时都不清楚那个团队出了问题或者来自 RN

RN 仍然属于原生

RN 比较常见的误解是允许开发者快速编写原生代码，但是明显不是真实情况。

RN 的原生基础仍然盛行，例如，文本在不同平台渲染效果不一致，

键盘处理完全不同，android 切换屏幕方向时默认重新创建 Activity。

高质量 RN 使用需要谨慎考虑两个方向平台之间的平衡。

精通三个平台的难度成为 RN 高质量开发的最大障碍。

跨平台调试

大部分工程师只熟悉一到两个平台。

很少人能够同时掌握安卓、IOS 和 React。

即使在 RN 环境下主要使用 JS 和 React 开发，但打包和调试时仍然要深入原生。

这就会导致工程师卡在他们不熟悉的领域，尝试去解决完全没用过的平台问题。

这种情形在根本原因很复杂时，工程师甚至无法确定问题来源，会变得更加糟糕。

招聘

即使我们在 RN 上投入很多，但我们移动端目标和团队仍在并行发展。

但是经过社区的口口相传，许多人开始把 RN 和公司关联在一起，有些甚至以为

我们的应用 100%用 RN。

虽然事实不是这样，结果许多安卓和 IOS 工程师依然犹豫是否要投简历。

如果你是其中一员，我们依然在招聘。

混合应用很难

完全原生开发或完全 RN 开发的路径相对比较直接。但是，一旦你在两者直接混合开发，

将会出现很多新问题。如何分割团队？团队之间如何协作？跨应用之间如何共享状态？

如何决策哪个平台使用新特性？如何招聘并跨组织协调资源？

这些都是之前没有尝试解决方案的问题。如果选择混合开发，问题将会接踵而至。

三种开发环境

为了成为高效的 RN 开发工程师，保持稳定实时更新的三端环境十分重要。

对于 airbnb 这样的大型团队，每个平台需要相当多的时间配置，学习和保持更新。

几周时间后回归团队就意味着要花费数小时来更新一切环境。

权衡原生和 RN

很多时候最佳解决方案原生和 RN 都可以实现。例如，导航可以用 Activity 和 ViewControllers 实现，

大部分代码都是平台原生代码。有时都不确定代码应该用原生还是 RN.

一般工程师都会选择自己熟悉的平台实现，导致不理想的代码实现。

跨平台测试

我们发现工程师为了方便，基本都开发一个平台，他们会认为一个平台测试通过了，其他平台也可以用。

大部分时间，由于 RN 的魔力，这种想法是对。 但是在后续的 QA 环节或生产环境中，经常会产生很多问题。

团队分割

采用混合式开发的团队经常会面临技术和沟通上的挑战。一旦代码在两个平台分离，代码变得碎片化。

共享业务逻辑、模型和状态等等会变得更加艰难，工程师们也无法掌握整个流程每个环节。

我们一开始就知道会发生这种情况，却认为可以通过和 web 紧密合作达到平衡。

很少团队真的开始在 web 和移动端共享资源和代码，但大部分不知道其中潜在的优势。

表面迭代速度

RN 的一项重要目标是提升开发速度。RN 功能通常由一个工程师开发，而不是针对每个平台。

从 RN 工程师的角度，开发相同的功能时长会比原生平台长 50%。

公开资源和文档

安卓和 IOS 平台已经发展数十年，数万计的工程师贡献了很多学习资源，开源库和在线帮助。

我们也在 CodePen 上提供很多资源帮助人们学习安卓和 IOS。

即使 RN 有着最庞大的跨平台社区，同时利用 React 资源，但仍然比原生平台要小的多。

我们不得不自己创建大部分的基础工具，和原生相比，RN 学习和培训资源却十分有限。

译者注

• 原文链接

• 原文有删减，因译者水平有限，如有错误，欢迎留言指正交流