OpenGL ES 2.0でAndroid Wearウォッチフェイスを作成する

GoogleがAndroid Wear用の新しいAndroid 5.0でカスタムダイヤルを作成する可能性を発表するとすぐに、この最新機能を体験するために、最寄りのオンラインストアで新しいASUS ZenWatchを注文しました。 既存の3次元ライブ壁紙の1つを移植するのではなく、時計専用の新しいシーンを作成することにしました。 その結果、概念が発明され、OpengGL ES 2.0を使用して3Dで実装された5つのデジタルダイヤルのセットでアプリケーションが作成されました。

初期コンセプト

ダイヤルのアイデアは、この作品に触発されました（ビープルによる）：







ビデオはクールに見え、一見複雑に見えません。 ただし、ビデオと同じシーンを作成できない技術的な制限がいくつか見つかりました。 互いに正しく重なり合う線（ワイヤフレーム）から数字を作成するのはそれほど簡単ではありません。 要するに、これには多数の描画呼び出しが必要になり、非常に限られたクロックハードウェアでは非常に多くの描画呼び出しに対応できません。 そこで、別のアイデアに移りました。古いコンピューターのピクセルフォントの数字に深みを加えます。

深度コンポーネントなしのOpenGL ES設定

Android Wear APIのGles2WatchFaceServiceクラスは、ダイヤルの完全な3次元シーンを作成するために必要なすべての機能へのアクセスを提供しません。 すぐに直面した主な問題は、必要なOpenGL ES構成を選択できないことでした。 実際、このクラスはEGLへのアクセスをまったく提供しません。 サンプルAPIから「Tilt」ダイヤルを実行するだけで十分ですが、EGLを構成する柔軟性はありません。 この例には、重複するジオメトリが含まれていないため、深度バッファは必要ありません。 Gles2WatchFaceServiceは 、 EGL_DEPTH_SIZEを使用せずに構成を選択するだけで、APIで変更することはできません。



このような重大な制限が発見されたため、ソースコードを逆コンパイルし、ブラックジャックと正しいEGL構成を使用してGles2WatchFaceServiceの独自の実装を作成することが決定されました。



また、ライブ壁紙とダイヤルの非常に有名な開発者であるKittehface Softwareは、Moto360は完全に正しい16ビットEGL構成では動作しないことをブログで報告しました 。 したがって、すべてのデバイスで、アプリケーションは常に32ビットカラーを使用します。 このことについて私たちや他の開発者に警告してくれたKittehface Softwareに感謝します。Moto360でクラッシュの原因を見つけるには数日かかる可能性があり、その時点では時計自体がありませんでした。



デコンパイルされたクラスGles2WatchFaceServiceの完全なコードは提供しません。これは、新しいAPIのリリースで変更されるためです。 以下は、逆コンパイルされたGles2WatchFaceServiceに加えた変更です 。



1.深さコンポーネントを使用して適切な構成の検索を更新します。

  private static final int [] EGL_CONFIG_ATTRIB_LIST = new int [] {
     EGL14.EGL_RENDERABLE_TYPE、4
     EGL14.EGL_RED_SIZE、8
     EGL14.EGL_GREEN_SIZE、8
     EGL14.EGL_BLUE_SIZE、8
     EGL14.EGL_ALPHA_SIZE、8
     EGL14.EGL_DEPTH_SIZE、16、//これでは十分ではありませんでした
     EGL14.EGL_NONE};

2. mInsetBottomおよびmInsetLeft変数を子クラスから利用できるようにします。 ビューポートを正しく更新するために使用されます。 たとえば、それらを保護します。

  protected int mInsetBottom = 0;
 protected int mInsetLeft = 0;

glViewport（）

公式ドキュメントには、 onApplyWindowInsets（）メソッドを使用して異なる画面を持つデバイスを操作する方法についての非常に乏しい漠然としたリファレンスがあります。 この方法は、下端がトリミングされた画面に適応するために使用する必要があると述べています。 これは、Moto 360などのデバイスの外観を調整するために必要です。



Moto360が手元にない場合、この方法をどのように使用するかが明確ではなかったため、この時計でアプリケーションを起動しようとする最初の試みでは、画面の切り取られた部分のサイズだけビューがシフトしました。 この問題がティルトダイヤルの例にないことはかなり奇妙でした-それは正しく中央に置かれていました。 これを理解するために、 Gles2WatchFaceServiceサービスの逆コンパイルされたコードをもう一度見る必要がありました。 理由はglViewport（）の使用でした。 ブルーム効果を実装するために、テクスチャでレンダリングを使用し、 glViewport（）と呼ばれるレンダリングをテクスチャまたは画面に切り替えました。 画像のシフトを避けるために、 glViewport（）を指定する際に、切り取られた画面の下のインデントの値を考慮する必要があります。

通常モードおよび周囲モードでの透明度

不明な理由により、スクリーンセーバーモード（アンビエントモード）で不透明な通知カード（ピークカード）を描画することはできません。 通常モードでは、カードのタイプを指定できますが、保存モードでは、カードは常に完全に透過的です。 getPeekCardPosition（）メソッドを使用して、その上にカードが表示される場所に自分で黒い長方形を描画する必要があります。 私たちの場合、小さなサイズのカードを使用すれば十分で、数字と重なっていませんが、一般的には、カードのサイズに合わせて描画領域のサイズを小さくすることが望ましいでしょう。

