摘要：聲明有助于保持我們的同步與底層狀態的聲明性質。值得注意的是，這些挑戰并非特定于。這導致或上出現不一致或意外錯誤。崩潰監控我們使用在和上進行崩潰報告。橋接有一個橋接，用于在本機和之間進行通信。

在Android，iOS，Web和跨平臺框架的橫向對比中，React Native本身是一個相對較新且快速開發移動的平臺。兩年后，我們可以肯定地說React Native在很多方面都是革命性的。這是移動設備的范例轉變，我們能夠從中受益很多。然而也有明顯的痛點，它的優點不僅僅是這些

跨平臺
React Native
的主要好處是，您編寫的代碼可以在Android和iOS上本機運行。使用React Native的大多數功能都能夠實現95-100％的共享代碼，0.2％的文件是特定于平臺的（android.js / ios.js）。

統一設計語言系統（DLS）
我們開發了一種名為DLS的跨平臺設計語言。我們有Android，iOS，React Native和每個組件的Web版本。擁有統一的設計語言可以編寫跨平臺功能，因為它意味著設計，組件名稱和屏幕在不同平臺上是一致的。但是，我們仍然可以在適用的情況下做出適合平臺的決策。例如，我們使用Android 上的原生工具欄和iOS 上的UINavigationBar，我們選擇隱藏Android上的披露指標，因為它們不符合Android平臺設計指南。

我們選擇重寫組件而不是包裝本機組件，因為為每個平臺多帶帶制作適合平臺的API更加可靠，并減少了可能不知道如何正確測試React Native中的更改的Android和iOS工程師的維護開銷。但是，它確實會導致同一組件的本機版本和React Native版本不同步的平臺之間出現碎片。

react
React是最受歡迎的 Web框架。它簡單而強大，可以很好地擴展到大型代碼庫。我們特別喜歡它的特點：

組件： React組件通過明確定義的道具和狀態強制分離關注點。這是React可擴展性的主要貢獻者。

簡化的生命周期： Android以及在較小程度上，iOS生命周期非常復雜。功能性反應性React組件從根本上解決了這個問題，使學習React Native比學習Android或iOS簡單得多。

聲明：react有助于保持我們的UI同步與底層狀態的聲明性質。

迭代速度
在React Native中進行開發時，我們能夠在一兩秒內可靠地使用熱重新加載來測試Android和iOS上的更改。盡管構建性能是我們原生應用程序的首要任務，但它從未接近我們使用React Native實現的迭代速度。充其量，本機編譯時間為15秒，但完整版本可能高達20分鐘。

基礎環境的搭建成本
我們開發與本機基礎架構是廣泛集成。所有核心部分（如網絡，國際化，測試，共享組件轉換，設備信息，帳戶信息等）都包含在一個React Native API中。這些橋接是一些比較復雜的橋接，因為我們希望將現有的Android和iOS API包裝成React的一致和規范。雖然通過快速迭代和新基礎設施的開發使這些橋接保持最新狀態是一個不斷追趕的游戲，但基礎設施團隊的投資使產品開發工作變得更加容易。

如果不對基礎環境進行大量投入，ReactNative將導致降低開發人員和用戶體驗。因此，我們不相信React Native可以簡單地添加到現有應用程序而無需大量持續投入。

性能
React Native最大的擔憂之一就是它的性能。但是，在實踐中，出現的次數相對來說還是比較少的。我們的大多數React Native屏幕都像我們的原生屏幕一樣流暢。性能通常被認為是單一維度。我們經?？吹揭苿庸こ處熆碕S并認為“比Java慢”。但是，在許多情況下，從主線程移動業務邏輯和布局實際上改善了渲染性能。

當我們確實看到性能問題，他們通常由過多的渲染引起的有效利用是緩解shouldComponentUpdate，removeClippedSubviews，并更好地利用終極版。

但是，初始化和首次渲染時間（如下所述）使得React Native在啟動屏幕，深層鏈接方面表現不佳，并且在屏幕之間導航時增加了TTI時間。此外，丟幀的屏幕很難調試，因為Yoga在React Native組件和本機視圖之間進行轉換。

Redux
我們使用Redux進行狀態管理，我們發現它有效并阻止UI與狀態不同步，并在屏幕上輕松實現數據共享。然而，學習曲線相對困難。我們為一些常見模板提供了生成器，但在使用React Native時，它仍然是最具挑戰性的部分之一和混淆源。值得注意的是，這些挑戰并非特定于React Native。

由Native支持
因為React Native中的所有內容都可以通過本機代碼進行橋接，所以我們最終能夠構建許多我們在開始時不確定的內容，例如：

