今年年初我接到一個需求要在 OpenHarmony 設(shè)備上做一款藝考真題題庫App刷題、?？?、錯題本都要有最關(guān)鍵的是要帶學(xué)習(xí)報(bào)告功能。團(tuán)隊(duì)里沒人碰過 Flutter for OpenHarmony 這套組合網(wǎng)上能搜到的資料要么停留在跑通 Hello World要么就是官方文檔里語焉不詳?shù)倪m配說明幾乎沒有一篇能告訴我“題庫 統(tǒng)計(jì)報(bào)告”這種完整產(chǎn)品怎么落地。做完之后我覺得很有必要把全過程寫下來——從環(huán)境搭建、數(shù)據(jù)模型設(shè)計(jì)到學(xué)習(xí)報(bào)告的統(tǒng)計(jì)口徑和圖表實(shí)現(xiàn)再到跨端適配時踩的一堆坑給后面想用 Flutter 做 OpenHarmony 應(yīng)用的同行留一份能直接抄作業(yè)的參考。這篇文章適合有 Flutter 基礎(chǔ)、想拓到 OpenHarmony 平臺的客戶端開發(fā)者也適合正在評估“題庫類產(chǎn)品跨端方案”的產(chǎn)品和技術(shù)負(fù)責(zé)人。1. 為什么選 Flutter 做 OpenHarmony 題庫需求背后的真實(shí)原因1.1 藝考刷題這個場景到底特殊在哪藝考和普通升學(xué)考不一樣它不是一個“科目大盤子”而是覆蓋美術(shù)、音樂、舞蹈、播音編導(dǎo)等多個大類每個大類下面還有細(xì)分方向的題庫需求。我做這個項(xiàng)目時甲方是某培訓(xùn)機(jī)構(gòu)他們的學(xué)生要刷的理論題主要是文藝常識、美術(shù)史、樂理、藝術(shù)概論、影視編導(dǎo)基礎(chǔ)這幾塊。題型以單選題、多選題、判斷題為主偶爾摻雜一些填空題。這帶來三個特殊點(diǎn)知識點(diǎn)標(biāo)簽是剛需。學(xué)生刷完題不是只看對錯的教務(wù)老師要能看出“這個班文藝常識普遍掌握得差”還是“樂理里面調(diào)式判斷總是錯”。所以題目數(shù)據(jù)模型里必須有 category 和 knowledgePoint 兩個字段學(xué)習(xí)報(bào)告全靠它們聚合。沒有這兩個字段后面做報(bào)告就是空中樓閣。碎片化刷題場景多。藝考生的訓(xùn)練時間被素描、形體、發(fā)聲練習(xí)切得很碎刷題基本發(fā)生在通勤路上、候場間隙、睡前十分鐘離線可用是第一優(yōu)先級在線同步反而是其次。報(bào)告要給機(jī)構(gòu)看。學(xué)習(xí)報(bào)告不只是學(xué)生自己的復(fù)盤工具也是機(jī)構(gòu)續(xù)課和教學(xué)調(diào)整的抓手。這意味著報(bào)告不能只給一個總正確率得拆到知識點(diǎn)維度最好還有時間趨勢。1.2 Flutter OpenHarmony 的組合邏輯這個項(xiàng)目的客戶端預(yù)算是有限的團(tuán)隊(duì)里沒有專職的 ArkTS 原生開發(fā)。而 OpenHarmony 生態(tài)的設(shè)備尤其是機(jī)構(gòu)會統(tǒng)一采購的學(xué)習(xí)終端和平板數(shù)量在明顯增長產(chǎn)品覆蓋范圍把 OpenHarmony 劃進(jìn)來了。Flutter 在這里的價值是一套 Dart 代碼同時出 Android 和 OpenHarmony 兩個安裝包。OpenHarmony 的 Flutter 支持來自開源社區(qū)的維護(hù)分支純 Dart 實(shí)現(xiàn)的 UI 和業(yè)務(wù)邏輯基本都能被這層適配接住前提是別用太多平臺插件。我在技術(shù)選型階段就定了一條原則能直接搜到 OHOS 適配的插件才用搜不到就用純 Dart 方案或者自己寫 MethodChannel絕對不在關(guān)鍵路徑上賭一個“據(jù)說能用”的插件。這條原則后面幫我們省了非常多排查時間。2. 環(huán)境搭建從 0 到 1版本選型和第一個 HAP2.1 工具鏈和版本選型Flutter for OpenHarmony 的 SDK 不能用官方 Flutter 發(fā)行版得用 OpenHarmony 社區(qū)維護(hù)的 flutter_flutter 倉庫的 ohos 分支。我落地時用的是基于 Flutter 3.7 系列的適配版本這套 API 對做題庫App完全夠用。需要注意不要混用官方 Flutter SDK否則 build 時根本找不到 ohos 平臺。需要配套的 OpenHarmony SDK在 IDE 里下載對應(yīng) API 版本的 SDK。構(gòu)建產(chǎn)物是 HAP 包類似 Android 的 APK。調(diào)試期用 Debug 證書沒問題發(fā)布必須配置簽名這和 Android 的 keystore 邏輯類似。工具鏈清單大致如下組件作用備注flutter_flutterohos分支Dart 側(cè) SDK 與編譯工具通過 git 拉取配置到 PATHOpenHarmony SDK原生側(cè)編譯所需在 IDE 中配置路徑OpenHarmony 配套 IDE管理 ohos 工程、簽名、構(gòu)建 HAP打開項(xiàng)目下的 ohos 目錄使用ohpmOpenHarmony 的包管理器原生側(cè)依賴安裝2.2 工程結(jié)構(gòu)長什么樣Flutter 工程創(chuàng)建之后除了常規(guī)的 android、ios 目錄還會多出一個 ohos 目錄這就是 OpenHarmony 的殼工程。核心結(jié)構(gòu)是項(xiàng)目根/ ├─ lib/ # Dart 業(yè)務(wù)代碼 ├─ ohos/ # OpenHarmony 殼工程 │ ├─ entry/ │ │ └─ src/main/ets/ # ArkTS 原生側(cè)代碼 │ ├─ AppScope/ # 應(yīng)用級配置 │ └─ oh-package.json5 # 原生依賴聲明 ├─ assets/ # 題目 JSON、圖片等資源 └─ pubspec.yaml大多數(shù)時候我們只需要在 lib/ 下寫 Dartohos/ 目錄里的東西不做大改。只有涉及原生能力調(diào)用時才需要動 ets 目錄下的文件。2.3 跑通第一個 HAP我這邊跑通工程的完整路徑是這樣把 ohos 分支的 Flutter SDK 下載到本地配好 PATH確認(rèn)flutter --version能輸出版本信息。創(chuàng)建工程后在項(xiàng)目根目錄新建local.properties寫入ohos.sdk.dir你的OpenHarmony SDK路徑。這一步不寫后面flutter devices識別不到 OpenHarmony 設(shè)備。連接設(shè)備或啟動模擬器執(zhí)行flutter devices能看到帶 ohos 標(biāo)識的設(shè)備條目。直接flutter run -d 設(shè)備ID首次構(gòu)建會非常慢因?yàn)橐幾g引擎相關(guān)的 so 文件耐心等。如果要出可安裝的 HAP 包把 ohos 目錄導(dǎo)入配套 IDEIDE 會跑 ohpm 安裝原生依賴同時幫你處理簽名再觸發(fā)構(gòu)建。2.4 環(huán)境上踩過的幾個坑flutter doctor 一直報(bào)警。OpenHarmony 平臺的工具鏈不會被完整識別doctor 會反復(fù)提示 Android toolchain 缺失。別慌這說明不了什么只看實(shí)際構(gòu)建能不能過。Debug 能跑、Release 裝不上。Release 包沒配簽名設(shè)備上安裝直接失敗。解決方式是 IDE 里生成證書并配置到工程的 build-profile.json5 里。熱重載是半個廢的。純 Dart 代碼改動基本能熱更新但動了原生 ArkTS 或者引擎相關(guān)的東西必須整個 HAP 重新構(gòu)建不能指望熱重載救場。3. 題庫和刷題核心數(shù)據(jù)模型、組卷與錯題歸集3.1 題目數(shù)據(jù)模型題目數(shù)據(jù)我設(shè)計(jì)成了一份 JSON 文件放進(jìn) assets而不是一開始就塞進(jìn)數(shù)據(jù)庫。原因有兩個題目是只讀數(shù)據(jù)一套題庫撐死幾千條全量加載進(jìn)內(nèi)存也就幾兆用 JSON 啟動時加載能繞開 sqflite 這類數(shù)據(jù)庫插件在 OpenHarmony 上適配不穩(wěn)定的問題。單題結(jié)構(gòu)如下{ id: mc_00123, type: 0, category: 美術(shù)史, knowledgePoint: 文藝復(fù)興美術(shù), stem: 下列哪位藝術(shù)家被認(rèn)為是“文藝復(fù)興美術(shù)三杰”之一, options: [達(dá)·芬奇, 魯本斯, 倫勃朗, 委拉斯貴茲], answer: [0], analysis: 文藝復(fù)興美術(shù)三杰指達(dá)·芬奇、米開朗琪羅、拉斐爾。 }type 用 0 單選、1 多選、2 判斷answer 用數(shù)組是為了兼容多選題。knowledgePoint 字段在學(xué)習(xí)報(bào)告階段是聚合維度所以導(dǎo)入時就必須按一套固定知識點(diǎn)詞表清洗不能隨性亂填。這里的教訓(xùn)是數(shù)據(jù)清洗比寫代碼費(fèi)時間。我們當(dāng)時拿到的原始題庫是 Excel里面“文藝復(fù)興”一會兒寫成“文藝復(fù)興時期美術(shù)”一會兒寫成“文藝復(fù)興藝術(shù)”我寫了段 Python 腳本按映射表統(tǒng)一替換才保證了后面報(bào)告統(tǒng)計(jì)口徑不出岔子。3.2 刷題流程與錯題歸集刷題頁的狀態(tài)機(jī)很簡單idle - answering - answered - next。用戶點(diǎn)選項(xiàng)時記錄選中答案點(diǎn)“下一題”時把這條答題記錄寫入本地庫同時更新當(dāng)前會話的統(tǒng)計(jì)緩存。練習(xí)記錄表是整套報(bào)告系統(tǒng)的地基字段是這樣設(shè)計(jì)的CREATE TABLE practice_records ( id INTEGER PRIMARY KEY AUTOINCREMENT, question_id TEXT NOT NULL, category TEXT NOT NULL, knowledge_point TEXT NOT NULL, is_correct INTEGER NOT NULL, selected_answer TEXT NOT NULL, duration_ms INTEGER NOT NULL, created_at INTEGER NOT NULL ); CREATE INDEX idx_records_created ON practice_records(created_at); CREATE INDEX idx_records_kp ON practice_records(knowledge_point);每條記錄必須冗余 category 和 knowledge_point而不是通過 question_id 去題目表關(guān)聯(lián)查。原因很實(shí)際題目 JSON 是內(nèi)存數(shù)據(jù)如果報(bào)告聚合時要回表關(guān)聯(lián)既要跨存儲又慢。冗余字段雖然在插入時多寫幾個字符串但換來的是報(bào)告查詢一次本地庫就全部拿到。錯題歸集我用了單獨(dú)一張錯題表question_id 做唯一約束答錯自動插入答對且已在錯題表里的記錄刪掉。這樣“錯題清零”功能也順手實(shí)現(xiàn)了。3.3 模擬考試組卷邏輯?？疾皇请S機(jī)抽題那么簡單得按考綱比例來。我用的組卷算法是按 category 的權(quán)重分層抽樣再做全局洗牌最后用固定隨機(jī)種子保證同一套卷子在不同設(shè)備上結(jié)果一致。ListQuestion buildPaper(ListQuestion pool, MapString, double blueprint, int seed) { final random Random(seed); final result Question[]; blueprint.forEach((category, weight) { final bucket pool.where((q) q.category category).toList()..shuffle(random); final need (weight * totalCount).round(); result.addAll(bucket.take(need)); }); result.shuffle(random); return result; }交卷邏輯有個坑未做答的題在評分時不能漏掉要按錯誤處理。?？加涗浺矔懭?practice_records但單獨(dú)加一個 source 標(biāo)識字段區(qū)分練習(xí)和模考報(bào)告里這兩個數(shù)據(jù)要分開看混在一起會嚴(yán)重污染知識點(diǎn)正確率。4. 學(xué)習(xí)報(bào)告實(shí)現(xiàn)從埋點(diǎn)到圖表4.1 數(shù)據(jù)采集一次答題記錄什么學(xué)習(xí)報(bào)告能不能做出來全看埋點(diǎn)定義。我埋的字段就是 3.2 節(jié)那張表question_id、category、knowledge_point、is_correct、duration_ms、created_at。這里要說三個容易漏的點(diǎn)duration_ms 必須逐題記。有了它才能算“平均每題用時”“知識點(diǎn)耗時”這些指標(biāo)對機(jī)構(gòu)判斷學(xué)生熟練度很有價值。created_at 用毫秒時間戳而不是存成“2025-04-01 10:00”這種格式化字符串。日期聚合只有在查詢時才做格式化存時間戳能避免時區(qū)問題和格式解析開銷。會話時長單獨(dú)處理。單題時長的總和并不等于用戶實(shí)際學(xué)習(xí)時長因?yàn)橛脩魰趦傻李}之間發(fā)呆。我在刷題會話開始和結(jié)束時各記一個時間點(diǎn)App 切后臺時用 AppLifecycleState 回調(diào)自動結(jié)算本段這個口徑更接近真實(shí)學(xué)習(xí)投入。4.2 統(tǒng)計(jì)口徑正確率、學(xué)習(xí)時長、連續(xù)天數(shù)怎么算統(tǒng)計(jì)口徑是最容易被產(chǎn)品和技術(shù)拉扯的地方我踩過之后強(qiáng)烈建議先寫一份統(tǒng)計(jì)口徑文檔再寫代碼。我最終落地的口徑是這樣的正確率 正確題數(shù) ÷ 總題數(shù)。但?？贾形醋鞔鸬念}一律計(jì)錯練習(xí)中用戶中途放棄的不計(jì)。知識點(diǎn)掌握度 該知識點(diǎn)答對次數(shù) ÷ 該知識點(diǎn)練習(xí)次數(shù)。練習(xí)題量少于 3 條的知識點(diǎn)不展示避免“練了一題對了就說掌握度 100%”的假象。學(xué)習(xí)時長 會話時長累加不是單題時長累加。連續(xù)學(xué)習(xí)天數(shù) 從今天開始往前掃只要當(dāng)天練習(xí)記錄數(shù)大于 0 就算連續(xù)如果今天還沒有記錄則從昨天開始掃。這樣不會因?yàn)椤敖裉爝€沒開始學(xué)”就粗暴斷掉連續(xù)記錄。聚合查詢用 SQL 做也行用 Dart 內(nèi)存聚合也行。我這邊因?yàn)橐呀?jīng)全量查了 records直接在內(nèi)存里分組更順手MapString, double knowledgeAccuracy(ListPracticeRecord records) { final stat String, Listint{}; for (final r in records) { final s stat.putIfAbsent(r.knowledgePoint, () [0, 0]); s[1]; if (r.isCorrect 1) s[0]; } return stat.map((kp, s) MapEntry(kp, s[0] / s[1])); }4.3 圖表落地fl_chart 折線與雷達(dá)圖學(xué)習(xí)報(bào)告頁我做了四個可視化塊7日正確率趨勢折線圖、知識點(diǎn)掌握度雷達(dá)圖、薄弱知識點(diǎn) Top5列表、每日刷題量柱狀圖。圖表庫選了 fl_chart它在 OpenHarmony 上的表現(xiàn)讓我意外地放心因?yàn)樗羌?Dart 繪制不依賴原生畫布能力。折線圖用 LineChart雷達(dá)圖用 RadarChartRadarChart( RadarChartData( dataSets: [ RadarDataSet( dataEntries: entries, borderColor: Colors.blue, fillColor: Colors.blue.withOpacity(0.2), ), ], radarShape: RadarShape.polygon, ticksTextStyle: const TextStyle(fontSize: 10), ), )這里有個真實(shí)的坑要講RadarChart 在部分 OpenHarmony 設(shè)備上對觸摸事件處理有兼容問題如果用戶手指滑過雷達(dá)圖偶爾會閃退。我沒花時間深究底層直接把整個報(bào)告的圖表區(qū)域包了一層 IgnorePointer用戶只能看不能點(diǎn)。報(bào)告頁本來就是展示型頁面交互需求為零這個取舍非常劃算。4.4 報(bào)告緩存與刷新策略報(bào)告頁打開時如果每次都全量掃 practice_records數(shù)據(jù)量上來后會卡。我加了一張冗余聚合表 daily_statsCREATE TABLE daily_stats ( date TEXT PRIMARY KEY, total_count INTEGER DEFAULT 0, correct_count INTEGER DEFAULT 0, duration_ms INTEGER DEFAULT 0 );每次答題完成就在事務(wù)里更新當(dāng)天這一行。打開報(bào)告頁時只需要查daily_stats 算今日數(shù)據(jù)和 7 日趨勢practice_records 按 knowledge_point 分組算掌握度。兩次小查詢毫秒級響應(yīng)。如果用戶通過某些后臺手段清了練習(xí)記錄daily_stats 會和 records 不一致。我在設(shè)置頁放了一個“重建統(tǒng)計(jì)數(shù)據(jù)”入口提供全量重建方法報(bào)給用戶“修復(fù)中”省了很多客訴。5. 跨端實(shí)坑清單OpenHarmony 上插件與原生協(xié)作5.1 插件兼容地圖這個項(xiàng)目做完我對 Flutter 插件在 OpenHarmony 上的兼容性總結(jié)了一張表給同行做個參考插件/庫是否純 DartOpenHarmony 可用性我的處理provider是正常直接用fl_chart是正常直接用關(guān)閉觸摸shared_preferences否有社區(qū)適配版版本需匹配找個固定版本鎖死path_provider否沒有可用的自寫 MethodChannelsqflite否不可用改用 JSON 文件存儲注意插件兼容版本是動態(tài)的今天能用的明天可能因?yàn)?SDK 升級掛掉。我的建議是鎖定 flutter_flutter 分支的 commit鎖定所有依賴的精確版本絕不輕易升級。這個項(xiàng)目從聯(lián)調(diào)到交付工具鏈一個沒升就是因?yàn)榉€(wěn)定壓倒一切。5.2 自寫 MethodChannel 對接 ArkTSpath_provider 用不了之后我寫了一個極簡的 MethodChannel 拿應(yīng)用文件目錄。Dart 側(cè)代碼static const MethodChannel _channel MethodChannel(app/native); FutureString getAppDir() async { return await _channel.invokeMethod(getAppDir); }原生側(cè)是用 ArkTS 實(shí)現(xiàn)的和 Android 上用 Kotlin 寫插件是兩套完全不同的 API。我這邊只是在殼工程的 ArkTS 入口里注冊了 channel 實(shí)現(xiàn)返回文件系統(tǒng)路徑。剛開始不熟悉 ArkTS 的模塊注冊規(guī)則折騰了一天才跑通原因只是我在錯誤的生命周期節(jié)點(diǎn)執(zhí)行了注冊。后來我把這一小段原生代碼寫成注釋文檔放在工程里交給團(tuán)隊(duì)其他人就沒再出過問題。方法論上我想多說一句自寫 MethodChannel 的數(shù)量要克制。每多一個 channel就多一個需要在原生側(cè)驗(yàn)證的邊界。這個項(xiàng)目把所有原生依賴收斂到了三個 channel應(yīng)用目錄獲取、輕量 KV 存儲、設(shè)備信息。剩下的全靠純 Dart 解決。5.3 包體積和性能調(diào)優(yōu)HAP 發(fā)布包體積一開始很大主要成本在 Flutter 引擎的 so 文件。我做三件事把它壓了下來發(fā)布構(gòu)建加--obfuscate --split-debug-info混淆的同時剝離符號表體積減小明顯。assets 里只打包當(dāng)前大綱對應(yīng)考點(diǎn)的題目 JSON不把全量題庫歷史版本打進(jìn)去。題目配圖統(tǒng)一壓縮到 WebP單張控制在 100KB 以內(nèi)。性能上最大的體感差異是 Debug 模式明顯比 Android 卡上 Release 包之后流暢度恢復(fù)正常。題庫列表頁我用了 itemExtent 固定行高避免長列表滾動時的反復(fù)測量開銷。這些在 Android 上可能無感的優(yōu)化在 OpenHarmony 的 Flutter 適配層上就是實(shí)打?qū)嵉牧鲿扯炔罹唷?. 交付之后回頭看這個項(xiàng)目真正的難點(diǎn)不在代碼6.1 時間花在了三個沒寫代碼的地方回頭看整個交付最花時間的三件事都不是 Flutter 代碼本身第一是題目 Excel 清洗成標(biāo)準(zhǔn) JSON幾百道題的人工核對第二是學(xué)習(xí)報(bào)告統(tǒng)計(jì)口徑的確認(rèn)產(chǎn)品和教務(wù)來回拉扯了好幾輪第三是插件兼容性驗(yàn)證每個依賴都要在真機(jī)上試一遍。我自己的感受是Flutter for OpenHarmony 的 UI 層開發(fā)體驗(yàn)已經(jīng)相當(dāng)夠用真正的不確定性全在生態(tài)層。哪個插件沒適配、哪個原生 API 換了簽名這些問題不會出現(xiàn)在報(bào)錯信息里而是冷不丁在某個流程上絆你一下。6.2 給后來者的三個選型標(biāo)準(zhǔn)如果你也想入坑 Flutter for OpenHarmony我建議你選依賴時用三條標(biāo)準(zhǔn)過濾純 Dart 優(yōu)先能查到官方維護(hù)的 OHOS 適配記錄才考慮原生插件。API 簡單且可替換萬一插件掛了自己寫 MethodChannel 的成本要可控。版本鎖死不要追新。這套組合下新版本帶來的不確定遠(yuǎn)大于收益。6.3 最后一點(diǎn)體會做完這套題庫如果讓我重來一次我會在第一天就把“學(xué)習(xí)報(bào)告口徑文檔”和“依賴兼容矩陣”兩個東西立起來而不是邊開發(fā)邊補(bǔ)。藝考題庫本身不難難的是它要求你在一個適配還不成熟的平臺上把數(shù)據(jù)、統(tǒng)計(jì)、可視化完整跑通。但反過來說正因?yàn)槠脚_生態(tài)不成熟先趟過這條路的人后面再遇到同類的項(xiàng)目基本就是降維打擊了。希望這篇分享能幫你少踩幾個我踩過的坑。