会期：5月28～29日(現地時間)

会場：米国サンフランシスコ モスコーニコンベンションセンター

　今回のGoogle IOの取材では、モバイル関連のトラックを中心にセッションを回った。ここでは、Googleの関わるAndroidについてセッションで得た情報などとともに解説していくことにしよう。

●オープンな携帯電話プラットフォームを目指す

　Androidは、もともとAndroid社が開発していた携帯電話用のプラットフォームであり、同社をGoogleが買収、T-Mobile、HTC、Qualcomm、Motorolaが中心となるOHA(Open Handset Alliance)が設立された。このOHAには、現在では30数社が参加し、日本からは、NTTドコモなどが参加している。

　Androidは、携帯電話用の共通プラットフォームである。「携帯電話の統合されたソフトウェアスタック」とでもいうべきもので、同一のアプリケーションを動作させることを目的としている。これまでの携帯電話向けの共通プラットフォームと大きく違うところは、ソフトウェア開発者に対して「オープン」であることだろう。

　たとえば、現在の携帯電話の中には、Linuxを採用するものが少なくないが、だからといってLinuxのアプリケーションを開発者が自由に移植できるわけではない。オープンソースから作られたといっても、プラットフォームとして情報公開がされているかどうか、アプリケーションインストールを認めているかどうか、あるいはこれらを行なうために契約が必要かどうかという問題がある。

　Androidは、端末メーカーに対しては、共通化による開発工数の削減をもたらし、開発者は、特定の携帯電話ネットワーク事業者、端末メーカー、OSメーカーと契約することなく自由に開発が行なえるようになるという。

　しかし、携帯電話には、さまざまなハードウェアプラットフォームが使われているため、ハードウェアに依存しないアプリケーションを開発できるような仕組みが組み込まれている。

　Androidの全体ブロック図を下に示す。Androidは、Linuxカーネルを使っているが、独自部分を追加し、単純なLinuxマシンというわけではない。また、Linuxディストリビューションに含まれているアプリケーションなども付属しない。

　Linuxを使う理由は、すでに実績があり、メモリやプロセスの管理ができること。デバイスドライバやTCP/IPスタックなどがあり、実績のあることなどが理由である。また、オープンソースであることも理由だという。

　ただし、Androidのアプリケーションは、基本的にはJavaで作られる。より正確に言うと、Dalvik-VMという仮想マシンでアプリケーションは実行される。このDalvik-VMの標準のコンパイラがJava用なのである。このため、Androidのアプリケーションは、携帯電話のハードウェアに関係なく動作できる。

デベロッパのメリットとして、「アプリケーションを出す許可を得なくていい」、「隠されていたり、制限されているAPIがない」、「既存のコンポーネントを統合、拡張、置き換えることができる」という3つが挙げられている

●Linuxベースだが携帯電話に特化したカーネル

　Androidは、Linuxカーネルの2.6.24を使う。さらに独自のパッチが当てられており、機能拡張が行なわれている。

　これには、プログラム間で通信を行なうためのIPC(Inter Process Communication)や、パワーマネジメント機能などがある。AndroidのIPCは、Binderと呼ばれ、このために開発されたもののようだ。デバイスドライバとメモリ共有機能を使い、Binderは、プロセス間のコミュニケーション(あるいは機能呼び出し)を実現している。

　パワーマネジメントは、Linuxカーネルが持つパワーマネジメント機能をベースに強化されている。バッテリの限られる携帯電話では、より積極的な電源管理が必要だからである。

Androidのブロックダイアグラム。下の赤い部分がLinuxカーネルとドライバ、デーモンなどのシステム側。その上にHALがあり、ここでハードウェア(Linuxのデバイスドライバなど)を抽象化する。また、この上に各種のライブラリがあり、Dalvik-VMとコアライブラリ(VMで実行される仮想コードに対して基本的な機能を提供する)がある。ライブラリやVMは、C/C++などで記述されていてネイティブコードとなる。その上に各種の機能を制御するマネージャからなるアプリケーションフレームワークがあり、その上でアプリケーションが動く。図の青い部分は仮想コードで記述されている

