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

React Native at Airbnb

The Technology

Building a Cross-Platform Mobile Team

Making a Decision on React Native

What's Next for Mobile

對于字多不看的同學，可以簡單看一下我下面的小結。

當初為什么選擇 React Native

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

對 React Native 的期望

快速開發

質量有保證

一次編寫，多平臺共享

提升開發體驗

我們所懷念的

跨平臺，實際上有 95% 以上的共享代碼率。

統一的 DSL。根據平臺也做具體的差異化實現。

React 是個好東西。組件化，簡單的生命周期,聲明式

開發迭代速度（熱更新 hot-reloading）

我們在 RN 生態基礎設施上的投資。

性能，在絕大部分頁面上 RN 都表現得很流暢。（有性能問題？ shouldComponentUpdate, removeClippedSubviews, Redux 了解一下。）

Redux 是個好東西。也是個好冗長的東西。

與 Native 的橋接，可以方便的封裝已有的 Native 庫。

靜態分析，從 ESLint 到 prettier

RN 的動畫庫不錯。

JS/React 的開源生態。

Flexbox

與 Web 平臺共享代碼。

讓我們沮喪的

論成熟度，穩定性，RN 比 不上iOS 和 Android 原生。

由于 RN 的 Bug，有時我們必須維護自己的一個 RN 分支。

JS缺少類型系統，Flow 太嚴格，TS 集成到已有項目也還有問題。

重構，重構是不可能重構的，又沒有類型系統，只能掙扎著做靜態分析。

JavaScriptCore 不一致性，更糟糕的是，現在都 8102年了，RN （Android）帶的還是不支持 ES 6 的 JSC

RN 開源庫質量參差不齊。比如在 iOS 上正常的庫在 Android 上可能有意想不到的錯誤（因為為作者也許只熟悉 iOS 和 RN,并不熟悉 Android）

有時不得不白手起家，因為很多的基礎框架中的庫還沒有 的RN 封裝。

崩潰監控庫在 RN 上表現不是特別特定，而且在 RN + Native 錯誤棧的跳轉要不要挑戰一下？

Native Bridge 的由于 JS 的弱類型造成Native 與 JS通信 中類型的不匹配，容易造成錯誤。（后悔沒早點用 TS 生成通信代碼。）

啟動時間，RN框架初始化需要幾秒，即使是在高端機器上。

新開頁面的渲染時間，0.4秒左右頁面第一次渲染費時。

APP 大小。至少增加 12M。

直到目前都無法在 Android 上支持 64位。

手勢，iOS 和 Android 的手勢 API 差距很大，不過喜聞react-native-gesture-handler 發布了 1.0 版本。

長列表，雖然 RN 團隊很努力了，但是由于 RN 的異步通信機制，長列表的流暢渲染，目前依然無解。

React Native 升級是個坑。

RN 中的 Accessibility就是個大坑。

還有一些奇怪的 Bug，暫沒有修復。

SavedInstanceState 在 Android 上跨進程的坑。

不是技術問題的問題

要用好 RN 你必須同時熟悉 iOS 和 Android ，當然還有 RN 本身，這就對我們工程師提出了更多挑戰。

團隊的管理，責任的劃分。

RN 文檔及相關資源不如 iOS 和 Android 的豐富。

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的Airbnb: React Native 从选择到放弃的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。