temporaryなめも帳

だらだらと備忘録とか。誰かの為になることをねがって。

Android Performance Patterns その２

その２

例のごとく、英語の勉強もかねてるので合ってるかは知らない。

今日のお題は Rendering Performance 101 派生してる次のも一緒に見ておいた。

Why 60fps

アプリケーションは60Hzで画面更新してる。つまりは、16ms毎にGPUの更新処理を終えないとフレーム落ちしちゃうことになる。

なぜ60fpsなのかというと、人間の目の性能的にマッチしている値だからだそう。 24fpsだと荒く見えちゃうし、60超えてても大きな差はあまり認識できないらしい。

Understanding VSYNC

16ms毎にViewの更新処理をなぜ行わなければいけないかというと、VSYNCの問題があるから。ラグになるよって話かな。
Refresh-Rate(画面の更新頻度)とFrame-Rate(GPUの絵の作成時間)の話を冒頭に、まだ出来上がってない絵を描いちゃうテアリングの話と、出来上がってない時に前の絵を描くVSYNCの話がまとまってた。

Android, UI and the GPU

layout.xmlに書いたUIをどうやって描画しているのかって話。
そのコアになる処理がrasterizationでこの処理はGPUでサポートされて高速化されてる。 OpenGLESをつかって描画するときは、CPUでポリゴンやテクスチャに変換して、GPUに転送しないといけない。OpenGLES APIにはGPU Bufferにテクスチャなどを置いておけるAPIがある。これを利用して都度の転送を減らすことが高速描画につながる。
アプリケーションのthemeのリソースは一つのテクスチャにまとめられてGPUにアップロードされている。これらを使う分には高速に描ける。 画像を描画するときはCPUでイメージをロードして（画像、Path、文字、アニメーションに言及）〜といった具合にCPUとGPUの処理内容をイメージできるといいよって話なのかな。

Understanding Overdraw

何回も同じpixelにdrawするのはもったいないよって話。
Overdrawを確認する時は、DeveloperOptionのShow GPU OverdrawをONにする。 するとOverdrawの回数によって、pixelに色がつくようになる。

  • overdraw無し: true color(色がつかない)
  • 1x: 青
  • 2x: 緑
  • 3x: ピンク
  • 4x: 赤

これを確認して、不必要なoverdrawは無くしていくべき。

Views, Invalidation and Perfowmance

Viewのプロパティを変更したときにAndroidの中で何が起きているのかって話。
まずは、Android UI and the GPUのおさらい。 GPUで描画するViewは全てDisplay Listで管理されていて、描画するときにOpenGLで描画される。 初めてViewが描画されるときにDisplay Listは作成され、それを実行する形でGPUに描画命令を出す。
Viewの位置変更のような変更はもう一度Display Listの実行命令を出すだけですむが、Viewの表示内容に関わる変更の場合はそれではすまない。 もう一度Display Listの作成を行った上で描画命令を出す必要が出てくる。
Viewの表示内容に関わる変更は描画パイプラインへの影響が大きい。 他の例を挙げると、TextViewの大きさを二倍に変更したときに、parentのコンテナの位置調整が起こり、関連するViewの描画位置の変更が発生することがある。 Viewの大きさを変えると、大きさの計算処理(Measure処理)がView Hierarchyに対して走り、それぞれのView毎に新たなサイズを計算する。さらに位置が変更されたときは、位置の計算処理(Layout処理)が走ることになる。 その後にDisplay Listを再構築して、描画命令が出る形になる。
大きさ変えたり、位置変えたりはコストでかいから初期位置には注意を払ってねってお話。
Viewのinvalidate処理のデバッグをするなら GPU View Updates が役に立つ。
LayoutやMeasure処理に時間がかかるようなら、Hierarchy Viewerを使ってViewの階層構造を確認してみるといいよ。

思ったより長くなったけど描画周りの勉強になった気がする。