Airbnb: React Native 從選擇到放棄

Airbnb 最近在 Medium 上發佈了一系列文章詳細描述了 Airbnb 與 React Native 從選擇到放棄的整個心路歷程。

1. React Native at Airbnb
2. The Technology
3. Building a Cross-Platform Mobile Team
4. Making a Decision on React Native
5. What's Next for Mobile

對於字多不看的同窗，能夠簡單看一下我下面的小結。

當初爲何選擇 React Native

有限的開發團隊知足不了日益增加的業務需求

對 React Native 的指望

1. 快速開發
2. 質量有保證
3. 一次編寫，多平臺共享
4. 提高開發體驗

咱們所懷念的

1. 跨平臺，實際上有 95% 以上的共享代碼率。
2. 統一的 DSL。根據平臺也作具體的差別化實現。
3. React 是個好東西。組件化，簡單的生命週期,聲明式
4. 開發迭代速度（熱更新 hot-reloading）
5. 咱們在 RN 生態基礎設施上的投資。
6. 性能，在絕大部分頁面上 RN 都表現得很流暢。（有性能問題？ shouldComponentUpdate, removeClippedSubviews, Redux 瞭解一下。）
7. Redux 是個好東西。也是個好冗長的東西。
8. 與 Native 的橋接，能夠方便的封裝已有的 Native 庫。
9. 靜態分析，從 ESLint 到 prettier
10. RN 的動畫庫不錯。
11. JS/React 的開源生態。
12. Flexbox
13. 與 Web 平臺共享代碼。

讓咱們沮喪的

1. 論成熟度，穩定性，RN 比 不上iOS 和 Android 原生。
2. 因爲 RN 的 Bug，有時咱們必須維護本身的一個 RN 分支。
3. JS缺乏類型系統，Flow 太嚴格，TS 集成到已有項目也還有問題。
4. 重構，重構是不可能重構的，又沒有類型系統，只能掙扎着作靜態分析。
5. JavaScriptCore 不一致性，更糟糕的是，如今都 8102年了，RN （Android）帶的仍是不支持 ES 6 的 JSC
6. RN 開源庫質量良莠不齊。好比在 iOS 上正常的庫在 Android 上可能有意想不到的錯誤（由於爲做者也許只熟悉 iOS 和 RN,並不熟悉 Android）
7. 有時不得不白手起家，由於不少的基礎框架中的庫尚未 的RN 封裝。
8. 崩潰監控庫在 RN 上表現不是特別特定，並且在 RN + Native 錯誤棧的跳轉要不要挑戰一下？
9. Native Bridge 的因爲 JS 的弱類型形成Native 與 JS通訊 中類型的不匹配，容易形成錯誤。（後悔沒早點用 TS 生成通訊代碼。）
10. 啓動時間，RN框架初始化須要幾秒，即便是在高端機器上。
11. 新開頁面的渲染時間，0.4秒左右頁面第一次渲染費時。
12. APP 大小。至少增長 12M。
13. 直到目前都沒法在 Android 上支持 64位。
14. 手勢，iOS 和 Android 的手勢 API 差距很大，不過喜聞react-native-gesture-handler 發佈了 1.0 版本。
15. 長列表，雖然 RN 團隊很努力了，可是因爲 RN 的異步通訊機制，長列表的流暢渲染，目前依然無解。
16. React Native 升級是個坑。
17. RN 中的 Accessibility就是個大坑。
18. 還有一些奇怪的 Bug，暫沒有修復。
19. SavedInstanceState 在 Android 上跨進程的坑。

不是技術問題的問題

1. 要用好 RN 你必須同時熟悉 iOS 和 Android ，固然還有 RN 自己，這就對咱們工程師提出了更多挑戰。
2. 團隊的管理，責任的劃分。
3. RN 文檔及相關資源不如 iOS 和 Android 的豐富。