Airbnb:ReactNative從選擇到放棄

青衫無名發表於2018-07-17

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. 靜態分析,從 ESLintprettier
  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 的豐富。

作者:banxi

原文釋出時間:2018年06月20日
本文來源掘金如需轉載請緊急聯絡作者


相關文章