作為一個(gè)在 HarmonyOS 應(yīng)用開發(fā)里泡了挺久的人我對(duì)“卡頓”兩個(gè)字特別敏感。大部分剛上手的朋友遇到性能問(wèn)題第一反應(yīng)就是優(yōu)化算法、精簡(jiǎn)布局但很多時(shí)候真正的元兇不是算法本身而是你讓 CPU 干重活的方式不對(duì)。HarmonyOS 的異步編程模型里Future 和 Callback 看似只是回調(diào)風(fēng)格的區(qū)別但在優(yōu)化 CPU 密集計(jì)算這件事上兩者的用法、邊界和收益差別非常大。這篇內(nèi)容我不打算講枯燥的 API 手冊(cè)而是從一個(gè)真實(shí)計(jì)算場(chǎng)景出發(fā)聊聊怎么用這兩套模型把耗時(shí)任務(wù)從主線程手里搶出來(lái)讓它該并行并行、該回報(bào)回報(bào)最終讓界面保持流暢。1. 先搞清楚CPU 計(jì)算和主線程之間的“賬本”怎么算1.1 主線程不是不能算而是預(yù)算太少HarmonyOS 應(yīng)用的主線程也被叫做 UI 線程承擔(dān)著事件分發(fā)、布局測(cè)量、繪制渲染、動(dòng)畫回調(diào)這一大堆活。設(shè)備屏幕刷新率通常是 60Hz 或 90Hz、120Hz按 60Hz 算留給每一幀的時(shí)間大約是 16.6 毫秒。也就是說(shuō)你的主線程里所有任務(wù)加在一起必須在這 16.6 毫秒里干完否則就會(huì)掉幀、卡頓、甚至觸發(fā)系統(tǒng)層面的 ANR。很多人對(duì)“計(jì)算任務(wù)”沒有概念覺得循環(huán)幾十萬(wàn)次也就一兩毫秒。實(shí)際上當(dāng)你要處理圖像濾波、音頻特征提取、復(fù)雜物理模擬、大量數(shù)據(jù)統(tǒng)計(jì)時(shí)一次 CPU 密集運(yùn)算動(dòng)輒幾百毫秒甚至幾秒。這種任務(wù)放在主線程里跑就像一個(gè)人在單行道上搬磚后面所有的車觸摸事件、繪制指令、動(dòng)畫回調(diào)都得等著。我見過(guò)一個(gè)案例某個(gè)統(tǒng)計(jì)頁(yè)面在進(jìn)入時(shí)會(huì)對(duì)過(guò)去一年的數(shù)據(jù)做聚合排序直接在生命周期回調(diào)里同步執(zhí)行結(jié)果進(jìn)入頁(yè)面白屏了將近兩秒用戶都以為應(yīng)用死了。所以第一步不是急著寫異步代碼而是承認(rèn)一個(gè)事實(shí)CPU 密集計(jì)算不應(yīng)該出現(xiàn)在主線程的預(yù)算里。異步編程解決的是“結(jié)果什么時(shí)候回來(lái)”的問(wèn)題而線程切換解決的是“任務(wù)在哪里執(zhí)行”的問(wèn)題。兩者必須配合使用。1.2 異步不等于不卡關(guān)鍵是“換線程”HarmonyOS 提供了兩套異步手段Callback 和 FuturePromise 是 Future 的一種典型實(shí)現(xiàn)。很多初學(xué)者以為把同步代碼改成回調(diào)就是異步了這是誤區(qū)。比如下面這種寫法setTimeout(() { // 在這里做小時(shí)級(jí)別的 CPU 密集循環(huán) for (let i 0; i 500000000; i) { // 大量浮點(diǎn)運(yùn)算 } }, 0);看著像是異步了但實(shí)際上定時(shí)器回調(diào)仍然在主線程執(zhí)行密集循環(huán)照樣把主線程堵死。真正的做法是把循環(huán)扔到子線程去跑主線程只負(fù)責(zé)發(fā)起任務(wù)、等待結(jié)果。HarmonyOS 里我們通常要借助任務(wù)池或 Worker 機(jī)制創(chuàng)建子線程執(zhí)行環(huán)境然后用 Future 或 Callback 把結(jié)果收回來(lái)。以我的經(jīng)驗(yàn)先想清楚“任務(wù)在哪執(zhí)行”再想“用什么回調(diào)風(fēng)格接收結(jié)果”順序不能反。你甚至可以把任務(wù)丟給 Worker然后主線程通過(guò)一個(gè) Future 等待返回這樣界面該渲染渲染該響應(yīng)響應(yīng)計(jì)算在后臺(tái)悄悄進(jìn)行。1.3 判斷一個(gè)計(jì)算適不適合異步化的標(biāo)準(zhǔn)不是所有 CPU 計(jì)算都值得異步化。我一般用三個(gè)標(biāo)準(zhǔn)來(lái)判斷執(zhí)行時(shí)長(zhǎng)單次耗時(shí)超過(guò) 16 毫秒就該考慮超過(guò) 100 毫秒必須處理。是否可拆分如果計(jì)算能被切成多個(gè)獨(dú)立片段比如分塊統(tǒng)計(jì)、分批渲染那異步化的收益會(huì)更大因?yàn)榭梢圆l(fā)。耦合度如果計(jì)算結(jié)果會(huì)被下一個(gè)步驟直接消費(fèi)且中間沒有 UI 更新點(diǎn)那么至少要保證它不在主線程執(zhí)行否則可以做成同步但挪到子線程。這三條標(biāo)準(zhǔn)看起來(lái)簡(jiǎn)單但在實(shí)際項(xiàng)目中非常有用。它能避免你陷入一個(gè)常見誤區(qū)為了一段 3 毫秒的計(jì)算引入復(fù)雜的異步流程得不償失。2. Callback 與 Future同樣是異步但控制的“顆粒度”完全不一樣2.1 Callback 模型簡(jiǎn)單直接但嵌套深了會(huì)窒息Callback 就是你把一個(gè)函數(shù)作為參數(shù)傳給另一個(gè)函數(shù)等異步操作完成后被調(diào)用。HarmonyOS 里很多底層能力比如傳感器數(shù)據(jù)讀取、文件 IO都提供 Callback 風(fēng)格接口。它最大的優(yōu)點(diǎn)是真的簡(jiǎn)單發(fā)起任務(wù)時(shí)直接把下一步要做的事寫好邏輯鏈路直觀。但 Callback 的缺點(diǎn)在復(fù)雜業(yè)務(wù)里格外突出。一旦你的 CPU 計(jì)算需要串聯(lián)多個(gè)步驟比如先讀取數(shù)據(jù)再過(guò)濾再計(jì)算特征再寫回緩存回調(diào)層級(jí)會(huì)越套越深代碼的可讀性急劇下降。更麻煩的是異常處理每一步都可能出錯(cuò)你得在每個(gè)回調(diào)里單獨(dú)判斷很容易漏掉分支。所以我對(duì) Callback 的使用原則是適合簡(jiǎn)短的一次性任務(wù)或者是需要高頻次進(jìn)度反饋的場(chǎng)景。比如一個(gè)計(jì)算函數(shù)支持分片回調(diào)每算完 10% 就通知一次進(jìn)度這種用 Callback 非常自然。2.2 Future 模型鏈?zhǔn)浇M合與統(tǒng)一異常處理的價(jià)值FutureHarmonyOS 里常以 Promise 形式出現(xiàn)代表一個(gè)尚未完成但最終會(huì) resolve 或 reject 的操作。它解決了 Callback 兩個(gè)核心痛點(diǎn)第一可以通過(guò) then 鏈把多個(gè)異步步驟串起來(lái)避免嵌套地獄第二異?？梢悦芭莸芥?zhǔn)轿膊拷y(tǒng)一處理。給你看一個(gè)直觀對(duì)比。假設(shè)我們的 CPU 計(jì)算流程是從緩存拿原始數(shù)據(jù) → 數(shù)據(jù)標(biāo)準(zhǔn)化 → 執(zhí)行核心計(jì)算 → 格式化結(jié)果。Callback 寫法大概是這樣function runWithCallback(callback: (err: Error | null, result?: number[]) void) { readCache((cacheErr, rawData) { if (cacheErr) { callback(cacheErr); return; } normalize(rawData, (normErr, normed) { if (normErr) { callback(normErr); return; } compute(normed, (computeErr, output) { if (computeErr) { callback(computeErr); return; } format(output, (formatErr, final) { if (formatErr) { callback(formatErr); return; } callback(null, final); }); }); }); }); }一旦進(jìn)入四層嵌套不管是閱讀還是修改人都會(huì)很吃力。用 Future 改寫后鏈條明顯清晰很多function runWithFuture(): Promisenumber[] { return readCache() .then(rawData normalize(rawData)) .then(normed compute(normed)) .then(output format(output)) .catch(err { console.error(計(jì)算流程失敗: ${err.message}); throw err; }); }2.3 如何根據(jù)計(jì)算場(chǎng)景選擇合理的 API 風(fēng)格沒有銀彈但有一個(gè)簡(jiǎn)單實(shí)用的選擇矩陣場(chǎng)景特征推薦風(fēng)格理由一次性的后臺(tái)計(jì)算結(jié)果只用于 UI 展示Future鏈?zhǔn)竭壿嬊逦惓Ｈ菀捉y(tǒng)一處理計(jì)算分片執(zhí)行需要實(shí)時(shí)反饋進(jìn)度Callback每次分片完成后自然觸發(fā)回調(diào)天然貼合進(jìn)度語(yǔ)義多個(gè)計(jì)算步驟串聯(lián)且每步依賴上一步Futurethen 鏈非常直觀中間狀態(tài)通過(guò)閉包傳遞多個(gè)獨(dú)立計(jì)算需要并行最后匯總Future可以用并發(fā)等待機(jī)制如 Promise.all聚合結(jié)果與系統(tǒng)底層 API 交互接口本身只提供 CallbackCallback順著平臺(tái)接口風(fēng)格走不要強(qiáng)行包裝我個(gè)人的傾向是核心業(yè)務(wù)邏輯盡量用 Future寧可包裝一層也要保證代碼可維護(hù)只有進(jìn)度類回調(diào)這種天然事件驅(qū)動(dòng)的場(chǎng)景才直接用 Callback。理由很簡(jiǎn)單CPU 計(jì)算的異步流程通常不止一步后續(xù)大概率會(huì)擴(kuò)展Future 的擴(kuò)展性更好。3. 用 Future 把一次 CPU 密集計(jì)算改造成流水線3.1 從一次真實(shí)的掉幀現(xiàn)場(chǎng)說(shuō)起我之前處理過(guò)的某圖像處理 Demo需要在一張 4000×3000 的圖片上做邊緣檢測(cè)。原始實(shí)現(xiàn)非常直接在拿到圖片數(shù)據(jù)后同步執(zhí)行一個(gè)雙層循環(huán)對(duì)每個(gè)像素做灰度矩陣運(yùn)算。在真機(jī)上測(cè)試整段計(jì)算耗時(shí)約 780 毫秒。結(jié)果就是用戶觸發(fā)處理按鈕后界面像被凍結(jié)一樣進(jìn)度條紋絲不動(dòng)直到計(jì)算結(jié)束才一次性刷新。這還只是視覺上的問(wèn)題期間如果用戶又滑動(dòng)了頁(yè)面或者點(diǎn)了別的按鈕事件全部堆積在主線程隊(duì)列等計(jì)算結(jié)束后瘋狂補(bǔ)執(zhí)行畫面會(huì)瞬間亂跳。這就是一個(gè)典型的“CPU 計(jì)算堵死主線程”問(wèn)題。我的目標(biāo)很明確把 780 毫秒的計(jì)算時(shí)間徹底移出主線程并通過(guò) Future 重組流程讓 UI 在計(jì)算期間保持響應(yīng)。3.2 拆解步驟同步計(jì)算如何變成 Future 鏈改造前我把整個(gè)流程拆成了三個(gè)獨(dú)立的計(jì)算單元單元 A把原始圖片數(shù)據(jù)轉(zhuǎn)為灰度矩陣。單元 B對(duì)灰度矩陣執(zhí)行邊緣檢測(cè)卷積。單元 C把處理后的矩陣重新編碼成可顯示的圖像數(shù)據(jù)。這三個(gè)單元都可以獨(dú)立運(yùn)行且每個(gè)單元耗時(shí)占比大約是 20%、60%、20%。最關(guān)鍵的是單元 A 和單元 C 涉及像素格式轉(zhuǎn)換屬于純計(jì)算單元 B 是卷積涉及大量浮點(diǎn)乘加它們是天然適合子線程執(zhí)行的 CPU 密集任務(wù)。我用 Future 重新設(shè)計(jì)了流程。核心思路是每個(gè)單元都返回一個(gè) Promise后續(xù)單元通過(guò) then 接收前一個(gè)單元的結(jié)果最終在鏈的末端把結(jié)果交給 UI 層。關(guān)鍵點(diǎn)在于計(jì)算本身要放到子線程環(huán)境里而不是直接在 Promise 構(gòu)造器里同步執(zhí)行。async function processImage(source: PixelData): PromiseImageData { // 灰度轉(zhuǎn)換在子線程中執(zhí)行 const grayMatrix: number[][] await runInTaskPool(() convertToGray(source)); // 邊緣檢測(cè)卷積同樣在子線程中執(zhí)行 const edgeMatrix: number[][] await runInTaskPool(() applySobel(grayMatrix)); // 結(jié)果編碼第三次子線程執(zhí)行 const output: ImageData await runInTaskPool(() encodeToImage(edgeMatrix)); return output; }這段代碼里的runInTaskPool是對(duì) HarmonyOS 任務(wù)池的封裝它接收一個(gè)函數(shù)把函數(shù)投遞到子線程執(zhí)行并返回一個(gè) Promise。主線程這邊調(diào)用時(shí)await會(huì)掛起當(dāng)前流程但事件循環(huán)沒有被阻塞UI 依然能正常渲染。3.3 每一步為什么要這樣設(shè)計(jì)這里我想重點(diǎn)解釋兩個(gè)容易被忽略的設(shè)計(jì)點(diǎn)第一為什么每個(gè)計(jì)算單元都單獨(dú)投遞到任務(wù)池而不是把三個(gè)單元合成一個(gè)大函數(shù)投進(jìn)去因?yàn)榉珠_投遞后每一步之間主線程都有機(jī)會(huì)處理其他事件比如更新進(jìn)度提示、響應(yīng)用戶操作。如果合成一個(gè)大函數(shù)子線程里跑完所有計(jì)算再一次性返回用戶看到的就是“點(diǎn)了按鈕后長(zhǎng)時(shí)間無(wú)反饋”交互體驗(yàn)依然不好。第二為什么用await而不是在 then 里嵌套從語(yǔ)義上講await是 Future 的語(yǔ)法糖但它讓代碼看起來(lái)更像同步邏輯調(diào)試也更方便。不過(guò)要注意await會(huì)創(chuàng)建隱式上下文如果你在循環(huán)里寫await要小心每次迭代都可能被調(diào)度器拆成多次任務(wù)反而增加開銷。在我們的場(chǎng)景里沒有循環(huán)三個(gè)await串行執(zhí)行簡(jiǎn)潔且可控。3.4 改造后的效果與鏈路開銷改造后我在同一臺(tái)真機(jī)上重新測(cè)試主線程的卡頓徹底消失因?yàn)樗邢袼匮h(huán)都在子線程執(zhí)行。圖像處理總耗時(shí)反而從 780 毫秒降到了 810 毫秒左右略微增加這是線程調(diào)度和線程間數(shù)據(jù)傳遞的固有開銷但你換來(lái)了完全不掉幀的交互體驗(yàn)。這里想提醒一下不是所有異步化改造都會(huì)讓計(jì)算變快很多時(shí)候只是讓計(jì)算不阻塞 UI性能數(shù)字反而會(huì)微降。衡量標(biāo)準(zhǔn)應(yīng)該是用戶體驗(yàn)而不是單純的 FLOPS。如果你非得追求總耗時(shí)也下降那就要引入并發(fā)把相互獨(dú)立的計(jì)算單元并行執(zhí)行而不是串行。這就涉及到第 5 部分要講的多核調(diào)度。4. 用 Callback 做分片進(jìn)度回報(bào)從“轉(zhuǎn)圈”到“知道跑到第幾步”4.1 為什么進(jìn)度反饋在 CPU 計(jì)算中如此重要Future 鏈能很好地組織流程但它不適合做高頻進(jìn)度通知。原因很簡(jiǎn)單Future 只關(guān)心“最終的結(jié)果”中間狀態(tài)需要通過(guò)額外手段透出。比如你可以在每個(gè) then 階段手動(dòng)調(diào)用一個(gè)進(jìn)度函數(shù)但這種做法粒度太粗只能報(bào)“灰度轉(zhuǎn)換完成”“卷積完成”無(wú)法報(bào)“卷積計(jì)算到第 37%”。當(dāng)任務(wù)耗時(shí)較長(zhǎng)用戶最需要的是確定性和掌控感。一個(gè)不動(dòng)的進(jìn)度條讓人焦慮一個(gè)不斷更新但準(zhǔn)確反映狀態(tài)的進(jìn)度條會(huì)大幅提升耐心。Callback 在這個(gè)場(chǎng)景下的優(yōu)勢(shì)就體現(xiàn)出來(lái)了你可以把它設(shè)計(jì)成在每個(gè)分片計(jì)算完成后被調(diào)用攜帶當(dāng)前進(jìn)度、剩余時(shí)間預(yù)估、甚至當(dāng)前處理的數(shù)據(jù)塊信息。4.2 一個(gè)典型的分片 Callback 設(shè)計(jì)假設(shè)我們的 CPU 計(jì)算是對(duì)一個(gè)超大數(shù)組做排序加過(guò)濾統(tǒng)計(jì)。數(shù)組長(zhǎng)度是 1000 萬(wàn)條記錄單次全量處理大約需要 3 秒。我先把它切成 N 個(gè)分片每個(gè)分片在子線程里單獨(dú)處理處理完成后通過(guò) Callback 上報(bào)一次進(jìn)度。interface ProgressInfo { stage: string; percent: number; } function processLargeArray( data: number[], onProgress: (info: ProgressInfo) void, onComplete: (result: number) void, onError: (err: Error) void ) { const CHUNK_SIZE 250000; const totalChunks Math.ceil(data.length / CHUNK_SIZE); let processedChunks 0; let stageResult 0; for (let i 0; i totalChunks; i) { const chunk data.slice(i * CHUNK_SIZE, (i 1) * CHUNK_SIZE); runInTaskPool(() { // 對(duì)分片排序并累加統(tǒng)計(jì) chunk.sort((a, b) a - b); let sum 0; for (const item of chunk) { sum item; } return sum; }).then(chunkSum { stageResult chunkSum; processedChunks; onProgress({ stage: sort-and-sum, percent: Math.floor((processedChunks / totalChunks) * 100) }); if (processedChunks totalChunks) { onComplete(stageResult); } }).catch(err { onError(err); }); } }注意這里有個(gè)并發(fā)隱患這個(gè)循環(huán)其實(shí)是在同時(shí)發(fā)起多個(gè)子線程任務(wù)每個(gè)分片并行執(zhí)行?；卣{(diào)觸發(fā)的順序不一定和切分順序一致所以進(jìn)度計(jì)算用的是“已完成分片數(shù) / 總分片數(shù)”而不是假設(shè)分片 i 一定先于分片 i1 完成。4.3 進(jìn)度上報(bào)的頻率控制別讓回調(diào)轟炸 UI雖然 Callback 很好用但如果不做頻率控制進(jìn)度回調(diào)可能一秒鐘觸發(fā)幾十次UI 層頻繁更新進(jìn)度條反而引起額外的主線程負(fù)擔(dān)。我常用的做法是閾值節(jié)流只有當(dāng)前進(jìn)度和上一次上報(bào)進(jìn)度之間的差值超過(guò)一定比例比如 5%才真正觸發(fā) UI 更新。另外如果進(jìn)度更新只是刷新一個(gè)文本和一條進(jìn)度條我傾向于把 UI 更新函數(shù)包在一個(gè)輕量級(jí)節(jié)流器里比如每 100 毫秒最多更新一次。這樣既保證用戶能看到變化又不會(huì)讓主線程被進(jìn)度刷新本身拖累。其實(shí)你仔細(xì)想想就明白進(jìn)度條本身是給人看的人眼對(duì) 100 毫秒內(nèi)的變化感知很弱所以 10Hz 的刷新率在進(jìn)度反饋場(chǎng)景已經(jīng)足夠了。過(guò)度刷新純屬浪費(fèi)。4.4 取消機(jī)制與回調(diào)安全的收尾處理Callback 方案還有一個(gè)容易被忽略的問(wèn)題如果用戶在中途退出了頁(yè)面或者不再需要計(jì)算結(jié)果回調(diào)仍然會(huì)被觸發(fā)可能造成內(nèi)存泄漏或者訪問(wèn)已銷毀 UI 組件。我在實(shí)際開發(fā)中養(yǎng)成了一個(gè)習(xí)慣凡是使用 Callback 的長(zhǎng)任務(wù)一定會(huì)設(shè)計(jì)一個(gè)取消令牌或狀態(tài)標(biāo)志。let cancelled false; function cancelProcessing() { cancelled true; } function processLargeArray(...) { // 在每個(gè)分片回調(diào)里先檢查 cancelled // 如果已取消就不要再累加結(jié)果也不再更新進(jìn)度 if (cancelled) { return; } }更進(jìn)一步回調(diào)里如果要更新 UI一定要通過(guò)安全的 UI 更新通道并先判斷頁(yè)面或組件實(shí)例是否仍然存活。這種細(xì)節(jié)看起來(lái)小但在長(zhǎng)耗時(shí)計(jì)算中非常關(guān)鍵因?yàn)橛脩舸蟾怕蕰?huì)在計(jì)算期間做其他操作生命周期發(fā)生變化是常態(tài)。5. 把計(jì)算任務(wù)打散到多核并發(fā)參數(shù)與真實(shí)收益5.1 并發(fā)數(shù)不是越大越好線程切換的開銷賬本當(dāng)我提到可以對(duì)分片做并行處理時(shí)很多人第一反應(yīng)是“把分片數(shù)量設(shè)得越多越好并發(fā)拉滿”。現(xiàn)實(shí)完全不是這樣。HarmonyOS 設(shè)備通常有 4 核、8 核甚至更多核心但你的任務(wù)池線程數(shù)量是有限的而且線程切換是有代價(jià)的。當(dāng)一個(gè) CPU 核心在多個(gè)線程之間來(lái)回切換時(shí)每次切換都要保存和恢復(fù)上下文這些開銷不僅不產(chǎn)出任何計(jì)算結(jié)果還會(huì)把 CPU 時(shí)間片切碎。我用一個(gè)簡(jiǎn)單模型來(lái)理解這事假設(shè)單個(gè)分片計(jì)算需要 10 毫秒數(shù)據(jù)分成 40 個(gè)分片。如果串行執(zhí)行總耗時(shí)大約 400 毫秒。如果并發(fā)數(shù)設(shè)為 4理想情況下總耗時(shí)約 100 毫秒但實(shí)際因?yàn)榫€程創(chuàng)建、調(diào)度、等待可能在 120 到 150 毫秒之間。如果并發(fā)數(shù)設(shè)為 40理論上只有 10 毫秒但線程切換成本會(huì)讓實(shí)際耗時(shí)飆升到 300 毫秒以上而且會(huì)擠壓其他應(yīng)用和系統(tǒng)服務(wù)的線程。并發(fā)收益的曲線是倒 U 型不是單調(diào)遞增。5.2 如何選擇合理的并發(fā)數(shù)我的經(jīng)驗(yàn)法則是并發(fā)數(shù)接近但不超過(guò)設(shè)備核心數(shù)。更具體地說(shuō)CPU 密集任務(wù)建議設(shè)置為設(shè)備可用核心數(shù) - 1留出一個(gè)核心給主線程和系統(tǒng)響應(yīng)使用。如果設(shè)備有 8 核那么你設(shè)置 7 個(gè)并發(fā)計(jì)算分片是比較穩(wěn)妥的。HarmonyOS 的 API 里你可以獲取系統(tǒng)的 CPU 核心數(shù)量信息。在高版本系統(tǒng)中任務(wù)池本身也會(huì)根據(jù)設(shè)備負(fù)載情況調(diào)整并發(fā)度但作為應(yīng)用開發(fā)者我仍然建議手動(dòng)控制并發(fā)數(shù)特別是當(dāng)你的計(jì)算任務(wù)分片特別多時(shí)要避免一次性把所有分片都塞進(jìn)任務(wù)池。一個(gè)實(shí)用的做法是采用固定窗口的調(diào)度維護(hù)一個(gè)正在執(zhí)行的任務(wù)列表當(dāng)任務(wù)完成一個(gè)才從待處理隊(duì)列中取出下一個(gè)分片投遞。這樣既保證了并發(fā)數(shù)不超過(guò)上限又保證了任務(wù)隊(duì)列的吞吐穩(wěn)定。5.3 實(shí)測(cè)數(shù)據(jù)對(duì)比不同并發(fā)策略在真實(shí)設(shè)備上的表現(xiàn)我在一臺(tái) 8 核真機(jī)上對(duì)同樣的 1000 萬(wàn)分片統(tǒng)計(jì)任務(wù)做了三組實(shí)驗(yàn)策略并發(fā)策略總耗時(shí)主線程掉幀數(shù)說(shuō)明串行子線程13.2 秒0UI 完全流暢但總耗時(shí)最長(zhǎng)用戶等待久全量并射40 個(gè)分片全部同時(shí)投遞1.9 秒0速度快但 CPU 占用飆到 80% 以上發(fā)熱明顯窗口限流固定 4 并發(fā) 隊(duì)列消費(fèi)2.3 秒0速度適中CPU 占用約 45%發(fā)熱可控全量并射看起來(lái)總耗時(shí)最短但代價(jià)是整機(jī)資源被占滿。如果你在頁(yè)面上還播放了視頻或者有動(dòng)畫其他線程很可能搶不到資源體驗(yàn)反而下降。我最終采用的是窗口限流方案因?yàn)樗凇坝?jì)算速度”和“系統(tǒng)穩(wěn)定性”之間取得了更好的平衡。5.4 優(yōu)先級(jí)與資源感知讓系統(tǒng)知道你在做什么除了并發(fā)數(shù)任務(wù)優(yōu)先級(jí)也是影響 CPU 計(jì)算體驗(yàn)的重要參數(shù)。HarmonyOS 任務(wù)池允許為任務(wù)設(shè)置優(yōu)先級(jí)高優(yōu)先級(jí)任務(wù)會(huì)優(yōu)先被調(diào)度。這里我的建議是前臺(tái)可見的計(jì)算任務(wù)可以適當(dāng)提高優(yōu)先級(jí)但不要讓所有分片都是高優(yōu)先級(jí)否則會(huì)擠占系統(tǒng)渲染和事件處理。后臺(tái)預(yù)加載類計(jì)算務(wù)必使用默認(rèn)或低于默認(rèn)的優(yōu)先級(jí)避免影響用戶當(dāng)前的操作。還有一個(gè)隱藏點(diǎn)要感知設(shè)備功耗狀態(tài)。設(shè)備在低電量模式下會(huì)限制 CPU 頻率此時(shí) CPU 計(jì)算會(huì)變得很慢。如果你的應(yīng)用在低電量下堅(jiān)持全速并發(fā)不僅算不快還可能加劇設(shè)備發(fā)熱和耗電。一個(gè)負(fù)責(zé)任的做法是在低電量模式下主動(dòng)降低并發(fā)數(shù)或者延遲非關(guān)鍵計(jì)算到電量充足時(shí)再執(zhí)行。6. 優(yōu)化后的實(shí)際效果與幾個(gè)值得注意的取舍6.1 最終方案的落地形態(tài)經(jīng)過(guò)前面幾輪調(diào)整我最終使用的方案是 Future 負(fù)責(zé)流程編排、Callback 負(fù)責(zé)進(jìn)度反饋、任務(wù)池窗口限流負(fù)責(zé)并發(fā)調(diào)度。它們各司其職互不干擾?？赡苡腥擞X得兩套模型混用會(huì)導(dǎo)致代碼混亂但在我看來(lái)只要約定清楚“Future 管流程Callback 管事件”反而比單一模型更清晰。落地后的頁(yè)面交互變成這樣用戶點(diǎn)擊處理按鈕按鈕變成可取消狀態(tài)進(jìn)度條開始平滑增長(zhǎng)每個(gè)階段顯示對(duì)應(yīng)的文字提示“正在排序分片”“正在統(tǒng)計(jì)特征”“正在生成結(jié)果”。整個(gè)計(jì)算期間用戶還可以正常上下滾動(dòng)頁(yè)面、點(diǎn)擊其他按鈕不再有卡頓感。6.2 我在調(diào)試中遇到的兩個(gè)隱蔽問(wèn)題問(wèn)題一子線程和主線程間傳遞大數(shù)據(jù)對(duì)象的拷貝成本。最開始我把整個(gè)數(shù)組直接傳給子線程每個(gè)分片在子線程里處理完后再把結(jié)果傳回主線程。數(shù)據(jù)量大的時(shí)候線程間通信的序列化和反序列化開銷非常可觀甚至抵消了并行收益。后來(lái)的做法是在任務(wù)池中直接完成大部分聚合運(yùn)算只把最終幾個(gè)數(shù)字傳回主線程而不是傳遞整個(gè)中間結(jié)果集。這提醒我設(shè)計(jì)計(jì)算任務(wù)時(shí)要盡量減少跨線程的數(shù)據(jù)傳輸。問(wèn)題二異常的靜默失敗。子線程中的計(jì)算如果拋出異常Future 會(huì)在 Promise 中變成 rejected 狀態(tài)但如果你忘了在鏈尾捕獲錯(cuò)誤日志可能一閃而過(guò)用戶看到的是“什么也沒發(fā)生”。我在調(diào)試某個(gè)統(tǒng)計(jì)頁(yè)面時(shí)就遇到過(guò)數(shù)據(jù)里混入了非法值在子線程里拋了異常結(jié)果真實(shí)原因被誤判成了“算法太慢”。最后我養(yǎng)成了習(xí)慣所有投遞到任務(wù)池的函數(shù)入口和出口都包上 try/catch并保證任何錯(cuò)誤都會(huì)回調(diào)到主線程打印日志。6.3 給同樣在做 CPU 計(jì)算優(yōu)化的人一點(diǎn)個(gè)人體會(huì)如果你正要著手優(yōu)化 HarmonyOS 應(yīng)用里的 CPU 密集計(jì)算我的建議是先量化再改造。在動(dòng)手寫異步代碼之前先明確計(jì)算耗時(shí)的分布、主線程的影響范圍、以及用戶可接受的等待時(shí)長(zhǎng)。然后按照“先換線程再定風(fēng)格后調(diào)并發(fā)”的順序推進(jìn)。換線程解決卡頓Future 或 Callback 解決協(xié)作方式并發(fā)調(diào)節(jié)解決效率。每一步都有明確的驗(yàn)證指標(biāo)不要一口氣全改完再測(cè)否則出了問(wèn)題你根本不知道是哪一環(huán)導(dǎo)致的。另外我特別建議你在真機(jī)上驗(yàn)證而不要在模擬器里做性能判斷。CPU 核心數(shù)、調(diào)度策略、功耗管理在真機(jī)和模擬器上的差異很大很多在模擬器上表現(xiàn)完美的方案到了真機(jī)才發(fā)現(xiàn)并發(fā)數(shù)設(shè)置得不合理。調(diào)試的時(shí)候可以把設(shè)備連上性能分析工具同時(shí)看 CPU 占用率、線程數(shù)量和主線程幀率這些數(shù)據(jù)比任何斷言都更有說(shuō)服力。