"L"の中身

ちょっとスマートウォッチで寄り道しましたが、「第74回 "L"がくる」の続きで"L" Developer Previewの内部的なところを見ていくことにしましょう。

"L"では、実行環境がARTに切り替わります。ARTについては昨年掲載の「第52回 android 4.4 "Kit Kat"の内部的な変更点」で簡単に解説しましたが、アンドロイドと同時に開発されこれまで使われてきた実行環境であるDalvik VM(Virtual Machine)に代わる新しいVMです。KitKatでは、標準はDalvikで、開発者オプションでARTに切り替えることが可能で、どちらかというと開発者に実機上でARTのテストをしてもらうという位置づけでしたが、"L"では、ARTが正式な実行環境になります。

ARTは、アプリのインストール時に仮想マシンコードをネイティブコードに変換する「AOT」(Ahead-of-time)コンパイル機能をがあります。このとき、より厳しくコードをチェックします。また、ARTでは、性能を上げるため、これまでのDalvikで有効だった手段が利用できなかったり、動作が違うためにアプリ側に変更が必要な場合があります。ARTでは、ガベージコレクション、JNI(Javaから機械語コードを使う方法)、オブジェクトモデル、スタックサイズなどに違いがあるようです。こうした違いのため、一部のアプリケーションでは、問題が出るようです。"L"を開発者プレビューとして公開した背景には、正式出荷までにARTで問題が出るようなら対応してもらうおうということなのでしょう。

もう1つの変更点は「通知」(Notification)です。Android Wareとの連携ということもありますが、通知機能が強化されるとともに、通知に属性を付けて、利用状況などを判断したうえで通知を行うようになりました。また、通知は、アプリの実行中でも画面上部に短冊状の矩形を表示してリアルタイムに行うだけでなく、ロックスクリーンにも通知が表示されるようになりました(写真01)。また、従来の通知シェード(画面上部の通知領域をドラッグして通知の一覧を表示するもの)は、単純なスクロール表示ではなく、3次元的な表示が行われます(写真02)。イメージ的には、積み上げたカードをずらして見ていくような感じです。

"L"では、通知に対して、アプリ側で、通知のタイプ(APIでは「見え方」、Visibilityと呼んでいます)を「私的」、「公的」、「秘密」の3つから指定でき、これにより、ロックスクリーンでの表示を制御します。たとえば、「秘密」と指定されたメッセージはロックスクリーンには表示されず、「私的」とした通知は、通知のアイコンなどの基本的な情報は表示されるものの、詳細な通知内容は表示されません。

これとは別に通知に属性(メタデータ)を指定することもでき、通知のカテゴリや優先度、通知を転送する人などを指定しておくこともできます。通知のカテゴリは、標準では14種類定義されています(表01)。

■表1
カテゴリ(APIで指定する定数名)	意味
CATEGORY_ALARM	アラームやタイマーの通知
CATEGORY_CALL	通話着信やリアルタイムコミュニケーションの要求など
CATEGORY_EMAIL	電子メールなどの非同期の量の多いメッセージ
CATEGORY_ERROR	バックグラウンド処理のエラーや認証状態など
CATEGORY_EVENT	カレンダーのイベント
CATEGORY_MESSAGE	SMSやインスタントメッセージなどの直接メッセージの到着
CATEGORY_PROGRESS	長時間バックグラウンドで動作する処理の進行状態
CATEGORY_PROMO	プロモーションや告知/広告
CATEGORY_RECOMMENDATION	1件の現時点の提案
CATEGORY_SERVICE	バックグラウンドサービスが実行中であることの通知
CATEGORY_SOCIAL	SNSや共有のアップデート
CATEGORY_STATUS	デバイスや状況に関する進行中の情報
CATEGORY_SYSTEM	システムやデバイスの状態更新
CATEGORY_TRANSPORT	メディアの再生制御