共享元素轉換：我們構建了一個組件，該組件由Android和iOS上的本機共享元素代碼支持。這甚至可以在Native和React Native屏幕之間使用。

Lottie：通過在Android和iOS上包裝現有庫，我們能夠讓Lottie在React Native中工作。

本機網絡堆棧： React Native在兩個平臺上使用我們現有的本機網絡堆棧和緩存。

其他核心基礎知識：就像網絡一樣，我們包裝了其余的現有本地基礎設施，如i18n，實驗等，以便它在React Native中無縫運行。

動畫
感謝React Native Animated庫，我們能夠實現無抖動的動畫甚至是交互驅動的動畫，例如滾動視差。

JS / React開源
因為React Native真正運行React和javascript，所以我們能夠利用極大的javascript項目，如redux，reselect，jest等。

Flexbox的
React Native使用Yoga處理布局，這是一個跨平臺的C庫，可通過flexbox API 處理布局計算。在早期，我們受到瑜伽限制的影響，例如缺乏寬高比，但它們已在后續更新中添加。此外，有趣的教程，如flexbox froggy使入門更加好玩。

與Web協作
在React Native探索的后期，我們立即開始為web，iOS和Android構建。鑒于Web也使用Redux，我們發現大量代碼可以在Web和本機平臺之間共享而無需更改。

React Native
React Native不如Android或iOS成熟。它更新，更雄心勃勃，移動速度極快。雖然React Native在大多數情況下都能很好地運行，但有些情況下，它的不成熟表現出來并且在本地調試某一些bug很難解決。不幸的是，這些實例很難預測，可能需要幾個小時到幾天才能解決。

維護React Native的分支
由于React Native的不成熟，我們有時需要修補React Native源。除了回饋React Native之外，我們還必須維護一個fork，我們可以快速合并更改并突破我們的版本。在這兩年中，我們不得不在React Native之上添加大約50個提交。這使得升級React Native的過程非常痛苦。

JavaScript工具
JavaScript是一種無類型語言。缺乏類型安全性難以擴展，也成為移動工程師爭論的焦點，因為他們習慣于輸入可能對學習React Native感興趣的語言。我們探索了采用流程，但隱秘的錯誤消息導致令人沮喪的開發人員體驗。我們還研究了TypeScript，但是將它集成到我們現有的基礎設施中，例如babel和metro bundler，這被證明是有問題的。但是，我們正在繼續積極研究網絡上的TypeScript。

重構
JavaScript無法解決的副作用是重構非常困難并且容易出錯。重命名道具，尤其是具有通用名稱的道具，如onClick或通過多個組件傳遞的道具，這些都是精確重構的噩夢。更糟糕的是，重構在生產中而不是在編譯時中斷，并且很難添加適當的靜態分析。

JavaScriptCore不一致
React Native的一個微妙而棘手的方面是由于它是在JavaScriptCore環境中執行的。以下是我們遇到的后果：

iOS提供了自己的JavaScriptCore開箱即用。這意味著iOS大部分都是一致的，對我們來說沒有問題。

Android不提供自己的JavaScriptCore，因此React Native捆綁了它自己的。但是，默認情況下你得到的之前的。結果，我們不得不竭盡全力捆綁一個最新的

在調試時，React Native會附加到Chrome Developer Tools實例。這很棒，因為它是一個功能強大的調試器。但是，一旦附加調試器，所有JavaScript都在Chrome的V8引擎中運行。99.9％的時間都很好。但是，在一個實例中，我們得到了什么時候toLocaleString在iOS上工作，但只在調試時才適用于Android。事實證明，Android JSC 不包含它，它默默地失敗，除非你在調試，在這種情況下，它使用的是V8。在不知道這樣的技術細節的情況下，它可能會導致產品工程師經歷數天的痛苦調試。

React Native開源庫
學習平臺既困難又耗時。大多數人只知道一兩個平臺。具有本地橋（例如地圖，視頻等）的React Native庫需要所有三個平臺的相同知識才能成功。我們發現大多數React Native Open源項目都是由只有一兩個經驗的人編寫的。這導致Android或iOS上出現不一致或意外錯誤。

在Android上，許多React Native庫還要求您使用node_modules的相對路徑，而不是發布與社區所期望的不一致的maven工件。

并行基礎設施和功能工作
我們在Android和iOS上積累了多年的原生基礎設施。但是，在React Native中，我們從一個空白的平板開始，不得不編寫或創建所有現有基礎架構的橋梁。這意味著有時候產品工程師需要一些尚不存在的功能。在那時，他們要么必須在他們不熟悉的平臺上工作，要么在他們的項目范圍之外進行構建，要么被阻止直到可以創建它。

