《開源鴻蒙跨平臺(tái)開發(fā)先鋒訓(xùn)練營(yíng)》走到第 10 天這批學(xué)員已經(jīng)從“Hello World”一路寫到了真機(jī)聯(lián)調(diào)。今天這一課我們把過(guò)去兩天反復(fù)提到的 React Native for OpenHarmony 實(shí)戰(zhàn)拉滿目標(biāo)非常直接用一套 React Native 代碼同時(shí)跑通 OpenHarmony 手機(jī)、平板和 RK3568 開發(fā)板布局不亂、交互不崩、現(xiàn)場(chǎng)不出事故。說(shuō)實(shí)話訓(xùn)練營(yíng)前 9 天里大家問(wèn)得最多的不是“ArkUI 怎么寫”而是“我們團(tuán)隊(duì)現(xiàn)有 RN 資產(chǎn)到底能不能低成本平移過(guò)來(lái)”。所以 Day 10 沒(méi)有去硬推全量 ArkUI 重構(gòu)而是帶著大家實(shí)操了一輪多端響應(yīng)式布局和高可用交互設(shè)計(jì)把真正會(huì)影響交付的問(wèn)題逐層拆開。這篇復(fù)盤寫給沒(méi)能到場(chǎng)的朋友也寫給即將在鴻蒙生態(tài)里落地的跨端團(tuán)隊(duì)內(nèi)容偏工程、偏落地每個(gè)環(huán)節(jié)我都會(huì)說(shuō)明當(dāng)時(shí)為什么這么選以及我們踩過(guò)的坑。1. 整體思路拆解為什么第 10 天要重點(diǎn)啃布局和交互1.1 訓(xùn)練營(yíng)后半程的真實(shí)困惑大家卡在選型而不是寫法到第 9 天結(jié)束訓(xùn)練營(yíng)里 20 多個(gè)小組基本都有了可運(yùn)行的頁(yè)面但 80% 的問(wèn)題集中在同一個(gè)點(diǎn)上OpenHarmony 應(yīng)用到底應(yīng)該用 ArkUI 從零寫還是用 React Native 兼容層直接復(fù)用業(yè)務(wù)代碼這個(gè)問(wèn)題不只是新手在問(wèn)連幾個(gè)做工業(yè)屏的團(tuán)隊(duì)也在猶豫。他們的存量代碼是 React Native團(tuán)隊(duì)對(duì) JS/TS 更熟如果全部切到 ArkUI 重寫一兩個(gè)月的排期根本扛不住。Day 10 的核心目標(biāo)就是讓這批人親眼看到“RN 代碼跑在 OpenHarmony 真機(jī)上”不是演示視頻里的特效而是一條有章可循的生產(chǎn)路徑。但選型不是“能不能跑”這么簡(jiǎn)單。訓(xùn)練營(yíng)里我們反復(fù)問(wèn)大家如果明天就要上生產(chǎn)你的應(yīng)用要同時(shí)適配手機(jī)豎屏、平板橫屏和 RK3568 這類帶觸摸的工控屏你現(xiàn)有的布局代碼禁不禁得住交互上遇到弱網(wǎng)、網(wǎng)絡(luò)斷開、用戶狂點(diǎn)按鈕頁(yè)面會(huì)不會(huì)直接變白或卡死坦白講很多同學(xué)之前只考慮過(guò)“功能通不通”沒(méi)考慮過(guò)“狀態(tài)穩(wěn)不穩(wěn)、布局碎不碎”。這也是我們把第 10 天教案設(shè)計(jì)成“多端響應(yīng)式布局 高可用交互設(shè)計(jì)”兩個(gè)重頭戲的原因它們不是錦上添花而是從 Demo 走向真實(shí)設(shè)備時(shí)必須跨過(guò)去的兩道坎。1.2 React Native for OpenHarmony 的架構(gòu)邏輯以及它適合誰(shuí)先給還沒(méi)接觸過(guò) RNOH 的朋友打個(gè)底。React Native for OpenHarmony 本質(zhì)上不是另起爐灶的新框架而是把 React Native 的運(yùn)行時(shí)、渲染邏輯和原生能力接入 OpenHarmony 的適配層。你可以把它理解成“給 JavaScript 大腦裝上一具 OpenHarmony 身體”業(yè)務(wù)代碼仍然是 React 組件、仍然是 Flexbox 布局、仍然走 RN 的狀態(tài)管理和事件體系但在底層視圖層級(jí)要映射成鴻蒙的 ArkUI 組件網(wǎng)絡(luò)、存儲(chǔ)、藍(lán)牙這些能力也要通過(guò)原生模塊橋接過(guò)去。所以它不是一個(gè)黑盒它是 RN 生態(tài)與 OpenHarmony 系統(tǒng)之間的一條雙向通路。理解這一點(diǎn)你就明白為什么我們用 RNOH 做跨端而不是簡(jiǎn)單套個(gè) WebView也不是要求所有人推翻重來(lái)。RNOH 的優(yōu)勢(shì)在于前端和 RN 團(tuán)隊(duì)能保留大量既有代碼社區(qū)里的通用組件邏輯也能直接復(fù)用劣勢(shì)則在于生態(tài)遠(yuǎn)沒(méi)有 Android 和 iOS 那邊成熟很多組件需要自己補(bǔ)原生實(shí)現(xiàn)遇到問(wèn)題時(shí)你能查到的現(xiàn)成資料也少。Day 10 面對(duì)的這批學(xué)員大多數(shù)是“有 RN 基礎(chǔ)、想快速覆蓋鴻蒙設(shè)備”的開發(fā)者RNOH 就是性價(jià)比最高的路徑。反過(guò)來(lái)說(shuō)如果項(xiàng)目零基礎(chǔ)、只做 OpenHarmony 單端那直接學(xué) ArkUI 也很合理沒(méi)必要為了跨端而跨端。1.3 這一天的交付物一個(gè)可復(fù)現(xiàn)的“跨端工作臺(tái) Demo”訓(xùn)練營(yíng)不能停在 PPT 上。Day 10 的實(shí)操目標(biāo)是讓每個(gè)小組把一個(gè)模擬業(yè)務(wù)頁(yè)面“跨端工作臺(tái)”跑通到三臺(tái)設(shè)備上。這個(gè)場(chǎng)景刻意做成偏企業(yè)內(nèi)部工具的樣子頂部是狀態(tài)概覽中間是任務(wù)列表和統(tǒng)計(jì)卡片底部有操作按鈕。頁(yè)面要滿足三個(gè)驗(yàn)收條件第一在手機(jī)豎屏下是單列流式布局底部放導(dǎo)航第二在平板或開發(fā)板寬屏下自動(dòng)切成側(cè)邊欄加內(nèi)容區(qū)卡片能排多列第三所有按鈕在弱網(wǎng)、重復(fù)點(diǎn)擊、接口報(bào)錯(cuò)時(shí)都有明確反饋不能白屏、不能讓用戶以為手機(jī)死了。這個(gè)交付物定得并不炫技但它幾乎覆蓋了生產(chǎn)環(huán)境最常見(jiàn)的需求。窄屏和寬屏之間的布局切換考察的是對(duì)尺寸斷點(diǎn)、柵格和 Flexbox 的掌握交互可靠性則考察狀態(tài)管理、防抖節(jié)流、異常兜底。最后每組都要交一份真機(jī)運(yùn)行的錄屏和一個(gè)自查清單?？雌饋?lái)任務(wù)量不大實(shí)際動(dòng)手時(shí)大家才發(fā)現(xiàn)跨端布局的“最后一公里”往往不是代碼邏輯寫不出來(lái)而是各種設(shè)備尺寸、系統(tǒng)字體、導(dǎo)航條避讓和狀態(tài)時(shí)序的細(xì)節(jié)問(wèn)題。這些細(xì)節(jié)正是后面幾節(jié)要展開講的內(nèi)容。2. 工程化基線先搭一個(gè)跑得穩(wěn)的 RNOH 多端工程2.1 初始化工程的推薦路徑與依賴骨架很多同學(xué)第一次跑 RNOH 項(xiàng)目時(shí)是按“Android 工程 Metro”的老思路去猜目錄結(jié)構(gòu)結(jié)果卡在入口加載上。實(shí)際 RNOH 工程至少包含兩層OpenHarmony 側(cè)的 ArkTS 工程負(fù)責(zé)應(yīng)用安裝與生命周期RN 側(cè)的 JS 業(yè)務(wù)代碼打包成 bundle 后由原生側(cè)加載。以 DevEco Studio 創(chuàng)建工程為例你會(huì)得到一個(gè)基于 hvigor 構(gòu)建的 OpenHarmony 應(yīng)用然后在entry模塊里通過(guò) ohpm 引入對(duì)應(yīng) RN 版本的 react-native-harmony 適配包。這里有個(gè)容易搞混的點(diǎn)RN 適配包的版本號(hào)通常要和你的 RN 版本嚴(yán)格對(duì)應(yīng)否則原生橋接層會(huì)跑飛。訓(xùn)練營(yíng)里我們統(tǒng)一鎖了一組經(jīng)過(guò)驗(yàn)證的版本組合避免大家各自試錯(cuò)。構(gòu)建時(shí)建議用 release 模式生成離線 bundle把產(chǎn)物放到 OpenHarmony 側(cè)的 rawfile 目錄下這樣應(yīng)用啟動(dòng)后不依賴 Metro 服務(wù)也能加載。調(diào)試階段可以連 Metro 熱更新但交付演示時(shí)一定要用離線包原因后面第 5 節(jié)講白屏問(wèn)題時(shí)會(huì)提到。整個(gè) RN 代碼工程和 OpenHarmony 宿主工程可以放在同一個(gè)倉(cāng)庫(kù)的不同目錄里用腳本統(tǒng)一構(gòu)建也可以拆成兩個(gè)倉(cāng)庫(kù)CI 里先打 bundle 再打 hap。訓(xùn)練營(yíng)采用前者主要是因?yàn)閷W(xué)員機(jī)器配置參差拆開倉(cāng)庫(kù)容易把環(huán)境問(wèn)題搞復(fù)雜。2.2 開發(fā)工具怎么分工DevEco 與 AI 輔助編程工具各干各的有學(xué)員問(wèn)“Trae 能開發(fā)鴻蒙應(yīng)用嗎”這實(shí)際上是沒(méi)分清“寫鴻蒙原生應(yīng)用”和“開發(fā) RNOH 混合項(xiàng)目”。Trae 這類 AI 輔助工具當(dāng)然可以幫你寫 React Native 組件、業(yè)務(wù)邏輯、狀態(tài)管理代碼因?yàn)樗鼈儽举|(zhì)上是 JS/TS 技術(shù)棧但 OpenHarmony 宿主工程里的 Ability 配置、module.json5、權(quán)限聲明、設(shè)備簽名和 hvigor 構(gòu)建還是離不開 DevEco Studio 的項(xiàng)目上下文。你在 DevEco 里能直接查看系統(tǒng)接口、運(yùn)行 hdc 命令、完成簽名安裝AI 工具目前還很難替代這部分和系統(tǒng) SDK 強(qiáng)綁定的操作。所以在訓(xùn)練營(yíng)里我們的建議是把兩者配合使用復(fù)雜業(yè)務(wù)組件、布局適配、工具函數(shù)交給 AI 輔助工具快速生成再回到 DevEco 里真機(jī)聯(lián)調(diào)。真機(jī)上出現(xiàn)的原生錯(cuò)誤、日志、崩潰棧還是得靠 DevEco 的 Log 面板和 hdc 命令來(lái)定位不能全靠 AI 猜。工具鏈沒(méi)有誰(shuí)取代誰(shuí)的問(wèn)題關(guān)鍵是讓每一環(huán)都待在它最擅長(zhǎng)的位置。2.3 多端差異別撒得到處都是收攏到適配層跨端工程最容易爛的地方就是業(yè)務(wù)代碼里到處寫if (設(shè)備A) ... else if (設(shè)備B) ...。今天加一個(gè)設(shè)備特判明天加一個(gè)平臺(tái)分支半個(gè)月后沒(méi)人敢動(dòng)那段代碼。Day 10 開始前我們專門強(qiáng)調(diào)了一個(gè)工程約束所有設(shè)備差異必須收攏到一個(gè)統(tǒng)一的適配層里業(yè)務(wù)頁(yè)面只能依賴適配層暴露的 hook 或組件不能自己去讀設(shè)備型號(hào)。這個(gè)適配層在代碼上可以做成一個(gè)useDeviceAdaptorHook集中處理四類信息當(dāng)前屏幕寬高與安全區(qū)、當(dāng)前斷點(diǎn)類型compact/medium/expanded、設(shè)備類型手機(jī)/平板/開發(fā)板、操作系統(tǒng)是否啟用了字體縮放。這樣做的價(jià)值會(huì)在你真正接到“適配 RK3568 一塊 1280x800 觸屏”的需求時(shí)體現(xiàn)出來(lái)。因?yàn)闃I(yè)務(wù)代碼不需要知道屏幕到底是多少像素只需要根據(jù)斷點(diǎn)類型去調(diào)整柵格列數(shù)和導(dǎo)航形態(tài)。后續(xù)如果新增一臺(tái)豎屏設(shè)備也只需要適配層去適配不影響幾十個(gè)業(yè)務(wù)頁(yè)面。3. 多端響應(yīng)式布局核心細(xì)節(jié)一套布局如何在三端都不亂3.1 從 dp、vp 到邏輯像素別再按物理像素寫界面了訓(xùn)練營(yíng)里第一個(gè)讓人翻車的知識(shí)點(diǎn)是尺寸單位。許多從 Web 轉(zhuǎn)過(guò)來(lái)的同學(xué)習(xí)慣了 px 思維在 RN 代碼里直接寫width: 300主觀上覺(jué)得“反正 RN 會(huì)適配”。實(shí)際上 RN 的寬度數(shù)字會(huì)映射到 OpenHarmony 的 vpvirtual pixel體系而 vp 在真機(jī)上會(huì)根據(jù)屏幕密度做縮放。你在設(shè)計(jì)稿里量出來(lái)的是物理像素直接填進(jìn)代碼往往會(huì)發(fā)現(xiàn)開發(fā)板上字特別小、手機(jī)上按鈕看不全原因是開發(fā)板的密度和手機(jī)密度差異很大。正確的做法是徹底放棄物理像素直覺(jué)堅(jiān)持使用邏輯像素、Flexbox、百分比和間距常量。訓(xùn)練營(yíng)里我們強(qiáng)制大家把設(shè)計(jì)稿里的尺寸除以密度系數(shù)再落到代碼里同時(shí)把 4、8、12、16、24 這類間距做成常量避免到處出現(xiàn)“看起來(lái)差不多”的魔數(shù)。這里順便補(bǔ)一句如果需要把邏輯像素轉(zhuǎn)回物理像素做判斷可以用PixelRatio.get()但頻繁使用說(shuō)明布局思路可能有問(wèn)題應(yīng)該回到結(jié)構(gòu)層去解決。3.2 斷點(diǎn)體系與柵格策略別讓 600px 和 800px 成為硬編碼多端響應(yīng)式布局不是“檢測(cè)到橫屏就切換樣式”而是要建立一套斷點(diǎn)體系。我們參考 Material Design 的斷點(diǎn)思路結(jié)合訓(xùn)練營(yíng)設(shè)備情況把屏幕寬度劃成三檔小于 600 邏輯像素是 compact手機(jī)/窄屏600 到 840 是 medium小平板或折疊屏展開態(tài)大于 840 是 expanded平板橫屏、開發(fā)板寬屏。為了讓斷點(diǎn)判斷可復(fù)用我寫了一個(gè)useBreakpointHook內(nèi)部監(jiān)聽useWindowDimensions()并且把系統(tǒng)字體縮放因子考慮進(jìn)去。為什么要除字體縮放因?yàn)橛脩舭严到y(tǒng)字體調(diào)大后同樣的邏輯像素寬度能顯示的內(nèi)容會(huì)變少布局應(yīng)該自動(dòng)降級(jí)而不是把文案擠到換行。柵格策略同樣基于斷點(diǎn)。compact 態(tài)下內(nèi)容區(qū)是單列卡片之間用縱向間距操作按鈕常駐底部medium 態(tài)可以排兩列expanded 態(tài)則可以排到四列同時(shí)把低頻信息放到側(cè)欄。這里有一個(gè)經(jīng)驗(yàn)斷點(diǎn)判斷只作為“布局框架”的依據(jù)不要試圖用它精確控制每一個(gè)卡片的像素。Flexbox 負(fù)責(zé)彈性填充斷點(diǎn)只決定列數(shù)和導(dǎo)航形態(tài)兩者結(jié)合才不會(huì)出現(xiàn)拉伸變形。export type Breakpoint compact | medium | expanded; export function useBreakpoint(): Breakpoint { const { width } useWindowDimensions(); const fontScale PixelRatio.getFontScale(); const effectiveWidth width / fontScale; if (effectiveWidth 600) return compact; if (effectiveWidth 840) return medium; return expanded; }3.3 窄屏切頁(yè)簽、寬屏切側(cè)欄一個(gè)能直接套用的響應(yīng)式組合這次訓(xùn)練營(yíng)的實(shí)戰(zhàn)案例是一個(gè)“跨端工作臺(tái)”。我沒(méi)讓學(xué)員一上來(lái)就寫復(fù)雜動(dòng)效而是先把頁(yè)面骨架做到符合業(yè)務(wù)直覺(jué)窄屏下如果強(qiáng)行放側(cè)欄可用內(nèi)容區(qū)只有 300 多邏輯像素寬操作起來(lái)非常局促寬屏下如果全部做成單列滾動(dòng)信息密度又太低。正確的方案是讓同一個(gè)頁(yè)面根據(jù)斷點(diǎn)渲染成兩種形態(tài)。export default function WorkbenchScreen() { const bp useBreakpoint(); if (bp compact) { return CompactWorkbench /; } return ExpandedWorkbench /; }在ExpandedWorkbench里外層一行用 Flexbox左側(cè)是 Sidebar右側(cè)是內(nèi)容區(qū)。內(nèi)容區(qū)里的統(tǒng)計(jì)卡片寬度通過(guò)flexBasis按列數(shù)分配比如四列就設(shè)置flexBasis: 25%每張卡片再留 8 到 12 的邏輯像素間距。這樣在 1280x800 的開發(fā)板橫屏上卡片不會(huì)因?yàn)槊芏葐?wèn)題擠成一團(tuán)當(dāng)系統(tǒng)字體調(diào)大導(dǎo)致有效寬度降到 840 以下時(shí)斷點(diǎn)會(huì)降級(jí)成 medium列數(shù)自動(dòng)減到兩列。這套組合在代碼上不復(fù)雜真正的難點(diǎn)是找到一個(gè)通用的“布局切換時(shí)機(jī)”。我們用useWindowDimensions()而不是啟動(dòng)時(shí)讀一次寬高就是為了讓旋轉(zhuǎn)屏幕、分屏、窗口大小變化時(shí)能即時(shí)重新渲染。RNOH 上這個(gè) Hook 是可靠的但要注意不要把它放在每個(gè)小組件里都調(diào)用否則一旋轉(zhuǎn)會(huì)導(dǎo)致大量組件重渲染。更好的做法是只在頁(yè)面容器層調(diào)用通過(guò) props 或 context 把斷點(diǎn)類型傳給子組件。3.4 安全區(qū)、劉海與底部導(dǎo)航條不處理就會(huì)被系統(tǒng)吃掉一塊手機(jī)有挖孔屏和底部導(dǎo)航條平板和 RK3568 開發(fā)板也有各自的系統(tǒng)避讓區(qū)域。很多同學(xué)寫布局時(shí)沒(méi)有考慮安全區(qū)結(jié)果頁(yè)面底部按鈕被系統(tǒng)導(dǎo)航條擋住一半點(diǎn)擊區(qū)域完全失效。RN 標(biāo)準(zhǔn)庫(kù)里的 SafeAreaView 在部分 OpenHarmony 設(shè)備上表現(xiàn)并不一致所以我們選擇在適配層自己算安全區(qū)再注入給業(yè)務(wù)組件。實(shí)現(xiàn)思路比較簡(jiǎn)單OpenHarmony 原生側(cè)拿到窗口的避讓區(qū)域avoidArea通過(guò)一個(gè)原生模塊把上、下、左、右的避讓值傳給 RN 側(cè)RN 側(cè)用 Provider 保存這些值業(yè)務(wù)組件再根據(jù)斷點(diǎn)應(yīng)用到外層 padding。這樣既不會(huì)一刀切地把所有設(shè)備都套用 iPhone 那套安全區(qū)值又能覆蓋帶物理導(dǎo)航鍵的開發(fā)板。實(shí)際測(cè)試中RK3568 這塊板子如果跑的是帶虛擬導(dǎo)航條的鏡像底部避讓值甚至可能是 0但觸摸區(qū)域距離邊緣很近手指操作時(shí)容易誤觸返回手勢(shì)。這種場(chǎng)景不能只依賴安全區(qū)還需要在交互設(shè)計(jì)上給底部操作留出足夠的外邊距。3.5 圖標(biāo)與字體官方庫(kù)再豐富也要注意渲染路徑訓(xùn)練營(yíng)里有人問(wèn)“OpenHarmony 官方是不是推出了 lucide 風(fēng)格的圖標(biāo)庫(kù)”確實(shí)看到過(guò)相關(guān)討論也有人在 ArkUI 原生工程里接入 Lucide 圖標(biāo)。但在 RNOH 場(chǎng)景下圖標(biāo)方案不能簡(jiǎn)單照搬。RN 這邊的react-native-vector-icons依賴的是字體文件注冊(cè)RNOH 對(duì)字體的加載方式還不完全等同 Android訓(xùn)練營(yíng)里出現(xiàn)過(guò)圖標(biāo)顯示成方塊的案例。遇到這種情況先別急著懷疑圖標(biāo)庫(kù)本身用 hdc 拉日志看字體是否 mount 成功。更穩(wěn)妥的做法是把圖標(biāo)問(wèn)題放到原生層去解決通過(guò)自定義原生組件暴露一個(gè)圖標(biāo)組件給 RN 側(cè)使用。ArkUI 的SymbolGlyph或Image加載 SVG 都比較成熟原生側(cè)按圖標(biāo)名渲染RN 側(cè)只傳名稱和尺寸。這樣既能享受新圖標(biāo)庫(kù)的設(shè)計(jì)風(fēng)格又避開了“RN 字體映射不完整”的坑。字體大小同樣要注意開啟系統(tǒng)字體縮放適配否則用戶調(diào)大系統(tǒng)字號(hào)后固定字號(hào)標(biāo)題會(huì)和卡片布局打架。4. 高可用交互設(shè)計(jì)用戶點(diǎn)下去那一下絕不能出事4.1 點(diǎn)得中、錯(cuò)不了觸摸熱區(qū)與點(diǎn)擊反饋高可用交互第一條也是最容易被視覺(jué)稿忽略的一條用戶能不能準(zhǔn)確點(diǎn)中目標(biāo)。開發(fā)板上手掌誤觸概率比手機(jī)高得多按鈕如果只按視覺(jué)尺寸做實(shí)際熱區(qū)會(huì)非常小。RN 里最簡(jiǎn)單的解法是用hitSlop擴(kuò)大觸摸熱區(qū)。比如一個(gè)刪除圖標(biāo)看起來(lái)只有 24x24可以給它上下左右各加 10 個(gè)邏輯像素的隱形熱區(qū)同時(shí)在按下時(shí)給背景色或透明度反饋。我們要求所有可點(diǎn)擊元素的視覺(jué)面積不小于 44x44如果設(shè)計(jì)上做不到就用hitSlop和透明內(nèi)邊距補(bǔ)足。點(diǎn)擊反饋也不能只是“好看”。在工控屏場(chǎng)景里用戶按下后如果沒(méi)有任何狀態(tài)變化會(huì)下意識(shí)再點(diǎn)一次反而容易造成重復(fù)操作。訓(xùn)練營(yíng)要求每個(gè)按鈕都必須有 pressed 狀態(tài)下的視覺(jué)變化不論是顏色加深還是縮放動(dòng)畫必須讓用戶感知到“系統(tǒng)已經(jīng)接收到這次點(diǎn)擊”。這一點(diǎn)對(duì) RNOH 同樣成立Pressable組件的style回調(diào)里可以根據(jù)pressed屬性動(dòng)態(tài)切換樣式實(shí)現(xiàn)成本很低。4.2 加載、空、錯(cuò)三態(tài)封裝把頁(yè)面從“白屏恐懼”里救出來(lái)很多頁(yè)面在真實(shí)環(huán)境中失敗不是因?yàn)楣δ軟](méi)實(shí)現(xiàn)而是因?yàn)闆](méi)有異常態(tài)。請(qǐng)求發(fā)出去后轉(zhuǎn)圈 2 秒接口報(bào)錯(cuò)后頁(yè)面直接空白用戶就會(huì)以為應(yīng)用壞了。訓(xùn)練營(yíng)里我們強(qiáng)制大家給所有異步頁(yè)面統(tǒng)一封裝一個(gè)RequestView組件把頁(yè)面狀態(tài)分成四類loading、error、empty、content。組件接收狀態(tài)和回調(diào)loading 時(shí)顯示骨架屏或加載指示器error 時(shí)顯示錯(cuò)誤信息和重試按鈕empty 時(shí)給引導(dǎo)文案content 時(shí)才渲染真正的業(yè)務(wù)內(nèi)容。type RequestViewProps { status: loading | error | empty | content; errorText?: string; onRetry?: () void; children?: React.ReactNode; }; export function RequestView({ status, errorText, onRetry, children }: RequestViewProps) { if (status loading) { return LoadingIndicator /; } if (status error) { return ( View style{styles.centerBox} Text style{styles.message}{errorText || 加載失敗請(qǐng)檢查網(wǎng)絡(luò)后重試}/Text {onRetry ? ( Pressable style{styles.retryBtn} onPress{onRetry} Text style{styles.retryText}重新加載/Text /Pressable ) : null} /View ); } if (status empty) { return EmptyView /; } return {children}/; }這套封裝的直接收益是“啟動(dòng)白屏”問(wèn)題至少能在應(yīng)用層被攔住。RNOH 應(yīng)用啟動(dòng)需要加載 JS bundle這個(gè)過(guò)程如果什么界面都沒(méi)有用戶看到的就是一塊白屏。我們訓(xùn)練營(yíng)里要求啟動(dòng)階段用原生側(cè)的能力先展示應(yīng)用閃屏或骨架等 RN 實(shí)例 ready 后再切到業(yè)務(wù)頁(yè)面。這個(gè)白屏問(wèn)題的排查細(xì)節(jié)我會(huì)在第 5.1 節(jié)展開講但交互設(shè)計(jì)上先把加載態(tài)做出來(lái)至少不會(huì)讓用戶在關(guān)鍵時(shí)刻面對(duì)一片空白。4.3 防重復(fù)點(diǎn)擊與操作冪等后端只能幫你兜底前端必須主動(dòng)擋業(yè)務(wù)頁(yè)面里最常見(jiàn)的事故是用戶連續(xù)點(diǎn)擊“提交”按鈕產(chǎn)生了兩條重復(fù)訂單或兩條重復(fù)數(shù)據(jù)。RN 的TouchableOpacity在onPress回調(diào)執(zhí)行完后并不會(huì)自動(dòng)禁用按鈕網(wǎng)絡(luò)慢的時(shí)候用戶很容易再點(diǎn)幾下。我們的標(biāo)準(zhǔn)做法是兩層防護(hù)第一層在按鈕組件里內(nèi)置isSubmitting狀態(tài)點(diǎn)擊后立刻把按鈕置為 disabled并把文案改成“提交中/處理中”第二層用一個(gè)useThrottledPressHook對(duì)高頻回調(diào)做節(jié)流。function useThrottledPress(handler: () void, ms 2000) { const lastTime useRef(0); return useCallback(() { const now Date.now(); if (now - lastTime.current ms) return; lastTime.current now; handler(); }, [handler, ms]); }需要注意的是第二層只是兜底不能替代后端冪等校驗(yàn)。因?yàn)榍岸嗽僭趺捶酪卜啦蛔【W(wǎng)絡(luò)請(qǐng)求超時(shí)后用戶刷新頁(yè)面再次提交。訓(xùn)練營(yíng)里我們讓學(xué)員用偽隨機(jī)字符串生成一個(gè)請(qǐng)求冪等鍵提交時(shí)帶上后端如果收到同樣冪等鍵就忽略重復(fù)請(qǐng)求這才是真正的“高可用”。前端防抖防止的是誤操作后端冪等解決的是網(wǎng)絡(luò)不確定性兩者缺一不可。4.4 弱網(wǎng)與設(shè)備離線的交互處理OpenHarmony 設(shè)備經(jīng)常跑在局域網(wǎng)環(huán)境尤其是 RK3568 這類開發(fā)板連接的可能是攝像頭、掃碼槍或工業(yè)設(shè)備。網(wǎng)絡(luò)抖動(dòng)、設(shè)備掉線、IP 地址變更都很常見(jiàn)。如果你只做一次 fetch失敗后彈個(gè)“網(wǎng)絡(luò)錯(cuò)誤”就結(jié)束用戶根本沒(méi)有恢復(fù)路徑。Day 10 的交互設(shè)計(jì)規(guī)范里我們把網(wǎng)絡(luò)異常分成三類處理超時(shí)類、連接失敗類、業(yè)務(wù)錯(cuò)誤類。超時(shí)和連接失敗時(shí)除了展示錯(cuò)誤態(tài)還要給“自動(dòng)重試倒計(jì)時(shí)”或“手動(dòng)重試按鈕”業(yè)務(wù)錯(cuò)誤則展示服務(wù)端返回的具體文案比如設(shè)備離線原因和處置建議。同時(shí)接口請(qǐng)求要支持取消。頁(yè)面已經(jīng)卸載時(shí)還在 setState 會(huì)導(dǎo)致警告嚴(yán)重時(shí)會(huì)引起原生側(cè)崩潰。我們用AbortController配合組件卸載標(biāo)記來(lái)取消已發(fā)請(qǐng)求具體寫法不復(fù)雜但必須養(yǎng)成習(xí)慣。RNOH 的 JS 引擎對(duì)AbortController的支持是足夠的真正容易出問(wèn)題的是原生側(cè)網(wǎng)絡(luò)模塊和 JS 層之間的事件監(jiān)聽沒(méi)有正確釋放所以自定義原生事件監(jiān)聽一定要在組件卸載時(shí)調(diào)用 remove避免內(nèi)存泄漏。4.5 無(wú)障礙與動(dòng)效高可用不只是“能用”還要“能感知”交互做完之后還要過(guò)一遍無(wú)障礙和動(dòng)效細(xì)節(jié)。開發(fā)板場(chǎng)景里可能接的是無(wú)障礙開關(guān)屏幕閱讀器需要能讀出按鈕含義普通用戶則需要通過(guò)動(dòng)效感知界面變化。RNOH 對(duì)accessibilityLabel的支持和 RN 基本一致訓(xùn)練營(yíng)要求每個(gè)圖標(biāo)按鈕、圖片按鈕必須設(shè)置語(yǔ)義化標(biāo)簽不能只放一個(gè)圖標(biāo)靠顏色區(qū)分。點(diǎn)擊動(dòng)效應(yīng)簡(jiǎn)短有力一般控制在 150 到 250 毫秒不要做需要等待超過(guò) 1 秒才能反饋的“炫技動(dòng)畫”在硬件配置一般的開發(fā)板上復(fù)雜動(dòng)效是掉幀重災(zāi)區(qū)。訓(xùn)練營(yíng)里也有學(xué)員查“React Native 如何實(shí)現(xiàn)循環(huán)滾輪”想做一個(gè)滾動(dòng)選擇器。RN 社區(qū)方案多數(shù)依賴原生滾輪實(shí)現(xiàn)在 RNOH 上直接移植不一定能跑。我們的建議是如果場(chǎng)景需要循環(huán)滾輪這類自定義交互組件優(yōu)先在 ArkUI 原生側(cè)實(shí)現(xiàn)一個(gè) Native Component再暴露給 RN而不是試圖用 ScrollView 強(qiáng)行模擬。動(dòng)效和手勢(shì)這一類對(duì)原生能力依賴較高的交互RNOH 的原則是“組件級(jí)復(fù)用原生側(cè)補(bǔ)強(qiáng)”硬用純 JS 方案去拼性能和手感都很難保證。5. 真機(jī)聯(lián)調(diào)實(shí)錄白屏、開發(fā)板設(shè)備樹與其他繞不開的坑5.1 啟動(dòng)白屏的排查流程按順序查別瞎試訓(xùn)練營(yíng)當(dāng)天的熱詞里出現(xiàn)“react native 啟動(dòng)白屏”實(shí)際項(xiàng)目里這也是攔路虎。處理這個(gè)問(wèn)題我給的排查順序非常固定。第一步先確認(rèn)應(yīng)用有沒(méi)有閃屏或啟動(dòng)圖如果連原生啟動(dòng)圖都沒(méi)有用戶看到白屏是必然的先補(bǔ)原生側(cè)啟動(dòng)界面再說(shuō)第二步檢查 RN bundle 是否成功生成并且放在了 rawfile 目錄下第三步查看應(yīng)用日志確認(rèn) RN instance 有沒(méi)有初始化完成第四步如果邏輯層已經(jīng)啟動(dòng)但界面是白的再看是不是頁(yè)面容器沒(méi)有正確掛載。這里有一個(gè)非常隱蔽的坑如果你構(gòu)建的是 debug 包RNOH 默認(rèn)會(huì)嘗試連接 Metro 開發(fā)服務(wù)器真機(jī)上如果連不上服務(wù)器它會(huì)等待超時(shí)后才嘗試加載本地 bundle這個(gè)過(guò)程在外界看起來(lái)就是長(zhǎng)時(shí)間白屏。訓(xùn)練營(yíng)里一個(gè)小組在 RK3568 上演示時(shí)遇到了這個(gè)情況現(xiàn)場(chǎng)看起來(lái)像“應(yīng)用崩了”其實(shí)日志里一直在打印連不上 Metro。解決辦法很簡(jiǎn)單演示環(huán)境一律構(gòu)建 release 離線包或者在原生配置里把加載模式設(shè)為 loadBundleFromRawFile不依賴 Metro。排查時(shí)按這個(gè)順序走能省掉大量無(wú)效操作。白屏階段優(yōu)先排查常見(jiàn)根因啟動(dòng)后無(wú)任何畫面原生啟動(dòng)圖與閃屏配置原生側(cè)缺失啟動(dòng)界面RN 實(shí)例未初始化hdc 日志、bundle 路徑離線包未生成或路徑錯(cuò)誤JS 層已執(zhí)行但無(wú) UI頁(yè)面容器掛載、組件渲染首屏組件異常、容器尺寸為 0長(zhǎng)時(shí)間白屏后恢復(fù)Metro 連接超時(shí)配置debug 包連不上開發(fā)服務(wù)器真機(jī)偶發(fā)白屏內(nèi)存占用、GPU 資源大圖、復(fù)雜嵌套導(dǎo)致資源不足5.2 RK3568 開發(fā)板鏡像與設(shè)備樹選擇別被“一堆 dts”嚇住很多人看到“openHarmony 的 rk3568 有許多設(shè)備樹到底咋選”這個(gè)問(wèn)題第一反應(yīng)是去翻內(nèi)核配置擔(dān)心選錯(cuò)設(shè)備樹后系統(tǒng)起不來(lái)。訓(xùn)練營(yíng)里我們用的是官方適配過(guò)的 RK3568 板卡原則上只要燒錄對(duì)應(yīng)的系統(tǒng)鏡像不需要手工選擇設(shè)備樹內(nèi)核在啟動(dòng)時(shí)會(huì)根據(jù)硬件檢測(cè)加載匹配的 dtb。真正需要你手動(dòng)處理設(shè)備樹的情況是板卡型號(hào)特殊、內(nèi)存顆粒不同、屏幕觸摸芯片不同或者你在自行編譯內(nèi)核這時(shí)才需要確認(rèn)設(shè)備樹與硬件匹配。如果你確實(shí)需要查看當(dāng)前系統(tǒng)加載的是哪個(gè)設(shè)備樹可以通過(guò)cat /proc/device-tree/model查看硬件型號(hào)字符串或者通過(guò)/sys/firmware/devicetree/下的目錄信息判斷。編譯內(nèi)核時(shí)dts 文件一般放在內(nèi)核源碼的arch/arm64/boot/dts/rockchip/目錄下有對(duì)應(yīng)板卡的 dts 文件比如官方 EVB 板、第三方核心板都會(huì)各有各的文件標(biāo)識(shí)。訓(xùn)練營(yíng)給的建議很實(shí)在學(xué)習(xí)階段不要為了“優(yōu)化性能”去亂動(dòng)設(shè)備樹先用官方統(tǒng)一鏡像跑通應(yīng)用等需要定制屏幕或外設(shè)時(shí)再拿著板卡型號(hào)和屏參去設(shè)備樹里做增量配置。RK3588 或其他型號(hào)的板子邏輯也一樣核心是先確認(rèn)硬件 model再找對(duì)應(yīng) dts而不是網(wǎng)上隨便下載一個(gè)。5.3 USB 與硬件外設(shè)調(diào)試從 libusb 到事件驅(qū)動(dòng)的封裝思路做工業(yè)屏的小組總會(huì)遇到 USB 外設(shè)讀取問(wèn)題。有同學(xué)直接在 RN 側(cè)調(diào)用 USBManager 和 libusb 的封裝結(jié)果發(fā)現(xiàn)設(shè)備插拔事件能監(jiān)聽到但異步讀取數(shù)據(jù)時(shí)經(jīng)常拿不到結(jié)果。這個(gè)問(wèn)題并不奇怪USB 數(shù)據(jù)讀取本身是持續(xù)數(shù)據(jù)流RN 側(cè)的 Promise 模型更適合“請(qǐng)求—響應(yīng)”式交互不適合處理“設(shè)備隨時(shí)上報(bào)”的流式事件。我們的建議是在 ArkUI 原生層寫一個(gè)獨(dú)立的 USB 服務(wù)負(fù)責(zé)設(shè)備枚舉、權(quán)限申請(qǐng)、數(shù)據(jù)讀取和錯(cuò)誤處理把數(shù)據(jù)通過(guò)事件通道持續(xù)推送給 RN 側(cè)RN 側(cè)只負(fù)責(zé)訂閱事件和展示狀態(tài)。這個(gè)思路和藍(lán)牙、串口外設(shè)的接入方式是一致的原生層做能力JS 層做狀態(tài)。訓(xùn)練營(yíng)現(xiàn)場(chǎng)還遇到過(guò)一個(gè)硬件級(jí)的坑開發(fā)板 USB 調(diào)試口數(shù)據(jù)線接觸不良hdc 一直無(wú)法連接設(shè)備。很多同學(xué)以為是系統(tǒng)鏡像的問(wèn)題折騰半天才發(fā)現(xiàn)是 USB 線只支持充電不支持?jǐn)?shù)據(jù)傳輸。排查這類問(wèn)題時(shí)先用hdc list targets看看設(shè)備在不在列表里如果不在換線、換接口、檢查驅(qū)動(dòng)三步走。開發(fā)板用 5V 供電不穩(wěn)時(shí)USB 外設(shè)也可能反復(fù)掉線最好用獨(dú)立供電的 USB Hub 給外設(shè)供電別把大功率設(shè)備直接插在開發(fā)板 USB 口上。5.4 Day 10 驗(yàn)收清單能過(guò)這份清單再談上線課程收尾時(shí)我們給了大家一份可以帶回團(tuán)隊(duì)用的驗(yàn)收清單這份清單不針對(duì)業(yè)務(wù)邏輯只針對(duì)“多端可用性”。第一同一個(gè) RN bundle 必須能在手機(jī)、平板和開發(fā)板真機(jī)上啟動(dòng)且啟動(dòng)階段不能出現(xiàn)超過(guò) 2 秒的白屏第二頁(yè)面寬度壓縮到 320 邏輯像素時(shí)不能出現(xiàn)橫向滾動(dòng)寬屏展開時(shí)按鈕高度不能小于 44第三所有異步頁(yè)面必須有加載中、空數(shù)據(jù)、錯(cuò)誤重試三種狀態(tài)第四連續(xù)點(diǎn)擊任何提交按鈕不會(huì)產(chǎn)生重復(fù)請(qǐng)求第五斷網(wǎng)或設(shè)備離線時(shí)頁(yè)面要給出可理解的提示并提供恢復(fù)路徑第六打開無(wú)障礙后關(guān)鍵按鈕能被屏幕閱讀器識(shí)別。這份清單聽起來(lái)簡(jiǎn)單但學(xué)員完成度并不高。Day 10 最后 40 分鐘我們只做一件事小組之間互相用這份清單“找茬”。結(jié)果很多組都在第一項(xiàng)就翻車不是手機(jī)白屏就是開發(fā)板顯示異常。問(wèn)題集中暴露是好事因?yàn)橛?xùn)練營(yíng)的目的不是讓大家看老師演示而是讓大家踩過(guò)、改過(guò)、記住。如果看完本文你也準(zhǔn)備在項(xiàng)目里落地 RNOH我建議你把這 6 條直接寫進(jìn)迭代 Definition of Done逐條過(guò)一遍比發(fā)布會(huì)前臨時(shí)救火要省心得多。訓(xùn)練營(yíng)這一天下來(lái)讓我最深的感觸是“跨端”不是把同樣的界面搬到不同屏幕上而是同一個(gè)功能在不同設(shè)備上都能被順暢地完成。React Native for OpenHarmony 的價(jià)值也正在于此它讓團(tuán)隊(duì)可以復(fù)用腦子里的業(yè)務(wù)邏輯但布局策略和交互細(xì)節(jié)必須重新敬畏每臺(tái)設(shè)備的真實(shí)約束。給學(xué)員重復(fù)最多的一句話還是那個(gè)樸素的道理用戶不在乎你底層用的是 ArkUI 還是 RNOH他只在乎點(diǎn)下去有沒(méi)有反應(yīng)、斷網(wǎng)了有沒(méi)有提示、換了一塊屏幕后界面還順不順手。把這幾件事做成默認(rèn)能力你的鴻蒙應(yīng)用才算真正具備進(jìn)入生產(chǎn)的底氣。