Kotlinで実装するCPU/GPU 「協調的」パフォーマンス管理

2025/11/01 kotlin fest 2025の資料です

https://2025.kotlinfest.dev/timetable/1719033600_b/

Transcript

1. Kotlinで実装するCPU/GPU 「協調的」パフォーマンス管理 Kotlin Fest 2025 yuhi yamane / @matuyuhi
2. 目的 ADPFの“難しさ”を Kotlinの型とFlowで“できない設計”に置き換える ADPF = Android Dynamic Performance Framework
3. • 型で契約を保証するDSLの作り方 • callbackFlow背圧の3パターン（状態/トレンド/高頻度） • JNIは檻の中（最小権限＋安全な解放） ゴール
4. 1.Android 15で進化したADPFによるCPU/GPU協調制御の概要 2.ADPF利用の壁 C/C++ APIとJNIの課題 3.FlowとDSLでネイティブAPIを抽象化で誤用不能の型を作る 4.コールバックの注意点や制御戦略 アジェンダ
5. なぜ？ • 長時間負荷→サーマル・スロットリング→FPS/応答低下 • 回避は無理、協調で“落ち幅”を制御 • アプリ → ADPF →OSにヒントを出せる時代
6. OS OS (DVFS/scheduling) App (目標ms/実測ms) ADPF(Android Dynamic Performance Framework)とは • ゲーム等の高負荷アプリが熱暴走せず安定動作するよう性能と熱を動的制御 • Android 15から作業時間を報告し、 OSが両者の周波数を同時に調整し最適化 • 従来のOS任せのDVFSに対し、ADPFはアプリから追加情報を渡し最適化を支援 https://developer.android.com/games/optimize/adpf https://source.android.com/docs/core/power/performance
7. ADPF利用の課題
8. ADPF利用の課題 • JNIの壁 ADPFの強力なAPIはC/C++実装で、Kotlin/Javaから直接扱えない • JNI呼び出しの煩雑さ ネイティブコード記述＆JNIブリッジが必要 • 型安全性の欠如 JNI経由ではコンパイル時チェックが弱く、誤った引数やリソース管理漏れのリスク
9. Flow＋DSLでクリーンに抽象化
10. • ADPFの契約 時間計測を統一（SystemClock.uptimeNanos）し、1サイクル1回の報告を厳守など • Flow活用 callbackFlowでネイティブイベントをReactiveにラップ • DSL活用 型安全ビルダーDSLでネイティブAPI操作を宣言的に記述（JNI詳細を意識せず使える） Flow＋DSLでクリーンに抽象化 煩雑なJNI処理を意識せず、Kotlinらしい可読性と安全性でコードを記述
11. イベント種別ごとの戦略 • 状態 最新だけ必要？ → conflate() 常に最新1件のみ保持 • トレンド ざっくり傾向？ → sample(推奨間隔) 定期サンプリング • 高頻度 量が多い？ → buffer(..., DROP_OLDEST) 古いデータを破棄し遅延防止
12. • 登録/解除は厳密に：awaitClose { removeListener() } • コールバック実行スレッド(MainExecutor) → 処理はで別スレッドへ • 必要に応じて buffer / conflate / sample / mapLatest を適用 • 演算子は意味で選ぶ ⚬ 最新のみ？間引き？ 最新優先？ • → Kotlin側で collect { … } するだけでデバイス状態をリアクティブに監視可能に Flow化の設計 （callbackFlow活用パターン）
13. thermalStatusFlow の実装 状態は最新だけで十分 → .distinctUntilChanged().conflate() で連続重複や古い値を除去 リーク対策: awaitClose { remove… } でリスナー登録を確実に解除 ↓ 温度が警告レベル以上になったら setPreferPowerEfficiency(true) で 省電力モードに切替えなど
14. 温度に応じてFPSレンジを落として発熱を抑制 thermalStatusFlowの利用
15. ExoPlayer：温度でSD上限にトラック選択 thermalStatusFlowの利用
16. DSL設計 API android.os.PerformanceHintManager アプリ⇄OSのヒント用チャネル ADPFの管理API • Session（作る→使う→閉じる） ⚬ 対象スレッド(TID)と目標時間（target）を束ねたハンドル ⚬ WorkDurationで測定結果を送信 • 主な操作 ⚬ updateTargetWorkDuration(...) / setPreferPowerEfficiency(...) ⚬ reportActualWorkDuration(WorkDuration)（1サイクル1回） ⚬ preferredUpdateRateNanos()（送信の上限目安）
17. 基本の書き方
18. • 時刻の混入：SystemClock.elapsedRealtimeNanos() vs System.nanoTime() • 必須の踏み忘れ：WorkDuration( )〜 の設定漏れがコンパイルで見えない • フェーズ混在：測定記述の中から目標時間（target）更新を呼べてしまう • TID誤り：Thread.currentThread( ).id を渡すなど、Linux TID 以外を指定しがち • 過剰送信：preferredUpdateRateNanos を無視して連打（意味がない／無駄に電力） • ライフサイクル：close( ) 漏れ／複数スレッドからの呼び出しで非スレッドセーフ 現状の問題点
19. 専用の型 • 時刻 • TID 専用型で混入をコンパイルで拒否し、誤指定を防ぐ
20. type-stateでコンパイル時に強制 TS: ThreadsMissing TT: TargetMissing threads(Tid) TS: ThreadsSet TT: TargetMissing TS: ThreadsSet TT: TargetSet target(N) build() SessionBuilder
21. エラー 実行可
22. android.os.PerformanceHintManager.Session へブリッジ
24. ネストしたレシーバの外側（control）と内側（report）の両方を同時に可視 • 意味の異なる操作が同一スコープで可視 • 時間軸の破壊（1サイクル=1報告の仮定が崩壊） • 型が守ってくれない このまま利用した場合
25. report { ... } の中は測定結果だけ、updateTarget(...) はサイクルの外で行う ──フェーズを分けるべき @HintDsl で内から外は不可視に コンパイルエラーに
26. イベント種別ごとの戦略
27. イベント種別ごとの戦略 • sample()で可読な頻度に • 連続的に変化する値の傾向を見る • データ量を間引く トレンド 連続的に変化する値
28. • buffer()で容量を決めて古いものから捨てる • 遅延で制御信号が古くなるのを防ぐ イベント種別ごとの戦略 高頻度 毎フレームのイベントなど
29. • conflate()で最新だけ通す • 現在の状態だけ分かれば十分な情報 イベント種別ごとの戦略 状態の取り扱い 現在の最新状態だけ • bufferのショートカット [Flow.conflate() == Flow.buffer(.... DROP_OLDEST)] https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/conflate.html
30. ADPFの限界と対処法 • 効きにくいケース I/Oボトルネックや瞬間的ジョブでは効果が薄い • Headroomの不安定 端末差やNaN値あり → 長い間隔でサンプル、無効ならThermalStatusのみで対処 • ヒント送信頻度 フレーム単位が実質上限（それ以上細かく送っても無意味）
31. JNI連携における安全策 • RAII（use{}でclose漏れゼロ） • callbackFlow の解除一点化（awaitClose{ unregister(...) }） • 失敗の三態化（例外を“沈めない”で型に出す）
32. JNI連携における安全策 • RAII（use{}でclose漏れゼロ） • Session側をCloseable/AutoCloseable • use{}の外でSessionを持ち回らない。 RAII = Resource Acquisition Is Initialization
33. JNI連携における安全策 • 失敗の三態化（例外を沈めないで型に出す） • 返り値を3種に • Success: 想定した挙動 • Limited: OSの制限ありの非エラー • Failed: 復帰不可能、要調査
34. まとめ Flowで運び、DSLで守り、JNIの複雑さは内側に封じる 型で表現した契約により、安全なネイティブ活用が可能になる • Flowでデータを輸送 イベントの種類に応じた背圧で無駄なくOSへヒントを届ける • DSLで契約を保証 型システムで単位や手順の誤りを事前に排除し、意味をコードに反映 • JNIの詳細は封じ込め 危険な処理は内側に隠蔽し、高度な制御をKotlinからシンプルに扱う
35. 参考 • Performance Hint API https://developer.android.com/games/optimize/adpf/performance-hint-api • PerformanceHintManager.Session https://developer.android.com/reference/android/os/PerformanceHintManager.Session • WorkDuration https://developer.android.com/reference/android/os/WorkDuration • Thermal API https://developer.android.com/games/optimize/adpf/thermal • Kotlin Flow https://developer.android.com/kotlin/flow • Type-Safe Builders https://kotlinlang.org/docs/type-safe-builders.html Thanks！