私たちは Android LLVM ツールチェーン チームです。私たちの最優先事項の一つは、LLVM エコシステムの最適化手法を通じて Android のパフォーマンスを向上させることです。私たちは、Android をより高速でスムーズかつ効率的にする方法を常に探しています。最適化作業の多くはユーザー空間で行われますが、カーネルはシステムの中心であり続けます。本日、ユーザーに大きなパフォーマンスの向上をもたらすために、自動フィードバック主導最適化（AutoFDO）を Android カーネルに導入する方法をご紹介します。

AutoFDO とは

標準のソフトウェア ビルドでは、コンパイラは静的コードのヒントに基づいて、関数をインライン化するかどうかや、条件分岐のどのブランチが選択される可能性が高いかなど、数千もの小さな決定を行います。これらのヒューリスティックは有用ですが、実際のスマートフォンの使用時のコード実行を常に正確に予測できるわけではありません。

AutoFDO は、実際の実行パターンを使用してコンパイラをガイドすることで、この問題を解決します。これらのパターンは、CPU の分岐履歴を記録することでキャプチャされた、実際の使用時にコードがたどる最も一般的な命令実行パスを表します。このデータはフリート デバイスから収集できますが、カーネルについては、上位 100 個の人気アプリの実行など、代表的なワークロードを使用してラボ環境で合成します。サンプリング プロファイラを使用してこのデータをキャプチャし、コードのどの部分が「ホット」（頻繁に使用される）で、どの部分が「コールド」であるかを特定します。これらのプロファイルを使用してカーネルを再構築すると、コンパイラは実際の Android ワークロードに合わせて、よりスマートな最適化の決定を行うことができます。

この最適化の影響を理解するために、次の重要な事実を考慮してください。

• Android では、カーネルが CPU 時間の約 40% を占めています。
• AutoFDO を使用して、ユーザー空間のネイティブ実行可能ファイルとライブラリを最適化し、コールド アプリの起動を約 4% 改善し、起動時間を 1% 短縮しています。

実環境でのパフォーマンスの向上

制御されたラボ環境のプロファイルを活用することで、Android の主要な指標全体で目覚ましい改善が見られました。これらのプロファイルは、アプリのクロールと起動を使用して収集され、6.1、6.6、6.12 のカーネルにわたって Google Pixel デバイスで測定されました。

最も顕著な改善点は以下のとおりです。これらのカーネル バージョンの AutoFDO プロファイルの詳細については、android16-6.12 カーネルと android15-6.6 カーネルのそれぞれの Android カーネル リポジトリをご覧ください。

これは単なる理論上の数値ではありません。エンドユーザーにとっては、インターフェースの高速化、アプリの切り替えの高速化、バッテリー駆動時間の延長、デバイスの全体的な応答性の向上につながります。

仕組み: パイプライン

Google のデプロイ戦略には、プロファイルの関連性を維持し、パフォーマンスを安定させるための高度なパイプラインが含まれています。

ステップ 1: プロファイルの収集

ユーザー空間バイナリのプロファイリングには社内テストフリートを使用していますが、汎用カーネル イメージ（GKI）については、管理されたラボ環境に移行しました。プロファイリングをデバイス リリース サイクルから切り離すことで、デプロイされたカーネル バージョンに関係なく、柔軟かつ迅速なアップデートが可能になります。重要なのは、このラボベースのデータが、実際のフリートと同等のパフォーマンス向上をもたらすことをテストで確認することです。

• ツールと環境: 最新のカーネル イメージでテストデバイスをフラッシュし、simpleperf を使用して命令実行ストリームをキャプチャします。このプロセスは、ハードウェア機能を利用して分岐履歴を記録します。具体的には、Google Pixel デバイスで  ARM Embedded Trace Extension（ETE）と ARM Trace Buffer Extension（TRBE）を使用します。
• ワークロード: Android アプリ互換性テストスイート（C-Suite）の人気の高い上位 100 個のアプリを使用して、代表的なワークロードを構築します。最も正確なデータを取得するために、以下の点に重点を置いています。
  • アプリの起動: ユーザーが最も認識しやすい遅延を最適化する
  • AI によるアプリのクロール: 継続的かつ進化するユーザー インタラクションをシミュレートする
  • システム全体のモニタリング: フォアグラウンド アプリのアクティビティだけでなく、重要なバックグラウンド ワークロードとプロセス間通信もキャプチャします。