APP崩潰監控
我們使用Bugsnag在Android和iOS上進行崩潰報告。雖然我們能夠讓Bugsnag在兩個平臺上都能正常工作，但它的可靠性較低，需要的工作量比其他平臺要多。因為React Native在業界相對較新且很少見，所以我們必須構建大量的基礎設施，例如在內部上傳源映射，并且必須與Bugsnag一起工作，以便能夠執行過濾崩潰等事情。反應原生。

由于React Native周圍的自定義基礎架構數量很多，我們偶爾會遇到嚴重的問題，即未報告崩潰或源地圖未正確上傳。

最后，如果問題跨越React Native和本機代碼，調試React Native崩潰通常更具挑戰性，因為堆棧跟蹤不會在React Native和native之間跳轉。

橋接
React Native有一個橋接API，用于在本機和React Native之間進行通信。雖然它按預期工作，但編寫起來非常麻煩。首先，它需要正確設置所有三個開發環境。我們還遇到了很多問題，其中來自JavaScript的類型是出乎意料的。例如，整數通常用字符串包裹，這個問題直到通過橋接才會實現。更糟糕的是，有時iOS會在Android崩潰時無聲地失敗。我們開始研究從2017年底開始自動生成TypeScript定義的橋接代碼，但實在太晚了。

初始化時間
在React Native第一次呈現之前，必須初始化其運行時。不幸的是，即使在高端設備上，這對于我們的應用程序來說也需要幾秒鐘。這使得使用React Native用于啟動屏幕幾乎是不可能的。我們通過在app-launch處初始化它來最小化React Native的首次渲染時間。

初始渲染時間
與原生屏幕不同，渲染React Native需要至少一個完整的主線程 - > js - >瑜伽布局線程 - >主線程往返才有足夠的信息來首次渲染屏幕。我們在iOS上看到平均初始p90渲染時間為280毫秒，而在Android上則為440毫秒。在Android上，我們使用了postponeEnterTransition API，它通常用于共享元素轉換，以延遲顯示屏幕，直到它呈現為止。在iOS上，我們遇到了從React Native快速設置導航欄配置的問題。因此，我們在所有React Native屏幕轉換中添加了50ms的人為延遲，以防止導航欄在加載配置后閃爍。

應用大小
React Native對應用程序大小的影響也不容忽視。在Android上，React Native（Java + JS +本地庫，如Yoga + Javascript Runtime）的總大小為每個ABI 8mb。在一個APK中使用x86和arm（僅32位），它將更接近12mb。

64位
由于此問題，我們仍然無法在Android上發送64位APK 。

手勢
我們避免將React Native用于涉及復雜手勢的屏幕，因為Android和iOS的觸摸子系統不同，因此提出統一的API對整個React Native社區來說都是一個挑戰。但是，工作正在繼續進行，而react-native-gesture-handler只是達到1.0。

很長的list
React Native在這個領域取得了一些進展，包括像FlatList這樣的庫。然而，它們遠不及Android 上的RecyclerView或iOS 上的UICollectionView的成熟度和靈活性。由于線程化，許多限制很難克服。無法同步訪問適配器數據，因此可以在快速滾動時異步呈現視圖時查看視圖。文本也無法同步測量，因此iOS無法使用預先計算的單元格高度進行某些優化。

React Native的升級
雖然大多數React Native升級都是微不足道的，但也有一些令人痛苦。特別是，幾乎不可能使用React Native 0.43（2017年4月）到0。49（2017年10月），因為它使用了React 16 alpha和beta。這是一個非常大的問題，因為大多數專為Web使用而設計的React庫不支持預發布的React版本。在此次升級中糾纏正確的依賴關系的過程對2017年中期其他React Native基礎架構的工作造成了重大損害。

麻煩的崩潰
我們不得不處理一些難以解決的非常奇怪的崩潰事件。例如，我們目前正在經歷@ReactProp注釋的崩潰，并且無法在任何設備上重現它，即使那些具有相同硬件和軟件的設備也會在野外崩潰。

Android上的進程中保存的實例狀態
Android經常清理后臺進程，但讓他們有機會同步保存自己的狀態。但是，在React Native上，只能在js線程中訪問所有狀態，因此無法同步完成。即使不是這種情況，redux作為狀態存儲也不兼容這種方法，因為它包含可序列化和非可序列化數據的混合，并且可能包含的數據超過了savedInstanceState包中可能導致崩潰的數據。生產。