連載

2009年4月21日

Androidアプリで高速描画チューニングをするコツ：インタビュー特集：Google直伝！（1）（3/3 ページ）

Googleのさまざまなサービスを使いこなすコツをグーグル担当者に聞くインタビュー。初回はいま注目のAndroidについて

[嶋是一, 中村秀樹, 安生真，日本Androidの会] PC用表示関連情報

LINE

Hatena

前のページへ | 　　　　　　

【1】「コンパチビリティ」と「ワン・バイナリ」

　Androidは、OpenGL ESのバージョン1.0が標準仕様だ。Android SDKでも、これがサポートされていて、今後販売されるAndroid端末も、OpenGL ES 1.0が動作することが保証されている。

　一方、G1はOpenGL ES 1.0と、OpenGL ES 1.1のいくつかの拡張機能をサポートしている。そのため、Androidの標準仕様を逸脱する形となるが、1.0になく1.1にある拡張機能を用いて、描画を高速化することが可能だ。

本稿の筆者の1人であり、インタビューも行った日本Androidの会幹事嶋是一氏「Androidは組み込み初心者も入門しやすい」

　前述のBasic Vert Quadsは、OpenGL ES 1.0標準なので、これを用いる場合は今後出荷されるAndroid端末のどこでも動作することが期待される。一方、Draw Texture ExtensionやVBO Extensionについては、OpenGL ES 1.1の拡張のため、今後のAndroid端末に搭載されるGPUデバイスで利用できる保証がない。サポートしていないのに使うとエラーとなってしまう。

　端末がこれらのExtensionを利用する場合は、デバイス（端末のGPU）がサポートしているかどうか確認する必要がある。これはOpenGL関数の「glGetString(GL_EXTENSIONS)」メソッドで出される文字列で確認できる。

　また、たとえGPUが搭載されてOpenGL ESがサポートされていても、搭載されているGPUチップの種類や性能によっても結果が変わってしまうだろう。今回の評価結果は、あくまでもT-Mobile G1としてのものであり、普遍的な結果ではない点には特に注意が必要だ。

「グーグルは、『ワン・バイナリ（One Binary）』を目指している。つまり、デバイス（Android実機本体）固有の実装は避けるべきで、どの装置でも同じバイナリが利用できるべきだ。これは、『コンパチビリティ（互換性）』の問題にもつながる。今回お話ししているようなデバイス依存なコーディングも、できる限りワン・バイナリに近づけるべきものだ」（プルエット氏）

　デバイス能力を100％引き出すようにデバイスに特化した設計をするよりも、85％程度に抑えて、この範囲でワン・バイナリを目指した方がよいだろう。特に、今回のSpriteMethodTestアプリケーションでは、OpenGL ESを利用した3手法のソースコードはほとんど変わらない。1ファイル程度の変更で済んでいる。そのため、今回の結果は意義があるものだろう。

【2】スレッドの設計が重要

　ゲームを設計するときには、スレッドの設計が重要だ。ハードウェア外部に処理を任せているケースでも、その処理が終わるまで処理を待つ「同期処理」でプログラムを記述するケースが多い。しかし、実際待っている間はCPU演算していないため、この間にほかの処理を行った方が効率が良い。その方が、時間に対してリアルタイムに動作する、ゲームのような処理をより効率的に実現できる。

■ ゲームアプリにおけるスレッド設計の基本

　このようなゲームアプリのスレッドは、次のように構成するとよい。

メインスレッド
ほとんど使用されないが、端末の入力やAndroidプラットフォーム内のほかのイベントを受け付ける
ゲームスレッド
思考アルゴリズムやゲームアプリケーションとして基本的な処理、そして“当たり判定”（演算のタイミングとか解像度により、すれ違ってもあたり判定が起きないケースがある）を含む、全てのゲーム演算をつかさどるスレッド
レンダリングスレッド
描画以外に影響されないようにし、レンダーはただ繰り返し描画するだけにする。表示場所などはゲーム処理本体スレッドなどから取得

■ OpenGL ESを用いた場合

　OpenGL ESを用いた場合は、SurfaceViewなどを利用して描画スレッドを作成するのがよい。アプリケーションの演算中でも、またはOpenGL ESの関数を呼び出して（ハードウェアが処理を行い）戻りを待っている間でも、お互いが動くことができるためだ。つまり、ブロック（同期処理で待っている）時間を有効活用できるため、描画速度が向上できる。

