アプリ デベロッパーにとって難しい問題の一つに、いかにしてスムーズで安定したジャンクのないアニメーションを実現するかという問題があります。特に、同じシステムでリソースを大量に消費するバックグラウンド タスクも実行されている場合、そのデバッグは困難です。ジャンクの原因がアプリとシステムのどちらにあるかを判断する簡単な方法はありません。ただし、不適切な動作の原因を特定できるプロファイラ ツールがあります。
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 キーを使用します。