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 的豐富。

鏈接：https://juejin.im/post/5b2a5368f265da595c0cf6d5

閱讀更多 前端圈 的文章

關鍵字: Medium 通信 選擇