實(shí)戰(zhàn)：白屏優(yōu)化、圖表選型與國(guó)內(nèi)適配指南)
聊一聊“React Native生態(tài)”這個(gè)話(huà)題。說(shuō)實(shí)話(huà)“生態(tài)”這個(gè)詞已經(jīng)被各種技術(shù)文章用爛了但RN的生態(tài)確實(shí)值得認(rèn)真掰扯一下。別的不說(shuō)光看國(guó)內(nèi)開(kāi)發(fā)者日常討論的幾個(gè)高頻問(wèn)題——啟動(dòng)白屏怎么治、統(tǒng)計(jì)圖用什么庫(kù)、Android Studio里配環(huán)境怎么老是報(bào)錯(cuò)、國(guó)內(nèi)落地有什么限制——這背后牽扯到的選型邏輯、依賴(lài)關(guān)系、工程化配套全都在“生態(tài)”這兩個(gè)字里了。這篇文章我會(huì)從生態(tài)全景、核心工具鏈、國(guó)內(nèi)適配、常見(jiàn)故障四個(gè)維度來(lái)展開(kāi)盡量把實(shí)際開(kāi)發(fā)中你會(huì)遇到的那些坑和方案一次講清楚。不管你是剛?cè)隦N不久的新手還是已經(jīng)被線(xiàn)上問(wèn)題折磨得焦頭爛額的老手這篇內(nèi)容應(yīng)該能幫你少走不少?gòu)澛贰?. 生態(tài)全景RN依賴(lài)的四大板塊與選型思路1.1 RN生態(tài)到底包含什么很多人一想到React Native生態(tài)就只想到第三方組件庫(kù)其實(shí)這是一種嚴(yán)重的誤讀。RN生態(tài)往大了說(shuō)至少可以拆成四個(gè)板塊框架與腳手架、核心功能庫(kù)、原生能力橋接層、工程化與調(diào)試工具鏈。框架與腳手架這一層最典型的就是Expo和Ignite。Expo把RN的工程復(fù)雜度降到了非常低的程度你不需要手動(dòng)配置Xcode和Android Studio掃碼就能在真機(jī)預(yù)覽。Ignite則是給喜歡“模板化啟動(dòng)新項(xiàng)目”的團(tuán)隊(duì)準(zhǔn)備的內(nèi)置了導(dǎo)航、狀態(tài)管理、UI組件體系的最佳組合。這層的核心價(jià)值在于它決定了你團(tuán)隊(duì)從零到一跑多遠(yuǎn)、踩多少坑。核心功能庫(kù)則是日常開(kāi)發(fā)的主體導(dǎo)航有React Navigation和React Native Navigation狀態(tài)管理有Redux Toolkit、Zustand、JotaiUI組件有React Native Paper、Tamagui、NativeBase等。這層的核心價(jià)值在于組合效率——你選擇哪幾個(gè)庫(kù)搭配在一起直接決定了項(xiàng)目的代碼風(fēng)格、性能邊界和維護(hù)成本。原生能力橋接層是RN生態(tài)里最特殊的一部分。RN通過(guò)JavaScriptCore或Hermes引擎跑JS代碼但底層還是要靠原生能力撐場(chǎng)面。攝像頭、藍(lán)牙、WiFi、通知、地圖、支付、統(tǒng)計(jì)、二維碼掃描這些能力要么靠官方模塊比如react-native-camera、react-native-push-notification去橋接要么靠你自研原生模塊。這個(gè)環(huán)節(jié)的技術(shù)含量決定了你在一個(gè)RN項(xiàng)目里的天花板。工程化與調(diào)試工具鏈則是容易被低估的一塊。Metro打包器、Flipper調(diào)試器、CodePush熱更新、Detox自動(dòng)化測(cè)試、Appium、Maestro等工具直接影響團(tuán)隊(duì)是否能在RN上長(zhǎng)期投入。很多項(xiàng)目做大了以后發(fā)現(xiàn)迭代不順往往就是這個(gè)板塊沒(méi)有事先規(guī)劃好。1.2 生態(tài)選型的核心原則我在幾個(gè)RN項(xiàng)目里反復(fù)思考過(guò)之后總結(jié)出一條選型原則別追架構(gòu)前沿追穩(wěn)定鏈條。RN生態(tài)最讓人頭疼的地方就是版本迭代太快而絕大多數(shù)第三方庫(kù)的適配速度都跟不上RN本身的速度。你在網(wǎng)上看教程的時(shí)候可能看到博主用的RN 0.72 React Navigation 6.x等你啟動(dòng)一個(gè)新項(xiàng)目時(shí)RN可能已經(jīng)到0.74甚至0.76了很多庫(kù)的配置方式已經(jīng)悄悄變了。所以我的實(shí)操建議是新項(xiàng)目起步時(shí)優(yōu)先選擇符合以下兩個(gè)條件的庫(kù)組合一是還在持續(xù)維護(hù)且issue響應(yīng)夠快的庫(kù)二是與當(dāng)前RN版本兼容性明確的庫(kù)。不必為了追求“新架構(gòu)New Architecture”或者“純JS渲染”去選根本沒(méi)人用的實(shí)驗(yàn)庫(kù)穩(wěn)定壓倒一切。1.3 新老架構(gòu)帶來(lái)的生態(tài)分裂這里要特別說(shuō)一下新架構(gòu)New Architecture的問(wèn)題。從RN 0.70開(kāi)始Meta就在推Fabric渲染器、TurboModules和CodeGen這套新架構(gòu)。到0.76版本新架構(gòu)已經(jīng)成為默認(rèn)選項(xiàng)。但問(wèn)題在于很多老牌第三方庫(kù)還沒(méi)完全適配新架構(gòu)尤其是那些自己寫(xiě)了原生代碼的庫(kù)。我在實(shí)際項(xiàng)目中遇到過(guò)依賴(lài)react-native-webview的老版本在Fabric下閃退的情況換成兼容版本就沒(méi)事了。這個(gè)問(wèn)題的核心在于你在選庫(kù)時(shí)一定要確認(rèn)它是否聲明支持New Architecture。npm頁(yè)面上一般都有說(shuō)明或者你直接去GitHub倉(cāng)庫(kù)看issues里有沒(méi)有人反饋Fabric兼容問(wèn)題。如果你接手的是老項(xiàng)目暫時(shí)不想遷移到新架構(gòu)也可以在android/gradle.properties里設(shè)置newArchEnabledfalse但在RN 0.76以后這個(gè)開(kāi)關(guān)還能用多久就不好說(shuō)了。這本身就是生態(tài)分裂帶來(lái)的風(fēng)險(xiǎn)點(diǎn)團(tuán)隊(duì)決策時(shí)必須把遷移成本估算進(jìn)去。2. 上手之前先解決三個(gè)最常見(jiàn)的技術(shù)痛點(diǎn)為什么很多人剛開(kāi)始學(xué)RN就被勸退因?yàn)樗麄冊(cè)谡莆蘸诵母拍钪跋缺蝗齻€(gè)非常普遍的技術(shù)痛點(diǎn)給折磨了一遍啟動(dòng)白屏、統(tǒng)計(jì)圖表無(wú)法選型、Android Studio里跑不起來(lái)。這三個(gè)問(wèn)題在熱搜詞里全部出現(xiàn)了說(shuō)明不是個(gè)例。我逐個(gè)說(shuō)說(shuō)我自己的處理經(jīng)驗(yàn)。2.1 啟動(dòng)白屏根因和一套可復(fù)用的優(yōu)化方案啟動(dòng)白屏是RN新手最容易撞上的問(wèn)題之一。打開(kāi)App之后屏幕先卡在原生啟動(dòng)頁(yè)上等好幾秒甚至十幾秒然后突然跳出一個(gè)白屏再過(guò)幾秒才渲染出真正的業(yè)務(wù)界面。這個(gè)體驗(yàn)放在生產(chǎn)環(huán)境里用戶(hù)分分鐘刪App。白屏的根因要拆成兩段來(lái)看。第一段是從原生啟動(dòng)頁(yè)LaunchScreen到RN頁(yè)面加載完成之間的空白期這個(gè)階段原生層已經(jīng)執(zhí)行完了但JS引擎還沒(méi)有把第一個(gè)視圖渲染出來(lái)。第二段是JS bundle加載完成后業(yè)務(wù)代碼里還在做初始化、請(qǐng)求數(shù)據(jù)導(dǎo)致首屏一直停留在空白狀態(tài)。針對(duì)第一段最直接的方案是給RN頁(yè)面增加一個(gè)原生側(cè)的過(guò)渡視圖用react-native-bootsplash或者react-native-splash-screen在啟動(dòng)頁(yè)上停留足夠時(shí)間等JS準(zhǔn)備好之后再調(diào)用隱藏方法切走。這里有個(gè)細(xì)節(jié)很容易踩坑iOS上LaunchScreen圖標(biāo)的尺寸必須嚴(yán)格按Retain模式設(shè)計(jì)不然會(huì)出現(xiàn)拉伸Android上需要把splash的drawable和各dpi尺寸都配好否則低端機(jī)可能遇到圖片閃黑。針對(duì)第二段重點(diǎn)在于減小啟動(dòng)期的工作量。啟動(dòng)白屏跟JS bundle體積直接相關(guān)bundle越大Hermes解析執(zhí)行的時(shí)間就越長(zhǎng)。我強(qiáng)烈建議從這幾個(gè)方向去優(yōu)化啟用Hermes引擎。只要你用的是RN 0.70以上版本默認(rèn)就是Hermes它能顯著減少JS執(zhí)行耗時(shí)。如果你在老項(xiàng)目里發(fā)現(xiàn)還沒(méi)開(kāi)記得在android/app/build.gradle里配置enableHermes true。做ram bundle。在Metro配置里開(kāi)啟unstable_enablePackageExports配合字節(jié)碼加載precompiled hermes bytecode能夠讓啟動(dòng)期的CPU負(fù)載顯著降低。延遲非首屏依賴(lài)。不要在App.js的頂層import大量三方庫(kù)而是通過(guò)lazy require的方式按需加載。尤其是統(tǒng)計(jì)、推送、地圖這類(lèi)大庫(kù)能延后初始化就延后。預(yù)緩存接口數(shù)據(jù)。首屏需要的數(shù)據(jù)如果在啟動(dòng)前就能從本地緩存讀到那渲染速度會(huì)快得多。這一整套做法下來(lái)啟動(dòng)白屏基本能控制在1秒以?xún)?nèi)。注意白屏問(wèn)題不是單點(diǎn)優(yōu)化就行的光靠splash頁(yè)掩蓋問(wèn)題你遲早會(huì)在性能測(cè)試?yán)锓?chē)。2.2 統(tǒng)計(jì)圖生態(tài)從SVG到Skia的選型路線(xiàn)統(tǒng)計(jì)圖需求在管理后臺(tái)、財(cái)務(wù)類(lèi)APP里非常常見(jiàn)也是熱搜詞的指向之一。RN生態(tài)里做圖表的選擇其實(shí)不少但每個(gè)庫(kù)的適用場(chǎng)景差異很大。第一梯隊(duì)是victory-native。老版本的victory-native是建立在react-native-svg上的如果你只是做折線(xiàn)圖、柱狀圖、餅圖它綽綽有余。但注意victory-native的最新版本尤其是XL版本已經(jīng)切到了Skia渲染引擎這套東西在新架構(gòu)下的性能確實(shí)更好因?yàn)槟阒苯优茉贕PU上但前提是你得集成shopify/react-native-skia而Skia本身的原生依賴(lài)對(duì)于新手又是一個(gè)額外負(fù)擔(dān)。第二梯隊(duì)是react-native-gifted-charts。這個(gè)庫(kù)是純JS實(shí)現(xiàn)的其實(shí)也是基于SVG不需要額外裝原生模塊上手成本低API設(shè)計(jì)也比較貼近業(yè)務(wù)開(kāi)發(fā)。我印象中它的雙柱對(duì)比圖、分割線(xiàn)、圓形進(jìn)度條都挺好用的數(shù)據(jù)量不大時(shí)性能足夠。第三梯隊(duì)是偏底層的方案直接自己畫(huà)。用react-native-svg的Path和Circle組件自己拼圖表適合那些需要高度定制化、且統(tǒng)計(jì)圖數(shù)量很少的項(xiàng)目。好處是零依賴(lài)壞處是圖表交互比如tooltip、手勢(shì)縮放得自己處理開(kāi)發(fā)成本高。我的建議是日常管理端看板類(lèi)的統(tǒng)計(jì)場(chǎng)景直接用react-native-gifted-charts如果團(tuán)隊(duì)對(duì)圖表性能有極高要求比如實(shí)時(shí)滾動(dòng)的大數(shù)據(jù)曲線(xiàn)再考慮victory-native Skia。如果只是畫(huà)幾個(gè)固定的靜態(tài)圖形干脆用react-native-svg手寫(xiě)算了沒(méi)必要引入一個(gè)大庫(kù)。2.3 Android Studio里運(yùn)行RN項(xiàng)目配置細(xì)節(jié)與常見(jiàn)報(bào)錯(cuò)說(shuō)到“react native 運(yùn)行在android studio”這應(yīng)該是很多RN新手的入門(mén)障礙。RN項(xiàng)目不是像純?cè)鶤ndroid項(xiàng)目一樣打開(kāi)AS就能跑的。你需要先搞清楚RN項(xiàng)目的啟動(dòng)鏈路RN的JS代碼由Metro打包器提供服務(wù)Android原生殼啟動(dòng)后從Metro拉取bundle然后交給Hermes/JSC執(zhí)行。所以在Android Studio里跑RN其實(shí)分兩半上半是原生工程層面的配置下半是Metro的啟動(dòng)。第一步環(huán)境變量配置。ANDROID_HOME需要指向你的Android SDK目錄通常是在local.properties里配置sdk.dir。JAVA_HOME也要正確指向JDK 17RN 0.73以后默認(rèn)要求JDK 17。如果你電腦上裝了多個(gè)JDK這個(gè)環(huán)節(jié)最容易出錯(cuò)。第二步打開(kāi)android目錄。注意別把整個(gè)RN項(xiàng)目根目錄當(dāng)Android工程打開(kāi)要單獨(dú)打開(kāi)android子目錄這樣才能讓Gradle正確解析。第三步同步和構(gòu)建。首次構(gòu)建Gradle會(huì)拉取很多依賴(lài)這會(huì)比較慢尤其是在網(wǎng)絡(luò)條件不理想的情況下。我建議提前配置好Maven國(guó)內(nèi)鏡像比如將倉(cāng)庫(kù)地址指向阿里云Maven并把Gradle wrapper的distributionUrl改成國(guó)內(nèi)可訪(fǎng)問(wèn)的地址。第四步啟動(dòng)Metro。在項(xiàng)目根目錄執(zhí)行npx react-native start然后連接設(shè)備或模擬器后再在Android Studio里點(diǎn)擊Run。如果你跑起來(lái)發(fā)現(xiàn)App連不上Metro那大概率是設(shè)備訪(fǎng)問(wèn)不了本機(jī)的8081端口。這是新人最高頻的報(bào)錯(cuò)之一。解決辦法是執(zhí)行adb reverse tcp:8081 tcp:8081讓Android設(shè)備上的請(qǐng)求反向轉(zhuǎn)發(fā)到電腦。模擬器通常不用執(zhí)行這一步但真機(jī)調(diào)試一定要。還有一個(gè)坑就是SDK版本不匹配。RN的build.gradle里默認(rèn)的compileSdkVersion、targetSdkVersion和buildToolsVersion如果跟你本地安裝的SDK不一致會(huì)出現(xiàn)各種莫名其妙的編譯錯(cuò)誤。所以最好提前統(tǒng)一好你團(tuán)隊(duì)里的SDK版本并在README里寫(xiě)清楚。3. 國(guó)內(nèi)環(huán)境下的RN生態(tài)適配真實(shí)限制與可行替代這個(gè)話(huà)題我在很多技術(shù)群里都被問(wèn)過(guò)。“國(guó)內(nèi)使用react native有哪些限制”其實(shí)是一個(gè)綜合性問(wèn)題它不只是某一個(gè)技術(shù)點(diǎn)的問(wèn)題而是RN生態(tài)與國(guó)內(nèi)開(kāi)發(fā)環(huán)境之間的一次系統(tǒng)適配。3.1 依賴(lài)源與構(gòu)建源的限制RN項(xiàng)目本身依賴(lài)npm、Gradle Maven倉(cāng)庫(kù)、CocoaPods。對(duì)于國(guó)內(nèi)團(tuán)隊(duì)來(lái)說(shuō)這三個(gè)依賴(lài)來(lái)源都存在可訪(fǎng)問(wèn)性問(wèn)題。npm方面核心依賴(lài)包體積大直接連接官方源經(jīng)常超時(shí)。這個(gè)問(wèn)題的解法有兩層第一層全局配淘寶鏡像npmmirror簡(jiǎn)單粗暴第二層更推薦的做法是使用鎖文件package-lock.json或yarn.lock配合內(nèi)部私有npm源這樣能保證團(tuán)隊(duì)內(nèi)所有成員的依賴(lài)版本完全一致同時(shí)規(guī)避公網(wǎng)源的不穩(wěn)定性。Gradle方面google()和mavenCentral()是國(guó)內(nèi)構(gòu)建中最容易卡住的地方。尤其是google()倉(cāng)庫(kù)因?yàn)椴糠忠蕾?lài)包體積極大。解決方案是給build.gradle配置鏡像倉(cāng)庫(kù)。目前比較穩(wěn)妥的做法是將依賴(lài)倉(cāng)庫(kù)地址替換為阿里云或者騰訊云的Maven鏡像同時(shí)保留google()作為fallback。CocoaPods對(duì)應(yīng)的是iOS側(cè)一般不裝iOS依賴(lài)的團(tuán)隊(duì)可以忽略。如果做iOS需要把CocoaPods的repo源替換為國(guó)內(nèi)鏡像否則pod install這一步會(huì)把人逼瘋。3.2 底層服務(wù)能力的限制與替代方案RN生態(tài)默認(rèn)對(duì)接的是Google Play Services和Apple的推送/地圖/支付體系但國(guó)內(nèi)Android環(huán)境沒(méi)有Google服務(wù)iOS由于政策限制有些服務(wù)也不可用。于是你面臨的不只是API調(diào)用方式的差異而是整套服務(wù)方案的替換。分別說(shuō)一下最常見(jiàn)的幾個(gè)場(chǎng)景。地圖react-native-maps在Android上默認(rèn)使用Google Maps在國(guó)內(nèi)完全不可用。替代方案是使用高德地圖或百度地圖的RN第三方封裝庫(kù)。如果你需要同時(shí)支持iOS和Android建議搭一個(gè)Provider抽象層把地圖模塊的調(diào)用統(tǒng)一封裝這樣切換底層SDK時(shí)只改一個(gè)文件。推送FCM在國(guó)內(nèi)Android上基本無(wú)法觸達(dá)iOS的APNs則正常。國(guó)內(nèi)方案要么直接用極光、個(gè)推這類(lèi)聚合推送服務(wù)要么接入小米、華為、OPPO、vivo、魅族的廠商通道。聚合推送的優(yōu)勢(shì)是接入成本低缺點(diǎn)是廠商通道的?；钚Ч枰约簤簻y(cè)。我建議在項(xiàng)目管理后臺(tái)做一個(gè)PushProvider分發(fā)層根據(jù)設(shè)備品牌分發(fā)到對(duì)應(yīng)的廠商SDK。崩潰監(jiān)控Sentry、Crashlytics這類(lèi)海外服務(wù)在國(guó)內(nèi)存在上報(bào)慢、網(wǎng)絡(luò)不穩(wěn)定的問(wèn)題。國(guó)內(nèi)替代方案首選Bugly騰訊它接入簡(jiǎn)單崩潰堆棧還原能力不錯(cuò)而且針對(duì)Android廠商ROM做了適配。統(tǒng)計(jì)分析Google Analytics、Firebase Analytics無(wú)法在國(guó)內(nèi)穩(wěn)定使用建議使用友盟或騰訊移動(dòng)分析。如果你只是需要埋點(diǎn)用友盟就夠了。熱更新CodePush官方服務(wù)在中國(guó)大陸區(qū)域的可用性一直不太穩(wěn)定。早年微軟Azure的節(jié)點(diǎn)在國(guó)內(nèi)直連有時(shí)候很卡。國(guó)內(nèi)團(tuán)隊(duì)如果要上熱更新我更推薦Pushy這個(gè)方案它是國(guó)內(nèi)團(tuán)隊(duì)基于RN原生的熱更新思路開(kāi)發(fā)的產(chǎn)品支持差分更新和灰度發(fā)布。這部分的總體思路是RN生態(tài)里很多庫(kù)默認(rèn)假設(shè)你可以訪(fǎng)問(wèn)Google/Apple那一套服務(wù)但國(guó)內(nèi)落地時(shí)你必須做一次“服務(wù)替換”而且這種替換不是簡(jiǎn)單換一個(gè)SDK的事往往還涉及業(yè)務(wù)層的抽象設(shè)計(jì)。3.3 國(guó)內(nèi)安卓碎片化與廠商適配國(guó)內(nèi)Android的碎片化程度遠(yuǎn)超國(guó)外這也算RN在國(guó)內(nèi)落地的一個(gè)特殊限制。RN的核心賣(mài)點(diǎn)是跨端一致但在國(guó)內(nèi)的各種ROM面前這種一致性會(huì)被明顯削弱。最常見(jiàn)的坑是權(quán)限適配。國(guó)內(nèi)主流ROM對(duì)后臺(tái)定位、自啟動(dòng)、通知權(quán)限都有自己的限制邏輯。比如小米和華為的系統(tǒng)會(huì)把App的“自啟動(dòng)”權(quán)限默認(rèn)關(guān)掉如果用戶(hù)沒(méi)有手動(dòng)打開(kāi)推送到達(dá)率就會(huì)大打折扣。這不是RN本身能解決的問(wèn)題你需要在前端引導(dǎo)用戶(hù)去設(shè)置頁(yè)開(kāi)啟對(duì)應(yīng)權(quán)限并在代碼里判斷當(dāng)前ROM類(lèi)型做差異化處理。另外部分廠商ROM的WebView組件有兼容性問(wèn)題比如有些ROM版本上WebView白屏或者視頻播放異常。如果你在RN里用到react-native-webview建議做UA兜底和WebView內(nèi)核監(jiān)控在頁(yè)面加載失敗時(shí)給出降級(jí)提示。這類(lèi)問(wèn)題做多了以后我自己養(yǎng)成了一個(gè)習(xí)慣RN項(xiàng)目里至少維護(hù)一張“廠商適配矩陣表”記錄每個(gè)機(jī)型、每個(gè)ROM版本下已知的問(wèn)題和對(duì)應(yīng)的hack代碼。這比在issue里臨時(shí)搜答案要高效得多。3.4 網(wǎng)絡(luò)庫(kù)與DNS解析的專(zhuān)項(xiàng)處理RN默認(rèn)的網(wǎng)絡(luò)請(qǐng)求走的是OkHttpAndroid和NSURLSessioniOS在正常網(wǎng)絡(luò)環(huán)境下沒(méi)什么問(wèn)題但國(guó)內(nèi)部分網(wǎng)絡(luò)環(huán)境下DNS解析會(huì)被污染導(dǎo)致域名無(wú)法解析或解析到錯(cuò)誤的IP。這在海外服務(wù)替換的同時(shí)也需要處理。工業(yè)界通用的做法是接入HTTPDNS。國(guó)內(nèi)有阿里云HTTPDNS和騰訊HTTPDNS兩個(gè)可選方案。做法是在原生層給OkHttp配置一個(gè)自定義DNS解析器將域名解析請(qǐng)求從系統(tǒng)的LocalDNS改為HTTPDNS服務(wù)。這樣一來(lái)即使LocalDNS被污染你的App也能拿到正確的服務(wù)器IP。操作上RN側(cè)不用改任何JS代碼只需要在原生側(cè)實(shí)現(xiàn)。但要注意HTTPDNS本身需要申請(qǐng)服務(wù)同時(shí)要處理解析結(jié)果的緩存和過(guò)期策略這個(gè)屬于原生層工作量團(tuán)隊(duì)得有安卓開(kāi)發(fā)資源才能搞定。4. RN日常開(kāi)發(fā)中的高頻故障排查與經(jīng)驗(yàn)速查這一節(jié)我把自己在過(guò)去項(xiàng)目中積累的“問(wèn)題-原因-解法”經(jīng)驗(yàn)整理成一張速查表。里面有些問(wèn)題你已經(jīng)知道有些可能還沒(méi)遇到但遲早會(huì)撞上。4.1 常見(jiàn)故障速查表問(wèn)題現(xiàn)象根因分析解決建議啟動(dòng)白屏超過(guò)3秒JS bundle過(guò)大、Hermes未啟用、首屏接口慢啟用Hermes、開(kāi)啟ram bundle、拆分bundle、splash過(guò)渡、預(yù)緩存首屏數(shù)據(jù)Android模擬器無(wú)法連接Metro8081端口未轉(zhuǎn)發(fā)、Metro未啟動(dòng)執(zhí)行adb reverse tcp:8081 tcp:8081或在AS里檢查端口占用真機(jī)調(diào)試時(shí)報(bào)SDK location not foundlocal.properties缺失在android目錄下創(chuàng)建local.properties并設(shè)置sdk.dirGradle首次構(gòu)建卡死依賴(lài)源下載慢配置阿里云/騰訊云Maven鏡像提前緩存Gradle distributioniOS pod install失敗CocoaPods源不可達(dá)將CocoaPods的repo地址替換為國(guó)內(nèi)鏡像源新架構(gòu)下第三方庫(kù)閃退該庫(kù)未適配Fabric/TurboModules升級(jí)到兼容版本臨時(shí)關(guān)閉newArchEnabled僅限老版本RN列表滾動(dòng)卡頓未使用FlatList/SectionList的虛擬化特性檢查renderItem里的內(nèi)聯(lián)函數(shù)用React.memo包裹列表項(xiàng)合理設(shè)置windowSize統(tǒng)計(jì)圖表渲染模糊圖表容器的devicePixelRatio未處理通過(guò)PixelRatio.getPixelSizeForLayoutSize調(diào)整SVG畫(huà)布的寬度和高度WebView嵌入后白屏Android ROM WebView兼容性問(wèn)題做內(nèi)核監(jiān)控、UA兜底針對(duì)特定ROM降級(jí)為系統(tǒng)瀏覽器打開(kāi)推送到達(dá)率低廠商通道未開(kāi)通或用戶(hù)權(quán)限被關(guān)閉集成廠商推送SDK引導(dǎo)用戶(hù)開(kāi)啟自啟動(dòng)和通知權(quán)限4.2 排查思路與工具鏈有很多RN開(kāi)發(fā)者在排查問(wèn)題時(shí)不習(xí)慣用工具習(xí)慣性在console.log和debugger之間來(lái)回切效率很低。我建議至少配置好Flipper它能同時(shí)查看Metro日志、網(wǎng)絡(luò)請(qǐng)求、AsyncStorage內(nèi)容、React組件樹(shù)和JS錯(cuò)誤堆棧。Flipper雖然不是萬(wàn)能的但很多“為什么請(qǐng)求沒(méi)發(fā)出”“為什么狀態(tài)沒(méi)更新”這類(lèi)問(wèn)題在Flipper里一眼就能看到。如果你用的是Expo開(kāi)發(fā)那Expo Go內(nèi)置的調(diào)試面板也夠用。但做國(guó)內(nèi)落地項(xiàng)目大多數(shù)時(shí)候還是要走bare workflow建議固定一套工具鏈Metro Flipper Android Studio Logcat Xcode Console。出現(xiàn)問(wèn)題先看Metro日志有沒(méi)有JS異常再看Logcat有沒(méi)有原生崩潰信息最后才在業(yè)務(wù)代碼里找線(xiàn)索。4.3 性能排查的經(jīng)驗(yàn)之談RN性能問(wèn)題常常不只在JS層原生層的布局計(jì)算和線(xiàn)程調(diào)度同樣是瓶頸。我自己排查RN性能問(wèn)題的順序是首先看JS線(xiàn)程的CPU占用。如果Redux狀態(tài)更新導(dǎo)致全組件樹(shù)重新渲染那就需要優(yōu)化selector或者說(shuō)用useSelector按片段訂閱。其次看UI線(xiàn)程的掉幀情況。RN的布局操作最終會(huì)傳到原生側(cè)如果你的UI層級(jí)過(guò)深或者使用大量陰影shadowUI線(xiàn)程很容易掉幀。最后看原生線(xiàn)程的開(kāi)銷(xiāo)。如果你的業(yè)務(wù)里大量使用bridge調(diào)用哪怕是新架構(gòu)的TurboModule那頻繁跨線(xiàn)程通信本身就會(huì)帶來(lái)性能損失。這里給一個(gè)很實(shí)用的調(diào)優(yōu)技巧在開(kāi)發(fā)模式下RN的JS線(xiàn)程性能會(huì)比生產(chǎn)模式差很多因?yàn)殚_(kāi)發(fā)模式多了很多警告和檢查。所以做性能測(cè)試一定要用release包別在開(kāi)發(fā)模式下測(cè)測(cè)出來(lái)的數(shù)據(jù)不能反映線(xiàn)上水平。4.4 團(tuán)隊(duì)協(xié)作層面的兩個(gè)建議落實(shí)到團(tuán)隊(duì)長(zhǎng)期維護(hù)RN項(xiàng)目還有兩個(gè)容易被忽視的建議。第一個(gè)把依賴(lài)升級(jí)做成例行機(jī)制。RN生態(tài)更新很快第三方庫(kù)也跟著變。建議每季度做一次依賴(lài)升級(jí)升級(jí)后重點(diǎn)回歸啟動(dòng)、導(dǎo)航、列表、網(wǎng)絡(luò)這四個(gè)模塊。如果長(zhǎng)期不升級(jí)技術(shù)債越積越多等哪天被迫升級(jí)時(shí)工作量會(huì)讓你崩潰。第二個(gè)沉淀自己的代碼模板和腳手架。不要每次開(kāi)新項(xiàng)目都從零配置react-native init。建議花點(diǎn)時(shí)間做一個(gè)團(tuán)隊(duì)的starter kit內(nèi)置好導(dǎo)航、狀態(tài)管理、網(wǎng)絡(luò)層、鑒權(quán)邏輯、UI基礎(chǔ)組件、埋點(diǎn)上報(bào)這些基礎(chǔ)能力。這樣新項(xiàng)目啟動(dòng)時(shí)會(huì)非常快而且能保證不同項(xiàng)目之間的代碼結(jié)構(gòu)一致方便人員流動(dòng)和交接。寫(xiě)在最后的一些個(gè)人體會(huì)帶了好幾個(gè)RN項(xiàng)目下來(lái)我自己最深的感受是React Native生態(tài)不是缺庫(kù)反而是過(guò)于豐富豐富的選擇本身就構(gòu)成了成本。真正考驗(yàn)團(tuán)隊(duì)的不是會(huì)用一兩個(gè)熱門(mén)庫(kù)而是能不能在紛繁復(fù)雜的生態(tài)里做減法選出一套最適合自己業(yè)務(wù)場(chǎng)景的穩(wěn)定組合。另外國(guó)內(nèi)RN開(kāi)發(fā)者和海外RN開(kāi)發(fā)者的經(jīng)驗(yàn)參考體系其實(shí)差別很大。海外的教程和模板默認(rèn)你生活在有Google服務(wù)、網(wǎng)絡(luò)順暢的環(huán)境里很多方案直接套到國(guó)內(nèi)項(xiàng)目上就跑不通。所以國(guó)內(nèi)團(tuán)隊(duì)在做技術(shù)調(diào)研時(shí)一定要額外關(guān)注“這個(gè)庫(kù)在本地網(wǎng)絡(luò)環(huán)境下是否可用”這一項(xiàng)。把這個(gè)因素前置到選型階段能省下后面大量的適配和填坑時(shí)間。最后再分享一個(gè)小技巧RN項(xiàng)目的node_modules目錄越來(lái)越大但很多依賴(lài)根本沒(méi)用上只是被npm解析進(jìn)來(lái)了。每次升級(jí)完依賴(lài)后記得跑一下npx react-native bundle --platform android --dev false --entry-file index.js --bundle-output androidApp.bundle然后看看這個(gè)文件的大小。如果bundle體積膨脹得很厲害說(shuō)明你引入了太多不必要的東西該做代碼分割了。React Native這個(gè)生態(tài)還會(huì)繼續(xù)往前演進(jìn)新架構(gòu)、靜態(tài)框架、IDE支持都在迭代。但不管底層怎么變做好基礎(chǔ)工程、保持依賴(lài)整潔、理解底層的原生機(jī)制這三件事始終不會(huì)過(guò)時(shí)。希望這篇內(nèi)容能幫你在RN生態(tài)里找到屬于自己的那條路。 React Native生態(tài)實(shí)戰(zhàn)：白屏優(yōu)化、圖表選型與國(guó)內(nèi)適配指南
聊一聊“React Native生態(tài)”這個(gè)話(huà)題。說(shuō)實(shí)話(huà)“生態(tài)”這個(gè)詞已經(jīng)被各種技術(shù)文章用爛了但RN的生態(tài)確實(shí)值得認(rèn)真掰扯一下。別的不說(shuō)光看國(guó)內(nèi)開(kāi)發(fā)者日常討論的幾個(gè)高頻問(wèn)題——啟動(dòng)白屏怎么治、統(tǒng)計(jì)圖用什么庫(kù)、Android Studio里配環(huán)境怎么老是報(bào)錯(cuò)、國(guó)內(nèi)落地有什么限制——這背后牽扯到的選型邏輯、依賴(lài)關(guān)系、工程化配套全都在“生態(tài)”這兩個(gè)字里了。這篇文章我會(huì)從生態(tài)全景、核心工具鏈、國(guó)內(nèi)適配、常見(jiàn)故障四個(gè)維度來(lái)展開(kāi)盡量把實(shí)際開(kāi)發(fā)中你會(huì)遇到的那些坑和方案一次講清楚。不管你是剛?cè)隦N不久的新手還是已經(jīng)被線(xiàn)上問(wèn)題折磨得焦頭爛額的老手這篇內(nèi)容應(yīng)該能幫你少走不少?gòu)澛贰?. 生態(tài)全景RN依賴(lài)的四大板塊與選型思路1.1 RN生態(tài)到底包含什么很多人一想到React Native生態(tài)就只想到第三方組件庫(kù)其實(shí)這是一種嚴(yán)重的誤讀。RN生態(tài)往大了說(shuō)至少可以拆成四個(gè)板塊框架與腳手架、核心功能庫(kù)、原生能力橋接層、工程化與調(diào)試工具鏈。框架與腳手架這一層最典型的就是Expo和Ignite。Expo把RN的工程復(fù)雜度降到了非常低的程度你不需要手動(dòng)配置Xcode和Android Studio掃碼就能在真機(jī)預(yù)覽。Ignite則是給喜歡“模板化啟動(dòng)新項(xiàng)目”的團(tuán)隊(duì)準(zhǔn)備的內(nèi)置了導(dǎo)航、狀態(tài)管理、UI組件體系的最佳組合。這層的核心價(jià)值在于它決定了你團(tuán)隊(duì)從零到一跑多遠(yuǎn)、踩多少坑。核心功能庫(kù)則是日常開(kāi)發(fā)的主體導(dǎo)航有React Navigation和React Native Navigation狀態(tài)管理有Redux Toolkit、Zustand、JotaiUI組件有React Native Paper、Tamagui、NativeBase等。這層的核心價(jià)值在于組合效率——你選擇哪幾個(gè)庫(kù)搭配在一起直接決定了項(xiàng)目的代碼風(fēng)格、性能邊界和維護(hù)成本。原生能力橋接層是RN生態(tài)里最特殊的一部分。RN通過(guò)JavaScriptCore或Hermes引擎跑JS代碼但底層還是要靠原生能力撐場(chǎng)面。攝像頭、藍(lán)牙、WiFi、通知、地圖、支付、統(tǒng)計(jì)、二維碼掃描這些能力要么靠官方模塊比如react-native-camera、react-native-push-notification去橋接要么靠你自研原生模塊。這個(gè)環(huán)節(jié)的技術(shù)含量決定了你在一個(gè)RN項(xiàng)目里的天花板。工程化與調(diào)試工具鏈則是容易被低估的一塊。Metro打包器、Flipper調(diào)試器、CodePush熱更新、Detox自動(dòng)化測(cè)試、Appium、Maestro等工具直接影響團(tuán)隊(duì)是否能在RN上長(zhǎng)期投入。很多項(xiàng)目做大了以后發(fā)現(xiàn)迭代不順往往就是這個(gè)板塊沒(méi)有事先規(guī)劃好。1.2 生態(tài)選型的核心原則我在幾個(gè)RN項(xiàng)目里反復(fù)思考過(guò)之后總結(jié)出一條選型原則別追架構(gòu)前沿追穩(wěn)定鏈條。RN生態(tài)最讓人頭疼的地方就是版本迭代太快而絕大多數(shù)第三方庫(kù)的適配速度都跟不上RN本身的速度。你在網(wǎng)上看教程的時(shí)候可能看到博主用的RN 0.72 React Navigation 6.x等你啟動(dòng)一個(gè)新項(xiàng)目時(shí)RN可能已經(jīng)到0.74甚至0.76了很多庫(kù)的配置方式已經(jīng)悄悄變了。所以我的實(shí)操建議是新項(xiàng)目起步時(shí)優(yōu)先選擇符合以下兩個(gè)條件的庫(kù)組合一是還在持續(xù)維護(hù)且issue響應(yīng)夠快的庫(kù)二是與當(dāng)前RN版本兼容性明確的庫(kù)。不必為了追求“新架構(gòu)New Architecture”或者“純JS渲染”去選根本沒(méi)人用的實(shí)驗(yàn)庫(kù)穩(wěn)定壓倒一切。1.3 新老架構(gòu)帶來(lái)的生態(tài)分裂這里要特別說(shuō)一下新架構(gòu)New Architecture的問(wèn)題。從RN 0.70開(kāi)始Meta就在推Fabric渲染器、TurboModules和CodeGen這套新架構(gòu)。到0.76版本新架構(gòu)已經(jīng)成為默認(rèn)選項(xiàng)。但問(wèn)題在于很多老牌第三方庫(kù)還沒(méi)完全適配新架構(gòu)尤其是那些自己寫(xiě)了原生代碼的庫(kù)。我在實(shí)際項(xiàng)目中遇到過(guò)依賴(lài)react-native-webview的老版本在Fabric下閃退的情況換成兼容版本就沒(méi)事了。這個(gè)問(wèn)題的核心在于你在選庫(kù)時(shí)一定要確認(rèn)它是否聲明支持New Architecture。npm頁(yè)面上一般都有說(shuō)明或者你直接去GitHub倉(cāng)庫(kù)看issues里有沒(méi)有人反饋Fabric兼容問(wèn)題。如果你接手的是老項(xiàng)目暫時(shí)不想遷移到新架構(gòu)也可以在android/gradle.properties里設(shè)置newArchEnabledfalse但在RN 0.76以后這個(gè)開(kāi)關(guān)還能用多久就不好說(shuō)了。這本身就是生態(tài)分裂帶來(lái)的風(fēng)險(xiǎn)點(diǎn)團(tuán)隊(duì)決策時(shí)必須把遷移成本估算進(jìn)去。2. 上手之前先解決三個(gè)最常見(jiàn)的技術(shù)痛點(diǎn)為什么很多人剛開(kāi)始學(xué)RN就被勸退因?yàn)樗麄冊(cè)谡莆蘸诵母拍钪跋缺蝗齻€(gè)非常普遍的技術(shù)痛點(diǎn)給折磨了一遍啟動(dòng)白屏、統(tǒng)計(jì)圖表無(wú)法選型、Android Studio里跑不起來(lái)。這三個(gè)問(wèn)題在熱搜詞里全部出現(xiàn)了說(shuō)明不是個(gè)例。我逐個(gè)說(shuō)說(shuō)我自己的處理經(jīng)驗(yàn)。2.1 啟動(dòng)白屏根因和一套可復(fù)用的優(yōu)化方案啟動(dòng)白屏是RN新手最容易撞上的問(wèn)題之一。打開(kāi)App之后屏幕先卡在原生啟動(dòng)頁(yè)上等好幾秒甚至十幾秒然后突然跳出一個(gè)白屏再過(guò)幾秒才渲染出真正的業(yè)務(wù)界面。這個(gè)體驗(yàn)放在生產(chǎn)環(huán)境里用戶(hù)分分鐘刪App。白屏的根因要拆成兩段來(lái)看。第一段是從原生啟動(dòng)頁(yè)LaunchScreen到RN頁(yè)面加載完成之間的空白期這個(gè)階段原生層已經(jīng)執(zhí)行完了但JS引擎還沒(méi)有把第一個(gè)視圖渲染出來(lái)。第二段是JS bundle加載完成后業(yè)務(wù)代碼里還在做初始化、請(qǐng)求數(shù)據(jù)導(dǎo)致首屏一直停留在空白狀態(tài)。針對(duì)第一段最直接的方案是給RN頁(yè)面增加一個(gè)原生側(cè)的過(guò)渡視圖用react-native-bootsplash或者react-native-splash-screen在啟動(dòng)頁(yè)上停留足夠時(shí)間等JS準(zhǔn)備好之后再調(diào)用隱藏方法切走。這里有個(gè)細(xì)節(jié)很容易踩坑iOS上LaunchScreen圖標(biāo)的尺寸必須嚴(yán)格按Retain模式設(shè)計(jì)不然會(huì)出現(xiàn)拉伸Android上需要把splash的drawable和各dpi尺寸都配好否則低端機(jī)可能遇到圖片閃黑。針對(duì)第二段重點(diǎn)在于減小啟動(dòng)期的工作量。啟動(dòng)白屏跟JS bundle體積直接相關(guān)bundle越大Hermes解析執(zhí)行的時(shí)間就越長(zhǎng)。我強(qiáng)烈建議從這幾個(gè)方向去優(yōu)化啟用Hermes引擎。只要你用的是RN 0.70以上版本默認(rèn)就是Hermes它能顯著減少JS執(zhí)行耗時(shí)。如果你在老項(xiàng)目里發(fā)現(xiàn)還沒(méi)開(kāi)記得在android/app/build.gradle里配置enableHermes true。做ram bundle。在Metro配置里開(kāi)啟unstable_enablePackageExports配合字節(jié)碼加載precompiled hermes bytecode能夠讓啟動(dòng)期的CPU負(fù)載顯著降低。延遲非首屏依賴(lài)。不要在App.js的頂層import大量三方庫(kù)而是通過(guò)lazy require的方式按需加載。尤其是統(tǒng)計(jì)、推送、地圖這類(lèi)大庫(kù)能延后初始化就延后。預(yù)緩存接口數(shù)據(jù)。首屏需要的數(shù)據(jù)如果在啟動(dòng)前就能從本地緩存讀到那渲染速度會(huì)快得多。這一整套做法下來(lái)啟動(dòng)白屏基本能控制在1秒以?xún)?nèi)。注意白屏問(wèn)題不是單點(diǎn)優(yōu)化就行的光靠splash頁(yè)掩蓋問(wèn)題你遲早會(huì)在性能測(cè)試?yán)锓?chē)。2.2 統(tǒng)計(jì)圖生態(tài)從SVG到Skia的選型路線(xiàn)統(tǒng)計(jì)圖需求在管理后臺(tái)、財(cái)務(wù)類(lèi)APP里非常常見(jiàn)也是熱搜詞的指向之一。RN生態(tài)里做圖表的選擇其實(shí)不少但每個(gè)庫(kù)的適用場(chǎng)景差異很大。第一梯隊(duì)是victory-native。老版本的victory-native是建立在react-native-svg上的如果你只是做折線(xiàn)圖、柱狀圖、餅圖它綽綽有余。但注意victory-native的最新版本尤其是XL版本已經(jīng)切到了Skia渲染引擎這套東西在新架構(gòu)下的性能確實(shí)更好因?yàn)槟阒苯优茉贕PU上但前提是你得集成shopify/react-native-skia而Skia本身的原生依賴(lài)對(duì)于新手又是一個(gè)額外負(fù)擔(dān)。第二梯隊(duì)是react-native-gifted-charts。這個(gè)庫(kù)是純JS實(shí)現(xiàn)的其實(shí)也是基于SVG不需要額外裝原生模塊上手成本低API設(shè)計(jì)也比較貼近業(yè)務(wù)開(kāi)發(fā)。我印象中它的雙柱對(duì)比圖、分割線(xiàn)、圓形進(jìn)度條都挺好用的數(shù)據(jù)量不大時(shí)性能足夠。第三梯隊(duì)是偏底層的方案直接自己畫(huà)。用react-native-svg的Path和Circle組件自己拼圖表適合那些需要高度定制化、且統(tǒng)計(jì)圖數(shù)量很少的項(xiàng)目。好處是零依賴(lài)壞處是圖表交互比如tooltip、手勢(shì)縮放得自己處理開(kāi)發(fā)成本高。我的建議是日常管理端看板類(lèi)的統(tǒng)計(jì)場(chǎng)景直接用react-native-gifted-charts如果團(tuán)隊(duì)對(duì)圖表性能有極高要求比如實(shí)時(shí)滾動(dòng)的大數(shù)據(jù)曲線(xiàn)再考慮victory-native Skia。如果只是畫(huà)幾個(gè)固定的靜態(tài)圖形干脆用react-native-svg手寫(xiě)算了沒(méi)必要引入一個(gè)大庫(kù)。2.3 Android Studio里運(yùn)行RN項(xiàng)目配置細(xì)節(jié)與常見(jiàn)報(bào)錯(cuò)說(shuō)到“react native 運(yùn)行在android studio”這應(yīng)該是很多RN新手的入門(mén)障礙。RN項(xiàng)目不是像純?cè)鶤ndroid項(xiàng)目一樣打開(kāi)AS就能跑的。你需要先搞清楚RN項(xiàng)目的啟動(dòng)鏈路RN的JS代碼由Metro打包器提供服務(wù)Android原生殼啟動(dòng)后從Metro拉取bundle然后交給Hermes/JSC執(zhí)行。所以在Android Studio里跑RN其實(shí)分兩半上半是原生工程層面的配置下半是Metro的啟動(dòng)。第一步環(huán)境變量配置。ANDROID_HOME需要指向你的Android SDK目錄通常是在local.properties里配置sdk.dir。JAVA_HOME也要正確指向JDK 17RN 0.73以后默認(rèn)要求JDK 17。如果你電腦上裝了多個(gè)JDK這個(gè)環(huán)節(jié)最容易出錯(cuò)。第二步打開(kāi)android目錄。注意別把整個(gè)RN項(xiàng)目根目錄當(dāng)Android工程打開(kāi)要單獨(dú)打開(kāi)android子目錄這樣才能讓Gradle正確解析。第三步同步和構(gòu)建。首次構(gòu)建Gradle會(huì)拉取很多依賴(lài)這會(huì)比較慢尤其是在網(wǎng)絡(luò)條件不理想的情況下。我建議提前配置好Maven國(guó)內(nèi)鏡像比如將倉(cāng)庫(kù)地址指向阿里云Maven并把Gradle wrapper的distributionUrl改成國(guó)內(nèi)可訪(fǎng)問(wèn)的地址。第四步啟動(dòng)Metro。在項(xiàng)目根目錄執(zhí)行npx react-native start然后連接設(shè)備或模擬器后再在Android Studio里點(diǎn)擊Run。如果你跑起來(lái)發(fā)現(xiàn)App連不上Metro那大概率是設(shè)備訪(fǎng)問(wèn)不了本機(jī)的8081端口。這是新人最高頻的報(bào)錯(cuò)之一。解決辦法是執(zhí)行adb reverse tcp:8081 tcp:8081讓Android設(shè)備上的請(qǐng)求反向轉(zhuǎn)發(fā)到電腦。模擬器通常不用執(zhí)行這一步但真機(jī)調(diào)試一定要。還有一個(gè)坑就是SDK版本不匹配。RN的build.gradle里默認(rèn)的compileSdkVersion、targetSdkVersion和buildToolsVersion如果跟你本地安裝的SDK不一致會(huì)出現(xiàn)各種莫名其妙的編譯錯(cuò)誤。所以最好提前統(tǒng)一好你團(tuán)隊(duì)里的SDK版本并在README里寫(xiě)清楚。3. 國(guó)內(nèi)環(huán)境下的RN生態(tài)適配真實(shí)限制與可行替代這個(gè)話(huà)題我在很多技術(shù)群里都被問(wèn)過(guò)。“國(guó)內(nèi)使用react native有哪些限制”其實(shí)是一個(gè)綜合性問(wèn)題它不只是某一個(gè)技術(shù)點(diǎn)的問(wèn)題而是RN生態(tài)與國(guó)內(nèi)開(kāi)發(fā)環(huán)境之間的一次系統(tǒng)適配。3.1 依賴(lài)源與構(gòu)建源的限制RN項(xiàng)目本身依賴(lài)npm、Gradle Maven倉(cāng)庫(kù)、CocoaPods。對(duì)于國(guó)內(nèi)團(tuán)隊(duì)來(lái)說(shuō)這三個(gè)依賴(lài)來(lái)源都存在可訪(fǎng)問(wèn)性問(wèn)題。npm方面核心依賴(lài)包體積大直接連接官方源經(jīng)常超時(shí)。這個(gè)問(wèn)題的解法有兩層第一層全局配淘寶鏡像npmmirror簡(jiǎn)單粗暴第二層更推薦的做法是使用鎖文件package-lock.json或yarn.lock配合內(nèi)部私有npm源這樣能保證團(tuán)隊(duì)內(nèi)所有成員的依賴(lài)版本完全一致同時(shí)規(guī)避公網(wǎng)源的不穩(wěn)定性。Gradle方面google()和mavenCentral()是國(guó)內(nèi)構(gòu)建中最容易卡住的地方。尤其是google()倉(cāng)庫(kù)因?yàn)椴糠忠蕾?lài)包體積極大。解決方案是給build.gradle配置鏡像倉(cāng)庫(kù)。目前比較穩(wěn)妥的做法是將依賴(lài)倉(cāng)庫(kù)地址替換為阿里云或者騰訊云的Maven鏡像同時(shí)保留google()作為fallback。CocoaPods對(duì)應(yīng)的是iOS側(cè)一般不裝iOS依賴(lài)的團(tuán)隊(duì)可以忽略。如果做iOS需要把CocoaPods的repo源替換為國(guó)內(nèi)鏡像否則pod install這一步會(huì)把人逼瘋。3.2 底層服務(wù)能力的限制與替代方案RN生態(tài)默認(rèn)對(duì)接的是Google Play Services和Apple的推送/地圖/支付體系但國(guó)內(nèi)Android環(huán)境沒(méi)有Google服務(wù)iOS由于政策限制有些服務(wù)也不可用。于是你面臨的不只是API調(diào)用方式的差異而是整套服務(wù)方案的替換。分別說(shuō)一下最常見(jiàn)的幾個(gè)場(chǎng)景。地圖react-native-maps在Android上默認(rèn)使用Google Maps在國(guó)內(nèi)完全不可用。替代方案是使用高德地圖或百度地圖的RN第三方封裝庫(kù)。如果你需要同時(shí)支持iOS和Android建議搭一個(gè)Provider抽象層把地圖模塊的調(diào)用統(tǒng)一封裝這樣切換底層SDK時(shí)只改一個(gè)文件。推送FCM在國(guó)內(nèi)Android上基本無(wú)法觸達(dá)iOS的APNs則正常。國(guó)內(nèi)方案要么直接用極光、個(gè)推這類(lèi)聚合推送服務(wù)要么接入小米、華為、OPPO、vivo、魅族的廠商通道。聚合推送的優(yōu)勢(shì)是接入成本低缺點(diǎn)是廠商通道的?；钚Ч枰约簤簻y(cè)。我建議在項(xiàng)目管理后臺(tái)做一個(gè)PushProvider分發(fā)層根據(jù)設(shè)備品牌分發(fā)到對(duì)應(yīng)的廠商SDK。崩潰監(jiān)控Sentry、Crashlytics這類(lèi)海外服務(wù)在國(guó)內(nèi)存在上報(bào)慢、網(wǎng)絡(luò)不穩(wěn)定的問(wèn)題。國(guó)內(nèi)替代方案首選Bugly騰訊它接入簡(jiǎn)單崩潰堆棧還原能力不錯(cuò)而且針對(duì)Android廠商ROM做了適配。統(tǒng)計(jì)分析Google Analytics、Firebase Analytics無(wú)法在國(guó)內(nèi)穩(wěn)定使用建議使用友盟或騰訊移動(dòng)分析。如果你只是需要埋點(diǎn)用友盟就夠了。熱更新CodePush官方服務(wù)在中國(guó)大陸區(qū)域的可用性一直不太穩(wěn)定。早年微軟Azure的節(jié)點(diǎn)在國(guó)內(nèi)直連有時(shí)候很卡。國(guó)內(nèi)團(tuán)隊(duì)如果要上熱更新我更推薦Pushy這個(gè)方案它是國(guó)內(nèi)團(tuán)隊(duì)基于RN原生的熱更新思路開(kāi)發(fā)的產(chǎn)品支持差分更新和灰度發(fā)布。這部分的總體思路是RN生態(tài)里很多庫(kù)默認(rèn)假設(shè)你可以訪(fǎng)問(wèn)Google/Apple那一套服務(wù)但國(guó)內(nèi)落地時(shí)你必須做一次“服務(wù)替換”而且這種替換不是簡(jiǎn)單換一個(gè)SDK的事往往還涉及業(yè)務(wù)層的抽象設(shè)計(jì)。3.3 國(guó)內(nèi)安卓碎片化與廠商適配國(guó)內(nèi)Android的碎片化程度遠(yuǎn)超國(guó)外這也算RN在國(guó)內(nèi)落地的一個(gè)特殊限制。RN的核心賣(mài)點(diǎn)是跨端一致但在國(guó)內(nèi)的各種ROM面前這種一致性會(huì)被明顯削弱。最常見(jiàn)的坑是權(quán)限適配。國(guó)內(nèi)主流ROM對(duì)后臺(tái)定位、自啟動(dòng)、通知權(quán)限都有自己的限制邏輯。比如小米和華為的系統(tǒng)會(huì)把App的“自啟動(dòng)”權(quán)限默認(rèn)關(guān)掉如果用戶(hù)沒(méi)有手動(dòng)打開(kāi)推送到達(dá)率就會(huì)大打折扣。這不是RN本身能解決的問(wèn)題你需要在前端引導(dǎo)用戶(hù)去設(shè)置頁(yè)開(kāi)啟對(duì)應(yīng)權(quán)限并在代碼里判斷當(dāng)前ROM類(lèi)型做差異化處理。另外部分廠商ROM的WebView組件有兼容性問(wèn)題比如有些ROM版本上WebView白屏或者視頻播放異常。如果你在RN里用到react-native-webview建議做UA兜底和WebView內(nèi)核監(jiān)控在頁(yè)面加載失敗時(shí)給出降級(jí)提示。這類(lèi)問(wèn)題做多了以后我自己養(yǎng)成了一個(gè)習(xí)慣RN項(xiàng)目里至少維護(hù)一張“廠商適配矩陣表”記錄每個(gè)機(jī)型、每個(gè)ROM版本下已知的問(wèn)題和對(duì)應(yīng)的hack代碼。這比在issue里臨時(shí)搜答案要高效得多。3.4 網(wǎng)絡(luò)庫(kù)與DNS解析的專(zhuān)項(xiàng)處理RN默認(rèn)的網(wǎng)絡(luò)請(qǐng)求走的是OkHttpAndroid和NSURLSessioniOS在正常網(wǎng)絡(luò)環(huán)境下沒(méi)什么問(wèn)題但國(guó)內(nèi)部分網(wǎng)絡(luò)環(huán)境下DNS解析會(huì)被污染導(dǎo)致域名無(wú)法解析或解析到錯(cuò)誤的IP。這在海外服務(wù)替換的同時(shí)也需要處理。工業(yè)界通用的做法是接入HTTPDNS。國(guó)內(nèi)有阿里云HTTPDNS和騰訊HTTPDNS兩個(gè)可選方案。做法是在原生層給OkHttp配置一個(gè)自定義DNS解析器將域名解析請(qǐng)求從系統(tǒng)的LocalDNS改為HTTPDNS服務(wù)。這樣一來(lái)即使LocalDNS被污染你的App也能拿到正確的服務(wù)器IP。操作上RN側(cè)不用改任何JS代碼只需要在原生側(cè)實(shí)現(xiàn)。但要注意HTTPDNS本身需要申請(qǐng)服務(wù)同時(shí)要處理解析結(jié)果的緩存和過(guò)期策略這個(gè)屬于原生層工作量團(tuán)隊(duì)得有安卓開(kāi)發(fā)資源才能搞定。4. RN日常開(kāi)發(fā)中的高頻故障排查與經(jīng)驗(yàn)速查這一節(jié)我把自己在過(guò)去項(xiàng)目中積累的“問(wèn)題-原因-解法”經(jīng)驗(yàn)整理成一張速查表。里面有些問(wèn)題你已經(jīng)知道有些可能還沒(méi)遇到但遲早會(huì)撞上。4.1 常見(jiàn)故障速查表問(wèn)題現(xiàn)象根因分析解決建議啟動(dòng)白屏超過(guò)3秒JS bundle過(guò)大、Hermes未啟用、首屏接口慢啟用Hermes、開(kāi)啟ram bundle、拆分bundle、splash過(guò)渡、預(yù)緩存首屏數(shù)據(jù)Android模擬器無(wú)法連接Metro8081端口未轉(zhuǎn)發(fā)、Metro未啟動(dòng)執(zhí)行adb reverse tcp:8081 tcp:8081或在AS里檢查端口占用真機(jī)調(diào)試時(shí)報(bào)SDK location not foundlocal.properties缺失在android目錄下創(chuàng)建local.properties并設(shè)置sdk.dirGradle首次構(gòu)建卡死依賴(lài)源下載慢配置阿里云/騰訊云Maven鏡像提前緩存Gradle distributioniOS pod install失敗CocoaPods源不可達(dá)將CocoaPods的repo地址替換為國(guó)內(nèi)鏡像源新架構(gòu)下第三方庫(kù)閃退該庫(kù)未適配Fabric/TurboModules升級(jí)到兼容版本臨時(shí)關(guān)閉newArchEnabled僅限老版本RN列表滾動(dòng)卡頓未使用FlatList/SectionList的虛擬化特性檢查renderItem里的內(nèi)聯(lián)函數(shù)用React.memo包裹列表項(xiàng)合理設(shè)置windowSize統(tǒng)計(jì)圖表渲染模糊圖表容器的devicePixelRatio未處理通過(guò)PixelRatio.getPixelSizeForLayoutSize調(diào)整SVG畫(huà)布的寬度和高度WebView嵌入后白屏Android ROM WebView兼容性問(wèn)題做內(nèi)核監(jiān)控、UA兜底針對(duì)特定ROM降級(jí)為系統(tǒng)瀏覽器打開(kāi)推送到達(dá)率低廠商通道未開(kāi)通或用戶(hù)權(quán)限被關(guān)閉集成廠商推送SDK引導(dǎo)用戶(hù)開(kāi)啟自啟動(dòng)和通知權(quán)限4.2 排查思路與工具鏈有很多RN開(kāi)發(fā)者在排查問(wèn)題時(shí)不習(xí)慣用工具習(xí)慣性在console.log和debugger之間來(lái)回切效率很低。我建議至少配置好Flipper它能同時(shí)查看Metro日志、網(wǎng)絡(luò)請(qǐng)求、AsyncStorage內(nèi)容、React組件樹(shù)和JS錯(cuò)誤堆棧。Flipper雖然不是萬(wàn)能的但很多“為什么請(qǐng)求沒(méi)發(fā)出”“為什么狀態(tài)沒(méi)更新”這類(lèi)問(wèn)題在Flipper里一眼就能看到。如果你用的是Expo開(kāi)發(fā)那Expo Go內(nèi)置的調(diào)試面板也夠用。但做國(guó)內(nèi)落地項(xiàng)目大多數(shù)時(shí)候還是要走bare workflow建議固定一套工具鏈Metro Flipper Android Studio Logcat Xcode Console。出現(xiàn)問(wèn)題先看Metro日志有沒(méi)有JS異常再看Logcat有沒(méi)有原生崩潰信息最后才在業(yè)務(wù)代碼里找線(xiàn)索。4.3 性能排查的經(jīng)驗(yàn)之談RN性能問(wèn)題常常不只在JS層原生層的布局計(jì)算和線(xiàn)程調(diào)度同樣是瓶頸。我自己排查RN性能問(wèn)題的順序是首先看JS線(xiàn)程的CPU占用。如果Redux狀態(tài)更新導(dǎo)致全組件樹(shù)重新渲染那就需要優(yōu)化selector或者說(shuō)用useSelector按片段訂閱。其次看UI線(xiàn)程的掉幀情況。RN的布局操作最終會(huì)傳到原生側(cè)如果你的UI層級(jí)過(guò)深或者使用大量陰影shadowUI線(xiàn)程很容易掉幀。最后看原生線(xiàn)程的開(kāi)銷(xiāo)。如果你的業(yè)務(wù)里大量使用bridge調(diào)用哪怕是新架構(gòu)的TurboModule那頻繁跨線(xiàn)程通信本身就會(huì)帶來(lái)性能損失。這里給一個(gè)很實(shí)用的調(diào)優(yōu)技巧在開(kāi)發(fā)模式下RN的JS線(xiàn)程性能會(huì)比生產(chǎn)模式差很多因?yàn)殚_(kāi)發(fā)模式多了很多警告和檢查。所以做性能測(cè)試一定要用release包別在開(kāi)發(fā)模式下測(cè)測(cè)出來(lái)的數(shù)據(jù)不能反映線(xiàn)上水平。4.4 團(tuán)隊(duì)協(xié)作層面的兩個(gè)建議落實(shí)到團(tuán)隊(duì)長(zhǎng)期維護(hù)RN項(xiàng)目還有兩個(gè)容易被忽視的建議。第一個(gè)把依賴(lài)升級(jí)做成例行機(jī)制。RN生態(tài)更新很快第三方庫(kù)也跟著變。建議每季度做一次依賴(lài)升級(jí)升級(jí)后重點(diǎn)回歸啟動(dòng)、導(dǎo)航、列表、網(wǎng)絡(luò)這四個(gè)模塊。如果長(zhǎng)期不升級(jí)技術(shù)債越積越多等哪天被迫升級(jí)時(shí)工作量會(huì)讓你崩潰。第二個(gè)沉淀自己的代碼模板和腳手架。不要每次開(kāi)新項(xiàng)目都從零配置react-native init。建議花點(diǎn)時(shí)間做一個(gè)團(tuán)隊(duì)的starter kit內(nèi)置好導(dǎo)航、狀態(tài)管理、網(wǎng)絡(luò)層、鑒權(quán)邏輯、UI基礎(chǔ)組件、埋點(diǎn)上報(bào)這些基礎(chǔ)能力。這樣新項(xiàng)目啟動(dòng)時(shí)會(huì)非常快而且能保證不同項(xiàng)目之間的代碼結(jié)構(gòu)一致方便人員流動(dòng)和交接。寫(xiě)在最后的一些個(gè)人體會(huì)帶了好幾個(gè)RN項(xiàng)目下來(lái)我自己最深的感受是React Native生態(tài)不是缺庫(kù)反而是過(guò)于豐富豐富的選擇本身就構(gòu)成了成本。真正考驗(yàn)團(tuán)隊(duì)的不是會(huì)用一兩個(gè)熱門(mén)庫(kù)而是能不能在紛繁復(fù)雜的生態(tài)里做減法選出一套最適合自己業(yè)務(wù)場(chǎng)景的穩(wěn)定組合。另外國(guó)內(nèi)RN開(kāi)發(fā)者和海外RN開(kāi)發(fā)者的經(jīng)驗(yàn)參考體系其實(shí)差別很大。海外的教程和模板默認(rèn)你生活在有Google服務(wù)、網(wǎng)絡(luò)順暢的環(huán)境里很多方案直接套到國(guó)內(nèi)項(xiàng)目上就跑不通。所以國(guó)內(nèi)團(tuán)隊(duì)在做技術(shù)調(diào)研時(shí)一定要額外關(guān)注“這個(gè)庫(kù)在本地網(wǎng)絡(luò)環(huán)境下是否可用”這一項(xiàng)。把這個(gè)因素前置到選型階段能省下后面大量的適配和填坑時(shí)間。最后再分享一個(gè)小技巧RN項(xiàng)目的node_modules目錄越來(lái)越大但很多依賴(lài)根本沒(méi)用上只是被npm解析進(jìn)來(lái)了。每次升級(jí)完依賴(lài)后記得跑一下npx react-native bundle --platform android --dev false --entry-file index.js --bundle-output androidApp.bundle然后看看這個(gè)文件的大小。如果bundle體積膨脹得很厲害說(shuō)明你引入了太多不必要的東西該做代碼分割了。React Native這個(gè)生態(tài)還會(huì)繼續(xù)往前演進(jìn)新架構(gòu)、靜態(tài)框架、IDE支持都在迭代。但不管底層怎么變做好基礎(chǔ)工程、保持依賴(lài)整潔、理解底層的原生機(jī)制這三件事始終不會(huì)過(guò)時(shí)。希望這篇內(nèi)容能幫你在RN生態(tài)里找到屬于自己的那條路。