摘要：聲明有助于保持我們的同步與底層狀態(tài)的聲明性質(zhì)。值得注意的是，這些挑戰(zhàn)并非特定于。這導(dǎo)致或上出現(xiàn)不一致或意外錯(cuò)誤。崩潰監(jiān)控我們使用在和上進(jìn)行崩潰報(bào)告。橋接有一個(gè)橋接，用于在本機(jī)和之間進(jìn)行通信。

在Android，iOS，Web和跨平臺框架的橫向?qū)Ρ戎校琑eact Native本身是一個(gè)相對較新且快速開發(fā)移動(dòng)的平臺。兩年后，我們可以肯定地說React Native在很多方面都是革命性的。這是移動(dòng)設(shè)備的范例轉(zhuǎn)變，我們能夠從中受益很多。然而也有明顯的痛點(diǎn)，它的優(yōu)點(diǎn)不僅僅是這些

跨平臺
React Native
的主要好處是，您編寫的代碼可以在Android和iOS上本機(jī)運(yùn)行。使用React Native的大多數(shù)功能都能夠?qū)崿F(xiàn)95-100％的共享代碼，0.2％的文件是特定于平臺的（android.js / ios.js）。

統(tǒng)一設(shè)計(jì)語言系統(tǒng)（DLS）
我們開發(fā)了一種名為DLS的跨平臺設(shè)計(jì)語言。我們有Android，iOS，React Native和每個(gè)組件的Web版本。擁有統(tǒng)一的設(shè)計(jì)語言可以編寫跨平臺功能，因?yàn)樗馕吨O(shè)計(jì)，組件名稱和屏幕在不同平臺上是一致的。但是，我們?nèi)匀豢梢栽谶m用的情況下做出適合平臺的決策。例如，我們使用Android 上的原生工具欄和iOS 上的UINavigationBar，我們選擇隱藏Android上的披露指標(biāo)，因?yàn)樗鼈儾环螦ndroid平臺設(shè)計(jì)指南。

我們選擇重寫組件而不是包裝本機(jī)組件，因?yàn)闉槊總€(gè)平臺多帶帶制作適合平臺的API更加可靠，并減少了可能不知道如何正確測試React Native中的更改的Android和iOS工程師的維護(hù)開銷。但是，它確實(shí)會(huì)導(dǎo)致同一組件的本機(jī)版本和React Native版本不同步的平臺之間出現(xiàn)碎片。

react
React是最受歡迎的 Web框架。它簡單而強(qiáng)大，可以很好地?cái)U(kuò)展到大型代碼庫。我們特別喜歡它的特點(diǎn)：

組件： React組件通過明確定義的道具和狀態(tài)強(qiáng)制分離關(guān)注點(diǎn)。這是React可擴(kuò)展性的主要貢獻(xiàn)者。

簡化的生命周期： Android以及在較小程度上，iOS生命周期非常復(fù)雜。功能性反應(yīng)性React組件從根本上解決了這個(gè)問題，使學(xué)習(xí)React Native比學(xué)習(xí)Android或iOS簡單得多。

聲明：react有助于保持我們的UI同步與底層狀態(tài)的聲明性質(zhì)。

迭代速度
在React Native中進(jìn)行開發(fā)時(shí)，我們能夠在一兩秒內(nèi)可靠地使用熱重新加載來測試Android和iOS上的更改。盡管構(gòu)建性能是我們原生應(yīng)用程序的首要任務(wù)，但它從未接近我們使用React Native實(shí)現(xiàn)的迭代速度。充其量，本機(jī)編譯時(shí)間為15秒，但完整版本可能高達(dá)20分鐘。

基礎(chǔ)環(huán)境的搭建成本
我們開發(fā)與本機(jī)基礎(chǔ)架構(gòu)是廣泛集成。所有核心部分（如網(wǎng)絡(luò)，國際化，測試，共享組件轉(zhuǎn)換，設(shè)備信息，帳戶信息等）都包含在一個(gè)React Native API中。這些橋接是一些比較復(fù)雜的橋接，因?yàn)槲覀兿Ｍ麑F(xiàn)有的Android和iOS API包裝成React的一致和規(guī)范。雖然通過快速迭代和新基礎(chǔ)設(shè)施的開發(fā)使這些橋接保持最新狀態(tài)是一個(gè)不斷追趕的游戲，但基礎(chǔ)設(shè)施團(tuán)隊(duì)的投資使產(chǎn)品開發(fā)工作變得更加容易。

