這兩年我一直有意把一些跨平臺(tái)項(xiàng)目往 OpenHarmony 上搬剛好遇到一個(gè)適合練手的場(chǎng)景數(shù)學(xué)練習(xí)。大概背景是我手上有一份用 React Native 寫(xiě)的口算練習(xí) Demo之前在 iOS 和 Android 上都跑得很順后來(lái)一次技術(shù)交流中看到 React Native for OpenHarmony 的適配層已經(jīng)能支撐常見(jiàn)業(yè)務(wù)組件就決定拿它做一次完整遷移實(shí)戰(zhàn)。這篇文章把整個(gè)過(guò)程拆開(kāi)講從工程初始化、功能實(shí)現(xiàn)到真機(jī)調(diào)試覆蓋我自己踩過(guò)也估計(jì)你們大概率會(huì)踩的坑。適合三類(lèi)人看已經(jīng)在 RN 上寫(xiě)過(guò)業(yè)務(wù)、想了解它能不能跑 OpenHarmony 的開(kāi)發(fā)者剛接觸 OpenHarmony、需要快速上手跨平臺(tái)方案的開(kāi)發(fā)者以及單純想找一個(gè)工具型 App 完整落地案例的學(xué)生。1. 項(xiàng)目定位與整體拆解1.1 數(shù)學(xué)練習(xí)這個(gè)場(chǎng)景為什么適合做實(shí)驗(yàn)田先說(shuō)業(yè)務(wù)背景。我要做的不是那種復(fù)雜題庫(kù)系統(tǒng)而是面向小學(xué)低年級(jí)的口算訓(xùn)練工具隨機(jī)出加減乘除題孩子輸入答案系統(tǒng)判斷對(duì)錯(cuò)一輪做完給正確率和用時(shí)錯(cuò)題自動(dòng)進(jìn)錯(cuò)題本。這類(lèi)應(yīng)用有個(gè)特點(diǎn)業(yè)務(wù)邏輯幾乎都集中在計(jì)算和狀態(tài)流轉(zhuǎn)上UI 以文本、按鈕、輸入框?yàn)橹鞑恍枰貓D、相機(jī)、高性能渲染這些重度原生能力。換句話說(shuō)它是典型的“邏輯驅(qū)動(dòng)型”應(yīng)用非常適合驗(yàn)證一個(gè)跨平臺(tái)框架在一個(gè)新系統(tǒng)上的成熟度。如果把應(yīng)用換成視頻剪輯或者帶大量自定義畫(huà)布的工具那 RN 適配層的壓力會(huì)大很多很多原生能力可能還沒(méi)鋪齊容易把框架短板全部暴露出來(lái)。數(shù)學(xué)練習(xí)不一樣它需要的組件無(wú)非是 View、Text、TextInput、FlatList、TouchableOpacity適配層只要把這些映射穩(wěn)了開(kāi)發(fā)體驗(yàn)和運(yùn)行效果就不會(huì)差。所以我說(shuō)它是 OpenHarmony 上做 RN 遷移的理想“小白鼠”項(xiàng)目。還有一個(gè)隱性好處教育類(lèi)工具對(duì) UI 動(dòng)態(tài)反饋要求高比如答對(duì)時(shí)背景閃綠、答錯(cuò)時(shí)抖動(dòng)這些動(dòng)畫(huà)用 RN 的 Animated 或 LayoutAnimation 就能處理不需要深入 ArkUI 寫(xiě)自定義動(dòng)畫(huà)。這樣我可以把精力放在驗(yàn)證跨平臺(tái)邏輯上而不是和系統(tǒng) UI 框架死磕。1.2 為什么不是直接用原生 ArkUI 開(kāi)發(fā)這個(gè)問(wèn)題我在動(dòng)手前問(wèn)過(guò)自己。如果團(tuán)隊(duì)里已經(jīng)有人熟悉 OpenHarmony 原生開(kāi)發(fā)直接上 ArkUI 肯定是最穩(wěn)的畢竟沒(méi)有中間層損耗。但我這邊的現(xiàn)實(shí)情況是核心業(yè)務(wù)代碼已經(jīng)用 React Native 寫(xiě)好團(tuán)隊(duì)對(duì) RN 生態(tài)也更熟ArkUI 雖然聲明式寫(xiě)起來(lái)不復(fù)雜但為了一個(gè)工具型應(yīng)用重新維護(hù)一套原生代碼成本并不劃算。更重要的是React Native for OpenHarmony 的適配方式不是套個(gè) WebView 的殼而是把 RN 的 JS 邏輯跑在系統(tǒng)自帶的 JS 引擎上再通過(guò)適配層把虛擬節(jié)點(diǎn)映射成 OpenHarmony 的原生組件。換句話說(shuō)業(yè)務(wù)層寫(xiě)的是 TypeScript / JavaScript渲染層走的是原生組件不是 HTML 頁(yè)面。這保證了性能下限和原生交互體驗(yàn)和傳統(tǒng)的 Hybrid 方案有本質(zhì)區(qū)別。當(dāng)然跨平臺(tái)不是免費(fèi)的。適配層目前還沒(méi)有覆蓋 iOS / Android 上的全部 API尤其是一些偏門(mén)原生模塊可能需要我寫(xiě)自定義原生橋接。而數(shù)學(xué)練習(xí)這個(gè)項(xiàng)目基本不碰這些偏門(mén)能力所以我只需要關(guān)注 RN 標(biāo)準(zhǔn)組件在 OpenHarmony 上的行為差異成本可控。1.3 功能范圍與版本規(guī)劃我給自己定的第一個(gè)版本功能清單如下模塊功能點(diǎn)優(yōu)先級(jí)出題引擎隨機(jī)生成加減乘除題支持難度分級(jí)P0答題交互輸入答案、提交、即時(shí)反饋P0練習(xí)會(huì)話每輪 10 題計(jì)時(shí)完成后統(tǒng)計(jì)正確率P0錯(cuò)題本自動(dòng)記錄錯(cuò)題支持重新練習(xí)P1歷史成績(jī)本地保存最近 20 條練習(xí)記錄P1設(shè)置頁(yè)選擇題型范圍、題目數(shù)量、是否計(jì)時(shí)P2我不建議第一個(gè)版本就把家長(zhǎng)端、老師端、云端同步全做進(jìn)去那會(huì)沖淡“驗(yàn)證 RN on OpenHarmony”這個(gè)主目標(biāo)。先把單機(jī)版跑通再把 P1、P2 功能加上整個(gè)項(xiàng)目節(jié)奏會(huì)舒服很多。2. 環(huán)境準(zhǔn)備與工程骨架搭建2.1 工具鏈準(zhǔn)備與版本搭配OpenHarmony 應(yīng)用開(kāi)發(fā)繞不開(kāi) DevEco Studio這是官方 IDE工程構(gòu)建、簽名、真機(jī)安裝都靠它。RN 側(cè)則需要 Node.js 環(huán)境以及社區(qū)提供的 OpenHarmony 適配腳手架和 npm 依賴(lài)包。動(dòng)手之前我建議先把以下工具裝齊Node.js建議 LTS 版本我這里用的是 18后面跑 Metro 和打包都要靠它DevEco Studio用當(dāng)前正式發(fā)布版本即可OpenHarmony SDK在 DevEco Studio 里通過(guò) SDK Manager 下載一臺(tái) OpenHarmony 真機(jī)或模擬器模擬器調(diào)試方便但有些硬件能力測(cè)不了。版本搭配是最容易被忽略的坑。RN 社區(qū)迭代快適配層一般會(huì)跟著 RN 版本走比如某個(gè)適配版本只支持某個(gè) RN 大版本。我一開(kāi)始圖省事直接裝最新版 RN結(jié)果適配包還沒(méi)跟上最后只能降級(jí)到受支持的版本。建議先查一下適配包說(shuō)明里寫(xiě)的“已支持 RN 版本范圍”再?zèng)Q定初始化用哪個(gè)模板別盲目追新。2.2 初始化工程把 RN 工程和 OpenHarmony 工程串起來(lái)這里有兩種路徑一種是從零創(chuàng)建用社區(qū)腳手架直接生成同時(shí)包含 RN 和 OpenHarmony 殼的工程另一種是已有 RN 工程再補(bǔ)一個(gè) OpenHarmony 工程接入。我這次因?yàn)槭诸^有舊 Demo走的是第二種。從零創(chuàng)建的大致命令是這樣以我用的腳手架版本為例具體命令名以你拉到的版本為準(zhǔn)npx react-native-ohos/generator-cli init MathPracticeApp --template react-native-ohos/template執(zhí)行完會(huì)生成一個(gè)同時(shí)包含harmony目錄和標(biāo)準(zhǔn) RN 目錄的工程。如果已有 RN 工程需要手動(dòng)在工程里加入 OpenHarmony 殼工程并把node_modules/react-native-ohos/...下對(duì)應(yīng)的底層庫(kù)引入殼工程。初始化完成后的第一件事不是急著寫(xiě)業(yè)務(wù)代碼而是先跑一個(gè)空模板確認(rèn) “RN 的 JS 層打包出來(lái)的 bundle 能被 OpenHarmony 殼加載”。這個(gè)環(huán)節(jié)通了后面所有開(kāi)發(fā)才有意義。我當(dāng)時(shí)第一次跑的時(shí)候卡在簽名上沒(méi)簽名裝不到真機(jī)模擬器又不穩(wěn)定折騰了小半天才把鏈路打通。2.3 工程結(jié)構(gòu)與目錄說(shuō)明生成后的工程結(jié)構(gòu)大致長(zhǎng)這樣MathPracticeApp ├── App.tsx # RN 業(yè)務(wù)入口 ├── harmony # OpenHarmony 殼工程 │ ├── entry │ │ ├── src/main/ets # 原生入口和橋接代碼 │ │ └── src/main/resources # 應(yīng)用圖標(biāo)、字符串等資源 │ ├── hvigorfile.ts # 構(gòu)建腳本 │ └── oh-package.json5 # 原生依賴(lài) ├── index.js ├── package.json └── tsconfig.json理解這個(gè)結(jié)構(gòu)的關(guān)鍵是RN 代碼是業(yè)務(wù)主體harmony目錄只是一個(gè)殼負(fù)責(zé)把應(yīng)用跑在 OpenHarmony 系統(tǒng)上并提供 JS 引擎和渲染橋接。日常開(kāi)發(fā)絕大部分時(shí)間在App.tsx和 src 目錄下的業(yè)務(wù)組件里度過(guò)不太需要?jiǎng)釉鷼?。有一點(diǎn)需要注意不要隨便改harmony目錄下的構(gòu)建文件名和包名配置。包名bundleName是 OpenHarmony 應(yīng)用的唯一標(biāo)識(shí)牽扯到安裝和更新我見(jiàn)過(guò)有人改了 bundleName 后舊數(shù)據(jù)讀不到排查半天才發(fā)現(xiàn)是包名變了AsyncStorage 的數(shù)據(jù)跟著失效。3. 數(shù)學(xué)練習(xí)核心功能設(shè)計(jì)與實(shí)現(xiàn)3.1 題目生成器避開(kāi)這幾個(gè)數(shù)學(xué)坑數(shù)學(xué)練習(xí)的靈魂是出題?？此坪?jiǎn)單實(shí)際需要考慮三個(gè)原則不能出現(xiàn)“不夠減”的減法、除法必須整除、不同運(yùn)算符難度要可控。如果忽略這些二年級(jí)小朋友練到一半發(fā)現(xiàn) 3 - 8 -5或者 7 ÷ 2 3.5產(chǎn)品就沒(méi)法用了。我實(shí)現(xiàn)了一個(gè)可配置的題目生成器核心思路是先確定運(yùn)算規(guī)則再根據(jù)規(guī)則生成合法數(shù)字interface Problem { id: string; left: number; right: number; operator: | - | × | ÷; answer: number; expression: string; } function generateProblem( maxNumber: number, operator: | - | × | ÷, ): Problem { const left Math.floor(Math.random() * (maxNumber 1)); const right Math.floor(Math.random() * maxNumber) 1; if (operator -) { // 保證結(jié)果不為負(fù) const a Math.max(left, right); const b Math.min(left, right); return { id: ${Date.now()}-${Math.random()}, left: a, right: b, operator, answer: a - b, expression: ${a} - $, }; } if (operator ÷) { // 通過(guò)“被除數(shù) 除數(shù) * 商”來(lái)構(gòu)造整除題 const divisor right; const quotient Math.floor(Math.random() * (maxNumber / divisor)) 1; const dividend divisor * quotient; return { id: ${Date.now()}-${Math.random()}, left: dividend, right: divisor, operator, answer: quotient, expression: ${dividend} ÷ ${divisor}, }; } // 加法和乘法直接算即可 const answer operator ? left right : left * right; return { id: ${Date.now()}-${Math.random()}, left, right, operator, answer, expression: ${left} ${operator} ${right}, }; }減法的關(guān)鍵是用Math.max和Math.min把兩個(gè)數(shù)對(duì)調(diào)從根上避免負(fù)數(shù)。除法的關(guān)鍵是用divisor * quotient反推出被除數(shù)而不是隨機(jī)出兩個(gè)數(shù)再用浮點(diǎn)數(shù)相除。順便提一句Math.random()的隨機(jī)性足夠出題用不需要用加密級(jí)隨機(jī)數(shù)別過(guò)度設(shè)計(jì)。出題引擎寫(xiě)完后我建議花十分鐘補(bǔ)幾個(gè)邊界測(cè)試比如maxNumber5時(shí)連續(xù)生成 200 題確認(rèn)沒(méi)有結(jié)果超范圍除法題確認(rèn)所有answer都是整數(shù)。這些測(cè)試雖然簡(jiǎn)單但能攔住后面改代碼時(shí)不小心的回歸。3.2 答題交互與校驗(yàn)邏輯答題界面這邊最需要小心的是輸入框和鍵盤(pán)。數(shù)學(xué)練習(xí)只需要數(shù)字輸入所以 TextInput 要設(shè)置keyboardTypenumeric。但注意在 OpenHarmony 的原生鍵盤(pán)適配還不是很完美的情況下numeric有時(shí)候會(huì)調(diào)起支持小數(shù)點(diǎn)的鍵盤(pán)孩子誤按小數(shù)點(diǎn)了就容易提交非法內(nèi)容。我的校驗(yàn)邏輯是把用戶(hù)輸入先用Number(input)轉(zhuǎn)換再用Number.isNaN排除異常值最后比較答案時(shí)用一個(gè)極小誤差閾值。為什么不用parseInt因?yàn)閜arseInt(12abc)會(huì)返回 12把用戶(hù)輸入的臟數(shù)據(jù)當(dāng)合法值處理了不適合做嚴(yán)格校驗(yàn)。function checkAnswer(problem: Problem, input: string): boolean { const value Number(input); if (Number.isNaN(value)) { return false; } return Math.abs(value - problem.answer) 1e-6; }提交后的反饋也要設(shè)計(jì)好。我這里做了三檔答對(duì)了按鈕變成綠色提示“正確”答錯(cuò)了按鈕抖一下顯示正確答案空提交直接忽略不判對(duì)也不判錯(cuò)。這里有個(gè)交互細(xì)節(jié)空提交不該消耗一次答題機(jī)會(huì)否則孩子誤觸就白白錯(cuò)了會(huì)打擊積極性。3.3 練習(xí)輪次與難度配置練習(xí)過(guò)程我定義成三個(gè)狀態(tài)ready準(zhǔn)備開(kāi)始、doing答題中、finished本輪結(jié)束。從doing到finished的切換條件是當(dāng)前題號(hào)達(dá)到總題數(shù)而不是用一個(gè)單獨(dú)的“結(jié)束”按鈕。這個(gè)設(shè)計(jì)更貼近實(shí)際使用孩子把最后一道題做完結(jié)果頁(yè)直接出現(xiàn)中間不需要額外操作。難度配置放在設(shè)置頁(yè)影響的是題目生成器參數(shù)。比如難度最大數(shù)字可用運(yùn)算符入門(mén)10、-基礎(chǔ)20、-、×進(jìn)階100、-、×、÷配置信息會(huì)在每次生成題目時(shí)傳入但我建議在做題中途不改難度。最簡(jiǎn)單的方式是每次點(diǎn)“開(kāi)始”時(shí)讀取一次配置鎖定到本輪上下文里。如果你用全局變量存難度做題中途孩子去設(shè)置頁(yè)切了難度當(dāng)前這輪題目就亂了。4. 狀態(tài)管理與數(shù)據(jù)持久化4.1 練習(xí)會(huì)話的狀態(tài)建模useState 還不夠一開(kāi)始我用三個(gè)useState分別存當(dāng)前題、答對(duì)數(shù)、計(jì)時(shí)器結(jié)果發(fā)現(xiàn)代碼很亂提交答案時(shí)需要同時(shí)更新題號(hào)、正確數(shù)、答案列表三個(gè) setState 經(jīng)常漏一個(gè)。后來(lái)我把一輪練習(xí)的所有狀態(tài)合并成一個(gè)對(duì)象用useReducer管理思路立刻清晰了。type SessionState { index: number; problems: Problem[]; answers: (string)[]; correctCount: number; startTime: number; elapsedSeconds: number; }; type Action | { type: START; problems: Problem[] } | { type: SUBMIT_ANSWER; answer: string; isCorrect: boolean } | { type: FINISH };SUBMIT_ANSWER時(shí)把index 1、correctCount、answers一并更新結(jié)果頁(yè)只需要讀取這一個(gè) state 對(duì)象UI 和邏輯完全對(duì)應(yīng)。不要小看這一步跨平臺(tái)項(xiàng)目最怕的就是業(yè)務(wù)狀態(tài)分散在多個(gè)useState里最后調(diào) UI 時(shí)互相打架。4.2 AsyncStorage 存取練習(xí)記錄OpenHarmony 適配層提供了 AsyncStorage 的兼容實(shí)現(xiàn)接口和 RN 端一致因此業(yè)務(wù)代碼不需要針對(duì)平臺(tái)寫(xiě)差異。我用它存兩樣?xùn)|西歷史成績(jī)列表和錯(cuò)題記錄。存儲(chǔ)層我做了一個(gè)很薄的封裝統(tǒng)一處理讀取、寫(xiě)入、JSON 序列化import AsyncStorage from react-native-async-storage/async-storage; const RECORD_KEY math_practice_records; export async function loadRecords(): PromisePracticeRecord[] { const raw await AsyncStorage.getItem(RECORD_KEY); if (!raw) return []; try { const parsed JSON.parse(raw); return Array.isArray(parsed) ? parsed : []; } catch (e) { return []; } } export async function appendRecord(record: PracticeRecord): Promisevoid { const list await loadRecords(); list.push(record); // 只保留最近 20 條避免內(nèi)容無(wú)限膨脹 const trimmed list.slice(-20); await AsyncStorage.setItem(RECORD_KEY, JSON.stringify(trimmed)); }這里有個(gè)容易踩的坑AsyncStorage 的讀寫(xiě)是異步的如果連續(xù)快速調(diào)用可能出現(xiàn)后寫(xiě)覆蓋先寫(xiě)的情況。我在提交本輪結(jié)果時(shí)只用appendRecord一次不在循環(huán)里頻繁調(diào)用。另外JSON 解析失敗要返回空數(shù)組不能直接 throw否則歷史記錄一壞整個(gè) App 啟動(dòng)就崩了。4.3 錯(cuò)題本不只是記一句“做錯(cuò)了”錯(cuò)題本如果只存“3 5 做錯(cuò)了”后續(xù)重練根本沒(méi)有可用的上下文。要保證錯(cuò)題本有價(jià)值每條記錄必須包含題目表達(dá)式、正確答案、用戶(hù)當(dāng)時(shí)的錯(cuò)誤答案、出錯(cuò)時(shí)間。這樣才能做到錯(cuò)題重練時(shí)按原題復(fù)現(xiàn)。我的錯(cuò)題記錄結(jié)構(gòu)interface WrongRecord { id: string; expression: string; correctAnswer: number; wrongAnswer: string; timestamp: number; }錯(cuò)題重練和普通練習(xí)共用一個(gè)出題引擎但參數(shù)不同直接給定expression和答案不再走隨機(jī)生成器。這個(gè)復(fù)用比單獨(dú)寫(xiě)一套“錯(cuò)題練習(xí)”邏輯省事得多新功能也就一個(gè)頁(yè)面的事。有一點(diǎn)要特別提醒錯(cuò)題本存儲(chǔ)必須做去重。孩子同一道題錯(cuò)三次不要存三條而是更新原記錄的timestamp和wrongAnswer。我判斷重復(fù)的標(biāo)準(zhǔn)是expression correctAnswer相同就合并。否則跑一個(gè)月后錯(cuò)題本會(huì)膨脹到?jīng)]法看。5. 原生能力銜接與性能優(yōu)化5.1 可以接入的原生能力與接入方式數(shù)學(xué)練習(xí)不依賴(lài)攝像頭、定位這類(lèi)敏感權(quán)限但還是有兩個(gè)原生能力值得接入震動(dòng)和語(yǔ)音報(bào)題。答對(duì)時(shí)輕輕震一下答錯(cuò)時(shí)長(zhǎng)震動(dòng)這個(gè)反饋對(duì)低齡用戶(hù)非常友好語(yǔ)音報(bào)題則可以讓孩子不用盯著屏幕讀題聽(tīng)題作答。震動(dòng)在 OpenHarmony 適配層里可以通過(guò)橋接調(diào)用原生模塊實(shí)現(xiàn)但 RN 原生模塊在 OpenHarmony 上的注冊(cè)方式和 Android 不完全一樣需要在harmony/entry/src/main/ets里寫(xiě)一個(gè)原生模塊再在 JS 側(cè)調(diào)用。這部分代碼量不大我建議放到業(yè)務(wù)功能全部跑通之后再做前期別讓原生橋接干擾主流程。老實(shí)說(shuō)如果你只做單機(jī)練習(xí)不接語(yǔ)音和震動(dòng)也完全夠用。但如果你也想驗(yàn)證一下 RN 原生橋接在 OpenHarmony 上的完整鏈路那值得試一次畢竟這是跨平臺(tái)方案繞不開(kāi)的話題。5.2 bundle 打包與首屏優(yōu)化RN 應(yīng)用在 OpenHarmony 上有兩種加載 bundle 的模式開(kāi)發(fā)模式連 Metro運(yùn)行時(shí)按需拉取發(fā)布模式把 bundle 打包進(jìn) hap 包安裝后離線加載。首屏優(yōu)化最關(guān)鍵的是把發(fā)布模式的預(yù)打包做對(duì)。我的做法是先在工程里配置好assets/index.bundle的輸出路徑然后在構(gòu)建 hap 之前先執(zhí)行打包腳本讓 JS bundle 進(jìn)到entry/src/main/resources/rawfile下。這個(gè)過(guò)程有點(diǎn)繞如果發(fā)現(xiàn)真機(jī)上長(zhǎng)時(shí)間白屏優(yōu)先懷疑 bundle 文件有沒(méi)有真的打進(jìn)包里。另一個(gè)優(yōu)化點(diǎn)是拆分“首屏等待”。數(shù)學(xué)練習(xí)首頁(yè)啟動(dòng)時(shí)需要讀本地設(shè)置如果每次都在頁(yè)面上 await用戶(hù)會(huì)看到白屏。我改成先渲染默認(rèn)設(shè)置再異步加載本地配置并更新界面。雖然差了零點(diǎn)幾秒但啟動(dòng)感知差別明顯。這套思路在 RN for OpenHarmony 上同樣有效因?yàn)樗簧婕霸阅苷{(diào)優(yōu)而是從用戶(hù)體驗(yàn)出發(fā)做取舍。5.3 列表卡頓與渲染優(yōu)化歷史成績(jī)和錯(cuò)題本都用 FlatList 實(shí)現(xiàn)。FlatList 在 RN on OpenHarmony 上能用但需要注意三件事第一每條列表項(xiàng)的數(shù)據(jù)結(jié)構(gòu)要盡量扁平不要在 renderItem 里做復(fù)雜計(jì)算。比如歷史成績(jī)里的“正確率”和“時(shí)長(zhǎng)”字段我是在寫(xiě)入記錄時(shí)就算好存下來(lái)渲染時(shí)直接讀字段不對(duì)源數(shù)據(jù)做二次計(jì)算。第二必須設(shè)置穩(wěn)定且唯一的keyExtractor。我用的是記錄里的id字段不用數(shù)組 index。原因很簡(jiǎn)單列表項(xiàng)如果只是 index插入或刪除時(shí)會(huì)引發(fā)整頁(yè)重渲染OpenHarmony 上的表現(xiàn)會(huì)更敏感。第三避免在renderItem里使用內(nèi)聯(lián)箭頭函數(shù)。寫(xiě)成renderRecord{this.renderRecord}而不是renderItem{() Item/}這樣列表復(fù)用節(jié)點(diǎn)時(shí)才能命中優(yōu)化路徑。這個(gè)點(diǎn)在 Android 上不明顯但我在 OpenHarmony 上測(cè)試時(shí)內(nèi)聯(lián)函數(shù)和高頻刷新同時(shí)出現(xiàn)滾動(dòng)確實(shí)會(huì)掉幀明顯。6. 真機(jī)調(diào)試與問(wèn)題排查6.1 從白屏到跑起來(lái)調(diào)試基礎(chǔ)操作RN on OpenHarmony 的調(diào)試思路和 Android 類(lèi)似但也有自己的怪脾氣。真機(jī)連接 DevEco Studio 后先確認(rèn)設(shè)備能安裝 hap 包再確認(rèn) Metro 服務(wù)是否正常啟動(dòng)。我碰到過(guò)的情況是Metro 沒(méi)開(kāi)應(yīng)用裝上了也白屏日志里一堆“bundle load failed”。開(kāi)發(fā)模式下手機(jī)和電腦必須在同一局域網(wǎng)而且 Metro 的監(jiān)聽(tīng)地址不要用localhost否則真機(jī)訪問(wèn)不到。我直接在命令行里跑react-native start --host 0.0.0.0這樣手機(jī)可以通過(guò)電腦的局域網(wǎng) IP 訪問(wèn) Metro。日志這塊也有坑。OpenHarmony 的 hilog 和 RN 的 console 不一定完全打通有時(shí)候業(yè)務(wù)代碼報(bào)錯(cuò)了DevEco 控制臺(tái)看不到信息。我的做法是給關(guān)鍵流程加一份本地日志寫(xiě)入比如記錄“bundle 加載完成”“題目生成成功”“存儲(chǔ)執(zhí)行成功”這些打點(diǎn)真機(jī)出問(wèn)題時(shí)先看這些打點(diǎn)再回頭查 hilog。6.2 常見(jiàn)問(wèn)題速查表現(xiàn)象可能原因排查思路真機(jī)安裝失敗包簽名不對(duì)在 DevEco Studio 里重新配置簽名確認(rèn) bundleName 和證書(shū)匹配白屏且無(wú)報(bào)錯(cuò)bundle 未打進(jìn) hap 或 Metro 未啟動(dòng)檢查 rawfile 下有沒(méi)有 bundle 文件確認(rèn) Metro 可用中文輸入法無(wú)法調(diào)起TextInput 的鍵盤(pán)類(lèi)型與系統(tǒng)沖突用keyboardTypenumeric并測(cè)試不同輸入法版本樣式不一致部分 RN 樣式屬性未完全映射查看適配層支持的樣式列表用boxShadow等屬性時(shí)預(yù)留降級(jí)方案AsyncStorage 讀不到數(shù)據(jù)bundleName 或應(yīng)用被卸載確認(rèn)包名未改變卸載重裝會(huì)清空本地?cái)?shù)據(jù)滾動(dòng)列表卡頓renderItem 內(nèi)聯(lián)函數(shù)或 key 不穩(wěn)定設(shè)置穩(wěn)定 key抽離 renderItem 為獨(dú)立方法這張表不是從文檔里抄的都是我自己在真機(jī)上一個(gè)一個(gè)試出來(lái)的。尤其是樣式不一致那條boxShadow在 Android 上已經(jīng)支持得不錯(cuò)但 OpenHarmony 適配層早期版本并不支持代碼里不寫(xiě)降級(jí)界面上就是干巴巴一個(gè)平面。我最后統(tǒng)一抽了個(gè)Card組件內(nèi)部做平臺(tái)兼容判斷業(yè)務(wù)層不用關(guān)心細(xì)節(jié)。6.3 我踩過(guò)的兩個(gè)關(guān)鍵坑第一個(gè)坑是數(shù)字鍵盤(pán)調(diào)起后中文輸入法還是能輸入字母。孩子做題時(shí)切到手寫(xiě)輸入法TextInput 拿到的是“三”而不是“3”Number(三)返回NaN校驗(yàn)直接判錯(cuò)。這個(gè)問(wèn)題的根子在鍵盤(pán)類(lèi)型只影響“彈出的面板”不影響輸入法引擎。我最后的處理是校驗(yàn)時(shí)只接受數(shù)字字符串檢測(cè)到非數(shù)字字符立即清空并提示“請(qǐng)輸入數(shù)字”。這個(gè)方法看著暴力但對(duì)低齡用戶(hù)其實(shí)最有效因?yàn)殄e(cuò)誤輸入被即時(shí)糾正了。第二個(gè)坑是提交按鈕快速點(diǎn)擊導(dǎo)致一次答題被記錄兩次。原因很簡(jiǎn)單點(diǎn)擊提交后 setState 還沒(méi)觸發(fā)重渲染按鈕一直處于可點(diǎn)擊狀態(tài)第二次點(diǎn)擊進(jìn)來(lái)時(shí)當(dāng)前題還是同一道答案被重復(fù)記錄。解決辦法是在提交入口加一個(gè)短鎖提交后立刻把按鈕disabled置為 true同時(shí)用一個(gè) ref 記錄isSubmitting直到當(dāng)前題索引變化后再恢復(fù)。這個(gè)問(wèn)題的排查過(guò)程也提醒我RN on OpenHarmony 的重渲染時(shí)機(jī)和 Android / iOS 略有差異不要完全依賴(lài) UI 狀態(tài)做并發(fā)控制。最后再說(shuō)一個(gè)個(gè)人心得數(shù)字和引號(hào)之類(lèi)的小問(wèn)題在 iOS / Android 上可能影響不大但在新適配平臺(tái)上都會(huì)更容易暴露。不要假設(shè)某個(gè)交互在當(dāng)前平臺(tái)表現(xiàn)正常一定要在真機(jī)上按真實(shí)用戶(hù)操作路徑完整跑一遍尤其是鍵盤(pán)、觸摸、焦點(diǎn)這類(lèi)和系統(tǒng)強(qiáng)相關(guān)的交互。數(shù)學(xué)練習(xí)這個(gè)項(xiàng)目做完我最大的收獲不是 RN 代碼本身而是學(xué)會(huì)了把所有“跨平臺(tái)想當(dāng)然”都當(dāng)成風(fēng)險(xiǎn)來(lái)處理。這個(gè)項(xiàng)目后續(xù)還可以繼續(xù)擴(kuò)展的方向很多比如把錯(cuò)題本導(dǎo)出成本地報(bào)告、增加多用戶(hù)切換或者加入語(yǔ)音聽(tīng)題功能。如果你們也在做類(lèi)似遷移建議保持耐心先把最小功能完整跑通一遍再逐步疊加能力。