尽管原文一直在委婉地使用 "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.medium.com/airbnb-engi…
第一篇是一个开场，介绍了他们是为什么在 2016 年决定在 RN 上堵一把的。大家都知道 RN 理论上的一些优势，所以他们的主要目标是希望能通过 RN 做到：
- 大团队快速迭代（Allow us to move faster as an organization.)
- 原生应用质量（Maintain the quality bar set by native.）
- 代码跨双平台（Write product code once for mobile instead of twice.）
- 提升开发体验（Improve upon the developer experience.）
如果这四点都达到了，大概今天的文章就是另一个基调了。不着急，我们还有四篇文章呢。
2. React Native at Airbnb: The Technology
The technical detailsmedium.com/airbnb-engi…
这篇文章着重从技术细节描述 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 Nativemedium.com/airbnb-engi…
这篇主要讲述他们在组建跨平台的移动团队时所遇到的一些管理挑战。
- 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.medium.com/airbnb-engi…
面对技术与管理的双重挑战，他们认为 RN 并没有达到他们最初列出的四个目标，所以决定 sunset RN 了。
Airbnb 已经停止用 RN 一些开发新特性，并且准备在发布新设计的同时，从最主要的业务开发逐步转回 native，预计在 2019 取得一定的进展。
对于开源，他们会将一些好的 RN 项目转到 react-native-community 下面。
Airbnb 总计投入了 8w 行产品代码，220 个页面和 4w 行基础设施代码在 RN 上，同时也指出他们在 iOS/Android 上分别有 10 倍于此的代码量和 4 倍于此的页面数量。（这么多吗！？）
他们提到 RN 在走向成熟，包括 State of React Native 2018 · React Native
最后，说明他们放弃 RN 的举措并不是适用于所有公司的。但是由于上述痛点和资源等原因，决定 sunset RN。
5. What’s Next for Mobile at Airbnb
Bringing the best back to nativemedium.com/airbnb-engi…
最后一篇介绍了 Airbnb 在移动端的未来方向：
首先，介绍了一个他们的新方向：
Server-Driven Rendering （服务端驱动渲染）
一言以蔽之，就是服务端发送某种 View 的抽象描述，然后移动端解析这种描述并渲染。
（其实阿里的 Weex 和 Facebook 内部都有类似的技术）
SDR（新词来了！）有诸多好处，详见原文吧 ;)
后面就是一些广告了，介绍了 Epoxy、MvRx、部分 build （类似 buck）技术，秀秀肌肉招招人，happy ending。
两年的 RN 投入付诸东流，我还是挺唏嘘的，一下也不知道该评论些什么。
如果你个人或者公司正在投入 React Native，不妨也看看 React Native Team 发布的 State of React Native 2018 · React Native ，React Native 正在经历一次巨大的重构，很多文中提及的问题也都是这次重构想要解决的，React Core Team 的 "首席科学家" Sebastian 正在很积极的参与这个项目 ;)
大家有什么想法，欢迎在评论里讨论吧 ;
