基礎から覚える 最新OSのアーキテクチャー 第5回

Windows 8でMetro Styleアプリを動かす「WinRT」

筆者予想によるWinRTの構造図

　Metro StyleはWindowsの中に作られた「独立した環境」であり、新しいAPIセットであるWinRTを使ってアプリを開発する。ここにDesktop Style側のコードは持ち込むことができず、Metro Style側でWinRTを使って動作させるためには、再コンパイルなどが必要になる。これは、コンパイル時にアプリがMetro Styleなのか、Desktop Styleなのかを区別した情報を書き込み、それにより呼び出せる機能を制御するからである。

　Metro Styleアプリでは、画面の表示に「XAML」(ザムル)を使うことを想定している。XAMLは「WPF」(Windows Presentation Foundation)の一部で、アニメーションなどの高度な記述が可能な、XMLをベースにした宣言型の表示記述言語である。.NET Frameworkでは、表示するオブジェクトなどをコードとして直接記述してもいいし、XAMLで記述したものをコードで制御してもいい(例えばボタンを押したときの動作)。Metro Styleアプリはマネージ/アンマネージコードのどちらも、XAMLにより画面を記述することを想定しているが、C＋＋などを使えば直接「Direct 3D」で画面を作ることも可能になる。

　WinJSの場合、「WWAHost.exe」というホストアプリが、HTMLやJavascriptを実行する。WWAHostはウェブブラウザーではないが、Windows 8組み込みのInternet Explorer 10(IE10)が持つレンダリングエンジンや、スクリプトエンジン(Chakra)を利用する。なお、IE10はDesktop StyleとMetro Styleの両方で起動できるが、2つのアプリがあるのではなく、ひとつのアプリがどちらでも動作するようになっている「特別扱い」のアプリだという。そのため、Metro Style側で表示しているページを、Desktop Style側のIEで表示するようなことが可能になるという。

モバイルOSに近くなった
アプリのライフサイクル

　Metro Styleアプリが起動してから終了するまでの「ライフサイクル」は、Desktop Styleとは異なる。Desktop Styleでは、アプリが自身の状態を決めて、終了も自身で行なっていた。クローズボタンをユーザーが押すとメッセージがアプリに送られ、これを受け取ったアプリが状態を判断して終了処理を行なう。保存されていない情報などがあればユーザーに提示し、場合によっては、終了しないという選択肢もあった。

　これに対してMetro Styleアプリのライフサイクルは、Windows側が決めるようだ。画面切替でバックグラウンドに回り、ユーザーが操作できない状態にあるアプリは「Suspended」状態とされ、CPU時間を使わなくなる。またアプリには終了メニューがなく、メモリーが必要となったときにはOSにより強制終了させられて、自身で終了を選択することはない。この仕組みは、Androidの「Activity」(アプリ画面に対応するオブジェクト)のライフサイクルとよく似ている。

Metro Styleアプリは、起動してから終了するまでの「ライフサイクル」を自分で決めるのではなく、システムが管理する。メモリーに残るだけで停止したままのSuspendedという状態が新設された。Suspendedのアプリは、メモリーが足りなくなると通知なしに停止されて、メモリーが回収される

　また、Metro Styleアプリの起動はApp Container環境内で行なわれ、エクスプローラーから実行ファイルをダブルクリックするなどしても、起動はできない。Start Screenでアプリのタイルをタップすると、App Containerがアプリの起動処理を行なう。

　モバイルデバイスでは、一度起動したアプリをメモリーにとどめておくという仕様が一般的だ。パソコンと違って、画面をほかのアプリに切り替えたからといって、必ずしも終了を意味しないし、ユーザーに「終了」と「画面切替」を明確に区別を付けて実行させるのも面倒だからだ。

　むしろメモリーに余裕があるなら、起動したアプリはそのままにしておけば、次回の起動が高速化できて、消費電力を抑えられる可能性も出てくる。メモリーが足りなくなったときに、終了させてからほかのアプリをロードすればいいのであって、「捨てるのはいつでもできる」という考えに立っている。

　そのためWindows 8で新たに作られたのが、Suspendedというアプリの状態だ。対応アプリは、Suspendedやそこから復帰するResumeのタイミングでイベントを受け取ることができるが、終了に関してはなんの警告も受けない。そのためアプリは、保存が必要な情報はスタンバイ前か、最悪でもSuspendedする前に保存しないと、メモリーが不足したときに終了させられて情報を失うはめになる。

　そのためアプリのデザイン方針としては、ユーザーにセーブボタンを押させるようなものではなく、情報に変更があったときには随時保存する、という構造にしなけばならない。