第12回 Androidに至る道：Embedded Android for Beginners（Android基礎講座）（2/3 ページ）
ソフトウェアの黎明期からAndroidの生い立ちをたどることは、Androidの今と将来を知るための大きな一助となります。今回は、そのような大きな目線でAndroid誕生までの流れを振り返ります。
Android Runtime/Application Framework
AndroidはJavaが登場して以来の夢が現実となったシステムであるといわれます。その言い方には少し正確性を期さなければいけませんが、ここではVM（Virtual Machine）とはどういうものかを整理し、その狙いはどのような理由から来たのかを考察します。
いろいろな経緯がありますが、興味のある方は別途調べていただくこととして、現在、VMと言えば次のいずれかを指します。
- ある仮想的に設計されたハードウェアをソフトウェアで表現し、その機械語で記述されたプログラムを実行するもの
- 現実のハードウェアをソフトウェアで表現し、現実のハードウェア上で動作するプログラムを実行するもの
言葉で説明すると分かりにくいのですが、直感的には、前者がJavaのようなもの、後者がVMWareのようなものと理解していただいて差し支えありません。前者について、ここでは中間言語を持たないインタプリタも含めます。
前者のVMは、プログラミング言語ありきの場合が多く、それを実行するためのソフトウェアとして作られています。このようなVMは、安全性と生産性の向上のために開発で利用されるようになりました。UNIXでは当初からシェルプログラミングが行われるようになり、それが今日のRubyやPythonといった言語での大規模開発につながっています。
しかし、サーバサイドの開発においてはそれで済みますが、組み込み機器となるともう一段いろいろな要求が起こります。エンドユーザーの手元にあり、エンドユーザー自身がアプリケーションをインストールする必要がありますが、まずその仕組みが必要です。プログラムが予期しない振る舞いをしても、システムに影響しないような仕組みも必要です。あまり制限をつけてしまっては便利なアプリケーションが作れないので、許可を得た場合にはアドレス帳などの大事な情報にアクセスできるといった仕組みも必要です。Javaはこれらの要求を満たすアプリケーションプラットフォームとして作りこまれていきました。
しかし、Javaの登場時には、組み込み機器におけるVMの利用はまだ皆無という状況でしたし、サーバサイドでのVMベースの大規模開発もまだ本格的には行われていませんでした。ハードウェア環境も恵まれているとは言えず、まだPentiumも登場していませんでした。そのような状況下で、なんとかJavaによるアプリケーションプラットフォームを実現するための取り組みが長く行われました。まず、Sun Microsystems（以下、Sun）は当初、JavaのAPIをサーバサイドでも組み込み機器でも全く同じものにしようとしていました。ただ、例えば表示を持たない組み込み端末に表示系APIを搭載しなくてはならないなどの矛盾が起こるため、Personal Java/Embedded Javaという、組み込み端末向けにAPIのコンフィグレーションが可能なプロファイルを用意しました。さらに、Java2ではサーバ、デスクトップ、組み込み向けにそれぞれJ2EE、J2SE、J2MEというJava仕様が定義され、これが今のJava EE、JavaSE、Java MEとなります。また、JCP（Java Community Process）という標準化プロセスを作り、複数の団体・個人が共同で仕様策定する場を整備しました。OracleがSunを買収した後もこういった仕組みは引き継がれましたが、買収後ほどなくして、Javaの並行処理に関する著名人でありJCPの執行役員でもあったダグ・リー氏が脱退したり、最近ではJava SE 7仕様承認において意見が採り入れられなかったことから、JCPにおいて大きな支持を得ていたASF（Apache Software Foundation）が脱退するなど、課題を抱えています。
話を組み込みJavaに戻します。Javaは特にサーバサイドにおいて地位を確立していきましたが、組み込みの分野では特筆すべき成果がなく、成功事例が必要でした。そんな中で、NTTドコモがiモードのアプリケーション版ということでJavaを採用したことで、携帯電話向けアプリケーションプラットフォームとしての道が開かれました。ちなみに、移動機向けJava 仕様としてはMIDPが策定中でしたが、NTTドコモがJavaの採用を決めたときにはまだ最終仕様が固まっていませんでした。そこで、独自仕様のDoJaを策定しました。この流れは現在まで続き、3DやGPSなどの機能についても、NTTドコモは独自仕様を定義し、世界に先駆けて商用化していきました。また、携帯電話以外の用途でも、例えばBlu-ray 向けのJava 仕様であるBD-Jが定義され、普及しました。
しかし、Javaを搭載するためには認証が必要であり、品質確保のための厳しい検査に合格しなければいけませんでした。また、JavaはOSを指定しないアプリケーションプラットフォームであり、LinuxやWindows、あるいはRTOSに移植して使用するものでした。つまり、ポーティングが必要であり、例えばブラウザなど他のソフトウェアとのインテグレーションを必要としました。そのため、Javaの導入自体のイニシャルコストが高いという問題がありました。そして、JavaのAPIが増えるほど、そのコストは高くなって行くというジレンマがJavaに立ちはだかったのです。
これは、JavaとAndroidの最大の違いと言っても過言ではない、実装上の本質的な相違点です。AndroidはLinuxにOSを限定し、ポーティングとドライバ・ライブラリへのつなぎ込みの部分をリファレンスに含めました。また、システム全体を包括するJavaレベルのAPIを定義し、Webkitなどのネイティブアプリケーションとのインテグレーションまでも済ませたリファレンスを供給しました（図3）。
図3 JavaとAndroidの対応方法の違い
Javaを対応する場合の作業箇所。個々の機能のつなぎ込み、他のソフトウェアとのインテグレーションが必要になる。システムが大きくなるほどにこの作業は複雑かつ膨大になる。Androidでは、このようなつなぎ込みとインテグレーションが済んだリファレンスが供給される。
ちなみに、PC 上のAndroid SDKはハードウェアエミュレータであるQEMU 上でいわば本物のAndroidを動作させています。これはJavaのようなVMとは違う、現実のハードウェアを模倣する方のVMの利用例です。
Copyright © ITmedia, Inc. All Rights Reserved.