• 検証: この合成ワークロードは、Google の内部フリートから収集された実行パターンと 85% の類似性を示しています。
• ターゲット データ: これらのテストを十分に繰り返すことで、最も人気のあるアプリケーションに対する実際のユーザー インタラクションを正確に表す高忠実度の実行パターンをキャプチャします。さらに、この拡張可能なフレームワークにより、追加のワークロードとベンチマークをシームレスに統合して、カバレッジを拡大できます。

ステップ 2: プロファイルの処理

未加工のトレースデータを後処理して、クリーンで効果的で、コンパイラで使用できる状態にします。

• 集計: 複数のテスト実行とデバイスからのデータを 1 つのシステムビューに統合します。
• 変換: 必要に応じて不要なシンボルをフィルタリングし、未加工のトレースを AutoFDO プロファイル形式に変換します。
• プロファイルのトリミング: プロファイルをトリミングして「コールド」関数のデータを削除し、標準の最適化を使用できるようにします。これにより、使用頻度の低いコードの回帰を防ぎ、バイナリサイズの不要な増加を回避できます。

ステップ 3: プロファイルのテスト

デプロイ前に、プロファイルは厳格な検証を受け、安定性のリスクなしに一貫したパフォーマンス向上を実現することが保証されます。

• プロファイルとバイナリの分析: 新しいプロファイルの内容（ホット関数、サンプル数、プロファイル サイズなど）を以前のバージョンと厳密に比較します。また、プロファイルを使用して新しいカーネル イメージをビルドし、バイナリを分析して、テキスト セクションの変更が想定どおりであることを確認します。
• パフォーマンス検証: 新しいカーネル イメージでターゲット ベンチマークを実行します。これにより、以前のベースラインで確立されたパフォーマンスの改善が維持されていることが確認されます。

継続的な更新

コードは時間の経過とともに自然に「ドリフト」するため、静的プロファイルは最終的に有効性を失います。最高のパフォーマンスを維持するために、パイプラインを継続的に実行して定期的な更新を推進します。

• 定期的な更新: 各 GKI リリースの前に Android カーネル LTS ブランチのプロファイルを更新し、すべてのビルドに最新のプロファイル データが含まれるようにします。
• 今後の拡張: 現在、これらのアップデートは android16-6.12 ブランチと android15-6.6 ブランチに提供されています。今後、サポートは、まもなくリリースされる android17-6.18 などの新しい GKI バージョンに拡大される予定です。

安定性の確保

プロファイルに基づく最適化に関する一般的な質問は、安定性のリスクが生じるかどうかです。AutoFDO は、ソースコードのロジックを変更するのではなく、主にコンパイラのヒューリスティック（関数のインライン化やコード レイアウトなど）に影響するため、カーネルの機能的完全性を維持します。このテクノロジーは、Android プラットフォーム ライブラリ、ChromeOS、Google 独自のサーバー インフラストラクチャの標準的な最適化として長年使用されており、大規模な環境で実績があります。

動作の一貫性をさらに保証するために、「デフォルトで保守的」な戦略を適用します。高忠実度プロファイルでキャプチャされない関数は、標準のコンパイラ メソッドを使用して最適化されます。これにより、カーネルの「コールド」な部分や実行頻度の低い部分が標準ビルドと同じように動作し、パフォーマンスの低下やコーナー ケースでの予期しない動作を防ぐことができます。

今後の展望

現在、android16-6.12 ブランチと android15-6.6 ブランチ全体に AutoFDO をデプロイしています。この初期ロールアウト以外にも、このテクノロジーをさらに強化するための有望な方法がいくつかあります。

• リーチの拡大: Google は、AutoFDO プロファイルを新しい GKI カーネル バージョンと、現在の aarch64 サポートを超える追加のビルド ターゲットにデプロイすることを予定しています。
• GKI モジュールの最適化: 現在、最適化はメインのカーネル バイナリ（vmlinux）に重点が置かれています。AutoFDO を GKI モジュールに拡張することで、カーネル サブシステムのより大きな部分でパフォーマンスのメリットが得られる可能性があります。
• ベンダー モジュールのサポート: ドライバ開発キット（DDK）を使用してビルドされたベンダー モジュールに対する AutoFDO のサポートも検討しています。ビルドシステム（Kleaf）とプロファイリング ツール（simpleperf）でサポートがすでに利用可能になっているため、ベンダーはこれらの最適化手法を特定のハードウェア ドライバに適用できます。
• プロファイルの適用範囲の拡大: より広範なクリティカル ユーザー ジャーニー（CUJ）からプロファイルを収集して最適化できる可能性があります。

AutoFDO を Android カーネルに導入することで、OS の基盤が、ユーザーが毎日デバイスを使用する方法に合わせて最適化されるようになります。