版權(quán)所有，轉(zhuǎn)載請(qǐng)注明出處。
最近在前端圈大名鼎鼎的 Airbnb（愛彼迎）團(tuán)隊(duì)宣布放棄 React Native。他們?cè)谧约旱牟┛偷闹袑懥?a target="_blank" rel="nofollow">一系列文章詳細(xì)介紹了使用 React Native 的開發(fā)經(jīng)歷，解釋了放棄使用 RN 的原因。本文就是對(duì)這些博文的整理和翻譯。
由于篇幅較長，我拆分成了上下兩部分，以下是上篇：
序
在 Airbnb 正式推出的十年前，智能手機(jī)還處于發(fā)展的初級(jí)階段。從那時(shí)起，它逐漸成為我們?nèi)粘Ｉ钪械闹匾ぞ摺Ｗ鳛橐患覟閿?shù)百萬人提供旅行服務(wù)的社區(qū)，開發(fā)強(qiáng)大穩(wěn)定的移動(dòng)端應(yīng)用程序?qū)ξ覀儊碚f非常重要，因?yàn)榭蛻粼谕獯蠖嘀煌ㄟ^手機(jī)來使用我們的服務(wù)。
從2008年開始，我們的移動(dòng)端用戶數(shù)量快速增長到了數(shù)百萬級(jí)別。我們的應(yīng)用讓客戶可以方便地在旅途中管理他們的住宿和行程，只需動(dòng)動(dòng)手指，就可以獲得完美的旅行體驗(yàn)！
Airbnb 擁有一百人規(guī)模的移動(dòng)開發(fā)團(tuán)隊(duì)，這使我們能跟上最新的技術(shù)潮流，不斷尋找和評(píng)估新的技術(shù)方向，來實(shí)現(xiàn)代碼的快速迭代，提升開發(fā)體驗(yàn)，打造更好的產(chǎn)品。
選擇 React Native
2016年，我們意識(shí)到移動(dòng)端對(duì)我們業(yè)務(wù)的重要性，但是當(dāng)時(shí)沒有足夠的人手來開發(fā) App，所以我們開始探索替代方案，因?yàn)槲覀兊木W(wǎng)站是由 React 來構(gòu)建的，它一直是 Airbnb 內(nèi)部非常受歡迎的 Web 開發(fā)框架。因此，我們選擇了 React Native，來幫助前端工程師快速地上手移動(dòng)端的編碼，
當(dāng)開始投入到 RN 的開發(fā)中時(shí)，我們清楚地知道其中的風(fēng)險(xiǎn)：它是一個(gè)未經(jīng)驗(yàn)證，尚未穩(wěn)定的平臺(tái)，它會(huì)割裂我們的代碼，帶來很多副作用。
但我們還是滿懷信心，期望能做到最好，當(dāng)時(shí)我們的目標(biāo)是：
- 實(shí)現(xiàn)代碼的快速迭代。
- 方便進(jìn)行不同平臺(tái)的質(zhì)量管理。
- 跨平臺(tái)開發(fā)，只需寫一次代碼，而不是為不同的平臺(tái)單獨(dú)開發(fā)程序。
- 提升開發(fā)體驗(yàn)。
兩年多來，我們慢慢積累了大量的開發(fā)經(jīng)驗(yàn)，打造了強(qiáng)大的 React Native 生態(tài)，實(shí)現(xiàn)很多復(fù)雜的功能，比如：共享元素變換、視差效果、定位，還有對(duì)接類似網(wǎng)絡(luò)、測(cè)試、本地化等現(xiàn)有原生基礎(chǔ)框架的橋接組件。
我們使用 React Native 開發(fā)了許多重要的產(chǎn)品，比如 Experiences，這是 Airbnb 推出的全新 App，包含了評(píng)論、禮品卡等等十幾項(xiàng)功能。而這些都是在我們沒有足夠的移動(dòng)開發(fā)人手時(shí)構(gòu)建的。
兩年后的今天，我們認(rèn)為 React Native 確實(shí)是一項(xiàng)革命性的技術(shù)，它徹底改變了移動(dòng)開發(fā)，我們從中獲益良多，但是這并不意味著它沒有缺點(diǎn)。
React Native 的優(yōu)點(diǎn)
跨平臺(tái)
React Native 的最重要的優(yōu)點(diǎn)是它的跨平臺(tái)性，你編寫的代碼可以同時(shí)在 iOS 和 Android 上運(yùn)行。大多數(shù)模塊可以實(shí)現(xiàn)95%-100%的代碼共享，只有0.2%的代碼需要針對(duì)平臺(tái)單獨(dú)實(shí)現(xiàn)（*.android.js *.ios.js）。
統(tǒng)一的設(shè)計(jì)語言（DLS）
我們開發(fā)了一套名為DLS的跨平臺(tái)設(shè)計(jì)語言。每一個(gè)組件都可能有 Android、iOS、React Native 和 web 版本的實(shí)現(xiàn)。擁有統(tǒng)一的設(shè)計(jì)語言意味著我們可以編寫跨平臺(tái)的功能，因?yàn)樵O(shè)計(jì)、組件名稱、屏幕適配在各個(gè)平臺(tái)上都是統(tǒng)一的。當(dāng)然我們?nèi)匀粫?huì)根據(jù)不同平臺(tái)的特性進(jìn)行一些微調(diào)，比如在實(shí)現(xiàn)導(dǎo)航欄時(shí)，我們?cè)?iOS 端使用 Navigation Bar，而在 Android 端使用 Toolbar 這類的原生組件，而且 Android 端的返回按鈕會(huì)被隱藏，因?yàn)檫@不符合 Android 的設(shè)計(jì)規(guī)范。
相對(duì)于包裝原生組件，我們更傾向于（使用JS）重寫組件，因?yàn)闉槊總€(gè)平臺(tái)分別編寫平臺(tái)適應(yīng)的 api 會(huì)更加可靠，也方便 Android 和 iOS 工程師去測(cè)試。但是這樣的做法也會(huì)導(dǎo)致碎片化的問題。
React
React是最受歡迎的 Web 開發(fā)框架是有原因的，它簡單但是功能強(qiáng)大，適合編寫大型項(xiàng)目。有幾個(gè)特性是我們非常喜歡的：
組件化（Components）：React 通過良好的設(shè)計(jì)，使用 props 和 state 管理組件的狀態(tài)，使得我們將功能拆分為獨(dú)立的組件。組件化是 React 靈活可擴(kuò)展性最重要的原因。
簡化的生命周期（Lifecycles）：Android 和 iOS 組件的生命周期是非常復(fù)雜的（特別是 Android），而 React 在這方面做的非常好，使得它易于學(xué)習(xí)上手。
聲明式渲染（Declarative）：聲明式編程告訴機(jī)器你想要什么（what），讓機(jī)器想出如何去做（how）。React 這個(gè)特性幫助我們實(shí)現(xiàn) UI 的實(shí)時(shí)更新（通過 setState）。
開發(fā)效率
開發(fā) React Native 應(yīng)用時(shí)，我們可以通過 Hot Reloading 來實(shí)時(shí)部署對(duì)代碼的改動(dòng)。盡管我們特別去優(yōu)化了 iOS 和 Android 應(yīng)用程序的編譯速度（達(dá)到測(cè)試編譯15s左右，完整編譯最長20分鐘），和它們相比，React Native 仍然快如閃電。
基礎(chǔ)框架搭建
我們搭建了大量的基礎(chǔ)框架，定義統(tǒng)一的接口來實(shí)現(xiàn)和原生端的橋接。所有的核心組件，比如：登錄信息、網(wǎng)絡(luò)層、測(cè)試、分享、設(shè)備信息等等，都被包含在了一個(gè)統(tǒng)一的 React Native API 中。我們想要為 React 端提供標(biāo)準(zhǔn)和權(quán)威的通信接口，并且通過快速迭代，來更新這些接口，增加新的內(nèi)容。這些工作使得前端的開發(fā)更加輕松。
如果沒有前期大量的投入，我們的開發(fā)體驗(yàn)和效率會(huì)變得非常低。所以，如果你想要在現(xiàn)有原生端嵌入 React Native，這些工作是非常有必要的。
性能
React Native 的問題之一是它的性能。但是在實(shí)踐中，我們發(fā)現(xiàn)完全在可以接受的范圍內(nèi)。大多數(shù)使用 React Native 開發(fā)的頁面就和原生頁面一樣流暢。性能包含很多個(gè)維度，通過做業(yè)務(wù)邏輯的調(diào)整，或者將 layout 相關(guān)計(jì)算移出主線程，可以解決大部分的性能問題。
當(dāng)然如果確實(shí)遇到了性能瓶頸（通常是由于大量組件的重復(fù)渲染造成的），我們可以通過 shouldComponentUpdate,removeClippedSubviews等方法來進(jìn)行優(yōu)化，當(dāng)然最好是使用 Redux 來管理狀態(tài)。
另外一個(gè)性能的缺點(diǎn)是 React Native 的首次加載時(shí)間太長了，這使得使用 React Native 開發(fā)諸如啟動(dòng)頁、全局跳轉(zhuǎn)、導(dǎo)航等功能時(shí)響應(yīng)緩慢。這個(gè)問題目前也沒有很好的解決方案，因?yàn)?Yoga 將 js 『翻譯』成原生組件需要大量的計(jì)算。
Redux
我們使用 Redux 來管理狀態(tài)，它非常高效，可以防止 UI 和狀態(tài)不同步，并且輕松實(shí)現(xiàn)垮屏幕的數(shù)據(jù)共享。
Redux 的缺點(diǎn)是過于死板不靈活，并且學(xué)習(xí)曲線陡峭。我們?yōu)橐恍┏Ｒ娔０寰帉懥松善鳎╣enerators），但是 Redux 仍然是 React Native 編碼中最為令人困惑的部分。當(dāng)然，Redux 框架也不是 React Native 特有的。
原生模塊支持
React Native 中所有的接口模塊都可以通過原生代碼來橋接，得益于此，我們最終實(shí)現(xiàn)了許多一開始并不確定能否實(shí)現(xiàn)的功能：
共享元素變換（Shared Element Transition）：通過橋接 Android 和 iOS 我們創(chuàng)建了一個(gè) <SharedElement> 組件來實(shí)現(xiàn)共享元素變換效果。它甚至可以在原生和 RN 頁面之間渲染過場(chǎng)動(dòng)畫！
Lottie：橋接在原生端的現(xiàn)有庫，我們成功地讓 Lottie 在 React Native 中運(yùn)行。（注：Lottie 是 Airbnb 開發(fā)的炫酷動(dòng)畫框架）
原生網(wǎng)絡(luò)堆棧：我們?cè)?React Native 端使用各自平臺(tái)原生的網(wǎng)絡(luò)層框架和緩存。
其它核心內(nèi)容：和網(wǎng)絡(luò)層類似，我們將其它現(xiàn)有的原生端基礎(chǔ)架構(gòu)（測(cè)試、i18n等）封裝起來，以便能在 js 端無縫地調(diào)用。
靜態(tài)分析
前端做靜態(tài)分析的經(jīng)典工具是 eslint，不過我們?cè)?Airbnb 的 React Native 端使用 prettier 工具。它的效率非常高，是我們的前端基礎(chǔ)架構(gòu)團(tuán)隊(duì)重點(diǎn)關(guān)注的工具之一。
我們也使用分析工具來測(cè)試頁面的渲染次數(shù)和事件，來找出應(yīng)用中性能瓶頸。
相較于我們的 Web 端工程，React Native 項(xiàng)目比較新，也比較小巧，所以它成為我們實(shí)驗(yàn)新想法新技術(shù)的『試驗(yàn)場(chǎng)』，很多我們?cè)?React Native 端開發(fā)的工具現(xiàn)在都應(yīng)用到了 Web 端。
動(dòng)畫
React Native 提供了強(qiáng)大的動(dòng)畫庫，我們可以實(shí)現(xiàn)流暢的動(dòng)畫效果，甚至是事件驅(qū)動(dòng)的動(dòng)畫，比如視差滾動(dòng)。
開源的 React/JS 代碼
React Native 基于 React 和 JS，這意味著我們可以使用海量好用的 js 框架，比如 Redux、reselect，jest 等等。
Flexbox
React Native 使用 Yoga 來實(shí)現(xiàn) UI 布局，它是一個(gè)基于C語言開發(fā)的跨平臺(tái)布局框架，使用 flexbox API。當(dāng)然 Yoga 在早期也有很多不足的地方，比如對(duì)比例布局沒有很好的支持，不過在后續(xù)版本中他們會(huì)逐漸改進(jìn)。
另外，例如 flexbox froggy 這類的小游戲也讓學(xué)習(xí) Flexbox 變得更有趣。
和 Web 端合作
深入使用 React Native 后，我們開始同時(shí)構(gòu)建服務(wù)的 iOS，Android 和 Web 版本。由于我們的 Web 端也使用 Redux，所以 RN 端和 Web 端可以共享大量的代碼。
React Native 的缺點(diǎn)
還不夠成熟
相比于 Android 和 iOS 兩個(gè)原生平臺(tái)，React Native 還不夠成熟。它更新，更有野心，并且還在不斷地迭代中。雖然 React Natvie 在大多數(shù)情況下都能很好地工作，但有時(shí)候，它不成熟的一面會(huì)讓一些看起來微不足道的事情變得非常困難讓你抓狂。不幸的是，這些情況很難預(yù)測(cè)，而且可能需要幾小時(shí)到幾天的時(shí)間才能解決。
維護(hù) React Native 的本地分支
由于 React Native 的不穩(wěn)定性，我們有時(shí)候會(huì)需要去修改它的源碼。除了在 github 上貢獻(xiàn)源碼外，我們還必須維護(hù)一個(gè)本地分支，以便能將這些改動(dòng)快速部署到我們的產(chǎn)品中，來解決 bug。在過去的兩年中，我們?cè)?React Native 上提交了50個(gè)本地 commit，這讓每次升級(jí) React Native 版本都變得非常痛苦。
JavaScript
JS 是一種弱類型的語言，缺乏類型安全讓那些習(xí)慣了使用類型安全語言（例如 Swift）的工程師抗拒學(xué)習(xí) React Natvie。我們嘗試使用 flow，但是那些晦澀難懂的錯(cuò)誤提示真的讓人非常沮喪。我們又調(diào)研了 TypeScript ，但是很難將它整合到現(xiàn)有的生態(tài)中去，它和 babel，metro bundler 這類框架有嚴(yán)重的兼容問題。 不過我們?nèi)匀辉诔掷m(xù)關(guān)注著 TypeScript 在 Web 端的發(fā)展。
重構(gòu)
JavaScript 一個(gè)時(shí)常被忽略的缺點(diǎn)是重構(gòu)代碼非常困難，而且容易出錯(cuò)。重命名屬性（props），特別是像 onClick 這樣常見名稱的屬性，簡直就是一場(chǎng)噩夢(mèng)。更糟糕的是，這樣的重構(gòu)很容易導(dǎo)致在運(yùn)行時(shí)崩潰，而且很難在編譯過程中發(fā)現(xiàn)這類錯(cuò)誤，也很難為這類錯(cuò)誤添加適當(dāng)?shù)撵o態(tài)分析。
JavaScriptCore 的不一致性
React Native 一個(gè)重要特性是它在 JavaScriptCore 環(huán)境中執(zhí)行，這有時(shí)候會(huì)導(dǎo)致一些很棘手的麻煩：
iOS 自帶了 JavaScriptCore 環(huán)境，所以 React Native 在 iOS 上的表現(xiàn)相對(duì)穩(wěn)定一致。
Android 沒有默認(rèn)的 JS Core 引擎，React Native 針對(duì) Android 自己打包了一個(gè)，但是這個(gè)打包的引擎版本比較老。所以我們自己想辦法打包了一個(gè)較新版本的 Core。
在 debug 調(diào)試時(shí)，React Native 會(huì)連接到 Chrome 的 Developer Tools，這是一個(gè)很強(qiáng)大的工具。這樣一來，debug 時(shí)所有的 js 代碼就會(huì)默認(rèn)在 Chrome 的 V8 引擎中執(zhí)行，99%的情況下不會(huì)有什么異常，但是我們因此遇到過一個(gè)詭異的錯(cuò)誤：
toLocaleString接口在 iOS 上能正常工作，在 Android debug 環(huán)境也 OK， 但是在打包的 Android App 中卻會(huì)導(dǎo)致崩潰，因?yàn)?Android JSC 并不包含這個(gè)接口！如果工程師不了解這些細(xì)節(jié)，那么調(diào)試這樣的錯(cuò)誤很有可能會(huì)花費(fèi)數(shù)天的時(shí)間，而且非常痛苦。
React Native 開源庫
學(xué)習(xí)一個(gè)全新的平臺(tái)總是費(fèi)時(shí)費(fèi)力的。大部分工程師都只對(duì)一兩個(gè)平臺(tái)比較了解。許多 React Natvie 模塊要用到原生端的橋接，比如地圖、視頻等等，這就要求工程師對(duì)三個(gè)平臺(tái)都比較熟悉。但是我們發(fā)現(xiàn)，大部分 React Native 開源庫的作者只對(duì)一兩個(gè)平臺(tái)有經(jīng)驗(yàn)，這就會(huì)導(dǎo)致這些庫在某個(gè)平臺(tái)上出現(xiàn)詭異的問題。
在 Android 端，許多 React Natvie 庫還在采用到 node_modules 的相對(duì)路徑來鏈接工程，而不是社區(qū)更加推薦的 maven 構(gòu)建方式。
重新搭建基礎(chǔ)架構(gòu)
我們已經(jīng)在 iOS 和 Android 平臺(tái)上積累了大量成熟的基礎(chǔ)架構(gòu)。但是在 React Native 中，一切都是全新的，我們從零開始慢慢橋接或者重新編寫這些框架。這意味著，我們的業(yè)務(wù)工程師常常發(fā)現(xiàn)他們需要的接口、功能還沒有被實(shí)現(xiàn)，只能阻塞手頭的工作，去自己并不熟悉的平臺(tái)編寫需要的功能。
崩潰監(jiān)測(cè)
我們?cè)?iOS 和 Android 平臺(tái)上使用 Bugsnag 來做線上崩潰監(jiān)測(cè)。我們花了很多精力使它能夠工作在 React Natvie 環(huán)境中，但仍然不夠穩(wěn)定。因?yàn)檎麄€(gè)社區(qū)在這方面的經(jīng)驗(yàn)太少了，我們不得不自己動(dòng)手編寫了很多監(jiān)測(cè)相關(guān)的功能，甚至和 Bugsnag 合作，來使它能正確過濾只在 React Native 中發(fā)生的異常。
得益于大量相關(guān)的工作，我們終于可以監(jiān)測(cè)到以前無法捕獲的錯(cuò)誤和閃退了。
還有一點(diǎn)，就是調(diào)試同時(shí)涉及到原生和 React Native 代碼的閃退是非常困難的，因?yàn)槟銦o法跨平臺(tái)來追蹤調(diào)用棧。
原生橋接
React Native 提供了聯(lián)系原生和 JavaScript 的橋接API。盡管它完全可以正常工作，但是編寫起來是在是太『笨重』了。首先，它要求三個(gè)平臺(tái)實(shí)現(xiàn)的橋接 API 都完全一致，我們經(jīng)常遇到的一個(gè)問題是從 JavaScript 端傳遞過來的類型發(fā)生錯(cuò)誤。舉個(gè)例子：整型數(shù)據(jù)會(huì)以字符串的格式被包裝傳遞，然后在運(yùn)行時(shí)導(dǎo)致錯(cuò)誤。更糟糕的是，在 iOS 平臺(tái)上這類錯(cuò)誤往往會(huì)導(dǎo)致靜默的異常，這讓它們更加難以捕捉。我們?cè)?017年底的時(shí)候嘗試使用 TypeScript 編寫更為安全的橋接代碼，但是成效甚微，也太晚了。
初始化時(shí)間
在 React Native 初次加載之前，你必須先初始化它的運(yùn)行時(shí) runtime。不幸的是：像我們這種體量的 App，即使是在性能比較好的手機(jī)上，這個(gè)初始化時(shí)間往往需要耗費(fèi)幾秒鐘之多！所以基于 React Native 做啟動(dòng)閃屏頁面這種功能幾乎是不可能的。不過我們還是讓 Runtime 在 App 啟動(dòng)過程中提前加載，來盡可能地縮減這段時(shí)間。
頁面渲染時(shí)間
和渲染原生頁面不同，渲染一個(gè) React Native 頁面至少要走一個(gè)：主線程 -> js線程 -> yoga layout 解析線程 -> 主線程 的完整工作流，來保證拿到渲染 UI 所需要的所有上下文。我們測(cè)試發(fā)現(xiàn)渲染一個(gè)普通的頁面在 iOS 端平均需要280毫秒，在 Android 端則是440毫秒。
在 Android 端，我們使用 postponeEnterTransition Api 來做頁面的延遲顯示。在 iOS 端，我們不得不為所有的 React Native 頁面添加一個(gè)50毫秒的固定延遲，來解決配置 Navigation Bar 的閃爍問題（注：Airbnb 在 RN 項(xiàng)目中使用了原生的 Navi bar，如果使用 js 重寫的 Navi bar 就可以避免這個(gè)異常）。
應(yīng)用的體積
引入 React Natvie 對(duì)應(yīng)用的體積有非常大的副作用。Android 端每個(gè) React Native 包的體積可以達(dá)到8M（Java + JS + 依賴原生實(shí)現(xiàn)的庫比如 Yoga，JS runtime等等），如果在一個(gè) APK 里同時(shí)集成 x86 和 arm 平臺(tái)庫的話，可以達(dá)到將近12M之多。
64位
因?yàn)槟硞€(gè)已知的issue，我們目前在 Android 端仍然無法打包64位的 APK。
手勢(shì)
我們盡量避免使用 React Native 來編寫含有復(fù)雜手勢(shì)的頁面。因?yàn)?iOS 和 Android 的手勢(shì)系統(tǒng)有很大的區(qū)別，所以在 RN 端提供一個(gè)統(tǒng)一的手勢(shì) API 對(duì)整個(gè)社區(qū)來說都是非常大的挑戰(zhàn)。不過相關(guān)的工作仍然在不斷推進(jìn)中，目前 react-native-gesture-handler 已經(jīng)發(fā)布了1.0版本。
長列表
React Native 已經(jīng)在改進(jìn)長列表性能方面取得了很多進(jìn)步，它們推出了 FlatList，但是還遠(yuǎn)不夠成熟，和 Android 端的 RecyclerView，iOS 端的 UICollectionView 相比還差很遠(yuǎn)。因?yàn)殇秩揪€程的問題，很多性能瓶頸暫時(shí)還很難解決。無法同步獲取到數(shù)據(jù)會(huì)導(dǎo)致快速滑動(dòng)的時(shí)候頁面閃爍，因?yàn)榱斜韮?nèi)的元素在這種情況下會(huì)被異步渲染。Text 組件的高度不能被同步地計(jì)算，因?yàn)閕OS端無法通過提前計(jì)算 cell 高度來進(jìn)行性能優(yōu)化。
升級(jí) React Native
盡管大部分 React Native 的版本升級(jí)改動(dòng)都不大，但有時(shí)候也會(huì)讓人抓狂。特別是當(dāng)你從 React Native 0.43 版本（2017年四月）升級(jí)到 0.49 版本（2017年十月）的時(shí)候，后者使用了 React 16 的 alpha 和 beta 版本，這會(huì)導(dǎo)致很多難以解決的問題，因?yàn)榇蟛糠譃?Web 設(shè)計(jì)的 React 框架不支持 pre-release 的 React 版本。2017年中的一段時(shí)間，我們遇到的大部分兼容問題都來自于這個(gè)蛋疼的升級(jí)過程。
輔助訪問
2017年，為了幫助殘障人士能正常使用 Airbnb 的服務(wù)，我們制定了輔助訪問規(guī)范。但是現(xiàn)有的 React Native 框架難以幫助我們達(dá)到這些規(guī)范哪怕最低的標(biāo)準(zhǔn)。因此我們不得不維護(hù)一個(gè)我們自己的 React Native 代碼分支，在上面實(shí)現(xiàn)我們需要的功能。這就導(dǎo)致我們花費(fèi)大量的精力來考慮怎么將我們的改動(dòng) merge 到 React Navite 倉庫中，然后在 github 上提 merge issue，再花時(shí)間去追蹤這些 issue 的進(jìn)度。
詭異的閃退
React Native 經(jīng)常有一些非常詭異的崩潰。比如說，最近就遇到一個(gè)頭疼的 bug，即使在和檢測(cè)到崩潰手機(jī)軟硬件完全一致的環(huán)境下我們?cè)趺匆矎?fù)現(xiàn)不了……
Android 的進(jìn)程狀態(tài)保存機(jī)制
Android 會(huì)經(jīng)常清理后臺(tái)進(jìn)程，但是會(huì)給進(jìn)程同步保存上下文到 bundle 中的機(jī)會(huì)。但是在 React Native 端，所有狀態(tài)只能在 js 線程中獲取到，所以它們無法被同步訪問到。不僅僅是這個(gè)問題，當(dāng)我們使用 Redux 來做保存數(shù)據(jù)狀態(tài)的 store 時(shí)，它同時(shí)包含了那些需要被序列化的狀態(tài)，和不需要被序列化的狀態(tài)，這就導(dǎo)致了往往會(huì)保存大量多余的數(shù)據(jù)到 bundle 中去，容量超出導(dǎo)致線上的異常崩潰。
