【ESEC 2010】Androidが遅い！高速化に挑戦する取り組みに注目：組み込み技術

Androidは公開直後からスマートフォンだけでなく、家電などの組み込み機器への応用が始まっている。ところが、Androidには大きな問題があるという業界関係者が増えてきている。「第13回組込みシステム開発技術展（ESEC 2010）」では、この問題を解決する技術のデモンストレーションを複数の企業のブースで見ることができた。

[笹田仁，EE Times Japan]

　スマートフォン向けオペレーティング・システム（OS）として登場した米Google社の「Android」。公開直後からスマートフォンだけでなく、家電などの組み込み機器への応用が始まっている。

　ところが、Androidには大きな問題があるという業界関係者が増えてきている。公開版を使っていては、遅くて使いにくいという問題があるという。「第13回組込みシステム開発技術展（ESEC 2010）」（2010年5月12日〜14日に東京ビッグサイトで開催）では、この問題を解決する技術のデモンストレーションを複数の企業のブースで見ることができた。

1秒でAndroidを起動

　ESEC 2010では、Androidを高速化する技術として、システムの起動を高速化する技術と、アプリケーション・プログラムの実行時に呼び出されるJava仮想マシンである「Dalvik Virtual Machine（Dalvik VM）」を高速化する技術の展示があった。

図1　リネオ ソリューションズはLinux向け高速起動技術「Warp!! 3」をAndroidに応用するデモを実施していた　
デモではAndroid 1.5が1秒程度で起動していた。

　Androidの起動を高速化する技術を展示していたのは、リネオ ソリューションズとユビキタスだ。リネオ ソリューションズはLinux向けの高速起動技術「Warp!! 3」を使ってAndroidを高速起動するデモを実施していた（図1）。デモは米Freescale Semiconductor社の「i.MX31」プロセッサ（動作周波数は400MHz）と128MバイトのRAM、32MバイトのNORフラッシュ・メモリを搭載した環境で実施していた。OSはAndroid 1.5だ。Warp!! 3を使わないと、電源を入れてから画面上の時計が動き出すまでに20秒程度かかっていたが、Warp!! 3を使うとその時間が1秒程度に縮まった。

　Warp!! 3の技術はハイバネーション技術を応用したものだ。つまり、起動直後のコンピュータのメモリ内容やプロセッサのレジスタの内容などのイメージをファイル化して不揮発性ストレージに格納し、起動時にはそれを書き戻すのだ。リネオ ソリューションズは起動時のイメージをNOR型フラッシュ・メモリに保存していた。

　ただし、メモリ内容などをすべて一括で書き戻すと、ハイバネーション技術を使っても1秒で起動させることはできない。リネオ ソリューションズは、高速起動時に書き戻すイメージを分割して保存しておき、レジスタの内容やカーネルがロックしているメモリ領域のほか、直近に読み書きされたメモリ領域を先に書き戻す。これで、見た目は起動処理がすべて完了したように見える。残りの部分はその後、バックグラウンド処理で戻していくという手法を採る。

　リネオ ソリューションズのソリューション統括部で統括部長を務める小林明氏によると、「デモに用いたAndroid 1.5を例に挙げると、起動時に合計40.42Mバイトのファイルを読み出す必要がある。Warp!!の前バージョンである「Warp!! 2」が備える圧縮機能を使っても、12.78Mバイトまでしか小さくならない。Warp!! 3が新たに搭載した、起動イメージを分割する機能を使うと、電源を入れてから画面を表示するまでに必要な部分だけを切り出せる。画面表示までに必要な部分は21.7Mバイトだった。さらにこれを圧縮すれば7.78Mバイトまで小さくなる。この結果、Androidを1秒程度で起動できるようになった」と語る。

NetWalkerでAndroidを高速起動

　一方ユビキタスは、Androidの高速起動について、2種類のデモを披露していた。1つ目はシャープの携帯型情報端末「NetWalker」で、Android 1.6を同社の高速起動技術「QuickBoot」を使って起動させるデモだ（図2）。デモでは電源を入れてから5秒程度でユーザーの操作を受け付けるようになった。QuickBootを使わないと、ユーザーの操作を受け付けるようになるまでに「80秒かかる」（ユビキタスQBプロジェクトでマーケティング・マネージャーを務める木村好徳氏）という。

図2　ユビキタスはシャープのNetWalkerを使ってAndroidを高速に起動させるデモを見せていた　
同社の高速起動技術「QuickBoot」を利用しており、5秒程度で起動していた。

　QuickBootもハイバネーション技術を応用し、起動に必要なイメージを分割して保存する手法を採っている。NetWalkerを使ったデモでは、起動イメージをNetWalkerが内蔵するNAND型フラッシュ・メモリに保存していた。木村氏によると、「NetWalkerの場合は起動イメージの大きさは131Mバイト程度になるが、最初に読み出す部分は10Mバイト程度に抑えてある」という。

