変わらないと生き残れないAndroid Lの新機能まとめ：Androidで動く携帯Javaアプリ作成入門（53）（2/4 ページ）

[緒方聡，株式会社イーフロー]

Dalvik用に実装したアプリが使えない？ 新しいランタイム「ART」

　実は、一つ前のAndroid 4.4では新しいART（Android RunTime）という実行エンジンが実験的に導入されていて、「開発者向けオプション」でDalvikと切り替えて使用することができました。4.4ではデフォルトのランタイムは従来の「Dalvik」でしたが、Android L開発者プレビューではデフォルトのランタイムはARTになりました。

　ARTの主要な機能は以下の通りです。

• AOTコンパイル（DalvikはJITコンパイル）
• GCの改善
• デバッグ機能の改善

　ほとんどのAndroidアプリはARTでも変更なしに動作するはずです。しかし、Dalvik上で動作するいくつかの技術についてはARTでは動作しません。特に以下は注意する必要があります。

• JNIを使用してC/C++コードを実行するアプリ
• 難読化ツールなどを使用しているアプリ
• 「Compacting GC」と相いれない技術を使用するアプリ（オブジェクトのアドレスを保持するなど）

コラム「ARTができた理由と思われるDalvikの2つの問題」

　AndroidにはDalvikという生え抜きのランタイムがあるにもかかわらず、ARTが生まれた背景について、筆者は情報を持ち合わせていません。ただ、Dalvikの抱える根本的な問題が解決できないため、新たに作り直さなければならなくなったのではないかと想像しています。

GC

　一つはGC（Garbage Collection）の問題です。

　DalvikのGC（Garbage Collection）は、「Mark & Sweep」という方式が採用されています。これはアプリやサービスが長時間動作して、オブジェクトの生成と破棄が繰り返されると、メモリの断片化（フラグメンテーション）が発生し、最終的にはOutOfMemoryErrorが発生してしまうという欠点があります。この問題を解決するためにDalvikには「Copying GC」が組み込まれようとされていましたが、結局完成には至りませんでした。Dalvik全体が、GCでオブジェクトのアドレスが変わることを想定して実装されていなかったためだと思います。

　現在はARTに対して「Compacting GC」の実装が進められています。

JITコンパイラー

　もう一つはJIT（Just In Timeコンパイラー）の問題です。

　DalvikのJITは「Tracing JIT」というコンパイル方式を採用しています。一方でオラクルのJava VMは「Method granularity JIT」と呼ばれるコンパイル方式を採用しています。

　Tracing JITは、実行頻度が高い箇所を小さい粒度でネイティブコードにコンパイルします。

　Method granularity JITはメソッド全体をネイティブコードにコンパイルします。オラクルのJava VMでは「HotSpot」と呼ばれています。余談ですが、HotSpotはサーバー向けとクライアント向けのオプションがあり、サーバー向けはコンパイル時間がかかっても高速なネイティブコードを生成するのに対し、クライアント向けはネイティブコードへのコンパイルを必要最低限に抑えます。

　AndroidのJITコンパイル方式としてTracing JITが選択されたのは、ネイティブコードへのコンパイル時間によるもたつき感を出さないようにするためではないかと考えています。

　ARTは「AOT」（Ahead-Of-Time）という事前コンパイル方式なので、実行時にコンパイル時間はかからず、全体がネイティブコード化されます。DalvikのTracing JITは省スペースで省メモリですが、高度な最適化はかけづらく、コンパイル結果を保存しておくこともできません。

　ARTのAOTは、LLVM（Low Level Virtual Machine）を利用した高度な最適化を行いコンパイル結果も保存しておくことができる半面、ストレージとメモリをたくさん必要とします。Android 2.2の頃から時代は進み、Androidを取り巻く環境がARTを受け入れるようになったということなのかもしれません。

ARTはDalvikに代わるロングリリーフか

　ARTは現時点ではDalvikとは完全な互換性はなく、アプリ単位でDalvikやARTを選択できるようにはなっていないため、動作しなくなってしまったアプリなどによって市場に混乱をもたらす可能性があります。

　しかしオラクルのJava VMも、長い歴史のかなり初期にコードベースが変わっており、長い歴史の間にJITが搭載され、現在につながる基盤が築かれたわけであって、ARTもDalvikに代わるロングリリーフになるべく登場したのだと、そう願いたいところです。

「生まれ変わった」Notification

　Notificationはバージョンが上がるごとに少しずつ進化していますが、Android L開発者プレビューでは、大幅な進化を遂げ、もはや「生まれ変わった」といっても過言ではありません。Notificationは過去に本連載第29回「Androidのウィジェットにノーティフィケーションするには」でも取り上げましたが、その頃とはかなり違ってきています。

　まず、Android標準アプリのカレンダーやチャット、Google NowなどでNotificationが活用されるようになり、ますますタイムリーな情報が表示されるようになりました。表示は視覚的になり、操作も直感的になりました。

画面キャプチャを行った際のNotificationの例（Android L公式サイトより引用）

　上図は、画面キャプチャを行った際のNotificationです。コンパクトに表示されている状態と引き伸ばした状態で異なる情報を表示できる他、操作ボタンまで配置できます。

　Android L開発者プレビューで追加された主要なNotification機能を以下に挙げます。

• Android LのMaterial DesignによりNotificationの見た目が変更
• ロックスクリーンでも利用可能になり、機密性の高い情報はこれまで通りロックスクリーンでは利用不可にもできる
• 「ヘッドアップ」と呼ばれる新しい表示方式
• クラウドに同期する通知（タブレットでのみ有効でありスマートフォンでは無効）

ヘッドアップ方式のNotification

　優先度がHighで到着したNotificationは、以下のように画面上部（赤枠で囲んだ部分）に短時間表示され、ユーザーに通知されます。

ヘッドアップ方式のNotificationの例（Android L公式サイトより引用）

　ヘッドアップ方式のNotificationは、例えばユーザーがフルスクリーンモードで楽しんでいるゲームの邪魔をすることがあります。ヘッドアップ方式のNotificationが適しているのは、通話着信、アラーム、SMS着信、電池切れなどです。

Android WearのためのNotification

　Android Wearでは、スマートフォンで受信したメッセージをNotificationで表示できます。

Android WearのNotificationの例（Android L公式サイトより引用）

　シングルタップでは実現できないようなアクションがNotificationに含まれている場合、アプリ開発者は、そうしたアクションを非表示にするか、Android Wear側で操作を完結させるための別の仕組みを検討する方がいいでしょう。

　Android Wearに適しているNotificationはインスタントメッセージなどで、適していないのは、ポッドキャストアプリが通知する新しいエピソードなどの、スマートフォン側で通知されることを期待するNotificationです。

　Android Wearに適しているアクションは「いいね！」「+1」などソーシャルボタン、「すぐ戻る」「今から帰る」などのメッセージリストや音声入力アプリを開くなど、シングルタップのアクションで、適していないのは、言うまでもなく腕時計では不可能な機能のアクションです。