导读《React Native at Airbnb》—— 为什么 Airbnb 放弃了 React Native?

@黄玄，自称前端娱乐圈老人，CS 弱渣。

尽管原文一直在委婉地使用 "sunset"（日落）这个行话，但事实的确是：Airbnb 要放弃 React Native 了。

早上刷到 Gabriel Peal 的推时，看到「两年，220 屏，12w 行 JS」，我的第一反应其实是「Airbnb 真的是很投入 RN 啊」。综所周知 Airbnb 是除 FB 之外对 React 投入最多，在社区里影响力最大的公司之一了， 他们让 React 可以和 Sketch interop ，甚至专门收购了一家做 RN IDE 的公司。结果看到第二行「moving away」我就觉得不对劲了。Grabriel 相信也知道公开宣布放弃 RN 的影响太大（你看我都懒这么久了……），觉得写一篇文不够，于是一连发了 5 篇来解释。

Well，让我们来看看他都说了啥。

1. React Native at Airbnb

In 2016, we took a big bet on React Native. Two years later, we’re ready to share our experience with the world and show what’s next.

https://medium.com/airbnb-engineering/react-native-at-airbnb-f95aa460be1cmedium.com

第一篇是一个开场，介绍了他们是为什么在 2016 年决定在 RN 上堵一把的。大家都知道 RN 理论上的一些优势，所以他们的主要目标是希望能通过 RN 做到：

1. 大团队快速迭代（Allow us to move faster as an organization.)

2. 原生应用质量（Maintain the quality bar set by native.）

3. 代码跨双平台（Write product code once for mobile instead of twice.）

4. 提升开发体验（Improve upon the developer experience.）

如果这四点都达到了，大概今天的文章就是另一个基调了。不着急，我们还有四篇文章呢。

2. React Native at Airbnb: The Technology

The technical details

https://medium.com/airbnb-engineering/react-native-at-airbnb-the-technology-dafd0b43838medium.com

这篇文章着重从技术细节描述 RN 的优劣，我相信大家都比较关注这个，所以我把每一条都列出来了，当然更细的内容还是看原文

他们满意的地方是：

• 跨平台 （只有 0.2% 的平台特定代码）

• 统一的设计语言，同时还能为不同平台提供不同设计

• React 的 scale 很好，生命周期比原生简单，声明式很好

• 迭代速度快（主要是 hot reloading 很快）

• 大量基础设施的投入值得（网络、国际化、复杂动画、设备信息、用户信息等等都是通过一个桥把原生 api 暴露给 RN 的。）

• 同时他们在这里也指出：他们并不相信在一个已有 app 上集成 RN 是一件简单事儿，必须要大量且持续地投入基础设施才行（说好的「满意的地方」呢）

• 性能 （尽管大家都担心但是其实基本没有问题）

• 不过首次渲染比较慢，导致不适合用作启动屏、deeplink，也增加了可交互时间（TTI），另外掉帧不好 debug（说好的「满意的地方」呢）

• Redux（好用，虽然废话太多）

• 背后是原生，一些曾经不确定能不能做的功能（Shared element transitions、动画库 Lottie、网络层、核心基础设施）发现都能做

• 静态分析（eslint，prettier，一些性能检测）

• 动画

• JS/React 的开源生态

• Flexbox （via Yoga）

• 有时候可以加上 Web 跨三端

他们不满意的地方是：

• RN 太不成熟

• 需要 fork RN

• JS 不行 （JS 没有类型不 scale，flow 不好用，TS 不好集成到 babel 和 metro）

• 不好重构（JS 没有类型无法静态分析，重构引起的错误不能在编译时被捕捉到）

• 咳，用我 FB 的新编译到 JS 语言大 ReasonML 啊……静态强类型 + 类型推断 + 自带不可变数据结构 + JS 友好语法 + 官方 React 支持，绝对 scale（咳扯远了

• JSCore 在 iOS / Android 上不一致 （Android 上是 RN 自己 bundle 的），很难 debug 这种坑

• RN 的开源库质量不行（因为太少人能精通所有平台了）

• 做功能时要回去搞基础设施（因为有的基础设施可能还没暴露给 RN）

• 奔溃监控（业内没方案，只能自己搞）

• 原生桥太难写，另外 JS 的类型太难预料（和强类型语言 interop 时）

• RN 运行时的初始化太慢

• 首次渲染时间慢（需要从 主线程 -> JS -> Yoga -> 主线程）

• 应用体积

• 64 位 （因为 RN 不兼容的 issue 导致他们至今没法在 android 发布 64 位应用）

• 手势（iOS 和 Android 的手势不好统一，虽然他们搞了 react-native-gesture-handler）

• 长列表

• 升级 RN 有的时候非常麻烦

• Accessibility （RN 的有 bug，又要 fork）

• 稀奇古怪的奔溃

• 安卓上的应用实例序列化问题

hmm……真是吐槽吐到天上去了……

3. Building a Cross-Platform Mobile Team

Adapting mobile for a world with React Native

https://medium.com/airbnb-engineering/building-a-cross-platform-mobile-team-3e1837b40a88medium.com

这篇主要讲述他们在组建跨平台的移动团队时所遇到的一些管理挑战。

• RN 在内部的评论两极化，

• 要想有好的 RN 体验或者 debug 时还是需要懂 Native，这种原生和 RN 混合对招聘、开发环境、学习成本、测试、迭代速度带来的各种负面影响。

• 如何决定一个新功能是用原生还是 RN？？

• 怎么拆分团队？

等等，很有意思，尤其值得 Engineering Manager/Director 阅读 ;)

4. Sunsetting React Native

Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing.

https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30amedium.com

面对技术与管理的双重挑战，他们认为 RN 并没有达到他们最初列出的四个目标，所以决定 sunset RN 了。