2017年04月16日

「Androidを支える技術T」を読んで その2

 Androidを支える技術〈T〉を読んでのその2です。

2.GPUを利用した究極の描画システム

 これは、「4.OpenGL ES を用いたグラフィックシステム」の部分です。

 実は、私は自作アプリと言っても、過去のバージョンの互換性のため、つい最近まで、コンパイルは2.3.3つまりapi levelを10にしたままで公開しておりましたので、4.0からハードウェアアクセラレーションが標準で有効になっているのをつゆ知らず(^_^;)、canvasでの描画速度はこの程度だろうなぁと思っておりました。

 ですが、つい先日コンパイラを4.0以降にしたところ、今のandroidの描画は何も苦労しなくても、実になめらかにスクロールするようになっているんですね、知らんかった(^_^;)

 …ということで、以下の部分は、時代遅れの私には、まさに驚愕の仕組みでした(^^)/

 描画は、Viewのdraw()メソッドの時点では行われず命令列を保持するだけにして、実際の描画は別のスレッドで非同期に行います。(中略) 命令列の実体はOpenGLの命令列を表すDisplayListというものです。

 DisplayListの再作成がなるべく少なくして済むような単位で分解しておくことで、画面の一部が変更された時に、その変更された所と関係のないViewサブツリーは以前のDisplayListを使いまわして必須な所だけ再構築するようにしておくことができます。

 DisplayListのシステムでは、アニメーションの時に影響を受ける要素をシステムが把握しているため、影響を受ける部分だけを更新して画面を描画することができます。アプリの開発者はアニメーションを指定するだけで、システムが高速でなめらかなアニメーションを実現してくれます。

 裏に隠れる不要な描画命令をスキップしたり、他のオブジェクトが上に来て隠れたり、逆に他のオブジェクトが上から移動して画面に現れたりした時にも、Viewのコードまでわざわざ戻らずにDisplayListを再利用するだけで対応できます。

 OpenGLで描画した後、(中略) 合成用のハードウェアを最大限使いつつ、(中略) 画面に表示します。

…このような仕組みのおかけで…

 アプリ開発者がそれほど特殊なことをしなくても、大量のアイテムをスクロールさせてもずっと60fpsが維持される、JITが走って、GCが走って、データベースのためのファイルIOが走って、ユーザーコードのレイアウトが動的に走って、それでも引っ掛からない。

というような究極の描画システムが出来上がっている訳ですね、納得です(^^)。

 …その3へ続きます。
posted by 【なかま】 at 22:00 | Comment(0) | android
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント: