「Android N」プレビュー その3

ロケールの改良

Android Nからは、ユーザーが複数のロケールを設定することが可能になります。ロケールとは、言語と地域を組にしたものです。なぜこのようにしてあるのかというと、同じ言語を使っていても、アメリカとイギリスでは習慣などに違いがあるからです。言語が同じでも、日付の並びや数値の桁区切り、小数点の使い方などに違いが出ます。このため、「英語-米国」などのように、言語と利用地域を対にした「ロケール」として、言語にかかわる情報を扱います。

アンドロイドのロケールは「設定 ⇒ 言語と入力 ⇒ 言語」で指定する「言語」が相当します(写真01)。アンドロイドの設定画面では、「English」に「United States」と「United Kingdom」など、合計5つがあります(写真02)。これらは、ロケールでは、「en_US」(英語でアメリカ合衆国)、「en_GB」(英語でイギリス)という意味になります。「日本語」は「ja_JP」で、「日本語で日本国」という意味になっています。ただし日本語のように日本でしか使われていない言語に関しては、国による違いがないため、アンドロイドの設定では「日本語」としか表示しません。

ロケールは、アプリやアンドロイド自体のメッセージや日付表示などの機能に影響をあたえます。具体的には、アプリやアンドロイドが持つ「文字列」などの「リソース」を切り替える場合に設定されたロケールの情報をもとに選択が行われるわけです。

アンドロイドの言語を切り替えると、一部の標準アプリの名称も切り替わります。たとえば、英語から日本語にすると、「Clock」が「時計」になります。これは、アプリが内部的に持っているリソースをロケールに応じて取り出して表示しているためです。

また、日付や時刻のデータを、表示可能な文字列に変換する関数(アプリが内部で利用する)も現在のロケール設定に合わせて動作を切り替えます。

さて、従来のアンドロイドでは、ロケールから言語を決定する場合に言語と地域が完全に一致するかどうかしかみていませんでした。このため、完全一致するロケールがない場合、必ず含まれているen_USに対応したリソースが使われ、表示が英語になります。

しかし、Android Nからは、この動作が切り替わり、言語部分だけの一致も見るようになりました。Googleの開発者向けサイトにある例では、「fr_CH」(フランス語でスイス)がある場合、従来のアンドロイドでは、「fr_CH」がなければ、en_USとなっていましたが、Android Nからは、前半の「fr」だけの一致も調べるようになったため、「fr_FR」(フランス語でフランス)が一致し、フランス向けのフランス語表記が出るようになります。地域が違うので完全ではありませんが、少なくとも、フランス語しか話さない人にとっては英語で表示されるよりもわかりやすいでしょう。

さらにAndroid Nでは、複数のロケールを登録(写真03)できるため、フランス語がなければスペイン語といった選択ができるようになるようです。

日本語にはja_JPしかないためにあまり恩恵がありませんが、英語よりもフランス語が得意といった人ならば、fr_FRなどを登録することで、日本語に対応していないアプリの場合に英語ではなくフランス語を出せるようになる可能性があります。

ARTの改良

Android Nの改良点のうち、地味ながら、メリットがありそうなのが、ART(Android Run Time)の改良です。これにより、アプリの実行速度が向上するといいます(写真04)。

ARTとは、アンドロイドのアプリを実行するJavaの仮想マシンです。ARTは、Android 5.0で導入されました。それ以前の仮想マシンであるDalvikとの大きな違いとして、インストール時にコンパイルを行う「Ahead of Time」(AOT。実行前)コンパイラがありました。アプリを高速に実行するため、Android 5.0では、インストール時にDalvik仮想マシンコードをCPUか直接実行可能な機械語にコンパイルしていました。アプリの起動が速くなる反面、この方式では、インストールに時間がかかります。これに対して、Dalvikでは、実行時に機械語へのコンパイルを行う「Just In Time」(JIT。実行中)コンパイラを採用していました。

AOTは、インストールに時間が必要になるものの、Playストアからのインストールやアップデートは、充電中に行われる可能性が高くなります。というのもPlayストアの設定では、アップデートを無線LAN接続時にのみ限り、モバイルネットワークでのアップデートを行わない場合、電源に接続されている可能性も高くなるからです(現在のPlayストアのデフォルト設定はWi-Fi接続時のみ自動更新)。このようにすることで、コンパイルがバッテリ駆動中に行われなくなるため、消費電力を抑えることが可能になります。

これに対して、JITコンパイラでは、アプリを実行しながら、何回も実行される部分のみをコンパイルしていきます。しかし、実行中のコンパイルであるため、あまり最適化などに時間をかけることができません。コンパイルに時間をかけてしまうとアプリの実行速度が落ちてしまうからです。また、実行時のコンパイルなので、単純な実行よりもバッテリ消費量が増えるといったデメリットがあります。

Android NのARTは、このときにアプリの実行状況に関する情報(プロファイル)を記録します(写真05)。Android NのARTは、原則JITコンパイラを使い、インストール時にはコンパイルを行いません。しかし、充電中かつ、ユーザーがスマートフォンを利用していない時間を使い、アプリのコンパイル処理を行う機能があります(写真06)。これは、実行時に得られたプロファイル情報を利用して「ホットスポット」と呼ばれる、何回も実行される場所のみを対象として行われます。このときには、JITと違って時間制限がないために、高いレベルの最適化を行えます。これをGoogleは、「Profile Guided Compilation」(プロファイルでガイドされたコンパイル)と呼んでいます(写真07)。

AOTの場合、実行時の情報がないため、全体をコンパイルすることしかできず、結果として、アプリがより多くのストレージ領域を占めてしまいます。これは、インストールしたプログラムとコンパイルされたプログラムの両方を保存しているからです。これに対して、JIT方式では、実行時にコンパイルを行い、次回以降のコンパイルを高速にするための情報を保存するだけなので、それほどストレージ領域を使いません。Android NのPGCでは、MarsmhallowのAOT方式ほどストレージを消費しません(写真08)。最初に起動したときには、わずかな増加(インストール処理によるものと思われる)で、その後PGCが行われると増加しますが、多くても1.5倍程度に収まっています。これは、事前に機械語に変換される部分がホットスポットだけに限られるからです。一般にプログラムでは、1%の部分が実行時間の90%を使うと言われているので、PGCでコンパイルされる部分はそれほど多くありません。

こうした最適化がどの程度なのかは、ARTの出来具合に依存しますが、少なくとも、インストールに時間がかかってイライラすることはなくなるはずです。また、システムアップデート直後の起動時にも、アプリを再コンパイルするのに時間がかかっていました。再コンパイルの時間が省かれるため短時間で立ち上がるようになるはずです(写真09)。グーグルの説明によれば、インタープリタ(コンパイルしていない部分を実行する機能)も高速化しているとのことで、全体として速度の向上が望めるでしょう。