如果不對基礎(chǔ)環(huán)境進(jìn)行大量投入，ReactNative將導(dǎo)致降低開發(fā)人員和用戶體驗(yàn)。因此，我們不相信React Native可以簡單地添加到現(xiàn)有應(yīng)用程序而無需大量持續(xù)投入。

性能
React Native最大的擔(dān)憂之一就是它的性能。但是，在實(shí)踐中，出現(xiàn)的次數(shù)相對來說還是比較少的。我們的大多數(shù)React Native屏幕都像我們的原生屏幕一樣流暢。性能通常被認(rèn)為是單一維度。我們經(jīng)常看到移動(dòng)工程師看JS并認(rèn)為“比Java慢”。但是，在許多情況下，從主線程移動(dòng)業(yè)務(wù)邏輯和布局實(shí)際上改善了渲染性能。

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

但是，初始化和首次渲染時(shí)間（如下所述）使得React Native在啟動(dòng)屏幕，深層鏈接方面表現(xiàn)不佳，并且在屏幕之間導(dǎo)航時(shí)增加了TTI時(shí)間。此外，丟幀的屏幕很難調(diào)試，因?yàn)閅oga在React Native組件和本機(jī)視圖之間進(jìn)行轉(zhuǎn)換。

Redux
我們使用Redux進(jìn)行狀態(tài)管理，我們發(fā)現(xiàn)它有效并阻止UI與狀態(tài)不同步，并在屏幕上輕松實(shí)現(xiàn)數(shù)據(jù)共享。然而，學(xué)習(xí)曲線相對困難。我們?yōu)橐恍┏Ｒ娔０逄峁┝松善鳎谑褂肦eact Native時(shí)，它仍然是最具挑戰(zhàn)性的部分之一和混淆源。值得注意的是，這些挑戰(zhàn)并非特定于React Native。

由Native支持
因?yàn)镽eact Native中的所有內(nèi)容都可以通過本機(jī)代碼進(jìn)行橋接，所以我們最終能夠構(gòu)建許多我們在開始時(shí)不確定的內(nèi)容，例如：

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

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

本機(jī)網(wǎng)絡(luò)堆棧： React Native在兩個(gè)平臺上使用我們現(xiàn)有的本機(jī)網(wǎng)絡(luò)堆棧和緩存。

其他核心基礎(chǔ)知識：就像網(wǎng)絡(luò)一樣，我們包裝了其余的現(xiàn)有本地基礎(chǔ)設(shè)施，如i18n，實(shí)驗(yàn)等，以便它在React Native中無縫運(yùn)行。

動(dòng)畫
感謝React Native Animated庫，我們能夠?qū)崿F(xiàn)無抖動(dòng)的動(dòng)畫甚至是交互驅(qū)動(dòng)的動(dòng)畫，例如滾動(dòng)視差。

JS / React開源
因?yàn)镽eact Native真正運(yùn)行React和javascript，所以我們能夠利用極大的javascript項(xiàng)目，如redux，reselect，jest等。

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

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

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

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

JavaScript工具
JavaScript是一種無類型語言。缺乏類型安全性難以擴(kuò)展，也成為移動(dòng)工程師爭論的焦點(diǎn)，因?yàn)樗麄兞?xí)慣于輸入可能對學(xué)習(xí)React Native感興趣的語言。我們探索了采用流程，但隱秘的錯(cuò)誤消息導(dǎo)致令人沮喪的開發(fā)人員體驗(yàn)。我們還研究了TypeScript，但是將它集成到我們現(xiàn)有的基礎(chǔ)設(shè)施中，例如babel和metro bundler，這被證明是有問題的。但是，我們正在繼續(xù)積極研究網(wǎng)絡(luò)上的TypeScript。

重構(gòu)
JavaScript無法解決的副作用是重構(gòu)非常困難并且容易出錯(cuò)。重命名道具，尤其是具有通用名稱的道具，如onClick或通過多個(gè)組件傳遞的道具，這些都是精確重構(gòu)的噩夢。更糟糕的是，重構(gòu)在生產(chǎn)中而不是在編譯時(shí)中斷，并且很難添加適當(dāng)?shù)撵o態(tài)分析。

JavaScriptCore不一致
React Native的一個(gè)微妙而棘手的方面是由于它是在JavaScriptCore環(huán)境中執(zhí)行的。以下是我們遇到的后果：

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

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