　両社の高速起動技術は似通っている。ただし、ユビキタスの木村氏は、「QuickBootでは、起動してユーザーが操作できる環境を作るまでのイメージを最初に読み出すようにしている」という。Warp!! 3の場合は、「起動して画面表示が動き出すまでのイメージを保存している」（小林氏）ので、ユーザーの操作を受け付けるには、その後1秒〜2秒程度必要になるという。

　NetWalkerを使ったデモのほかに、ユビキタスは基本的なハイバネーション方式と、QuickBootの比較デモも披露していた（図3）。このデモには、Freescale Semiconductor社の「i.MX31」プロセッサ（動作周波数は400MHz）と128MバイトのRAMを搭載した環境で、SDメモリーカードにAndroid 1.6の起動イメージを保存していた。

図3　QuickBootと基本的なハイバネーション方式の比較デモ　
QuickBootを利用したデモ機は1秒程度で起動したが、基本的なハイバネーション方式を利用したデモ機は起動に15秒程度かかっていた。

　QuickBootを採用したデモ機では、1秒程度でAndroidがユーザーの操作を受け付けるようになったが、基本的なハイバネーション方式は、メモリやレジスタの内容をすべて一括で読み出すため、ユーザーの操作を受け付けるまでに15秒程度かかっていた。

構文解析やJITコンパイルでVMを高速化

　Androidの特徴の1つであるJava仮想マシンDalvik VMを改良して、アプリケーション・プログラム全体の高速化を図ろうとする企業もある。イーフローは、プログラムを高速に動作させるJava仮想マシン「Dalvik Turbo」のデモを実施していた（図4）。

図4　Android向け高速Java仮想マシン「Dalvik Turbo」のデモ　
立方体を回転させる3Dアニメーションを再生するプログラムを実行していた。Dalvik Turboを搭載したデモ機の方では24フレーム/秒程度で動作していたが、標準のAndroidでは、14フレーム/秒程度で動作していた。OSGiとは、Javaプログラムに簡単に機能を追加できるようにする仕組みであり、プログラムの高速実行には関係ない。

　Dalvik Turboは、スイスMyriad Group社が開発したもので、2010年2月に発表されたばかりの技術だ。Myriad Group社はDalvik Turboを「Mobile World Congress 2010」（2010年2月15日〜18日にスペイン・バルセロナで開催）で展示し、イーフローの担当者は展示会場でデモを見て、すぐに採用を決めたという。

　Dalvik TurboがAndroidプログラムを高速に動作させる仕組みは、2つに分けられる。1つめは、構文解析と、その結果に応じたコードの整形だ。Androidのアプリケーション・プログラムは、出荷前にJavaの実行ファイルである「.class」ファイルからDalvik VMの実行ファイルである「.dex」形式に変換する必要がある。その際、構文解析を実行し、実行順序を解析してコードを並べ替えたり、ループを展開するなどの整形を施す。.classファイルから.dexファイルへの変換には独自ツールを使う。

　2つめはプログラム実行時にJIT（Just in Time）コンパイルを実行することだ。Dalvik VMは.dexファイルのコードを読んで機械語に翻訳しながら逐次実行するので処理速度が遅くなる。JITコンパイルとは、プログラム実行直前にプログラム全体を機械語に翻訳すること。機械語に変換してからプログラムを実行するので、プログラムが高速に動作する。

　以上2点の工夫により、Dalvik VMと比べておよそ3倍高速にAndroidプログラムを処理できるようになったという。イーフローの開発本部でゼネラルマネージャーを務める金山二郎氏は、「独自に性能を評価したところ、アプリケーション・プログラムの種類によっては10倍以上速くなることもあった」とその性能の高さを強調した。Google社もAndroid 2.1からJITコンパイル機能を持つDalvik VMを提供しているが、Dalvik Turboはそれよりも高速だという。

　Dalvik VMとの互換性も確保している。Dalvik Turboでは、独自ツールを使って.classファイルを.dexファイルに変換しているが、変換後の.dexファイルは、独自フォーマットではなく、Dalvik VMでも実行できる形式だ。そして、Google提供のツールで作った.dexファイルをDalvik Turboで実行することも可能だ。

　Dalvik TurboはARMプロセッサに対応したものと、x86プロセッサに対応したものの2種類がある。金山氏によると、今後MIPSプロセッサに対応するものを提供する予定だという。

　Dalvik VMの性能の低さを問題視している企業はほかにもあった。東芝情報システムのエンベデッドアプリケーション事業部第二ソリューションセンターでプロジェクトマネージャを務める福田浩之氏は、「Androidは処理性能という点で幾つか課題を抱えているが、その中でもDalvik VMは大きな課題だ」と語った。同社ではDalvik VMの解析を進めており、「将来は、JITコンパイルなどの機能を搭載した独自の仮想マシンを提供することも考えている」と語った。