　今回の「SpriteMethodTest」でスレッドの効果を測定するパラメータが、前述表2の「Draw」「Page Flip」だ。

　「Draw」時間とは、Canvasを用いた場合は「Canvas.drawBitmap()」メソッド（※2）の時間だ。OpenGL ESを用いた場合は1つのフレームのすべてのGLファンクションが完了するまでの時間（例えば、DrawTextureの場合は「glBindTexture()」メソッドと「glDrawTexfOES()」メソッドの処理時間）を示す。

※2：インタビューでの話とドキュメントでは「Bitmap.drawCanvas()」メソッドとあったが、著者メンバーで「Canvas.drawBitmap()」メソッドであろうと結論づけた

GLファンクションについて説明中のプルエット氏「グーグルは、ワン・バイナリを目指す。デバイスに特化した設計をするよりも、85％程度に抑え、この範囲でワン・バイナリを目指した方がよいだろう」

　「Page Flip」時間とは、Canvasを用いた場合は「lockCanvas()」メソッドの時間だ。プルエット氏のコードでは、「unlockCanvasAndPost()」メソッドと「lockCanvas()」メソッドの両方を記録しているが、速度評価を行うテストの結果に影響は出ない。

　またOpenGL ESの場合は、「eglSwapBuffers()」メソッドの処理が相当し、この間GPUの中で処理が行われる。この関数が完了するまでは、スレッドの処理は止まる。この時間が長ければ、待ち時間が多いこととなり、スレッドにより効率よく処理が分散できていないことを示す。

【3】JNIが遅いというパラドックス

　OpenGL ESを用いたチューニング時に気を付けるべきは、これらの関数のほとんどがJNI（Java Native Interface）を用いて呼び出されている点だ。

　一般的にJNIはJavaアプリケーションから、C/C++で記述されたライブラリの関数を呼び出す手段として提供される。そのため、いずれのケースでも高速に動作すると思われがちだが、実際にはそうではない。Java関数の呼び出し時間を図5に紹介する。横軸は時間だ。

図5　Android上での関数呼び出し時間（JNIを使うと、通常のJava内に比べて倍程度の時間が掛かっている）

　JNIを用いた場合の関数呼び出しが、通常のJava内に比べて、倍程度かかってしまうことが分かる。理由は、JNIを介してC/C++にブリッジする際、関数をルックアップするため、ほかの処理を一度止めて関数ポインタを探しているからではないかと考えられる。

　これは関数を呼び出す瞬間の時間であり、実際呼び出された後の演算はC/C++に準じた携帯電話のネイティブコードで実行される。このことは、単発でJNIをコールするケースはスループットに影響しないが、ループの内部などでJNIを複数回呼び出す（かつ、C/C++部分の処理がほとんどない）場合にオーバーヘッドが効いてくる。OpenGL ESの処理などでも、このJNI越しの関数呼び出しについては、どの程度の頻度で呼び出されるかにより、アルゴリズムのチューニングができるだろう。

　ちなみに、Android上のJNIは利用する自体は可能だが、グーグルでは一般開発者向けに正式に公開していない。この理由は、今後JNIの利用方法が変更される可能性があるためと、JNIを利用したアプリケーションについて、ワン・バイナリの考え方に反してしまうためだ。

ベストチューニングAndroidの可能性

　今後登場する数々のAndroid端末に特化したチューニングを施すことにより、標準的なアプリケーションの作り方では実現しなかったパフォーマンスを手に入れることができる。その中には「ゲーム専用機」に近いスペックを持つものも登場するかもしれない。将来へのAndroidアプリケーションの期待が膨らんだ。

Androidのこれからについて話し合う4人（左から、日本Androidの会幹事安生真氏、嶋氏、中村秀樹氏、プルエット氏）

「私はAndroid上で動作するさまざまなアプリケーションが開発されることを期待しているが、ゲームアプリケーションへの期待は大きい。また、Androidのコミュニティ（Android-SDK-Japan）や、Google Developer Dayでもほかの話題と同様、このようなAndroidゲームの話題を増やしていきたい」（プルエット氏）

著者紹介

日本Androidの会幹事
嶋是一
中村秀樹
安生真

「次回」へ

「インタビュー特集：Google直伝！」バックナンバー