ウォッチフェイスを更新するための設定を含むメッセージを送信する

時計調整アプリケーションの実装では、 HoloColorPickerを使用して数字と背景の色を選択します。 時計の色の変更は、ユーザーが色を変更するとすぐにリアルタイムで発生します （色選択コントロールのColorPicker.OnColorChangedListenerイベントで）。 ただし、これによりいくつかの問題が発生します。 ユーザーは非常に迅速に色を変更できます（色選択リングに沿って指を動かすとイベントが発生します）。これにより、色変更メッセージキューがオーバーフローします。 Wearable Data Layer APIは、それほど集中的にメッセージを送信するようには設計されていません。 何も落ちることはありませんが、最新のメッセージの一部は単に時計に届かない場合があります。 これを回避するために、色の更新の送信を500ミリ秒の間隔に制限します。 このようなわずかな遅延によって不都合が生じることはなく、ウェアラブルデータレイヤーAPIの機能を過負荷にしないようにします。

ハンドラーhandlerUpdateColorBackground = new Handler（）;

 Runnable runnableUpdateColorBackground = new Runnable（）{
     @Override
     public void run（）{
         //色が変更された場合にのみ更新
         if（pickedColorBackground！= lastSentColorBackground）{
             sendConfigUpdateMessage（KEY_BACKGROUND_COLOR、pickedColorBackground）;
         }
 
         handlerUpdateColorBackground.postDelayed（this、500）;

         //ウォッチに送信された最後の色を更新します
         lastSentColorBackground = pickedColorBackground;
     }
 };  

一般的なAndroid Wearエクスペリエンス

ほとんどのAndroid Wear時計はSnapdragon 400チップに基づいています-ASUS、Sony、Samsung、LGはすべての時計で使用しています。 このチップには、最大1.2 Hzの周波数を持つ印象的なクアッドコアプロセッサが搭載されており、時計としては十分です。 彼のビデオカードAdreno 305は一見、少し時代遅れに見えるかもしれません。 ただし、この時計の解像度は320x320ピクセルとやや小さいため、非常に複雑な3Dシーンを毎秒60フレームでレンダリングするには十分です。 古いOMAP3630チップを搭載したMoto 360でさえ、使用可能な画面解像度で十分なパフォーマンスを発揮するかなり強力なPowerVR SGX530グラフィックスカードを搭載しています。



たとえば、128x128解像度で追加された4パスブラーによるブルーム効果は、パフォーマンスの低下を引き起こしませんでした-Adreno 305はこの追加タスクに簡単に対処しました。 ただし、クロックでは、2つのブラーサイクルでブルーム64x64の低解像度を使用するのに十分であることが判明しました。



テンプルラン2やAndroidウォッチで動作するGTAなどのゲームを遅延なく動作させる多くのビデオがあります。これは、これらのデバイスでのビデオカードのパフォーマンスをもう一度示しています。

アプリケーションで使用されるシェーダー

レンダリングコマンドの数とCPUによって実行される作業を減らすために、数値のアニメーションは頂点シェーダーで実行されます。 これを説明するために、数字「5」と「0」の間の遷移モデルの例を次に示します。



ご覧のとおり、モデルの頂点は3つのグループに分けられます。

• アニメーション化されていない黄色の部分-数字「5」と「0」の間で共通の部分を表します。
• 暗い灰色の部分はアニメーション中に省略されます-番号「0」では使用されません。
• 薄い灰色の部分はアニメーション中に上昇します;それらは数字「0」で使用されますが、「5」では使用されません。

この情報はテクスチャ座標に入力されます。V座標は、固定部分の場合は0、上昇部分の場合は1、下降部分の場合は-1に設定されます。 これに加えて、U座標はアニメーションのフェーズを設定するため、シリンダーはすべて一緒に移動するのではなく、互いにわずかな遅れを持ちます。



フラグメントシェーダーは非常に単純です。頂点のZ座標が小さいほど、最終ピクセルがより黒く描画されます。 「3」と「4」の間の遷移を次に示します（モデルはRenderMonkeyによりミラーリングされます）-「4」の部分が下にシフトし、「3」の部分が上に上がる様子を確認できます。



以下は、モデルの下部が黒い背景と結合したときの最終結果です。





uAnimは[-1..1]の範囲で設定されたアニメーションを制御します

uHeightはアニメーションの高さを設定します-値は「フォント」に依存し、モデルの単一列の高さを設定します-写真に表示されるフォントの40単位に等しくなります。

uHeightColorおよびuHeightOffsetを使用すると、色の遷移を黒に変えることができます。 値uHeightColor = 40およびuHeightOffset = 0は写真の例に使用されましたが、フォントによって異なります。



ご覧のとおり、ほとんどすべての計算は既に頂点シェーダーで行われています。フラグメント1は色を補間するだけです。



RenderMonkeyプログラムのシェーダーを含むアーカイブへのリンク： dl.dropboxusercontent.com/u/20585920/shaders_watchface.rar

転記

Google PlayでAndroid Wearアプリを公開するときは、「Android Wearでアプリを配布する」の横にあるチェックボックスをオンにします 。 これにより、 Wear App Qualityの要件を満たすようにアプリをモデレートするプロセスが開始されます。 私たちの場合、このプロセスには数時間しかかかりませんでした。