Ente 移動端 ML 調度驗證報告DVFS 與線程調度如何讓 Pixel 8 的 Rust 預處理慢 2.8 倍以及如何修復【免費下載鏈接】ente End-to-end encrypted cloud for everything.項目地址: https://gitcode.com/GitHub_Trending/en/ente導讀Ente 的移動端 ML 索引管線人臉檢測、CLIP 圖像嵌入、人臉特征提取在 AndroidONNX Runtime WebGPU與 iOSCoreML之間存在驚人的端到端差距。2026-07-22 的基準顯示 iPhone 15 Pro 在 Rust 預處理上快約 12 倍、串行解碼快約 4 倍遠超兩顆 SoC 之間約 1.62 倍的真實硅片差距。本文基于倉庫內的 Android ML 調度驗證報告完整復盤其四個受控實驗變體、sched_getcpu() DVFS 頻率采樣等新型埋點、假設驗證結論以及按預期價值排序的六條生產落地建議。讀完本文你將掌握如何用頻率采樣與線程集中來診斷突發型負載下 CPU 提頻不足這一 Android 移動端性能頑疾以及 Ente 計劃如何通過單線程管線、CPU/GPU 流水線、ADPF 等手段回收 2.8 倍預處理性能。一、背景07-22 基準報告中的異常差距驗證實驗的起點是 20260722_FINAL_MOBILE_ML_BENCHMARK_REPORT.md。該報告在 Pixel 8Android 17ONNX Runtime WebGPU與 iPhone 15 ProiOS 26.5.2ONNX Runtime CoreML上用同一 14 圖語料測得如下穩定態數據設備端到端 14 圖每圖Rust 總耗時Rust 每圖Pixel 8 WebGPU12,994.3 ms928.2 ms7,265.3 ms518.9 msiPhone CoreMLwarm5,022.2 ms358.7 ms1,789.8 ms127.8 ms其中 iPhone 端到端快 2.59 倍Rust 管線內快約 4 倍。但分階段看差距分布極不均勻階段Pixel 8iPhone 15 Pro差距Decode2,771.0 ms1,169.6 ms~2.4xRust 預處理652.8 ms55.1 ms~11.8xInferenceWebGPU vs CoreML3,720.0 ms557.9 ms~6.7xRust 后處理12.7 ms2.3 ms~5.5xRust 其他117.2 ms0.5 ms—預處理 11.8 倍、后處理 5.5 倍的差距遠不能由 WebGPU/CoreML 之間的推理引擎差異5.78.8x屬真實平臺差距或硅片差異解釋。這構成了本次驗證實驗的直接動機Pixel 的 CPU 側慢到底慢在硬件、并行度還是調度二、實驗設計四個變體與有效性控制驗證實驗在ort_opt_ios分支HEAD3c9ee2cb76追加基準埋點上進行設備為 Google Pixel 8shiba全部變體滿足AOT releaseconnectedIndependentReleaseAndroidTest每輪驗證dart.vm.producttrue變體 B 額外通過ML_PARITY_REQUIRE_RELEASEtrue門禁、14 圖語料、每圖 1 次不計時預熱 3 次計時采樣、按文件取中位數。每個變體前后設備熱狀態均為 1輕度跨變體一致因此橫向對比內部自洽。四個變體的編譯期覆蓋與bench_config確認如下變體編譯期覆蓋bench_config確認A無基線 放置采樣rayon 池 9 線程無親和性BENTE_ML_BENCHMARK_RAYON_THREADS1池配置為 1 線程CENTE_ML_BENCHMARK_CPU_AFFINITY4-8掩碼0x1f09/9 工作線程釘在 midbigD兩者皆用親和性8僅 Cortex-X3池 1 線程全部工作壓到 cpu8其中 A 為基線B 用于檢驗 rayon 扇出fan-out是否是預處理瓶頸C 用于檢驗小核放置的影響D 用于檢驗線程集中 單大核能否讓 DVFS 持續提頻。上述ENTE_ML_BENCHMARK_*覆蓋開關是基準專用、編譯期可選的能力生產構建默認不開啟07-22 報告中明確基準日志通過ENTE_ML_BENCHMARK_LOGGING編譯期 opt-inAndroid release 埋點通過ENTE_ML_BENCHMARK_RELEASE_TESTS1開啟普通構建不受影響。新增的埋點編譯出生產構建之外包括在各階段時鐘之外采樣sched_getcpu()與 DVFS 頻率以及在每次管線之后運行一次空broadcast的 rayon 喚醒延遲探針。三、結果階段到底跑在哪、跑在多少 MHzPixel 8 的集群拓撲為cpu0-3 Cortex-A510little最高 1.70 GHz、cpu4-7 Cortex-A715mid最高 2.37 GHz、cpu8 Cortex-X3big最高 2.91 GHz。基線 A 下各階段的實際放置與頻率占總階段時間的份額階段變體 A放置位置中位頻率decode長突發42% mid / 58% bigmid 1,418 MHzbig 2,687 MHz預處理短突發3% little / 61% mid / 37% bigmid910 MHzbig 1,557 MHz后處理μs 級突發98% mid697 MHz這直接測量到了 07-22 分析所預測的模式只有足夠長的 decode 突發能在突發中途掙到高頻率短促的預處理/后處理突發總是冷啟動、冷結束。ML 管線的 CPU 短突發每次跟隨約 240 ms 的 GPU 推理休眠在約 9 個工作線程間輪轉從未在每個線程上累積出足夠的利用率讓 Android 調度器提頻或遷移到大核。基線預處理大部分時間跑在 mid 核上中位僅910 MHz只有其 2.37 GHz 上限的 38%。變體 D全部工作集中到一個 big 核的效果持續頻率升至2,363 MHz語料預處理總耗時從596.7 ms 降至 212.4 ms2.8 倍落入硅片應有的水平區間盡管只用 1 個核而非 9 個核卻產生了所有變體中最快的端到端運行。13 個共有 fixture 的語料匯總語料總計msA基線B串行 rayonC無 little 核D串行 1 big 核decode2,772.13,907.52,898.93,194.0Rust 預處理596.7535.9472.2212.4inferenceWebGPU3,349.53,947.73,622.83,159.8Rust 后處理13.68.511.49.6Rust 其他103.0119.0105.462.7Rust 總計6,874.58,536.27,073.96,652.6在變體 D 中同一預處理的每次調用中位數從 15.0 ms 降到5.4 msp90 從 30 ms 降到 10 ms最大值從 81 ms 降到 21 ms。rayon 喚醒探針每次 resize 分發的扇出屏障開銷數據顯示變體 A 中位數 2.2 ms、p90 4.9 ms且 46% 的池工作線程在小核上喚醒即便在 C全部線程釘到 midbig中仍是 2.4 ms 中位數——說明該開銷本質是空閑線程退出延遲而非小核放置問題單線程池D下則驟降至 0.10 ms。四、假設驗證H1 被否決H2 被確認H1 — rayon 扇出屏障主導預處理被否決為主因被確認是真實次要成本將池串行化B只回收了約 597 ms 語料預處理中的約 60 ms約 10%且呈雙峰分布小圖顯著受益1343.jpg從 39.6 ms 降至 13.0 ms——純屏障開銷而大圖或人臉密集圖反而變差pano39.7 → 59.3 mspeople.jpeg74.2 → 84.8 ms因為丟失了真實的并行計算。結論是每次分發的 25 ms 屏障稅真實存在但有限。從源碼可以印證該扇出的存在ente-mlcrate 的 Cargo.toml 中fast_image_resize { workspace true, features [rayon] }顯式啟用了 resize 庫的 rayon 并行特性且 crate 直接依賴rayon 1.12.0。實際 resize 調用鏈位于 preprocess.rsYOLO 輸入預處理使用fast_image_resize的Resizer與雙線性插值以及 cv/resize.rs 等模塊。這正是報告中每次 resize 分發的 25 ms 屏障稅的代碼出處。H2 — 冷核/DVFS 放置主導確認且頻率是決定性杠桿排除 little 核C只讓預處理改善 21%因為 mid 核仍以 910 MHz 空轉。把工作集中到一個核D后schedutil得以維持 2,363 MHz帶來 2.8 倍改善。結論單靠放置affinity不是解藥持續的利用率sustained utilization才是。解碼并行值得保留串行解碼B在語料范圍內多花 1,135 ms幾乎全部來自兩個大/平鋪 HEICpano714 → 1,426 ms8606239 → 519 ms普通 HEIC 本就接近串行解碼。而在升頻后的核D上串行 JPEG/PNG/WebP 解碼器反而比基線更快astronaut.png11.6 → 5.0 msui_app.webp121.5 → 79.9 ms。與 iPhone 的對賬在 13 個共有 fixture 上iPhone 15 Pro 的預處理總量約 51 ms。變體 D 把 Pixel 從落后 11.7 倍拉近到約 4.2 倍殘余差距來自真實的硅片差距單核約 23 倍加上 X3 在推理休眠間隙只維持 2,363 MHz而非 2,914 MHz。07-22 報告中Pixel 處處慢約 10 倍的讀法被證偽——那是在測量調度器行為而非硬件。五、異常與注意事項CR2 平臺回退失敗IMG_8905.CR2在 C、D 變體中其平臺 JPEG 回退失敗在 A、B 及所有 07-22 運行中成功。兩次失敗都發生在測試框架開始保留已安裝應用持久化應用數據之后因此首要嫌疑是持久化應用數據而非親和性覆蓋本身。任何親和性相關改動上線前需針對性重跑。共有文件分析已剔除該 fixture頭條數字不受影響。WebGPU 推理波動各變體間推理耗時 ±9% 波動3,1603,948 ms且無明確排序變體間推理差值應視為噪聲。熱狀態差異本次全程熱狀態 107-22 為 0但基線 A 仍復現了 07-22 的語料總量decode 2,772 vs 2,771 ms預處理 597 vs 653 ms證明埋點與熱狀態沒有扭曲基準。logcat 環形緩沖A/B 的 logcat 各有一個 fixture 的事件在緩沖區擴容到 16 MB 前被驅逐已由共有文件分析處理。變體 D 的診斷性質硬釘一個核是診斷手段而非可上線配置——它獨占 X3、無視熱余量、與其他負載沖突。六、生產建議按預期價值排序報告為生產 Android 索引給出的建議按預期價值排序停止把管線工作輪轉在 FRB 工作線程池上改為在單一持久專用線程上運行 ML 管線可選第二線程專用于解碼。這是變體 D 結論的可上線形態線程集中才能讓schedutil維持高頻第一步無需任何 pinning。CPU 與 GPU 流水線化在圖像 N 處于Session::run內時同步解碼/預處理圖像 N1。這一舉兩得完全隱藏預處理延遲同時保持工作線程高利用率以維持頻率——還能同時打擊解碼的 24 倍缺口這是單階段修復做不到的。采用 ADPFPerformanceHintManager為 ML 工作線程設置每圖目標時長。這是 Android 官方針對突發型負載 DVFS問題的既定機制可替代任何親和性 hack。從rust/crates/ml中移除fast_image_resize的rayonfeature保留heic_decoder自身的 rayon 并行用于解碼。resize 扇出從未回本——B 變體在無它時預處理凈更快——且每次分發還要付出 25 ms 屏障稅。小而安全、立即可做。不要上線 CPU 親和性 pinning除非 CR2 異常得到解決并在爭用/熱負載下測試僅當 13 項不達預期時才重新考慮。修正 07-22 報告的跨平臺表述CoreML 對 WebGPU 的推理差距5.78.8 倍是真實平臺差距但預處理/后處理/解碼差距約 1.62 倍硅片差距 Android 調度債務后者可由 14 項回收。報告對 124 項組合暫不含推理側工作的穩定態影響預估端到端約 1020%本語料上預處理 597 → 約 210 ms其他103 → 約 60 ms串行解碼 fixture 快 1.52 倍大 HEIC 解碼不變更大的戰略價值在于CPU 成本不再隨調度器心情波動WebGPU 推理差距成為 Android 唯一的剩余短板。七、結論性能問題的層級與取證方法本次驗證的完整敘事是Pixel 8 的 CPU 側慢根因不是硬件、也不是主要來自 rayon 扇出而是 DVFS 與調度。短 CPU 突發跟隨長 GPU 休眠、跨約 9 個線程輪轉導致每線程利用率不足、調度器不提頻基線預處理長期運行在 38% 的峰值頻率上。將工作集中到單一大核后2.8 倍性能被直接解凍。這一結論對移動端 ML 工程有普遍方法學意義跨平臺基準必須先排除調度因素才能討論硅片差距——否則會把調度器行為誤讀為硬件差距診斷突發型負載性能問題時同時采樣放置sched_getcpu與頻率DVFS是不可或缺的一對觀測手段修復方向應該是線程集中 CPU/GPU 流水線 ADPF 提示而不是盲目堆并行度或依賴親和性硬釘。相關產物與深入閱讀本次驗證的機器可讀產物與工具位于 infra/ml/test各變體日志、熱快照與結果載荷infra/ml/test/out/sched_verification_2026-07-23/{A,B,C,D}/device_logcat.txt與.../{A,C,D}/results.jsonB 的載荷因測試框架測試后自動卸載而丟失其基準數據完整保留在 logcat 中分析腳本python3 infra/ml/test/tools/analyze_ml_sched_verification.py device_logcat.txt輸出放置、頻率、探針與語料匯總過程文檔20260723_ANDROID_SCHED_VERIFICATION_RUNBOOK.md與本文同目錄。與本主題直接相關的倉庫源碼與配置rust/crates/ml/Cargo.tomlfast_image_resize的 rayon feature、rayon依賴、Android/iOS 的 ORT provider featurerust/crates/ml/src/preprocess.rsYOLO 輸入預處理resize letterbox 歸一化rust/crates/ml/src/cv/resize.rs通用圖像 resize 路徑infra/ml/playground/optimizations/README.md模型優化流水線GELU 融合、PReLU 改寫等保證同一 ONNX 產物可被 CoreML 與 WebGPU 共用infra/ml/playground/optimizations/benchmark_reports/20260722_FINAL_MOBILE_ML_BENCHMARK_REPORT.md本文的基線報告如需復現基準可參考 infra/ml/test/run_ml_parity_tests.sh 與 infra/ml/test/README.md 了解 14 圖 ML 一致性語料含man.jpeg、people.jpeg、singapore.jpg等 fixture位于 infra/ml/playground/data的構成與運行方式。【免費下載鏈接】ente End-to-end encrypted cloud for everything.項目地址: https://gitcode.com/GitHub_Trending/en/ente創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 Ente 移動端 ML 調度驗證報告：DVFS 與線程調度如何讓 Pixel 8 的 Rust 預處理慢 2.8 倍，以及如何修復
Ente 移動端 ML 調度驗證報告DVFS 與線程調度如何讓 Pixel 8 的 Rust 預處理慢 2.8 倍以及如何修復【免費下載鏈接】ente End-to-end encrypted cloud for everything.項目地址: https://gitcode.com/GitHub_Trending/en/ente導讀Ente 的移動端 ML 索引管線人臉檢測、CLIP 圖像嵌入、人臉特征提取在 AndroidONNX Runtime WebGPU與 iOSCoreML之間存在驚人的端到端差距。2026-07-22 的基準顯示 iPhone 15 Pro 在 Rust 預處理上快約 12 倍、串行解碼快約 4 倍遠超兩顆 SoC 之間約 1.62 倍的真實硅片差距。本文基于倉庫內的 Android ML 調度驗證報告完整復盤其四個受控實驗變體、sched_getcpu() DVFS 頻率采樣等新型埋點、假設驗證結論以及按預期價值排序的六條生產落地建議。讀完本文你將掌握如何用頻率采樣與線程集中來診斷突發型負載下 CPU 提頻不足這一 Android 移動端性能頑疾以及 Ente 計劃如何通過單線程管線、CPU/GPU 流水線、ADPF 等手段回收 2.8 倍預處理性能。一、背景07-22 基準報告中的異常差距驗證實驗的起點是 20260722_FINAL_MOBILE_ML_BENCHMARK_REPORT.md。該報告在 Pixel 8Android 17ONNX Runtime WebGPU與 iPhone 15 ProiOS 26.5.2ONNX Runtime CoreML上用同一 14 圖語料測得如下穩定態數據設備端到端 14 圖每圖Rust 總耗時Rust 每圖Pixel 8 WebGPU12,994.3 ms928.2 ms7,265.3 ms518.9 msiPhone CoreMLwarm5,022.2 ms358.7 ms1,789.8 ms127.8 ms其中 iPhone 端到端快 2.59 倍Rust 管線內快約 4 倍。但分階段看差距分布極不均勻階段Pixel 8iPhone 15 Pro差距Decode2,771.0 ms1,169.6 ms~2.4xRust 預處理652.8 ms55.1 ms~11.8xInferenceWebGPU vs CoreML3,720.0 ms557.9 ms~6.7xRust 后處理12.7 ms2.3 ms~5.5xRust 其他117.2 ms0.5 ms—預處理 11.8 倍、后處理 5.5 倍的差距遠不能由 WebGPU/CoreML 之間的推理引擎差異5.78.8x屬真實平臺差距或硅片差異解釋。這構成了本次驗證實驗的直接動機Pixel 的 CPU 側慢到底慢在硬件、并行度還是調度二、實驗設計四個變體與有效性控制驗證實驗在ort_opt_ios分支HEAD3c9ee2cb76追加基準埋點上進行設備為 Google Pixel 8shiba全部變體滿足AOT releaseconnectedIndependentReleaseAndroidTest每輪驗證dart.vm.producttrue變體 B 額外通過ML_PARITY_REQUIRE_RELEASEtrue門禁、14 圖語料、每圖 1 次不計時預熱 3 次計時采樣、按文件取中位數。每個變體前后設備熱狀態均為 1輕度跨變體一致因此橫向對比內部自洽。四個變體的編譯期覆蓋與bench_config確認如下變體編譯期覆蓋bench_config確認A無基線 放置采樣rayon 池 9 線程無親和性BENTE_ML_BENCHMARK_RAYON_THREADS1池配置為 1 線程CENTE_ML_BENCHMARK_CPU_AFFINITY4-8掩碼0x1f09/9 工作線程釘在 midbigD兩者皆用親和性8僅 Cortex-X3池 1 線程全部工作壓到 cpu8其中 A 為基線B 用于檢驗 rayon 扇出fan-out是否是預處理瓶頸C 用于檢驗小核放置的影響D 用于檢驗線程集中 單大核能否讓 DVFS 持續提頻。上述ENTE_ML_BENCHMARK_*覆蓋開關是基準專用、編譯期可選的能力生產構建默認不開啟07-22 報告中明確基準日志通過ENTE_ML_BENCHMARK_LOGGING編譯期 opt-inAndroid release 埋點通過ENTE_ML_BENCHMARK_RELEASE_TESTS1開啟普通構建不受影響。新增的埋點編譯出生產構建之外包括在各階段時鐘之外采樣sched_getcpu()與 DVFS 頻率以及在每次管線之后運行一次空broadcast的 rayon 喚醒延遲探針。三、結果階段到底跑在哪、跑在多少 MHzPixel 8 的集群拓撲為cpu0-3 Cortex-A510little最高 1.70 GHz、cpu4-7 Cortex-A715mid最高 2.37 GHz、cpu8 Cortex-X3big最高 2.91 GHz。基線 A 下各階段的實際放置與頻率占總階段時間的份額階段變體 A放置位置中位頻率decode長突發42% mid / 58% bigmid 1,418 MHzbig 2,687 MHz預處理短突發3% little / 61% mid / 37% bigmid910 MHzbig 1,557 MHz后處理μs 級突發98% mid697 MHz這直接測量到了 07-22 分析所預測的模式只有足夠長的 decode 突發能在突發中途掙到高頻率短促的預處理/后處理突發總是冷啟動、冷結束。ML 管線的 CPU 短突發每次跟隨約 240 ms 的 GPU 推理休眠在約 9 個工作線程間輪轉從未在每個線程上累積出足夠的利用率讓 Android 調度器提頻或遷移到大核。基線預處理大部分時間跑在 mid 核上中位僅910 MHz只有其 2.37 GHz 上限的 38%。變體 D全部工作集中到一個 big 核的效果持續頻率升至2,363 MHz語料預處理總耗時從596.7 ms 降至 212.4 ms2.8 倍落入硅片應有的水平區間盡管只用 1 個核而非 9 個核卻產生了所有變體中最快的端到端運行。13 個共有 fixture 的語料匯總語料總計msA基線B串行 rayonC無 little 核D串行 1 big 核decode2,772.13,907.52,898.93,194.0Rust 預處理596.7535.9472.2212.4inferenceWebGPU3,349.53,947.73,622.83,159.8Rust 后處理13.68.511.49.6Rust 其他103.0119.0105.462.7Rust 總計6,874.58,536.27,073.96,652.6在變體 D 中同一預處理的每次調用中位數從 15.0 ms 降到5.4 msp90 從 30 ms 降到 10 ms最大值從 81 ms 降到 21 ms。rayon 喚醒探針每次 resize 分發的扇出屏障開銷數據顯示變體 A 中位數 2.2 ms、p90 4.9 ms且 46% 的池工作線程在小核上喚醒即便在 C全部線程釘到 midbig中仍是 2.4 ms 中位數——說明該開銷本質是空閑線程退出延遲而非小核放置問題單線程池D下則驟降至 0.10 ms。四、假設驗證H1 被否決H2 被確認H1 — rayon 扇出屏障主導預處理被否決為主因被確認是真實次要成本將池串行化B只回收了約 597 ms 語料預處理中的約 60 ms約 10%且呈雙峰分布小圖顯著受益1343.jpg從 39.6 ms 降至 13.0 ms——純屏障開銷而大圖或人臉密集圖反而變差pano39.7 → 59.3 mspeople.jpeg74.2 → 84.8 ms因為丟失了真實的并行計算。結論是每次分發的 25 ms 屏障稅真實存在但有限。從源碼可以印證該扇出的存在ente-mlcrate 的 Cargo.toml 中fast_image_resize { workspace true, features [rayon] }顯式啟用了 resize 庫的 rayon 并行特性且 crate 直接依賴rayon 1.12.0。實際 resize 調用鏈位于 preprocess.rsYOLO 輸入預處理使用fast_image_resize的Resizer與雙線性插值以及 cv/resize.rs 等模塊。這正是報告中每次 resize 分發的 25 ms 屏障稅的代碼出處。H2 — 冷核/DVFS 放置主導確認且頻率是決定性杠桿排除 little 核C只讓預處理改善 21%因為 mid 核仍以 910 MHz 空轉。把工作集中到一個核D后schedutil得以維持 2,363 MHz帶來 2.8 倍改善。結論單靠放置affinity不是解藥持續的利用率sustained utilization才是。解碼并行值得保留串行解碼B在語料范圍內多花 1,135 ms幾乎全部來自兩個大/平鋪 HEICpano714 → 1,426 ms8606239 → 519 ms普通 HEIC 本就接近串行解碼。而在升頻后的核D上串行 JPEG/PNG/WebP 解碼器反而比基線更快astronaut.png11.6 → 5.0 msui_app.webp121.5 → 79.9 ms。與 iPhone 的對賬在 13 個共有 fixture 上iPhone 15 Pro 的預處理總量約 51 ms。變體 D 把 Pixel 從落后 11.7 倍拉近到約 4.2 倍殘余差距來自真實的硅片差距單核約 23 倍加上 X3 在推理休眠間隙只維持 2,363 MHz而非 2,914 MHz。07-22 報告中Pixel 處處慢約 10 倍的讀法被證偽——那是在測量調度器行為而非硬件。五、異常與注意事項CR2 平臺回退失敗IMG_8905.CR2在 C、D 變體中其平臺 JPEG 回退失敗在 A、B 及所有 07-22 運行中成功。兩次失敗都發生在測試框架開始保留已安裝應用持久化應用數據之后因此首要嫌疑是持久化應用數據而非親和性覆蓋本身。任何親和性相關改動上線前需針對性重跑。共有文件分析已剔除該 fixture頭條數字不受影響。WebGPU 推理波動各變體間推理耗時 ±9% 波動3,1603,948 ms且無明確排序變體間推理差值應視為噪聲。熱狀態差異本次全程熱狀態 107-22 為 0但基線 A 仍復現了 07-22 的語料總量decode 2,772 vs 2,771 ms預處理 597 vs 653 ms證明埋點與熱狀態沒有扭曲基準。logcat 環形緩沖A/B 的 logcat 各有一個 fixture 的事件在緩沖區擴容到 16 MB 前被驅逐已由共有文件分析處理。變體 D 的診斷性質硬釘一個核是診斷手段而非可上線配置——它獨占 X3、無視熱余量、與其他負載沖突。六、生產建議按預期價值排序報告為生產 Android 索引給出的建議按預期價值排序停止把管線工作輪轉在 FRB 工作線程池上改為在單一持久專用線程上運行 ML 管線可選第二線程專用于解碼。這是變體 D 結論的可上線形態線程集中才能讓schedutil維持高頻第一步無需任何 pinning。CPU 與 GPU 流水線化在圖像 N 處于Session::run內時同步解碼/預處理圖像 N1。這一舉兩得完全隱藏預處理延遲同時保持工作線程高利用率以維持頻率——還能同時打擊解碼的 24 倍缺口這是單階段修復做不到的。采用 ADPFPerformanceHintManager為 ML 工作線程設置每圖目標時長。這是 Android 官方針對突發型負載 DVFS問題的既定機制可替代任何親和性 hack。從rust/crates/ml中移除fast_image_resize的rayonfeature保留heic_decoder自身的 rayon 并行用于解碼。resize 扇出從未回本——B 變體在無它時預處理凈更快——且每次分發還要付出 25 ms 屏障稅。小而安全、立即可做。不要上線 CPU 親和性 pinning除非 CR2 異常得到解決并在爭用/熱負載下測試僅當 13 項不達預期時才重新考慮。修正 07-22 報告的跨平臺表述CoreML 對 WebGPU 的推理差距5.78.8 倍是真實平臺差距但預處理/后處理/解碼差距約 1.62 倍硅片差距 Android 調度債務后者可由 14 項回收。報告對 124 項組合暫不含推理側工作的穩定態影響預估端到端約 1020%本語料上預處理 597 → 約 210 ms其他103 → 約 60 ms串行解碼 fixture 快 1.52 倍大 HEIC 解碼不變更大的戰略價值在于CPU 成本不再隨調度器心情波動WebGPU 推理差距成為 Android 唯一的剩余短板。七、結論性能問題的層級與取證方法本次驗證的完整敘事是Pixel 8 的 CPU 側慢根因不是硬件、也不是主要來自 rayon 扇出而是 DVFS 與調度。短 CPU 突發跟隨長 GPU 休眠、跨約 9 個線程輪轉導致每線程利用率不足、調度器不提頻基線預處理長期運行在 38% 的峰值頻率上。將工作集中到單一大核后2.8 倍性能被直接解凍。這一結論對移動端 ML 工程有普遍方法學意義跨平臺基準必須先排除調度因素才能討論硅片差距——否則會把調度器行為誤讀為硬件差距診斷突發型負載性能問題時同時采樣放置sched_getcpu與頻率DVFS是不可或缺的一對觀測手段修復方向應該是線程集中 CPU/GPU 流水線 ADPF 提示而不是盲目堆并行度或依賴親和性硬釘。相關產物與深入閱讀本次驗證的機器可讀產物與工具位于 infra/ml/test各變體日志、熱快照與結果載荷infra/ml/test/out/sched_verification_2026-07-23/{A,B,C,D}/device_logcat.txt與.../{A,C,D}/results.jsonB 的載荷因測試框架測試后自動卸載而丟失其基準數據完整保留在 logcat 中分析腳本python3 infra/ml/test/tools/analyze_ml_sched_verification.py device_logcat.txt輸出放置、頻率、探針與語料匯總過程文檔20260723_ANDROID_SCHED_VERIFICATION_RUNBOOK.md與本文同目錄。與本主題直接相關的倉庫源碼與配置rust/crates/ml/Cargo.tomlfast_image_resize的 rayon feature、rayon依賴、Android/iOS 的 ORT provider featurerust/crates/ml/src/preprocess.rsYOLO 輸入預處理resize letterbox 歸一化rust/crates/ml/src/cv/resize.rs通用圖像 resize 路徑infra/ml/playground/optimizations/README.md模型優化流水線GELU 融合、PReLU 改寫等保證同一 ONNX 產物可被 CoreML 與 WebGPU 共用infra/ml/playground/optimizations/benchmark_reports/20260722_FINAL_MOBILE_ML_BENCHMARK_REPORT.md本文的基線報告如需復現基準可參考 infra/ml/test/run_ml_parity_tests.sh 與 infra/ml/test/README.md 了解 14 圖 ML 一致性語料含man.jpeg、people.jpeg、singapore.jpg等 fixture位于 infra/ml/playground/data的構成與運行方式。【免費下載鏈接】ente End-to-end encrypted cloud for everything.項目地址: https://gitcode.com/GitHub_Trending/en/ente創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考