引言

尽管很多团队都依赖 RN，计划在未来投入使用，但 RN 最终无法满足我们初始目标。

另外，有很多我们无法克服技术和组织挑战，继续投入 RN 成为另一个挑战。

最终，我们决定放弃 RN，重新全力投入原生方向。

未能实现目标

更高效的运行速度

当 RN 持续更新时，工程师无法保持相对的跟进速度。

我们之前提到的很多技术和组织问题也带来阻碍，导致很多项目延期。

维持平稳质量

近期，RN 逐渐成熟，我们也积累更多经验，已经能够处理一些之前不确定能否实现的功能。

我们创建了元素渐变、视差，能够优化某些以前经常掉帧的界面性能。

但是，像初始化和异步初次渲染等技术挑战让实现某些目标变得颇具挑战。

缺乏内部和外部资源导致更加困难。

写份代码而不是两份

即使 RN 代码几乎可以完全跨平台共享，但我们应用只有很少比例 RN 代码。

另外需要大量桥接基础设施代码来确保工程师们高效工作。

结果，我们包装了三个平台的支持代码。

我们的确在 web 和移动端之间共享了一些 npm 包，但是实际上代码共享没有真正实现过。

提升开发者体验

RN 的开发者体验可以说是混合式的 BUG，有时比如，构建时间出奇的好，但是像调试，就会变得很恶心。

放弃计划

因为我们通过 RN 实现团队目标，我们决定 RN 已不再适合团队。

目前我们正在着手制定一项稳定平移计划。

我们已经停止所有 RN 新功能开发，计划年底前把大部分的高访问流量的界面转变原生界面。

界面重新设计的计划也正在进行中。

原生基础团队将会支持 RN 渡过 2018 年。

2019 年将会放弃 RN 支持，并减少某些头疼的 RN 场景，比如，开启时初始化运行时。

我们团队都是开源的忠实信徒。

我们积极使用开源，也贡献了很多世界范围的开源项目，并且开源了一些我们的 RN 项目。

放弃 RN 之后，我们不会再维护 RN 分支仓库，我们会迁移一些 RN 开源项目到 RN 社区，比如已经开始进行的

react-native-maps 和马上进行的native-navigation和lottie-react-native。

也不完全糟糕

尽管我们无法通过 RN 实现我们的目标，但是使用 RN 的工程师一般体验比较好。

• 60%的人认为开发体验比较好

• 20%认为有点好

• 15%认为有点不好

• 5%认为很糟糕

63%的工程师会重新选择 RN，74%的人会在新项目考虑使用 RN.

这些工程一共编写 220 屏界面，8 万行代码和 4 万行 js 工具代码。

我们的代码量是他们的 10 倍，界面是 4 倍。

RN 趋于成熟

这系列文章都是我们迄今为止使用 RN 的真实经验。

但是，FN 和广大的 RN 社区致力于让 RN 项目构建扩展的混合应用。

RN 进步很快。

仓库去年已经有 2500 次提交。

FB 也宣布他们面临和我们一样的技术挑战。

即使我们不会继续投入 RN 项目，我们也会继续跟踪社区的发展。

因为 RN 技术胜利意味哪些全世界使用我们产品用户的胜利。

额外体会

我们在已经成熟快速迭代的大型原生应用中集成 RN.

我们碰到的很多问题是当前采用的混合模型方法产生的。

但是我们的体量允许我们解决很多困难问题，而很多更小的公司可能没有时间解决。

每个使用 RN 的公司团队组合、既有原生应用、产品需求和 RN 成熟度方面会有自己独特的体验。

当所有一切组合在一起，可以实现很多功能，迭代速度，开发质量，开发体验，也许会超越我们

的目标和期望。

有时，真的感觉正在改变移动开发。

即使这些经验很鼓舞人，我们平衡积极面和当前需求和资源的痛点鸡皮，我们 RN 已经不适合团队。

决定是否采用新平台是一项重大决策，依赖很对团队相关的因素。

我们的经验和快速发展目标可能并不适应你的团队。

实际上，很多公司仍然使用 RN，并且很成功，对于很多团队来说，RN 也许仍然是最好的选择。

尽管我们没有停止在原生的投入，放弃 RN 释放了更多资源，可以让原生做的更好。

下面的文章将会介绍我们原生平台的新方向。

译者注

• 原文链接

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