こうした属性情報を利用して、アンドロイド側が把握しているユーザー状況やユーザー指示などから作られる通知のフィルターやランク付けで通知をどう表示するかなどを判断するとされています。ただし、属性に指定されるものははっきりしていますが、それに対してシステム側がどのような動作を行うかは、はっきりとしたドキュメントはいまのところないようです。また、こうした属性などが設定された通知は、"L"対応のアプリでないと作ることができないため、当面は、属性が指定されていない古いタイプの通知と混在することなり、システム側が、通知のフィルタリングやランク付けを完全に行うことは難しいと思われます。

さらに内部的な違いとして、アプリから利用するWebViewと呼ばれる「部品」が強化されています。WebViewはその名前の通り、HTMLなどを使って画面表示を行うための「部品」です。"L"では、Chromium M36(36.0.0.0.)というバージョンのものになっています。Chromiumは、Chromeブラウザなどのベースになるオープンソースプロジェクトの成果物のことで、このChromiumからChromeブラウザやWebViewなどが作られます。デスクトップPC用のChromeでは、現在Chromium M36ベース(36.0.1985.125m)になっています。KitKatの最初のものでは30.0.0.0.が採用され、最新のKitKat 4.4.3では、33.0.0.0.です。KitKatのWebViewとの違いは、WebGL、WebRTC、WebAudioへの対応です(表02)。WebGLは、HTML内で3次元表示を行うための機能(API)、WebRTCは、リアルタイム通信を行う機能、WebAudioは、HTML内でオーディオデータを扱う機能です。

■表2
	Android	4.4.0	4.4.3	"L"
	Chromium	30.0	33.0	36.0
機 能	WebGL	×	×	○
	WebRTC	×	×	○
	WebAudio	×	×	○
	Form validation	×	○	○
		×	○	○

また、グラフィックス機能もOpenGL ES 3.1が搭載されるだけでなく、その拡張機能となるAndroid Extension Packが搭載され、機能が強化されました。OpenGE ES 3.1は、今年3月に発表されたOpenGL ESの最新版で、GPU演算を可能にするコンピュートシェーダーなどが利用可能になっています。

Android Extension Packは、OpenGL ES 3.1を補完するアンドロイド共通の拡張機能です。

このパックには、テッセレーションシェーダー、ジオメトリシェーダー(OpenGL ES 3.1ではこの2つのシェーダーはサポートされていない)などが追加されているほか、OpenGL ES 3.1でオプションとされているピクセルシェーダー(OepnGLではフラグメントシェーダーと呼ぶ)の一部機能などがサポートされている。

テッセレーションとは、3Dグラフィックスを構成するポリゴンを、頂点計算が終わったあとに分割することで、頂点計算を軽減して高速化を行う技法をいい、テッセレーションシェーダーは、その処理を行うシェーダー機能のことです。これに対してジオメトリシェーダーは、ポリゴンから構成されるプリミティブに対する処理(プリミティブの分割や補完など)を行うシェーダーです。この2つのシェーダー機能は、OpenGL 4.xでは対応が行われています。

現状、OpenGLとOpenGL ESには、機能的な差があり、また、Windowsの標準であるDirect3Dとも差があります。また、OpenGL ESにないけれどもOpenGLにはある機能をモバイル用のGPUが実装している場合もあります。

Android Extension Packは、アンドロイドへゲームアプリなどを移植する開発者のために、足りない機能などを補う役目を果たしています。こうしたOpenGL ES 3.1への拡張機能をアンドロイドとして定義することで、GPUを直接操作したり、開発者が独自のライブラリなどを用意することなく、拡張機能を利用できるようになります。

モバイル向けのGPUはここ2～3年で急速に性能が向上しており、デスクトップ用のGPUと描画速度などの性能には違いがあっても、機能的には同等になりつつあります。このため、将来的には、OpenGL ESではなく、OpenGLを使うという可能性もでできました。また、逆にOpenGLとOpenGL ESを統合するという話もあり、近い将来、デスクトップ用とモバイル用では、OpenGLが共通化される可能性が高くなりました。Android Extension Packはこうした将来を見据えて、OpenGL ESにない機能を先取りするものといえます。

本稿は、2014年7月29日にAndorid情報のWeb専門誌「AndroWire」に掲載した記事を再構成したものです。