　アプリケーションは、動作中にCPUが停止するスタンバイ状態に入らないようにするためには、システムに対して「Weak Lock」と呼ばれる要求を出す。たとえば、音楽プレーヤーなどでは、動作中に液晶がOFFになることは許可できても、CPUが停止してしまうと、音楽再生が止まってしまう。このため、Weak Lockを出してCPUが停止することを防ぐ必要がある。

Androidのパワーマネジメント。アプリケーションが、Weak Lockを発行すると、スタンバイ状態にならない。Weak Lockにはいくつかの種類があり、場合によっては、LCDをオフにする程度の省電力化は行なわれる。アプリケーションがWeak Lockを解除すると、CPUはOFFになることができる

　また、Linuxカーネルを使っているものの、基本的な機能を格納したlibcライブラリも独自のもの(Bionicというらしい)になっている。

　UNIXがCで開発されてきたことから、UNIX系OSでは、ファイルオープンなどの基本的な機能がこのlibcに入っている。このため、多くのプロセスがこのlibcを利用する。独自のものを開発した理由は、メモリが限られる携帯電話で、多くのプロセスが利用するため、コンパクトで、高速なものが必要だったからだという。

　また、もう1つの理由は、LinuxカーネルのGPL(GNU Public License)をユーザースペースに伝搬させないためだという。つまり、libcがGPLであれば、これをリンクするソフトはGPLとなるからだ。ちなみにBionic libc自体はBSDライセンスで提供され、コンパクトで高速なスレッド機能(pthread)が実装されているという。

　このほか、Linuxのデバイス関連のデーモン(usbdなど)や、ライブラリ(libgpsなど)などもシステム側のモジュールとして組み込まれるようだ。

　Linuxカーネルとライブラリなどの間には、HAL(Hardware Abstruction Layer)が置かれている。ここでは、カメラやGPS、ラジオ(携帯電話の無線部)などを仮想化している。カーネル側のドライバとライブラリの間に入り、差異を吸収するためだ。通常HALというと、ハードウェアとカーネルの間に置かれるが、AndroidのHALは、カーネルの外(ユーザースペース)にある。これも、GPLになるデバイスドライバとユーザースペースをライセンス的に分離するためでもあるという。

　ライブラリは、ネイティブコード(非仮想コード)で記述されており、このあたりまでは、Linuxのスタイルである。ここには、広く使われているOpenGL(3D)やSQLite(データベース)、FreeType(TureTypeのオープンソース実装)などがある。

●レジスタマシンアーキテクチャーのVM

　アプリケーションは、コンパイラによりソースコードがDalvik-VM用の仮想コードに変換され、専用のファイルフォーマットであるDex File Formatとして、Androidにインストールされる。これまでのJavaでは、ClassファイルやJarファイルなどが用いられてきたが、Dalvik-VMでは、配布するアプリケーションのサイズや、メモリフットプリントを小さくするために、必要なクラスやメソッドなどの情報をまとめてしまう。これがDex File Formatである。

　Androidのメモリは最低で64MBとなっており、起動後に各種のサービスが動き出すと、残りは20MB程度になるという。アプリケーションは、この中で動かす必要がある。このため、より使用メモリが小さいファイル形式が作られたのだという。また、実行時もクラスやメソッド、定数などを管理する情報が統合されているため高速化するという。

Androidのメモリに関する記述。発表などでは、要求ハードウェア仕様が公開されていないが、これを見ると最低が64MBであることがわかる

　また、Dalvik-VMは、SUN MicrosystemsのJava-VMとは異なる実装であり、VMのアーキテクチャも違う。つまり、仮想コードレベルでも互換性はない。

