Airbnb：我們為什麼會選擇放棄 React Native
今年6月，Airbnb 技術團隊宣佈， ofollow,noindex">Airbnb 將放棄使用 React Native ，迴歸到使用基於原生技術的自有框架開發 App。作為一家世界級頂尖公司，在對 React Native 投入大量精力後，突然決定棄它而去，這讓不少想要使用和正在使用 React Native 的人都感到震驚和疑惑。
近日，Airbnb 工程師 Gabriel Peal 在接受 外媒採訪 時，聊到了 Airbnb 的移動開發歷史、React Native 的優缺點，以及 Airbnb 最終為什麼決定從 React Native 遷移。
React Native 對 Airbnb 來說最大優勢是快速開發和平臺不可知論（platform agnosticism）。通過 React Native ，Airbnb 可以利用整個開發團隊來幫助構建和支援他們的移動應用。這意味著無論後來的員工在移動和 Web 開發方面的背景如何，都可以快速培訓上手。它還意味著更精簡的程式碼庫，因為能夠跨三個平臺部署一個儲存庫。但同時，也帶來了挑戰：
從 0 至 1 ，需要一大筆投入
許多人認為在 Airbnb 決定使用 React Native 時有做完整的遷移，其實到目前為止，React Native 程式碼僅佔 Airbnb 程式碼庫和開發資源的 15-20％，它一直就不是 Airbnb 公司的主要平臺。儘管 React Native 是一個框架並且極大地簡化了移動開發流程，但啟動和執行起來並非易事，尤其是在已有現成程式碼庫的情況下。將 React Native 整合到現有的移動程式碼庫中預期會耗費大量時間和精力。
開發者仍需編寫原生程式碼
對於 API 在兩個平臺之間具有明確橋樑的簡單應用，React Native 是一個很好的選擇。在 Airbnb 移動應用的早期階段，React Native 是移動應用中的強大加速器。但最終，API 將無法以你想要的方式執行，你還是不得不深入到原生庫中進行必要的調整。
如果聘請一位 JavaScript 開發者來維護你的 React Native 專案，那麼他們必須編寫原生程式碼來彌補功能上的縫隙。
小心“地雷”
React Native 程式碼中的地雷和互作用極難追蹤和重現。舉個實際例子，Airbnb 團隊有遇到 React Native 元件在某些手機上顯示一片空白的問題，該 bug 不僅不可靠，而且難以追蹤。
解決方案是關閉初始化 Fresco ，這是一個適用於 Android 的 React Native 標準影象渲染庫。直到今天，工程師仍然不明白為什麼這個步驟修復了這個 bug 。
投入永無止境/迭代緩慢
許多團隊使用 React Native 進行小型移動應用的原型設計，並相信它能解決他們的所有問題。但與所有開源軟體一樣，該平臺在不斷變化，每天都會發現新的 bug 和問題。支援 React Native 還處於動盪的生態需要持續的投資。
比如 Airbnb 工程師希望一個符合其產品目標的補丁能夠儘快合併進入 React Native 框架，不幸的是，React Native 的開發生命週期為每四周釋出一次。如果這次沒通過，他們將不得不等待差不多一個月，來重新審查或採用他們的修改。
隨著 Airbnb 的發展加速，他們無法承擔其中的風險。由於劣勢高於優勢，促使 Airbnb 重新考量，並最終放棄 React Native 開發。
此外，雖然除了 React Native 之外還有其他的跨平臺替代方案，比如 Google 的 Flutter 和微軟的 Xamarin ，但和上面提到的類似的問題也都可以在這些框架上面找到，而且這兩個框架在 Google 和 Microsoft 中的使用率都相對較低。雖然跨平臺框架能解決大多數簡單問題，但一些更復雜的問題最終還是需要回到相應移動裝置的原生平臺來處理。
來自： softwareengineeringdaily.com 編譯：開源中國