1. 負(fù)載異常與功耗問(wèn)題的現(xiàn)象定義先說(shuō)一個(gè)背景。Flutter 落地 OpenHarmony 生態(tài)之后應(yīng)用層遇到最多、最讓人頭疼的反饋不是崩潰也不是功能缺失而是負(fù)載和功耗。負(fù)載異常的表現(xiàn)千奇百怪有的應(yīng)用一掛后臺(tái) CPU 占用率不降反升有的應(yīng)用靜態(tài)頁(yè)面也沒(méi)人碰耗電曲線開(kāi)始抬頭還有一類更隱蔽前臺(tái)操作流順暢但整機(jī)持續(xù)發(fā)熱用戶感知是“這應(yīng)用耗電”。表面上看是功耗問(wèn)題實(shí)際上根源是負(fù)載異常兩者互為因果。定位這類問(wèn)題前先把概念理清楚。負(fù)載異常指的是應(yīng)用進(jìn)程的資源占用不合理常見(jiàn)指標(biāo)包括CPU 占用率異常偏高、特定線程起火、線程數(shù)爆炸式增長(zhǎng)、IO 調(diào)度異常頻繁、GPU 幀構(gòu)建耗時(shí)異常、內(nèi)存換頁(yè)頻繁導(dǎo)致內(nèi)核軟中斷加劇。功耗問(wèn)題則是整機(jī)耗電維度的表現(xiàn)在 OHOS 上可以量化為功耗模型回歸、電池電流采樣異常、單應(yīng)用耗電排名靠前、亮屏待機(jī)下載電曲線不收斂。負(fù)載異常是原因功耗問(wèn)題是結(jié)果但不全是線性關(guān)系。比如后臺(tái)一個(gè)空轉(zhuǎn)定時(shí)器CPU 可能只占 5%但持續(xù)片上電流可能拉高 200mA 以上功率模型拆解后用戶感知的耗電量依然很明顯。另外要澄清一個(gè)常見(jiàn)誤區(qū)很多人拿到測(cè)試報(bào)告就說(shuō)“Flutter 引擎耗電”“OHOS 適配層耗電”這種結(jié)論太粗暴。Flutter 在 OHOS 上的運(yùn)行鏈路由 Dart 虛擬機(jī)、引擎渲染線程、平臺(tái)通道、GPU 接入層組成每一層負(fù)載高都可能有不同的觸發(fā)源不能籠統(tǒng)甩鍋給某一端。合理的做法是帶著監(jiān)控?cái)?shù)據(jù)逐層下鉆先看進(jìn)程整體負(fù)載再細(xì)分線程然后對(duì)照幀調(diào)度和網(wǎng)絡(luò)請(qǐng)求情況最終定位到具體代碼路徑。根據(jù)我的實(shí)際經(jīng)驗(yàn)這類問(wèn)題在項(xiàng)目不同階段出現(xiàn)的形態(tài)也不一樣。開(kāi)發(fā)期遇到的負(fù)載異常通常好定位因?yàn)榇a路徑簡(jiǎn)單跑幾個(gè) profile 就有結(jié)論真正麻煩的是發(fā)布后的線上問(wèn)題用戶設(shè)備型號(hào)雜后臺(tái)存活狀態(tài)差異大只靠開(kāi)發(fā)機(jī)復(fù)現(xiàn)不了. 所以排查思路一定要以“可觀測(cè)性”優(yōu)先把進(jìn)程級(jí)、線程級(jí)、引擎級(jí)的三層數(shù)據(jù)抓到再談優(yōu)化。2. 負(fù)載異常的整體分析思路2.1 先搞清楚是“持續(xù)負(fù)載”還是“瞬時(shí)尖峰”拿到一個(gè)負(fù)載異常的問(wèn)題報(bào)告第一件事不是翻代碼而是確認(rèn)負(fù)載的類型。持續(xù)負(fù)載表現(xiàn)為 CPU 占用率長(zhǎng)時(shí)間維持在高位比如 30% 以上不掉常見(jiàn)于死循環(huán)、無(wú)限觸發(fā)的 Timer、DoWork 事件風(fēng)暴、渲染管線反復(fù)失效重建。瞬時(shí)尖峰表現(xiàn)為負(fù)載偶爾飆一下然后回落常見(jiàn)于集合遍歷、JSON 解析、圖片解碼、導(dǎo)航切換預(yù)構(gòu)建等場(chǎng)景。兩種問(wèn)題的排查策略完全不一樣持續(xù)負(fù)載要抓線程棧瞬時(shí)尖峰要多輪采樣疊加看分布。還有一個(gè)容易被忽略的維度前臺(tái)和后臺(tái)的負(fù)載特征要分開(kāi)度量。OHOS 上應(yīng)用切換到后臺(tái)后系統(tǒng)會(huì)通過(guò)掛起suspend機(jī)制管理進(jìn)程正常來(lái)說(shuō) CPU 占用應(yīng)該降到接近 0。如果應(yīng)用切后臺(tái)后負(fù)載仍然異常說(shuō)明了存在繞過(guò)系統(tǒng)暫停機(jī)制的資源操作。常見(jiàn)元兇包括配置了短周期后臺(tái)任務(wù)、長(zhǎng)連接沒(méi)有正確釋放、Dart Isolate 內(nèi)還有在跑的徹底死循環(huán)、以及第三方 SDK 拉起原生線程。從實(shí)操層面來(lái)說(shuō)想要正確分類負(fù)載單靠應(yīng)用側(cè)埋點(diǎn)不夠通常需要把系統(tǒng)整機(jī)負(fù)載和應(yīng)用進(jìn)程負(fù)載疊加來(lái)看。比如整機(jī) CPU 不高說(shuō)明問(wèn)題與應(yīng)用無(wú)關(guān)整機(jī)高而進(jìn)程高才需要繼續(xù)下鉆。2.2 Flutter 引擎的多線程模型對(duì)定位的影響Flutter 在 OHOS 上的線程模型與原生應(yīng)用差異很大。默認(rèn)情況下引擎會(huì)啟動(dòng)多個(gè)線程包括 UI 線程、Raster 線程、IO 線程還有 Dart 運(yùn)行時(shí)的工作線程。每個(gè)線程的職責(zé)不同但負(fù)載特征不同UIPlatform線程負(fù)責(zé)處理生命周期、輸入事件、平臺(tái)通道調(diào)用如果被阻塞會(huì)直接表現(xiàn)為應(yīng)用卡頓但 CPU 占用不一定高因?yàn)樗赡茉诘却i或等待平臺(tái)消息返回。RasterGPU Raster線程負(fù)責(zé)渲染樹(shù)的光柵化負(fù)載高通常意味著布局復(fù)雜、重繪頻繁、圖形 API 調(diào)用過(guò)度會(huì)體現(xiàn)為 GPU 功耗上升。IO 線程負(fù)責(zé)紋理上傳、圖片解碼等持續(xù) IO 線程繁忙一般是資源加載策略問(wèn)題比如圖片沒(méi)有尺寸緩存、圖片解碼放在 IO 線程反復(fù)執(zhí)行。定位負(fù)載問(wèn)題時(shí)我會(huì)把引擎線程拆出來(lái)逐個(gè)看而不是只看進(jìn)程總 CPU。在 OHOS 上可以用線程級(jí)采樣工具同時(shí)采集所有線程的 CPU 占用和狀態(tài)Running/Uninterruptible/Runnable。判斷重點(diǎn)在于哪條線程占用率高一段時(shí)間內(nèi)各線程耗時(shí)分布有什么變化如果 UI 線程繁忙但 Raster 線程空閑那問(wèn)題基本在 Dart 側(cè)如果 Raster 線程繁忙而 UI 線程空閑那就是繪制指令過(guò)于復(fù)雜需要優(yōu)化布局和重繪邏輯。2.3 建立“現(xiàn)象→線程→代碼路徑”的定位模型我習(xí)慣把定位流程抽象成三層漏斗現(xiàn)象層、線程層、代碼層。現(xiàn)象層回答“是什么樣的負(fù)載異?！本€程層回答“資源消耗發(fā)生在哪條線程”代碼層回答“線程上的具體哪段代碼在消耗”。用這個(gè)模型大多數(shù)問(wèn)題不超過(guò)三個(gè)小時(shí)就有結(jié)論?，F(xiàn)象層不需要代碼介入靠系統(tǒng)工具就能完成。關(guān)鍵是不要被測(cè)試同學(xué)給的模糊描述帶偏比如“應(yīng)用很卡”“手機(jī)很燙”“電量掉得快”這些描述要映射到可量化的指標(biāo)上選一個(gè)錨點(diǎn)指標(biāo)比如整機(jī) CPU或者應(yīng)用 CPU 時(shí)間片或者功耗采樣曲線以這個(gè)錨點(diǎn)延伸記錄系統(tǒng)全部狀態(tài)。線程層就要依賴一些系統(tǒng)級(jí)采樣工具OHOS 上可以臨時(shí)開(kāi) CPU 調(diào)頻策略把大小核綁定關(guān)閉減少變頻對(duì)采樣數(shù)據(jù)的影響確保采樣出的線程占用能夠真實(shí)反映代碼工作量。代碼層則是把線程棧抓回來(lái)對(duì)應(yīng)到我們的代碼位置這一步靠的是對(duì) Flutter 引擎和 Dart 運(yùn)行時(shí)的棧符號(hào)是否齊全的理解。3. 定位負(fù)載異常的具體排查實(shí)操3.1 抓取進(jìn)程線程級(jí)負(fù)載數(shù)據(jù)在 OHOS 上定位負(fù)載問(wèn)題我常用的第一組命令是獲取進(jìn)程和線程狀態(tài)。首先要明確應(yīng)用進(jìn)程 PID?？梢酝ㄟ^(guò) ps -ef 查找應(yīng)用主進(jìn)程O(píng)HOS 下 Flutter 應(yīng)用通常是多進(jìn)程結(jié)構(gòu)PageAbility 相關(guān)進(jìn)程和引擎進(jìn)程也許分開(kāi)負(fù)載數(shù)據(jù)要按進(jìn)程維度匯總。找到 PID 后抓線程負(fù)載用 ps -T -p 可以看到所有線程的 CPU 占用和狀態(tài)。如果發(fā)現(xiàn)某個(gè)線程 CPU 占用高且狀態(tài)為 R運(yùn)行中這個(gè)線程就是主要懷疑對(duì)象。絕大多數(shù)情況下 Flutter 問(wèn)題出在 ui 線程或者 raster 線程?？淳€程名字可區(qū)分如果線程名為 root 或者 pipeline配合引擎線程的命名映射表。篩選線程號(hào)拿到線程棧用 OHOS 的 hidumper 可以抓指定線程的詳細(xì)信息包括內(nèi)核態(tài)和用戶態(tài)的?；厮輬?zhí)行后輸出到文件再分析。注意要在負(fù)載異常持續(xù)期間抓取最高效的方式是先把負(fù)載觸發(fā)起來(lái)然后把全部線程棧 dump 一遍間隔 10 秒重復(fù)兩到三次看可疑線程的遞歸棧是否出現(xiàn)累積。抓取時(shí)有一個(gè)小技巧不要只抓一次。單次線程快照可能剛好打在任務(wù)切換點(diǎn)得連續(xù)多次采樣才能確認(rèn)函數(shù)調(diào)用頻率。我個(gè)人通常連續(xù)抓 5 組每組間隔 2 秒左右重點(diǎn)看棧頂函數(shù)在不同組之間的重復(fù)情況重復(fù)出現(xiàn)次數(shù)最多的調(diào)用鏈基本就是熱點(diǎn)路徑。3.2 借助 Flutter DevTools 采樣引擎層數(shù)據(jù)進(jìn)程線程數(shù)據(jù)只能定位到線程真正要定位到代碼路徑還得看 Dart 側(cè)。Flutter DevTools 是社區(qū)標(biāo)配的 profiling 工具支持連接到運(yùn)行中的 OHOS 設(shè)備。連接前確保應(yīng)用開(kāi)啟了 VM ServiceOHOS 上可以把 VM Service 端口映射到開(kāi)發(fā)機(jī)上然后直接用 Chrome 打開(kāi) DevTools 頁(yè)面。用 DevTools 的 CPU profiler 進(jìn)行采樣時(shí)有兩個(gè)關(guān)鍵設(shè)置值得注意。一是采樣模式選擇“CPU Sampling”不要選“CPU Timeline”因?yàn)?Timeline 記錄完整調(diào)用事件開(kāi)銷高采集久了會(huì)改變負(fù)載特征掩蓋真實(shí)問(wèn)題二是采集時(shí)長(zhǎng)一般控制在 10 到 30 秒之間太短熱點(diǎn)不穩(wěn)定太長(zhǎng)容易引入其他噪音。分析火焰圖時(shí)要先找底部寬、向上收窄的調(diào)用鏈這類調(diào)用鏈通常是長(zhǎng)時(shí)間占有 CPU 的函數(shù)。如果是 Dart Isolate 內(nèi)部的循環(huán)邏輯火焰圖會(huì)在對(duì)應(yīng)函數(shù)處出現(xiàn)寬闊平臺(tái)如果是引擎層 C 代碼火焰圖可能斷在 Dart 邊界這時(shí)候要回到線程棧去查原生側(cè)。3.3 后臺(tái)異常負(fù)載的專項(xiàng)追蹤后臺(tái)負(fù)載異常是最容易被誤判的場(chǎng)景因?yàn)橛脩舾兄钪苯拥珡?fù)現(xiàn)條件往往復(fù)雜。排查時(shí)優(yōu)先確認(rèn)后臺(tái)存活狀態(tài)應(yīng)用是處于正常掛起suspend還是退到后臺(tái)仍然活躍。OHOS 的掛起機(jī)制會(huì)凍結(jié) Dart 線程但如果應(yīng)用持有鎖、有后臺(tái)連接的 fd 或持續(xù)持有系統(tǒng)喚醒鎖就會(huì)使整個(gè)進(jìn)程退出掛起白名單。排查后臺(tái)問(wèn)題時(shí)可以用 hidumper 查看進(jìn)程休眠狀態(tài)確認(rèn)進(jìn)程是否被系統(tǒng)標(biāo)記為喚醒DozeWhitelist 之類的機(jī)制具體字段按版本看。如果進(jìn)程確實(shí)在后臺(tái)正常運(yùn)行再檢查應(yīng)用代碼里是否有周期性 Timer 或后臺(tái)數(shù)據(jù)同步邏輯。Flutter 里常見(jiàn)錯(cuò)誤是開(kāi)啟了一個(gè)低頻全局 Timer比如每 60 秒上報(bào)一次位置在頁(yè)面銷毀時(shí)沒(méi)有取消退后臺(tái)后 Timer 還在跑Dart 線程被定時(shí)喚醒這會(huì)導(dǎo)致周期性功耗尖峰。一個(gè)很容易遺漏的場(chǎng)景是動(dòng)畫(huà)控制器生命周期多個(gè)頁(yè)面銷毀后 AnimationController 沒(méi)有被 dispose引擎仍按 60fps 請(qǐng)求幀回調(diào)即使看不到界面變化渲染管線也會(huì)持續(xù)消費(fèi) GPU 資源。這種場(chǎng)景在進(jìn)程線程抓取里主要表現(xiàn)為 raster 線程負(fù)載反復(fù)出現(xiàn)但 UI 線程相對(duì)空閑。4. 功耗問(wèn)題的根因拆解4.1 渲染功耗與 Flutter 繪制鏈路的關(guān)系Flutter 在 OHOS 上默認(rèn)通過(guò) Impeller 或 Skia 后端完成渲染渲染鏈路的任務(wù)分配直接決定 GPU 功耗。實(shí)踐中發(fā)現(xiàn)的一部分功耗問(wèn)題其實(shí)根因在渲染指令過(guò)于復(fù)雜比如頁(yè)面存在大量半透明疊加、長(zhǎng)陰影、高斯模糊效果這些效果會(huì)觸發(fā) offscreen render passGPU 負(fù)擔(dān)倍數(shù)增加。CPU 占用率看著不算高但 GPU 高負(fù)載直接拉高整機(jī)功耗測(cè)試人員感知為發(fā)熱耗電。檢查渲染鏈路的方法是記錄幀構(gòu)建期Frame Build和幀提交期Frame Submit的時(shí)間。Flutter 引擎的幀生命周期分為 build 和 raster 兩個(gè)階段如果 raster 階段耗時(shí)超標(biāo)說(shuō)明 GPU 指令過(guò)于復(fù)雜或者存在無(wú)效的離屏渲染。可以在 DevTools 的 Performance overlay 里打開(kāi)“Show raster thread timeline”逐幀看每幀開(kāi)銷。連續(xù)多幀 raster 時(shí)間超過(guò) 8ms 的話大概率存在渲染熱點(diǎn)。對(duì)這類問(wèn)題做優(yōu)化時(shí)先不要深挖引擎渲染細(xì)節(jié)優(yōu)先從業(yè)務(wù)層面排查是否有非必要的 RepaintBoundary、是否有 Stack 嵌套后觸發(fā)多個(gè)層合并、是否有過(guò)大的圖片尺寸原圖上傳到 GPU。把繪制復(fù)雜的業(yè)務(wù)層代碼優(yōu)化掉比調(diào)引擎參數(shù)更直接見(jiàn)效。4.2 持有系統(tǒng)資源導(dǎo)致的待機(jī)耗電另一類功耗問(wèn)題與渲染無(wú)關(guān)是應(yīng)用沒(méi)有正確釋放系統(tǒng)資源。OHOS 對(duì)后臺(tái)進(jìn)程有一套功耗治理策略應(yīng)用后臺(tái)長(zhǎng)時(shí)間運(yùn)行會(huì)被限制網(wǎng)絡(luò)訪問(wèn)和 CPU 調(diào)度。但應(yīng)用側(cè)如果你持有多種系統(tǒng)資源不放系統(tǒng)的功耗治理機(jī)制也無(wú)法完全兜底。常見(jiàn)的資源泄漏場(chǎng)景包括傳感器監(jiān)聽(tīng)注冊(cè)后沒(méi)有注銷比如接近傳感器、陀螺儀位置服務(wù)沒(méi)有在頁(yè)面退出時(shí)關(guān)閉藍(lán)牙掃描回調(diào)持續(xù)注冊(cè)以及高精度網(wǎng)絡(luò)定位沒(méi)有超時(shí)釋放。這些資源在持有期間會(huì)周期性喚醒系統(tǒng)導(dǎo)致整機(jī)功耗無(wú)法進(jìn)入低功耗模式。排查這類問(wèn)題要用 OHOS 的功耗排查工具查看喚醒源。如果喚醒源記錄里反復(fù)出現(xiàn)應(yīng)用名基本可以確定是資源未釋放問(wèn)題。從代碼習(xí)慣上建議所有注冊(cè)的監(jiān)聽(tīng)器都盡量與頁(yè)面生命周期綁定在 onDispose 里注銷獨(dú)立的生態(tài)服務(wù)調(diào)用要設(shè)計(jì)必要的超時(shí)和釋放策略不能只依賴系統(tǒng)兜底。這項(xiàng)習(xí)慣在 Flutter 側(cè)一樣適用即 Dart 層注冊(cè)的平臺(tái)通道監(jiān)聽(tīng)需要在 WidgetsBindingObserver 或 State.dispose 中取消。4.3 Dart 側(cè)定時(shí)任務(wù)與系統(tǒng)功耗的耦合在 Flutter 應(yīng)用里寫(xiě)定時(shí)任務(wù)是再常見(jiàn)不過(guò)的事情但很少有人認(rèn)真評(píng)估其功耗成本。當(dāng)一個(gè) Timer 每隔 10 秒觸發(fā)一次每次觸發(fā)會(huì)導(dǎo)致 Dart 事件循環(huán)喚醒如果觸發(fā)時(shí)還要執(zhí)行一些網(wǎng)絡(luò)請(qǐng)求或者文件寫(xiě)入那整個(gè)系統(tǒng)都會(huì)因?yàn)閼?yīng)用而被喚醒。如果是持續(xù)高頻的定時(shí)器比如 1 秒一次哪怕每次處理邏輯很輕也會(huì)讓 CPU 工作在較高的頻率檔位。功耗優(yōu)化實(shí)踐中凡是用定時(shí)器的場(chǎng)景我都建議先問(wèn)三個(gè)問(wèn)題這個(gè)任務(wù)是否需要在前臺(tái)實(shí)時(shí)執(zhí)行后臺(tái)還需要繼續(xù)嗎能否改成觸底延遲或批量執(zhí)行。以埋點(diǎn)上報(bào)為例與其每 15 秒把本地緩存寫(xiě)入一次不如在網(wǎng)絡(luò)從后臺(tái)切換回前臺(tái)時(shí)統(tǒng)一上報(bào)或者根據(jù)數(shù)據(jù)量觸發(fā)條件上報(bào)。多數(shù)業(yè)務(wù)場(chǎng)景對(duì)實(shí)時(shí)性的要求并不高合并執(zhí)行既滿足業(yè)務(wù)需求又能省功耗。如果你發(fā)現(xiàn)應(yīng)用的定時(shí)任務(wù)確實(shí)無(wú)法避免建議把任務(wù)邏輯與屏幕狀態(tài)綁定用 WidgetsBindingObserver 監(jiān)聽(tīng) AppLifecycleState在應(yīng)用退到后臺(tái)時(shí)暫停正在執(zhí)行的周期任務(wù)回到前臺(tái)時(shí)再同步狀態(tài)并恢復(fù)。這是成本最低的功耗優(yōu)化方案。5. 常見(jiàn)問(wèn)題定位速查與處理建議下面整理幾個(gè)高頻問(wèn)題場(chǎng)景方便直接對(duì)照排查?，F(xiàn)象特征可能的根因定位方向處理建議后臺(tái) CPU 居高不下后臺(tái)未取消的 Timer 或動(dòng)畫(huà)控制器Dart 層定時(shí)器任務(wù)、引擎幀回調(diào)生命周期綁定取消任務(wù)前臺(tái)相同操作序列 CPU 偏高圖片反復(fù)解碼、IO 線程繁忙IO 線程棧采樣加圖片緩存策略、降低解碼次數(shù)幀率正常但整機(jī)發(fā)熱渲染指令復(fù)雜觸發(fā) GPU 高負(fù)載Raster 線程幀時(shí)間簡(jiǎn)化布局、減少透明疊加效果待機(jī)時(shí)功耗曲線周期性抬升傳感器監(jiān)聽(tīng)、網(wǎng)絡(luò)輪詢未釋放功耗喚醒源記錄注銷監(jiān)聽(tīng)器、合并網(wǎng)絡(luò)請(qǐng)求線程數(shù)量持續(xù)增長(zhǎng)線程池濫用、原生層 JNI 回調(diào)ps 線程數(shù)熱統(tǒng)計(jì)統(tǒng)一線程管理、避免重復(fù)建線程頁(yè)面切換瞬時(shí) CPU 飆高路由預(yù)構(gòu)建、大量同步 IODevTools 幀執(zhí)行序列延遲加載、異步化資源加載注意排查環(huán)境也會(huì)掩蓋問(wèn)題。如果用測(cè)試機(jī)本身電量告急系統(tǒng)會(huì)主動(dòng)限制 CPU 頻率導(dǎo)致負(fù)載數(shù)據(jù)失真開(kāi)發(fā)機(jī)連著 USB 充電模擬的功耗曲線也不具備參考價(jià)值最好是滿電量分離充電實(shí)測(cè)。另外補(bǔ)充一個(gè)經(jīng)驗(yàn)Flutter OHOS 上的錯(cuò)誤日志等級(jí)默認(rèn)可能不輸出引擎層 C 信息。需要排查原生側(cè)引擎邏輯時(shí)在啟動(dòng)參數(shù)里加上 verbose_logging有些版本還提供 trace 參數(shù)可以打開(kāi)引擎內(nèi)部的事件追蹤。開(kāi)啟后復(fù)現(xiàn)一次問(wèn)題trace 文件能給出引擎內(nèi)部各階段的耗時(shí)占比定位更精準(zhǔn)。6. 個(gè)人實(shí)踐中的一點(diǎn)經(jīng)驗(yàn)總結(jié)最后分享一點(diǎn)個(gè)人的感受。負(fù)載與功耗問(wèn)題難點(diǎn)從來(lái)不是單條技術(shù)手段不會(huì)而是容易被表面現(xiàn)象帶偏。測(cè)試反饋一句“耗電高”你可能翻半天代碼也找不到明顯熱點(diǎn)問(wèn)題在于沒(méi)有先把問(wèn)題量化分層。實(shí)踐中最有效的方式是先花十幾分鐘把進(jìn)程線程采樣數(shù)據(jù)抓全再花幾分鐘看整體分布最后才是深入代碼。另外很多負(fù)載異常其實(shí)是多種因素疊加的。比如一個(gè)應(yīng)用后臺(tái)發(fā)熱可能既有 Timer 在跑也有位置監(jiān)聽(tīng)未釋放同時(shí)還有引擎的動(dòng)畫(huà)幀回調(diào)沒(méi)取消。這種情況靠單一工具只能看到片段需要把多個(gè)數(shù)據(jù)面的結(jié)果拼在一起解讀才能完全定位。還有一點(diǎn)容易被忽略第三方 SDK 和插件包也常常成為負(fù)載飆升的根源。攔截進(jìn)程里的線程創(chuàng)建?？梢钥焖俣ㄎ皇悄膫€(gè)模塊起的線程如果線程棧中有特定插件包符號(hào)優(yōu)先查對(duì)應(yīng)插件的資源管理邏輯而不是在自己業(yè)務(wù)代碼里徘徊。這套方法我已經(jīng)在多個(gè)基于 Flutter 的 OHOS 應(yīng)用優(yōu)化實(shí)踐中驗(yàn)證過(guò)總的來(lái)說(shuō)就是保證鏈路可觀測(cè)量化問(wèn)題分層定位優(yōu)先簡(jiǎn)化代碼路徑再談引擎參數(shù)調(diào)優(yōu)。希望你下次遇到負(fù)載異常時(shí)也能快速找到真正的元兇。