　これまで多くのVMは、スタックを演算対象とするスタックマシンアーキテクチャを採用してきた。これは、高級言語からコードを生成するときに、スタックマシンのほうが有利だからである。

　これに対して、現在の多くの(仮想でない)プロセッサは、内部レジスタを演算対象とするレジスタマシンアーキテクチャである。Dalvik-VMは、このレジスタマシンアーキテクチャを採用する。これは、既存のハードウェアがレジスタマシンであり、その内部レジスタを使うことで、高速なVMを開発できるからだ。その半面、生成される仮想コードが大きくなることが知られている。

　スタックアーキテクチャでは、演算対象は常にスタックなので、命令に演算対象を指定する情報を付ける必要がない。たとえば足し算なら、スタックのトップにある数値とその次にある数値を加算するだけである。これに対して、レジスタアーキテクチャでは、どのレジスタあるいはメモリアドレスを加算に使うのかといった指定が必要となるため、必然的に命令が長くなる。

　Dalvik-VMの開発チームの調査によれば、35%程度、命令ストリーム(つまり生成されるコート)が長くなるとのことだが、逆に、命令の種類は30%程度減り(アドレッシングモードを無視してだと思うが)、仮想命令を処理するコードも35%程度小さくなるという。このため、レジスタアーキテクチャを採用するメリットがあるのだという。また、前述のように最低64MBで動作することを考えると、すべてのプロセスに入ることになるVM自体を小さくしたほうが有利になる。

　ここまでくると、Javaとはいえ、かなり違う。Javaの文法を借りた別の言語といってもいいかもしれない。例えは悪いが、.NETのCLRで動くJavaみたいなものである。

　また、アプリケーションは、Linuxの1つのプロセスに対応している。アプリケーションは、独立したプロセスとして起動したVMがこれを実行する。1つのVMプロセスが複数のアプリケーションを実行するようにはなっていない。これは、1つのアプリケーションのエラーが、VM自体をクラッシュさせ、全体に影響することを防ぐためだという。このために、アプリケーションは、IPC経由でマネージャを呼び出し、マネージャ(ここまでは仮想コード)が、JNI(Java Native Interfaec)でライブラリを呼び出すという構造になる。このあたりのオーバーヘッドを小さくするためにも独自のIPCが必要だったのだと思われる。

●最初の搭載機は2008年後半に登場

　構造的には、現在の携帯電話でJavaによるアプリケーションが実行可能というのと、表面上は大きく変わらないが、携帯電話用のJavaよりは広範囲な携帯電話の機能にアクセスができる。また、アプリケーション間でデータを共有するような仕組みも提供され、たとえば、電話帳のデータをメールソフトと電話ソフトが共有することができ、これは、ユーザーが作成したアプリケーションでも可能だという。

　ただ、セキュリティの問題とか、携帯電話ネットワーク側の都合による実装の違いがどこまで入るのかがいまのところ不明である。ウィルスのようなものには対策があると思われるが、動作からは危険が認識できない悪意のあるソフトウェア(たとえば、メールをコピーして特定のアドレスへ転送してしまう)などへの耐性は、現在のPC並と思われる。ユーザーが注意しないと、危険なソフトウェアをインストールしてしまいかねない。

　逆に、インストールを制限したり、機能を制限したりすると、今度は、現在の携帯電話とほとんど変わらないものになってしまう。このあたりをどう解決するのかが興味のあるところだ。Google IOのセッションなどでは、2008年後半には、最初のAndroid端末が登場との発言があった。また、基調講演でデモしていた試作機の速度は十分な感じで、ネイティブなコードを使うスマートフォンと遜色がなかったので、かなりの程度完成しているのではないかと思われる。

□Googleのホームページ
http://www.google.com/
□Google IOのホームページ(英文)
http://code.google.com/events/io/
□Androidのホームページ(英文)
http://code.google.com/android/

(2008年6月1日)

[Reported by 塩田紳二 / Shinji Shioda]