Traceview: Androidのトレース＆プロファイリングツールとは

AndroidのTraceviewとは

TraceviewはAndroid Studioに組み込まれたグラフィカルプロファイラで、Androidアプリケーションメソッドの実行トレースをタイムラインと呼び出しテーブルとして表示します。これはAndroid SDKの一部であり、Android Studio 3.0以降のAndroid Profiler、およびdmtracedumpコマンドラインユーティリティを介して利用できます。

ツールの目的

Traceviewの主な役割は、最も多くのCPU時間を消費するメソッドを開発者が見つけるのを助けることです。単純なロギングとは異なり、Traceviewは各メソッドの正確な開始時間と終了時間を記録し、Call ChartとTop-Downツリーを構築して、パフォーマンスの異常を視覚的に検出できるようにします。このツールは、16msの遅延がフレームドロップを引き起こすUIスレッドのプロファイリング時に特に役立ちます。

歴史と開発

Traceviewは、.traceファイルを表示するためのスタンドアロンユーティリティとして、Android SDKの初期バージョンで初めて登場しました。Android Studio 3.0（2017）のリリースに伴い、Android Profilerの一部となり、ライブCPU、メモリ、ネットワークのタイムラインとの統合を獲得しました。Google I/O 2018によると、Android Studioチームはプロファイラの開発を継続しており、systraceおよびperfettoを介したネイティブコードのサポートを追加しています。現在のバージョンのAndroid Studioでは、TraceviewはPerfetto形式の上で動作しますが、従来の.trace形式との下位互換性を維持しています。

Traceviewの仕組み

Traceviewは、Android Runtime（ART）のSystem Tracingメカニズムからデータを受け取ります。トレースを有効にしてアプリケーションを起動すると、ARTは実行された各メソッドの開始タイムスタンプと終了タイムスタンプを記録します。これには、クラス名、メソッド名、スレッドIDが含まれます。

// アプリコードでのトレース開始
Debug.startMethodTracing("app_trace")

// プロファイリング対象の重要なコード区間
loadHeavyData()

// トレース停止 — ファイルはデバイスに保存
Debug.stopMethodTracing()

System TracingはART仮想マシンレベルで動作し、マイクロ秒精度で各メソッド呼び出しを記録します。アプリケーションのパフォーマンスへの影響を最小限に抑えるため、データはリングバッファに書き込まれます。トレースが停止すると、バッファはデバイスの内部ストレージにある.traceファイルにフラッシュされます。

.traceファイル形式

.traceファイルには、形式バージョンと開始時間を含むヘッダーがあり、その後に各呼び出しのレコードが続きます: スレッドID、メソッドID、開始タイムスタンプ、終了タイムスタンプ。Android Studioは.traceファイルを自動的にロードし、時系列のタイムラインパネルと呼び出し階層のプロファイルパネルの2つのメインビューを構築します。デフォルトの最大バッファサイズは8MBですが、Debug.startMethodTracing(filename, maxSize)で増やすことができます。

Traceviewの主な機能

Traceviewは、パフォーマンス分析においてそれぞれ特定のタスクに対応する複数の補完的なデータビューを提供します。

Call Chart（コールチャート）

Call Chartは水平方向のタイムラインで、各スレッドが個別のレーンとして表示されます。メソッドは色付きの長方形で示され、長方形の幅は実行時間に比例し、ネストは呼び出し階層を反映します。メソッドが別のメソッドを呼び出すと、子の長方形が親の長方形の内側に描画されます。この可視化により、スレッドをブロックした操作を即座に特定できます。

Top-DownツリーとBottom-Upツリー

Top-Downツリーは、ネストされたすべての呼び出しを含むメソッドの実行時間を表示します — Inclusive Time。一方、Bottom-Upツリーは、特定のメソッドを呼び出した親メソッドを表示します — 負荷の高い操作の原因を見つけるのに役立ちます。Inclusive TimeとExclusive Timeの違いは重要です。メソッド自体は高速に実行されても、低速な子メソッドを呼び出す可能性があり、これはInclusive Timeでのみ確認できます。

検索とフィルタリング

Traceviewはメソッド名、パッケージ、クラスによる検索をサポートしています。結果はタイムライン上でハイライト表示され、プロファイルパネルには見つかったメソッドの統計のみが表示されます。スレッドによるフィルタリングも可能で、バックグラウンドスレッドを非表示にして、遅延が最も重要なメイン（UI）スレッドに集中できます。

データエクスポート

Traceviewは、トレースをCSV形式でエクスポートして、スプレッドシートやグラフ作成でさらに分析することができます。Android Studioでは、タイムラインの選択部分を画像としてコピーして、バグレポートやドキュメントに挿入することもできます。CI/CDでは、cmdline-toolsユーティリティを介してPerfetto形式でのエクスポートが利用可能です。

Android StudioでのTraceviewの使い方

プロファイリングはTraceviewを介して2つの方法で利用できます: ライブキャプチャを使用したAndroid Profilerを介する方法と、プログラムによるDebug API呼び出しを介する方法です。最初の方法はアドホック分析に便利で、2番目の方法は再現可能なパフォーマンステストに適しています。

Android Profilerを介したキャプチャ

Android StudioでProfilerタブ（View → Tool Windows → Profiler）を開き、デバイスとアプリケーションプロセスを選択します。CPUセグメントをクリックし、“Trace Java Methods”モードを選択してRecordをクリックします。アプリケーションを操作した後、Stopをクリックすると Traceviewが自動的に記録されたトレースを開きます。デフォルトの録画時間は30秒に制限されていますが、プロファイラ設定で制限を変更できます。

プログラムによるトレース開始

