アニメーション ジャンクをデバッグする
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
アプリ デベロッパーにとって難しい問題の一つに、いかにしてスムーズで安定したジャンクのないアニメーションを実現するかという問題があります。特に、同じシステムでリソースを大量に消費するバックグラウンド タスクも実行されている場合、そのデバッグは困難です。ジャンクの原因がアプリとシステムのどちらにあるかを判断する簡単な方法はありません。ただし、不適切な動作の原因を特定できるプロファイラ ツールがあります。
ChromeOS でのレンダリング
ゲームなどの細かな調整を要するアプリの場合、通常ダブル バッファリングを使用して、ユーザーへの応答時間を可能な限り短くします。それでもなお、パフォーマンスを低下させる要因はたくさんあります。たとえば、フレームのレンダリングに時間がかかりすぎると、レンダリングされた結果は次のバッファ交換の準備ができておらず、前のフレームが繰り返されます。
すると、レンダラは次のフレームのレンダリングを開始できなくなり、さらなる問題が生じます。このシナリオは Android モバイル デベロッパーにはおなじみのものです。アプリが ChromeOS で実行される場合、状況はさらに複雑になります。
デスクトップで実行されているアプリは、画面のディスプレイ フレームに直接レンダリングされません。データはレンダリングされてテクスチャになります。通常はアプリが複数あり、それぞれによってグラフィックスがテクスチャにレンダリングされます。システムがコンポジタを使用して画面上にビューを構築し、すべてのテクスチャを 1 つのデスクトップ画像に統合します。
コンポジタはバックグラウンドで透過的に動作します。ただし、GPU パイプラインを最大限に活用するために、1 フレームの遅延が発生します。これは理想的には必要ないかもしれませんが、システム パフォーマンスの変動を抑制し、非対称な負荷のバランスを取るのに役立ちます。
OS が非常に忙しく動作している場合、GPU が圧迫される可能性があります。フレームがレンダリングされてから画面に表示されるまでに遅延が発生する場合があります。ハードウェアによっては、補正に 4 倍バッファリングが使用される場合があります。バッファリングを深くしても、グラフィック パイプラインに不具合が生じる可能性があります。
ARC グラフィック トレーサー
ChromeOS には、システム内でのバッファのパーコレーション状況、メモリスワップの発生時間、CPU/GPU のビジー状態、特定の時点でのアプリの動作を示すプロファイリング ツールが用意されています。下の画像をご覧ください。

プロファイラを設定する
プロファイラを使用するには、M75 以降を実行する必要があります。Intel デバイスを使用すると、最適な結果が得られます。
プロファイラを使用する前に、アプリをトレースでシードします。トレースを追加するコードに、Trace.traceCounter(Trace.TRACE_TAG_GRAPHICS, "Event", <number>);
を追加します。接頭辞 customTrace
で始まる Event
を使用します。この接頭辞はトレース メッセージには含まれません。
プロファイラの設定手順は次のとおりです。
- デベロッパー モードをオンにします。
- Chrome の設定をオンにして、ARC グラフィック バッファ可視化ツールを有効にします。
chrome://arc-graphics-tracing
に移動します。
プロファイラを実行する
- [ジャンクで停止] を選択します。
- Android アプリを実行します。
- Android アプリがアクティブでフォーカスされている状態で、Ctrl+Shift+G キーを押します。
ジャンクが発生すると、ブラウザ ウィンドウがポップアップ表示されます。タイムラインのズームと縮小を行うには、W キーと S キーを使用します。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-07-27 UTC。"],[],[],null,["# Debug animation jank\n\nOne of the most difficult problems for app developers is\nensuring smooth, glitchless, and jank-free animation. This is especially hard to\ndebug when the system is also performing resource-intensive background\ntasks. There is no easy way to determine whether some jank is caused by your app or\nthe system. However, there is a profiler tool that can help you identify the\npossible source of the bad behavior.\n\nRender on ChromeOS\n------------------\n\nA fine-tuned app, like a game, usually uses double buffering to keep the user\nresponse time as low as possible. Still, there are many things that can degrade\nperformance. For example, if rendering a frame takes too long, the rendered\nresult is not ready for the next buffer swap, and consequently the previous\nframe repeats.\n\nThen, the renderer can't start rendering the next frame,\ncausing even more problems. This scenario is familiar to Android mobile\ndevelopers; when an app runs on ChromeOS, the context is even more complicated.\n\nAn app running on the desktop doesn't render directly to the screen's display\nframe. It renders its data into a texture instead. There are usually multiple\napps, each rendering its graphics into a texture. The system constructs the view\non the screen using a compositor to combine all the textures into a single\ndesktop image.\n\nThe compositor works transparently in the background. However, it introduces a\none-frame time delay to maximize the use of the GPU pipeline. In an ideal\nworld this might not be necessary, but it smooths system performance\nfluctuations and helps balance an asymmetrical load.\n\nWhen the OS is working very hard, the GPU might get squeezed. There can be a\ndelay from the time a frame renders to when it appears on the\nscreen. Depending on the hardware, the system might use quadruple buffering to\ncompensate. Even with deeper buffering, the graphic pipeline can still glitch.\n\nThe ARC graphics tracer\n-----------------------\n\nChromeOS has a profiling tool that shows how the buffers are percolating\nthrough the system, when memory swaps occur, how busy the CPU/GPU is, and what\nyour application is doing at a given time, shown in the following image:\n\n### Set up the profiler\n\nTo use the profiler, you must run M75 or later.\nFor best results, use an Intel device.\n\nBefore using the profiler, seed your app with traces.\nAdd `Trace.traceCounter(Trace.TRACE_TAG_GRAPHICS, \"Event\", \u003cnumber\u003e);` to your code\nwherever you'd like to include a trace. Use an `Event` that begins with\nthe prefix `customTrace`. The prefix doesn't appear in the trace message.\n\nTo set up the profiler, follow these steps:\n\n1. Turn on developer mode.\n2. Turn on Chrome settings and enable the **ARC graphic buffers visualization tool**.\n3. Navigate to `chrome://arc-graphics-tracing`.\n\n### Run the profiler\n\n1. Select **stop on jank**.\n2. Run the Android app.\n3. When the Android app is active and has focus, press \u003ckbd\u003eControl\u003c/kbd\u003e+\u003ckbd\u003eShift\u003c/kbd\u003e+\u003ckbd\u003eG\u003c/kbd\u003e.\n\nWhen some jank happens, a browser window pops up.\nUse the \u003ckbd\u003eW\u003c/kbd\u003e and \u003ckbd\u003eS\u003c/kbd\u003e keys to zoom and shrink the timeline."]]