在調(diào)試時(shí)，React Native會(huì)附加到Chrome Developer Tools實(shí)例。這很棒，因?yàn)樗且粋€(gè)功能強(qiáng)大的調(diào)試器。但是，一旦附加調(diào)試器，所有JavaScript都在Chrome的V8引擎中運(yùn)行。99.9％的時(shí)間都很好。但是，在一個(gè)實(shí)例中，我們得到了什么時(shí)候toLocaleString在iOS上工作，但只在調(diào)試時(shí)才適用于Android。事實(shí)證明，Android JSC 不包含它，它默默地失敗，除非你在調(diào)試，在這種情況下，它使用的是V8。在不知道這樣的技術(shù)細(xì)節(jié)的情況下，它可能會(huì)導(dǎo)致產(chǎn)品工程師經(jīng)歷數(shù)天的痛苦調(diào)試。

React Native開源庫
學(xué)習(xí)平臺既困難又耗時(shí)。大多數(shù)人只知道一兩個(gè)平臺。具有本地橋（例如地圖，視頻等）的React Native庫需要所有三個(gè)平臺的相同知識才能成功。我們發(fā)現(xiàn)大多數(shù)React Native Open源項(xiàng)目都是由只有一兩個(gè)經(jīng)驗(yàn)的人編寫的。這導(dǎo)致Android或iOS上出現(xiàn)不一致或意外錯(cuò)誤。

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

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

APP崩潰監(jiān)控
我們使用Bugsnag在Android和iOS上進(jìn)行崩潰報(bào)告。雖然我們能夠讓Bugsnag在兩個(gè)平臺上都能正常工作，但它的可靠性較低，需要的工作量比其他平臺要多。因?yàn)镽eact Native在業(yè)界相對較新且很少見，所以我們必須構(gòu)建大量的基礎(chǔ)設(shè)施，例如在內(nèi)部上傳源映射，并且必須與Bugsnag一起工作，以便能夠執(zhí)行過濾崩潰等事情。反應(yīng)原生。

由于React Native周圍的自定義基礎(chǔ)架構(gòu)數(shù)量很多，我們偶爾會(huì)遇到嚴(yán)重的問題，即未報(bào)告崩潰或源地圖未正確上傳。

最后，如果問題跨越React Native和本機(jī)代碼，調(diào)試React Native崩潰通常更具挑戰(zhàn)性，因?yàn)槎褩８櫜粫?huì)在React Native和native之間跳轉(zhuǎn)。

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

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

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

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

64位
由于此問題，我們?nèi)匀粺o法在Android上發(fā)送64位APK 。

手勢
我們避免將React Native用于涉及復(fù)雜手勢的屏幕，因?yàn)锳ndroid和iOS的觸摸子系統(tǒng)不同，因此提出統(tǒng)一的API對整個(gè)React Native社區(qū)來說都是一個(gè)挑戰(zhàn)。但是，工作正在繼續(xù)進(jìn)行，而react-native-gesture-handler只是達(dá)到1.0。

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

React Native的升級
雖然大多數(shù)React Native升級都是微不足道的，但也有一些令人痛苦。特別是，幾乎不可能使用React Native 0.43（2017年4月）到0。49（2017年10月），因?yàn)樗褂昧薘eact 16 alpha和beta。這是一個(gè)非常大的問題，因?yàn)榇蠖鄶?shù)專為Web使用而設(shè)計(jì)的React庫不支持預(yù)發(fā)布的React版本。在此次升級中糾纏正確的依賴關(guān)系的過程對2017年中期其他React Native基礎(chǔ)架構(gòu)的工作造成了重大損害。

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

Android上的進(jìn)程中保存的實(shí)例狀態(tài)
Android經(jīng)常清理后臺進(jìn)程，但讓他們有機(jī)會(huì)同步保存自己的狀態(tài)。但是，在React Native上，只能在js線程中訪問所有狀態(tài)，因此無法同步完成。即使不是這種情況，redux作為狀態(tài)存儲(chǔ)也不兼容這種方法，因?yàn)樗尚蛄谢头强尚蛄谢瘮?shù)據(jù)的混合，并且可能包含的數(shù)據(jù)超過了savedInstanceState包中可能導(dǎo)致崩潰的數(shù)據(jù)。生產(chǎn)。