特定のコードセクションを正確にプロファイリングするには、Debug.startMethodTracingとDebug.stopMethodTracingを使用します。ファイルは、context.getExternalFilesDir(null)が返すパスのアプリケーション外部ストレージに保存されます。完了後、Android Studio Device Explorerを介して.traceファイルをコンピュータに転送し、Android StudioでFile → Openから開きます。

Debug.startMethodTracing(
    "heavy_computation",
    Debug.TRACE_COUNT_ALLOCS
)

processLargeDataset()

Debug.stopMethodTracing()

トレースパラメータの設定

Debug.startMethodTracingは、ファイル名（拡張子なし）、最大バッファサイズ（デフォルト8MB）、フラグの3つのパラメータを受け取ります。TRACE_COUNT_ALLOCSフラグはオブジェクト割り当てのカウントを追加します — メモリリークの発見に役立ちます。Traceviewはネイティブコードのプロファイリングには適していません — SimplePerfまたはPerfettoを使用してください。長時間のテスト（30秒以上）では、maxSizeパラメータを使用してバッファを64–128MBに増やすことをお勧めします。

Traceviewタイムラインの読み方

Traceviewタイムラインは2つのパネルで構成されています: 上部の色付き呼び出し長方形のタイムラインパネルと、下部の統計テーブルのプロファイルパネルです。タイムラインパネルは左から右にスレッドの実行を表示し、各長方形は単一のメソッド呼び出しです。長方形の色はメソッドタイプによってコード化されています: Androidシステム呼び出し（緑）、アプリケーションメソッド（青）、ライブラリ呼び出し（オレンジ）。

プロファイルパネルの読み方

プロファイルパネルでは、各行がInclusive Time、Exclusive Time、Calls + Recur、CPU Timeの列を持つメソッドです。テーブルをInclusive Time（降順）で並べ替えると、最初に合計時間が最も長いメソッドが表示されます。Inclusive Timeが高いメソッドのExclusive Timeが低い場合 — 問題は子呼び出しにあり、ツリーを展開する必要があります。たとえば、ListView.getViewは画像読み込み呼び出しのために高いInclusive Timeを持つ可能性があります。

ボトルネックの特定

Real Timeが異常に高くCPU Timeが低いメソッドを探します — これはブロッキング（I/O待機、ネットワーク操作、ロック競合）を示しています。CPU Timeが高いメソッドはアルゴリズムの最適化が必要です。UIスレッドの場合、各メソッドは16ms以内に完了する必要があります — いずれかの呼び出しがこのしきい値を超えると、アプリケーションはフレームをドロップし、ユーザーはジャッターを目にします。Googleの推奨によると、UIスレッドの1フレームあたりの全呼び出しの合計時間は8〜10msを超えてはならず、システム操作のためのマージンを残します。

Traceview vs Systrace: ツール比較

TraceviewとSystraceはどちらもAndroidトレースツールですが、異なるタスクを解決し、異なるプロファイリング段階で使用されます。主な違いは詳細レベルです: TraceviewはJava/Kotlinメソッドレベルで動作し、Systraceはシステムプロセスレベル（CPU、GPU、Binder、SurfaceFlinger）で動作します。

実際には、両方のツールは相互に補完します。最初にSystraceがどのシステムコンポーネントが問題を引き起こしているか（頻繁なGCやBinderロックなど）を特定するのに役立ち、次にTraceviewでアプリケーション内の特定のメソッドを詳細に調査できます。Android Studioでは、両方のツールがAndroid Profilerに統合されており、CPU Profilerが自動的に最適な記録モードを選択します。Android 12+のデバイスでは、SystraceとTraceviewはPerfetto上で動作し、すべてのタイプのプロファイリングに統一されたデータ形式を提供します。

Traceviewを使用したコード例

効果的なプロファイリングには、トレースを開始するだけでは不十分です — キャプチャポイントを適切に配置し、結果を解釈する必要があります。以下に2つの実用的な例を示します: RecyclerView読み込みのプロファイリングと、パフォーマンステストにおける2つのアルゴリズムの比較です。

RecyclerView読み込みのプロファイリング

最初の例は、リストスクロール中のクリティカルパスのトレースです。RecyclerViewは表示される各アイテムに対してonBindViewHolderを呼び出し、このメソッドが16ms以上かかる場合、スクロールがガタつきます。onBindViewHolderの前後をトレースすることで、その内部のどの特定の操作が時間を消費しているかがわかります。

class MyAdapter : RecyclerView.Adapter<ViewHolder>() {
    override fun onBindViewHolder(
        holder: ViewHolder,
        position: Int
    ) {
        Debug.startMethodTracing("bind_card_$position")

        holder.bind(items[position])

        Debug.stopMethodTracing()
    }
}

2つのアルゴリズムの比較

2番目の例は、2つの実装のA/B速度テストです: Glideを介した画像読み込みと手動のBitmapFactoryの比較です。このトレースにより、両方の戦略のInclusive Timeを客観的に比較し、最適なものを選択できます。各テストは、同一条件下（バックグラウンド負荷、温度）でウォームアップしたデバイス（3〜5サイクル後）で実行することが重要です。

fun compareImageLoadingStrategies() {
    // テストA: Glide
    Debug.startMethodTracing("glide_test")
    loadWithGlide()
    Debug.stopMethodTracing()

    // テストB: BitmapFactory
    Debug.startMethodTracing("bitmap_test")
    loadWithBitmapFactory()
    Debug.stopMethodTracing()
}

実行後、Android Studioで両方の.traceファイルを開き、プロファイルパネルでInclusive Timeを比較します。Glideが同じタスクに対して3倍少ないInclusive Timeを示した場合 — これはライブラリを選択する客観的な根拠となります。Tony John（Glide開発者、2023年）によると、このライブラリはキャッシュとスレッドプールを使用しており、繰り返しの読み込みで最大40%の利得を提供します。