導讀《React Native at Airbnb》—— 為什麼Airbnb 放棄了React Native?
儘管原文一直在委婉地使用"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.
第一篇是一個開場，介紹了他們是為什麼在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 details
這篇文章著重從技術細節描述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
這篇主要講述他們在組建跨平台的移動團隊時所遇到的一些管理挑戰。
- 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.
面對技術與管理的雙重挑戰，他們認為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 native
最後一篇介紹了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 正在很積極的參與這個項目;)
大家有什麼想法，歡迎在評論裡討論吧;