這個(gè)系列寫到第十篇的時(shí)候幸運(yùn)大轉(zhuǎn)盤的基礎(chǔ)功能其實(shí)已經(jīng)跑通了。界面、動(dòng)畫、抽獎(jiǎng)邏輯、音效反饋該亮的都亮了該轉(zhuǎn)的也能轉(zhuǎn)了。但站在產(chǎn)品角度它還活得比較“虛無”——用戶抽了多少次中獎(jiǎng)率是不是符合預(yù)設(shè)什么時(shí)候抽得最頻繁大家更喜歡哪個(gè)獎(jiǎng)品檔位這些數(shù)據(jù)如果拿不到后續(xù)的優(yōu)化方向就只能靠猜或者說全憑感覺調(diào)參數(shù)。這期我就把數(shù)據(jù)統(tǒng)計(jì)這塊補(bǔ)上讓這個(gè) Flutter for OpenHarmony 的幸運(yùn)大轉(zhuǎn)盤從一個(gè)“會(huì)轉(zhuǎn)的玩具”變成一個(gè)“可觀察、可迭代”的功能模塊。內(nèi)容會(huì)包括統(tǒng)計(jì)維度怎么定、數(shù)據(jù)模型怎么設(shè)計(jì)、存儲(chǔ)怎么選、埋點(diǎn)怎么接以及在 OpenHarmony 上實(shí)測(cè)時(shí)踩到的一些坑。對(duì)這個(gè)系列前幾期跟下來的讀者來說這一篇的代碼量不大但設(shè)計(jì)上的取舍值得琢磨。如果你正打算給自己的跨平臺(tái) app 加一個(gè)類似的本地統(tǒng)計(jì)模塊這篇文章可以直接“抄作業(yè)”。1. 數(shù)據(jù)統(tǒng)計(jì)模塊的整體設(shè)計(jì)思路1.1 為什么選擇純客戶端本地統(tǒng)計(jì)在動(dòng)手寫之前我先問了自己一個(gè)問題這個(gè)統(tǒng)計(jì)要不要往后端上報(bào)幸運(yùn)大轉(zhuǎn)盤這種功能在很多業(yè)務(wù)里確實(shí)是掛在服務(wù)端下發(fā)獎(jiǎng)品、記錄中獎(jiǎng)流水。但這套系列教程做的場(chǎng)景是“單機(jī)娛樂型”的小應(yīng)用沒有登錄體系也沒有服務(wù)器。強(qiáng)行引入后端上報(bào)意味著要維護(hù)接口、做鑒權(quán)、處理離線隊(duì)列工程量直接翻倍。對(duì)大多數(shù)人來說這屬于過度設(shè)計(jì)。所以我的方案是全部走本地存儲(chǔ)把統(tǒng)計(jì)當(dāng)作客戶端的一個(gè)內(nèi)聚模塊來做。這樣一來有幾個(gè)實(shí)際好處數(shù)據(jù)實(shí)時(shí)性高不依賴網(wǎng)絡(luò)抽完立刻入庫。實(shí)現(xiàn)成本低一個(gè)單例管理器加一套存儲(chǔ)就夠。后續(xù)如果想上報(bào)可以在這套本地統(tǒng)計(jì)的基礎(chǔ)上做增量同步不需要推翻重來。我見過不少開發(fā)者一上來就想做“完整數(shù)據(jù)中臺(tái)”結(jié)果卡在網(wǎng)絡(luò)波動(dòng)、數(shù)據(jù)一致性這些事上連基礎(chǔ)統(tǒng)計(jì)都沒跑起來。對(duì)于這種工具型的小應(yīng)用先把本地統(tǒng)計(jì)做好讓數(shù)據(jù)“有跡可循”比什么花架子都強(qiáng)。1.2 統(tǒng)計(jì)維度怎么定先滿足三個(gè)核心問題定統(tǒng)計(jì)維度這步特別容易失控。有人會(huì)忍不住把用戶每次點(diǎn)擊、頁面停留、手指滑動(dòng)軌跡全記錄下來最后得到一堆用不上的數(shù)據(jù)還占存儲(chǔ)空間。我給自己圈了一個(gè)邊界只要回答三個(gè)產(chǎn)品問題就行。第一個(gè)問題這個(gè)轉(zhuǎn)盤到底被玩了多少次對(duì)應(yīng)的是抽獎(jiǎng)總次數(shù)、每日抽獎(jiǎng)次數(shù)、單用戶連續(xù)抽獎(jiǎng)次數(shù)。這些數(shù)據(jù)能反映功能活躍度。第二個(gè)問題發(fā)放的獎(jiǎng)品有沒有偏離配置概率對(duì)應(yīng)的是總中獎(jiǎng)次數(shù)、各獎(jiǎng)品中獎(jiǎng)次數(shù)、未中獎(jiǎng)次數(shù)。這個(gè)數(shù)據(jù)能驗(yàn)證轉(zhuǎn)盤概率算法是否正常也能發(fā)現(xiàn)是否存在“永遠(yuǎn)抽不到某檔獎(jiǎng)品”的暗坑。第三個(gè)問題用戶集中在什么時(shí)間段抽為什么要知道這個(gè)因?yàn)槿绻l(fā)現(xiàn)晚間活躍度明顯偏高那后續(xù)的運(yùn)營活動(dòng)就可以考慮在晚間時(shí)段做加成如果半天才有人抽一次說明入口不夠吸引人得考慮調(diào)整按鈕露出。我最終確定的統(tǒng)計(jì)字段包括抽獎(jiǎng)總次數(shù)、今日抽獎(jiǎng)次數(shù)、未中獎(jiǎng)次數(shù)、每個(gè)獎(jiǎng)品的中獎(jiǎng)次數(shù)、最后一次抽獎(jiǎng)時(shí)間、每日抽獎(jiǎng)時(shí)間分布用小時(shí)桶來聚合。這里沒有做“連續(xù)未中獎(jiǎng)次數(shù)”的實(shí)時(shí)記錄原打算做防“曬”優(yōu)化后來想了下這個(gè)維度更適合放服務(wù)端做風(fēng)控本地統(tǒng)計(jì)做了意義不大。如果以后真需要我再加一個(gè)字段而已模型上留了擴(kuò)展位。1.3 存儲(chǔ)方案選型不要一上來就上數(shù)據(jù)庫本地存儲(chǔ)可選的方案有幾類。第一類是 SharedPreferences 這種 key-value 輕量存儲(chǔ)適合存簡(jiǎn)單配置和少量計(jì)數(shù)。第二類是 SQLite 這類關(guān)系型數(shù)據(jù)庫適合存結(jié)構(gòu)化歷史記錄能按時(shí)間范圍查詢。第三類是直接讀寫文件自己控制序列化格式。幸運(yùn)大轉(zhuǎn)盤這個(gè)場(chǎng)景數(shù)據(jù)量本身不會(huì)大就算用戶一天抽幾百次也就幾百條記錄。但如果只存一個(gè)聚合后的整數(shù)后續(xù)想看時(shí)間分布、獎(jiǎng)品明細(xì)就得改存儲(chǔ)結(jié)構(gòu)重新刷數(shù)據(jù)。我的選擇是折中方案聚合指標(biāo)用 key-value 存例如total_spins、today_spins、prize_a_count讀取快改動(dòng)小。明細(xì)記錄用結(jié)構(gòu)化存儲(chǔ)但我不直接引入數(shù)據(jù)庫依賴而是用 JSON 文件追加寫入按天分文件。為什么不直接上 SQLite因?yàn)樵?OpenHarmony 生態(tài)上Flutter 插件適配參差不齊sqflite 這類依賴原生實(shí)現(xiàn)的插件不一定能直接跑起來。我試過在模擬器上用某個(gè)版本的原生數(shù)據(jù)庫插件結(jié)果初始化時(shí)報(bào)一堆底層錯(cuò)誤排查起來非常痛苦。文件存儲(chǔ)只要路徑對(duì)基本不依賴平臺(tái)特殊能力兼容性更穩(wěn)。這里也提一下OpenHarmony 上如果項(xiàng)目直接做的是標(biāo)準(zhǔn) Flutter 應(yīng)用很多純 Dart 的 API比如dart:io、path_provider是可用的但path_provider這個(gè)插件本身也需要 OpenHarmony 側(cè)的適配實(shí)現(xiàn)。我在實(shí)際工程里是自己獲取應(yīng)用沙箱路徑來繞開的后續(xù)會(huì)有相關(guān)說明。2. 數(shù)據(jù)模型與核心統(tǒng)計(jì)邏輯拆解2.1 數(shù)據(jù)模型設(shè)計(jì)聚合字段和明細(xì)記錄分開數(shù)據(jù)模型是統(tǒng)計(jì)模塊的地基我分了兩層來設(shè)計(jì)。第一層是實(shí)時(shí)聚合層。這一層保存當(dāng)前累計(jì)值主要用于面板頂部那幾張“指標(biāo)卡”顯示總次數(shù)、今日次數(shù)、中獎(jiǎng)次數(shù)等。用 key-value 存就夠了每次抽完獎(jiǎng)只更新一個(gè)計(jì)數(shù)器性能開銷可忽略。第二層是歷史明細(xì)層。這一層保存每次抽獎(jiǎng)的具體信息包括時(shí)間戳、是否中獎(jiǎng)、獎(jiǎng)品 ID、獎(jiǎng)品名稱、抽獎(jiǎng)消耗的“幸運(yùn)幣”數(shù)量?？紤]到后續(xù)可能要看“近7天走勢(shì)”這一層必須按時(shí)間可查詢。我用 JSON 數(shù)組文件來存文件名按日期區(qū)分例如statistics_2025_06_01.json這樣想看哪天就加載哪天。字段定義上我用一個(gè) Dart 類來表示單次抽獎(jiǎng)記錄class SpinRecord { final int timestamp; final bool isWin; final String prizeId; final String prizeName; final int costCoins; SpinRecord({ required this.timestamp, required this.isWin, required this.prizeId, required this.prizeName, required this.costCoins, }); MapString, dynamic toJson() { t: timestamp, win: isWin, pid: prizeId, name: prizeName, cost: costCoins, }; factory SpinRecord.fromJson(MapString, dynamic json) SpinRecord( timestamp: json[t], isWin: json[win], prizeId: json[pid], prizeName: json[name], cost: json[cost], ); }注意字段名我用了縮寫比如t、win、pid純粹是為了壓縮 JSON 體積。單條記錄省不了幾個(gè)字節(jié)但記錄多了、文件要反復(fù)讀寫時(shí)體積小一點(diǎn)還是有意義的?？勺x性方面因?yàn)橹辉谖募锎娌簧婕翱缍苏故舅詥栴}不大。聚合層的字段我保存在另一個(gè) key-value 存儲(chǔ)里大概長(zhǎng)這樣totalSpins: 157 todaySpins: 23 todayDate: 2025-06-01 winCount: 31 prizeCounts: {prize_001: 12, prize_002: 5, prize_003: 14} lastSpinTime: 1717228800000todayDate單獨(dú)存一個(gè)字段用來判斷是否需要把todaySpins清零——跨天時(shí)首次訪問統(tǒng)計(jì)模塊如果存的日期不是今天就直接重置今日次數(shù)。這樣做比每次 get 時(shí)動(dòng)態(tài)比較日期再算要省事也更直觀。2.2 概率與統(tǒng)計(jì)模塊的解耦寫統(tǒng)計(jì)模塊的時(shí)候最容易犯的錯(cuò)就是把統(tǒng)計(jì)代碼直接塞進(jìn)抽獎(jiǎng)函數(shù)里比如void startSpin() { // 一堆轉(zhuǎn)盤邏輯 // 統(tǒng)計(jì)邏輯混進(jìn)來 statistics.total; statistics.prizeCount[xx]; statistics.save(); }這在功能上沒錯(cuò)但后續(xù)會(huì)很痛苦。假設(shè)你要給轉(zhuǎn)盤增加一個(gè)“十連抽”模式、加一個(gè)“保底機(jī)制”或者要調(diào)整統(tǒng)計(jì)字段都得回來改這個(gè)函數(shù)。如果埋點(diǎn)位置稍有偏差統(tǒng)計(jì)數(shù)據(jù)的準(zhǔn)確性也會(huì)跟著出問題。更好的做法是把統(tǒng)計(jì)模塊設(shè)計(jì)成事件的“觀察者”。主流程只負(fù)責(zé)發(fā)出“抽獎(jiǎng)完成”這件事統(tǒng)計(jì)模塊自行決定怎么記、記多少。我在項(xiàng)目里定義了一個(gè)輕量的事件回調(diào)接口class SpinResultEvent { final bool isWin; final String prizeId; final String prizeName; final int costCoins; SpinResultEvent({ required this.isWin, required this.prizeId, required this.prizeName, required this.costCoins, }); }然后在抽獎(jiǎng)動(dòng)畫播放完畢、結(jié)果真正確定后通過一個(gè)簡(jiǎn)單的總線把事件發(fā)出去eventBus.emit(SpinResultEvent( isWin: result.isWin, prizeId: result.prizeId, prizeName: result.prizeName, costCoins: config.spinCost, ));統(tǒng)計(jì)模塊只負(fù)責(zé)訂閱這個(gè)事件eventBus.onSpinResultEvent().listen((event) { statisticsManager.recordSpin(event); });這樣做的好處是顯而易見的。第一業(yè)務(wù)代碼完全不感知統(tǒng)計(jì)的存在后續(xù)調(diào)整統(tǒng)計(jì)邏輯不會(huì)影響抽獎(jiǎng)流程。第二新增統(tǒng)計(jì)維度時(shí)只需要在recordSpin方法里擴(kuò)展不需要碰轉(zhuǎn)盤代碼。第三如果以后要加“抽獎(jiǎng)后推送通知”“截屏分享”等額外動(dòng)作都用同一套事件機(jī)制架構(gòu)上保持統(tǒng)一。2.3 數(shù)據(jù)落盤時(shí)機(jī)內(nèi)存更新與異步寫文件并行數(shù)據(jù)落盤時(shí)機(jī)這個(gè)細(xì)節(jié)很容易被忽略但恰恰是最影響可靠性的地方。移動(dòng)應(yīng)用的進(jìn)程隨時(shí)可能被系統(tǒng)殺掉如果每次抽完獎(jiǎng)只是把數(shù)據(jù)放在內(nèi)存里等用戶退出時(shí)才寫文件那用戶中途把 app 切到后臺(tái)再殺掉這幾次抽獎(jiǎng)數(shù)據(jù)就丟了。我的策略是“內(nèi)存快速更新、磁盤異步兜底”。每次抽獎(jiǎng)完成后立即更新內(nèi)存中的聚合值做到面板展示一定是實(shí)時(shí)的同時(shí)啟動(dòng)一個(gè)異步任務(wù)把最新的聚合值寫入 key-value 存儲(chǔ)并把當(dāng)天的明細(xì)追加寫入 JSON 文件。這個(gè)異步任務(wù)本身做了節(jié)流每秒最多觸發(fā)一次寫操作Futurevoid _scheduleFlush() async { if (_flushScheduled) return; _flushScheduled true; await Future.delayed(const Duration(milliseconds: 500)); _flushScheduled false; await _writeAggregates(); await _appendTodayRecord(); }單次抽獎(jiǎng)之后用戶可能立刻連續(xù)再抽這時(shí)候用 500 毫秒的節(jié)流窗口把多次寫盤合并成一次能減少 IO 次數(shù)。如果進(jìn)程被殺最多丟 500 毫秒內(nèi)的增量實(shí)際抽獎(jiǎng)記錄通常已經(jīng)寫進(jìn)去了。我還在 app 的生命周期回調(diào)里做了兜底切到后臺(tái)或即將銷毀時(shí)強(qiáng)制調(diào)用一次flush()。Flutter 側(cè)在WidgetsBindingObserver的didChangeAppLifecycleState里監(jiān)聽paused或inactive狀態(tài)OpenHarmony 上這個(gè)回調(diào)同樣會(huì)觸發(fā)。因?yàn)榻y(tǒng)計(jì)面板需要長(zhǎng)時(shí)間保持最新數(shù)據(jù)這個(gè)兜底必須做扎實(shí)。3. 核心實(shí)現(xiàn)過程與關(guān)鍵代碼3.1 路徑獲取OpenHarmony 上的沙箱目錄處理前面提到path_provider在 OpenHarmony 上不一定有現(xiàn)成實(shí)現(xiàn)我實(shí)際處理方式是直接通過系統(tǒng)能力拿到應(yīng)用沙箱路徑。在 Flutter for OpenHarmony 工程里可以通過Platform.environment或拼接固定路徑的方式獲取可用目錄。不同版本的系統(tǒng)可能在基線上有差異穩(wěn)妥起見我封裝了一個(gè)路徑工具類class AppPaths { static String get statisticsDir { final base _resolveBaseDirectory(); final dir Directory($base/statistics); if (!dir.existsSync()) { dir.createSync(recursive: true); } return dir.path; } static String _resolveBaseDirectory() { // 優(yōu)先使用環(huán)境變量獲取沙箱目錄 final envDir Platform.environment[HOME]; if (envDir ! null envDir.isNotEmpty) { return envDir; } // 兜底邏輯使用當(dāng)前工作目錄 return Directory.current.path; } }這里并沒有使用任何三方插件純 Dart 實(shí)現(xiàn)跨平臺(tái)的時(shí)候也能編譯通過。在 OpenHarmony 上這個(gè)路徑最終會(huì)指向 app 的數(shù)據(jù)沙箱目錄用戶不可見但持久化沒有問題。如果你用的 Flutter 版本已經(jīng)適配了path_providerfor OpenHarmony那直接用官方插件自然更好少維護(hù)一套代碼。我這邊的項(xiàng)目里還有一些歷史原因所以自己處理路徑反而更省事。有一點(diǎn)必須強(qiáng)調(diào)不要硬編碼/data/xxx這種絕對(duì)路徑。不同版本的系統(tǒng)對(duì)沙箱路徑的解析方式可能有區(qū)別用環(huán)境變量或者官方 API 返回的路徑才是穩(wěn)妥之道。我一開始圖省事直接寫死路徑結(jié)果升級(jí)系統(tǒng)版本后目錄結(jié)構(gòu)變了統(tǒng)計(jì)文件找不到了所有歷史數(shù)據(jù)“消失”排查了半天才定位到是路徑問題。3.2 統(tǒng)計(jì)管理器核心方法實(shí)現(xiàn)統(tǒng)計(jì)管理器我用的是一個(gè)單例類StatisticsManager它內(nèi)部持有聚合值和當(dāng)天的記錄緩存。初始化時(shí)從 key-value 存儲(chǔ)中讀取聚合值并判斷是否跨天。class StatisticsManager { StatisticsManager._internal(); static final StatisticsManager instance StatisticsManager._internal(); int _totalSpins 0; int _todaySpins 0; int _winCount 0; MapString, int _prizeCounts {}; String _todayDate ; Futurevoid init() async { _totalSpins await _kv.getInt(totalSpins) ?? 0; _todaySpins await _kv.getInt(todaySpins) ?? 0; _winCount await _kv.getInt(winCount) ?? 0; _prizeCounts await _kv.getJson(prizeCounts) ?? {}; _todayDate await _kv.getString(todayDate) ?? ; _checkDateRollover(); } void _checkDateRollover() { final now _dateFormatter.format(DateTime.now()); if (_todayDate ! now) { _todaySpins 0; _todayDate now; _flushAggregates(); } } void recordSpin(SpinResultEvent event) { _totalSpins; _todaySpins; if (event.isWin) { _winCount; _prizeCounts[event.prizeId] (_prizeCounts[event.prizeId] ?? 0) 1; } _scheduleFlush(); } MapString, dynamic getPanelData() { ... } }recordSpin里的邏輯不復(fù)雜但有個(gè)細(xì)節(jié)值得說一下_todayDate的跨天判斷。我把它放在init()和recordSpin()里各做一次。放在init()里是為了保證冷啟動(dòng)時(shí)面板展示的今日次數(shù)是準(zhǔn)確的放在recordSpin()里則是為了處理“app 一直開著、跨了零點(diǎn)”這種邊緣情況。如果不做第二次判斷那用戶從昨晚 23:59 用到今天 00:01今日次數(shù)會(huì)延續(xù)昨天的數(shù)據(jù)展示出來就是錯(cuò)的了。getPanelData()返回的是一個(gè)只讀視圖用來給 UI 層渲染。這里不做復(fù)雜的數(shù)據(jù)處理面板需要什么字段直接從這個(gè)方法拿。比如MapString, dynamic getPanelData() { final total _totalSpins; final winRate total 0 ? 0 : (_winCount / total * 100); return { totalSpins: total, todaySpins: _todaySpins, winCount: _winCount, winRate: winRate, prizeCounts: Map.of(_prizeCounts), lastSpinTime: _lastSpinTime, }; }這里有個(gè)小陷阱如果直接把_prizeCounts返回給 UI外部可能不小心修改了內(nèi)部狀態(tài)。所以我用Map.of()復(fù)制了一份再返回避免調(diào)用方改動(dòng)到管理器的內(nèi)部數(shù)據(jù)。這個(gè)習(xí)慣在寫任何管理器類的時(shí)候都值得保持。3.3 明細(xì)記錄按天追加寫入與讀取聚合值走 key-value明細(xì)記錄走文件。我把每天的數(shù)據(jù)存成一個(gè) JSON 數(shù)組文件名如下String _todayFilePath() { final date DateFormat(yyyy_MM_dd).format(DateTime.now()); return ${AppPaths.statisticsDir}/statistics_$date.json; }追加寫入時(shí)不能先把整個(gè)文件讀進(jìn)來再寫——那樣文件大了以后每次寫入都全量讀寫性能是硬傷。我的做法是打開文件句柄直接追加一行 JSON。為了區(qū)分多條記錄我讓每條記錄單獨(dú)占一行Futurevoid _appendTodayRecord(SpinResultEvent event) async { final file File(_todayFilePath()); final record SpinRecord( timestamp: DateTime.now().millisecondsSinceEpoch, isWin: event.isWin, prizeId: event.prizeId, prizeName: event.prizeName, costCoins: event.costCoins, ); final line jsonEncode(record.toJson()) \n; await file.writeAsString(line, mode: FileMode.append); }讀取某一天的記錄時(shí)按行讀取并解析FutureListSpinRecord loadRecordsForDate(DateTime date) async { final fileName statistics_${DateFormat(yyyy_MM_dd).format(date)}.json; final file File(${AppPaths.statisticsDir}/$fileName); if (!file.existsSync()) return []; final lines await file.readAsLines(); return lines .where((line) line.trim().isNotEmpty) .map((line) SpinRecord.fromJson(jsonDecode(line))) .toList(); }這種逐行 JSON 的格式有幾個(gè)好處第一追加操作不需要鎖整個(gè)文件第二可以很方便地用tail之類的思路只讀取最后 N 行第三如果某一行因?yàn)閷懭胫袛喽鴵p壞不會(huì)影響其他行讀取時(shí)跳過空行就行。相比存在一個(gè)大 JSON 數(shù)組文件里這種格式的容錯(cuò)性好得多。但也要注意追加寫的方式會(huì)讓文件在沒有達(dá)到“整理”條件時(shí)越來越大。我這個(gè)場(chǎng)景體量不大先不考慮分頁等積累到一個(gè)月再做一個(gè)歸檔壓縮把每天多個(gè)小文件合并成一個(gè)壓縮包也不遲。3.4 數(shù)據(jù)可視化面板用 CustomPainter 繪制柱狀圖與餅圖統(tǒng)計(jì)面板我設(shè)計(jì)成三個(gè)區(qū)域頂部指標(biāo)卡、中部近7天抽獎(jiǎng)趨勢(shì)柱狀圖、底部獎(jiǎng)品分布餅圖。圖表組件我沒有引入第三方庫直接用 Flutter 自帶的CustomPainter畫。原因一是第三方圖表庫在 OpenHarmony 上的兼容性不確定二是轉(zhuǎn)盤這個(gè)場(chǎng)景的圖表形態(tài)很固定自己畫反而更可控。柱狀圖畫近7天每日抽獎(jiǎng)次數(shù)本質(zhì)上就是一組矩形的繪制。核心邏輯在paint()方法里class BarChartPainter extends CustomPainter { final Listint values; final ListString labels; BarChartPainter({required this.values, required this.labels}); override void paint(Canvas canvas, Size size) { final barPaint Paint()..color const Color(0xFF3A7BFD); final axisPaint Paint() ..color const Color(0xFFCCCCCC) ..strokeWidth 1; canvas.drawLine( Offset(0, size.height - 20), Offset(size.width, size.height - 20), axisPaint, ); final maxValue values.reduce((a, b) a b ? a : b).toDouble(); final barWidth size.width / values.length * 0.6; final gap size.width / values.length; for (var i 0; i values.length; i) { final barHeight maxValue 0 ? 0 : (values[i] / maxValue) * (size.height - 40); final left gap * i (gap - barWidth) / 2; final rect RRect.fromRectAndRadius( Rect.fromLTWH(left, size.height - 20 - barHeight, barWidth, barHeight), const Radius.circular(4), ); canvas.drawRRect(rect, barPaint); // 文本繪制代碼省略 } } override bool shouldRepaint(covariant BarChartPainter oldDelegate) { return oldDelegate.values ! values; } }這里做了兩個(gè)細(xì)節(jié)處理一是柱子的圓角矩形視覺上不會(huì)顯得生硬二是在shouldRepaint中判斷數(shù)據(jù)是否變化避免每次 build 都觸發(fā)重繪對(duì)低端機(jī)友好。如果直接把整個(gè)列表的引用傳進(jìn)來而列表還是同一個(gè)實(shí)例但內(nèi)容變了可能不會(huì)觸發(fā)重繪所以我會(huì)在數(shù)據(jù)更新時(shí)用一個(gè)新 List 實(shí)例來替換或者在shouldRepaint里比較listEquals。餅圖的繪制稍微復(fù)雜一點(diǎn)但核心就是canvas.drawArc()void paint(Canvas canvas, Size size) { final rect Rect.fromLTWH(0, 0, size.width, size.height); final total prizeValues.values.fold(0, (a, b) a b).toDouble(); if (total 0) return; var startAngle -90.0; final colors [...]; // 獎(jiǎng)品顏色序列 var index 0; for (final value in prizeValues.values) { final sweepAngle 360 * (value / total); canvas.drawArc(rect, startAngle * pi / 180, sweepAngle * pi / 180, true, Paint()..color colors[index % colors.length]); startAngle sweepAngle; index; } }注意drawArc的角度單位是弧度不是度數(shù)所以需要把度數(shù)換算一下。起始角度統(tǒng)一用 -90 度即 12 點(diǎn)鐘方向符合閱讀習(xí)慣。在面板的 UI 布局上我用了SingleChildScrollView包裹整個(gè)統(tǒng)計(jì)頁避免小屏手機(jī)上內(nèi)容溢出。每個(gè)區(qū)塊是獨(dú)立的Card組件數(shù)據(jù)刷新通過setState觸發(fā)后圖表 painter 收到新的數(shù)據(jù)列表自動(dòng)重繪。這里不用做動(dòng)畫統(tǒng)計(jì)面板的信息密度為主動(dòng)畫反而干擾閱讀。3.5 與轉(zhuǎn)盤主流程的接線最后把統(tǒng)計(jì)管理器接入轉(zhuǎn)盤主流程。我是在抽獎(jiǎng)結(jié)果開始展示的那一步接入的。具體來說轉(zhuǎn)盤的SpinController在動(dòng)畫結(jié)束時(shí)會(huì)回調(diào)一個(gè)onSpinCompleted(result)我在那個(gè)回調(diào)里發(fā)出SpinResultEvent。void _onSpinCompleted(SpinResult result) { setState(() { _lastResult result; }); eventBus.emit(SpinResultEvent( isWin: result.isWin, prizeId: result.prizeId, prizeName: result.prizeName, costCoins: _currentCost, )); }這個(gè)位置是我經(jīng)過兩次調(diào)整后確定的。第一次我想在用戶“按下抽獎(jiǎng)按鈕”時(shí)就埋點(diǎn)但這樣會(huì)把用戶抽了一半、動(dòng)畫沒播完就強(qiáng)退的情況也算進(jìn)去會(huì)造成統(tǒng)計(jì)次數(shù)偏大。第二次想在中獎(jiǎng)結(jié)果彈窗展示后再埋點(diǎn)但這個(gè)時(shí)機(jī)可能因?yàn)閺棿斑壿嫯惓６┑簟Ｗ罱K選動(dòng)畫結(jié)束回調(diào)這個(gè)位置正好是“一次抽獎(jiǎng)?wù)嬲瓿伞钡恼Z義邊界。抽獎(jiǎng)頁也加了一個(gè)入口按鈕跳轉(zhuǎn)到統(tǒng)計(jì)頁。跳轉(zhuǎn)用的就是普通的 Navigator pushNavigator.of(context).push( MaterialPageRoute(builder: (_) StatisticsPage()), );StatisticsPage在initState里調(diào)用StatisticsManager.instance.init()并加載近7天的明細(xì)數(shù)據(jù)。init 過程如果文件較大可能稍微耗時(shí)但本地文件一般不大啟動(dòng)過程基本無感。4. 常見問題與排查實(shí)錄4.1 路徑不對(duì)導(dǎo)致統(tǒng)計(jì)文件丟失這是我在 OpenHarmony 上踩過的第一個(gè)大坑。最初我用了一個(gè)固定的路徑來保存統(tǒng)計(jì)文件后來升級(jí)了某個(gè)系統(tǒng)組件版本應(yīng)用沙箱的路徑規(guī)則發(fā)生了變化讀取時(shí)找不到了表現(xiàn)為統(tǒng)計(jì)面板全部歸零。排查思路是先確認(rèn)文件是否存在?？梢栽诮y(tǒng)計(jì)管理器初始化時(shí)把實(shí)際使用的路徑打出來debugPrint(statistics dir: ${AppPaths.statisticsDir});然后再去看那個(gè)目錄下有沒有文件。如果目錄不對(duì)就調(diào)整路徑解析邏輯。我最終用的是從環(huán)境變量HOME讀取的方案這在新版本上驗(yàn)證可用。如果你也遇到類似現(xiàn)象第一步先確認(rèn)路徑別急著懷疑統(tǒng)計(jì)邏輯。4.2 統(tǒng)計(jì)次數(shù)與真實(shí)抽獎(jiǎng)次數(shù)不一致這個(gè)問題的根源通常有兩個(gè)。第一埋點(diǎn)時(shí)機(jī)不對(duì)比如前面提到的在動(dòng)畫開始前埋點(diǎn)用戶中途退出就會(huì)多記第二異步落盤被中斷比如用戶抽獎(jiǎng)后立刻殺進(jìn)程節(jié)流的 500 毫秒窗口還沒到。對(duì)第一個(gè)原因把埋點(diǎn)移到事件回調(diào)里就能解決。對(duì)第二個(gè)原因雖然沒有辦法根治“進(jìn)程被殺瞬間的數(shù)據(jù)丟失”但至少要在 App 生命周期切后臺(tái)時(shí)強(qiáng)制 flush把丟失窗口縮小到幾百毫秒內(nèi)。如果你們的產(chǎn)品要求極端嚴(yán)格那只能每抽一次就同步寫盤犧牲一點(diǎn)點(diǎn)性能換可靠性。我在調(diào)試這個(gè)一致性時(shí)加了一個(gè)自檢方法統(tǒng)計(jì)管理器維護(hù)一個(gè)“本地真實(shí)次數(shù)”的計(jì)數(shù)器每次執(zhí)行recordSpin都會(huì)自增同時(shí)聚合字段也更新。開發(fā)調(diào)試模式下拉起統(tǒng)計(jì)面板時(shí)面板上會(huì)顯示兩個(gè)數(shù)字一旦發(fā)現(xiàn)不一致立刻能定位是哪個(gè)環(huán)節(jié)丟數(shù)據(jù)。4.3 圖表重繪導(dǎo)致界面卡頓近7天柱狀圖加獎(jiǎng)品餅圖理論上數(shù)據(jù)點(diǎn)很少不會(huì)造成卡頓。但如果每次頁面 build 都重新創(chuàng)建 painter并且 painter 內(nèi)部做了大量文本測(cè)量低端機(jī)上也會(huì)有掉幀感。我遇到過在某個(gè) OpenHarmony 測(cè)試設(shè)備上點(diǎn)進(jìn)統(tǒng)計(jì)面板時(shí)明顯卡了一拍后來發(fā)現(xiàn)是因?yàn)槲以?paint 方法里每次都重新計(jì)算所有文本樣式和寬度。優(yōu)化思路有兩個(gè)。一個(gè)是在shouldRepaint里嚴(yán)格控制重繪條件數(shù)據(jù)沒變就返回 false另一個(gè)是把文本樣式這類不變的對(duì)象提取成 painter 的靜態(tài)成員或 final 字段避免 paint 方法里重復(fù)創(chuàng)建。改完之后頁面切換順滑多了。4.4 概率配置與統(tǒng)計(jì)結(jié)果偏差較大后臺(tái)配置了 50% 中獎(jiǎng)率但統(tǒng)計(jì)面板顯示的中獎(jiǎng)率只有 30%。這種情況通常不是統(tǒng)計(jì)代碼的問題而要看抽獎(jiǎng)算法的實(shí)現(xiàn)。比如如果每次抽獎(jiǎng)是先在獎(jiǎng)品列表上生成一個(gè)隨機(jī)索引但獎(jiǎng)品列表里“未中獎(jiǎng)”對(duì)應(yīng)的分區(qū)過大那實(shí)際中獎(jiǎng)率自然和配置參數(shù)不一致。我用一個(gè)模擬腳本驗(yàn)證過在純 Dart 環(huán)境里模擬 10000 次抽獎(jiǎng)把每次的中獎(jiǎng)結(jié)果記錄下來再和統(tǒng)計(jì)面板輸出對(duì)比。這樣做可以同時(shí)驗(yàn)證抽獎(jiǎng)算法的數(shù)學(xué)正確性和統(tǒng)計(jì)模塊的記錄準(zhǔn)確性。如果模擬結(jié)果符合配置概率但真實(shí)用戶數(shù)據(jù)偏差大就要考慮是不是用戶抽獎(jiǎng)次數(shù)太少隨機(jī)波動(dòng)還沒收斂。這時(shí)候不用急著改代碼先攢數(shù)據(jù)再觀察。4.5 shared_preferences 初始化時(shí)序問題在 OpenHarmony 上如果SharedPreferences插件要實(shí)現(xiàn)異步初始化稍有疏忽就會(huì)在讀取統(tǒng)計(jì)值時(shí)拿到 null。我把統(tǒng)計(jì)管理器的init()設(shè)計(jì)成Future在main()里等它完成后再runApp保證 UI 第一次展示統(tǒng)計(jì)值時(shí)數(shù)據(jù)已經(jīng)就緒。Futurevoid main() async { WidgetsFlutterBinding.ensureInitialized(); await StatisticsManager.instance.init(); runApp(const LuckyApp()); }這樣做的壞處是會(huì)略微增加冷啟動(dòng)耗時(shí)但換來的穩(wěn)定性值得。如果你的統(tǒng)計(jì)面板不在啟動(dòng)頁面上當(dāng)然也可以把 init 放到頁面加載時(shí)再執(zhí)行按需初始化。把數(shù)據(jù)統(tǒng)計(jì)做完之后這個(gè)幸運(yùn)大轉(zhuǎn)盤 app 的“感知”層面就閉環(huán)了。你能看到用戶哪怕只是你自己什么時(shí)間在玩、獎(jiǎng)品分布是什么樣、中獎(jiǎng)率和配置的偏差有多少這些數(shù)據(jù)能直接指導(dǎo)下一輪迭代——比如哪個(gè)獎(jiǎng)檔太小導(dǎo)致總不中、哪個(gè)時(shí)段活躍度低需要做活動(dòng)刺激。我個(gè)人在實(shí)際操作中的體會(huì)是統(tǒng)計(jì)模塊的難點(diǎn)從來不是寫幾個(gè)計(jì)數(shù)器而是想清楚“什么數(shù)據(jù)值得記、什么時(shí)機(jī)記最準(zhǔn)、怎么存才靠譜”。把這三個(gè)問題想透代碼量再少也是個(gè)能用、能擴(kuò)展的模塊。這期的實(shí)現(xiàn)保留了明細(xì)文件這一層后續(xù)你真的要上服務(wù)端、做跨端數(shù)據(jù)同步也可以基于這些本地記錄做增量上傳歷史數(shù)據(jù)結(jié)構(gòu)不用推倒重來。希望這篇對(duì)正在做相似功能的人有幫助下期我打算把數(shù)據(jù)這一塊的“設(shè)置頁”和“用戶配置持久化”也補(bǔ)上到時(shí)候繼續(xù)聊。