モバイル OS アーキテクチャーのトレンド

この記事は、インテル® デベロッパー・ゾーンに掲載されている「Mobile OS Architecture Trends」(http://software.intel.com/en-us/articles/mobile-os-architecture-trends/) の日本語参考訳です。

---

モバイル化が進み、ますます高速かつ安全につながることで、世界が均一化しています。人々はモバイルデバイスを手軽に持ち歩き、友人や家族と気軽に連絡を取り合い、デバイスやデータの管理に煩わされることなく、さまざまな使用モデルと無限のコンテンツを楽しめることを期待しています。これらはすべてモバイルデバイスの要件であり、その中心となるのはモバイル OS です。長年にわたるモバイル OS の設計と業界動向の広範な調査経験から、将来のモバイル OS アーキテクチャーにはユーザー体験、電力管理、セキュリティー設計、クラウド対応、オープンな設計といった共通性があると考えられます。この検証を行うため、我々は独自の解析モデルを考案しました。ここでは、主要な共通性に注目して、今後 10 年間のモバイル OS アーキテクチャーのトレンドを検証します。検証結果に基づいて、アーキテクチャーのトレンドから、現在のモバイル OS の特徴についても言及します。

はじめに

モバイル OS の設計は、この 10 年間に PC ベースの OS から組込み OS へ、そして現在のスマートフォン向けの OS へと 3 段階の進化を遂げました。この間、モバイル OS アーキテクチャーは複雑なものから単純なものへ、そしてその中間へと変わりました。この進化は、ハードウェア、ソフトウェア、インターネット分野の技術が進歩したことで自然に起こりました。

• ハードウェア: ハードウェア業界は、モバイルデバイス向けに、マイクロプロセッサーと周辺機器のサイズを縮小してきました。サイズが十分に小さくならなければ、モバイルデバイスは小さなサイズと処理能力の両方を同時に達成することができません。当初は、PC と同程度のサイズのラップトップ・コンピューターか、電話と同程度のサイズの低性能のパーソナル・データ・アシスタント (PDA) のどちらかしかありませんでした。通常、PDA 向けのモバイル OS は、マルチタスクや 3D グラフィックを完全にサポートしていませんでした。センサー、加速度計、コンデンサー・ベースのタッチスクリーンのような機能は、過去のモバイル OS では利用できませんでした。
• ソフトウェア: ラップトップ・コンピューターでは、ソフトウェアはユーザーの生産性を重視し、正確に入力するためのキーボードとマウスのサポートは不可欠でした。PDA ソフトウェアは、その名の通り、連絡先やメールのような個人データの管理を支援します。モバイル OS は、タッチスクリーンやその他のセンサーを含む、多種多様なユーザー・インターフェイス (UI) を使用して優れた応答性と円滑な動作をもたらすようには設計されていませんでした。
• インターネット: 特に Web 2.0 以降のインターネットの発展に伴い、ネットワークにはユーザーが利用できる情報が大量に存在するようになりました。Web を閲覧するだけでなく、インターネットは人々の生活の一部になりつつあります。情報の発信、アプリケーションの開発、社会的交流も含め、より多くの人々がインターネットの成長に関わってきています。モバイル OS は自己完結型ではなく、オープンなシステムでなければなりません。

従来のモバイルデバイスの使用モデルは限定されていました。ユーザーはデータ管理アプリケーションを実行したり、ローカルでゲームをプレイすることがほとんどで、たまに静的な Web ページを閲覧したり、メールなどの特定のサービスを利用していました。つまり、デバイスの使用モデルは、購入時にプリインストールされているアプリケーションにより決まっていました。新しいモバイルデバイスではこの点が大きく異なります。新しいモバイルデバイスは、実質的にさまざまなモデルへのポータルと言えます。サービス・プロバイダー、アプリケーション開発者、他のデバイスユーザーなどと継続的に関わりを持ち、デバイスを通してその所有者とやりとりします。図 1 は、従来のモバイルデバイスと新しいモバイルデバイスの高レベルの使用モデルにおける相違点を示します。

図 1: モバイルデバイスの高レベルの使用モデル – 出典: インテル コーポレーション (2012 年)

現在のモバイル OS の代表的なものとして、Apple* iOS 5.0、Google* Android* 4.0、Microsoft* Windows* Phone 7.0 があります。これらのオペレーティング・システムの使用モデルには、相違点よりも類似点のほうが数多くあります。

• どのモバイル OS もソフトウェア開発キット (SDK) とドキュメント、十分に定義された API を備えており、一般的な開発者がこれらのシステム向けにアプリケーションを開発することができます。
• すべてに Apple App Store、Google Play、Windows Phone Marketplace のような、開発者がアプリケーションを公開し、ユーザーがダウンロードできるオンライン・アプリケーション・ストアがあります。
• どのモバイル OS もある程度のレベルのマルチタスクと 3D グラフィックをサポートしています。もちろん、タッチスクリーンとセンサーにも対応しています。応答性に優れたスムーズなユーザー操作を実現するため、多大な労力が費やされています。
• Web 体験は静的ページの閲覧だけにとどまりません。Web ベースのアプリケーションを実行するため、HTML5 が主流になりつつあります。
• どれもデバイスベースの支払いに対応しています。エンタープライズ・アプリケーションと個人情報を組み合わせて使用するため、システムのセキュリティーはデバイスユーザーにとって常に重要な懸念事項です。
• モバイル OS として、バッテリー寿命が重視されている点が非モバイル OS の設計と大きく異なります。可能な場合は常にデバイス・コンポーネントをアイドル状態にし、電力消費をできるだけ抑えるようにしています。

これらの類似点は、ハードウェア、ソフトウェア、インターネットの進化のトレンドを反映しています。モバイル OS のトレンドから、次世代のモバイル OS 設計ではユーザー体験、バッテリー寿命、クラウド対応、オープン性などが重視されると考えられます。しかし、多くの場合、それらは互いに矛盾します。

• ユーザー体験とバッテリー寿命: 応答性に優れたスムーズな動作を実現するには、システムがすべてのハードウェア・リソースを最大限に利用できなければなりません。一方、バッテリーを長持ちさせるためには、できるだけハードウェア・コンポーネントをアイドル状態にする必要があります。
• セキュリティーとオープン性: システムのすべてを外部にさらすことは、セキュリティー上の脅威となるため望ましくありません。一方、システム API を提供しなければ、開発者が革新的な使用モデルを考案することはできません。
• クラウド対応: クラウドで提供されるサービスやアプリケーションの増加に伴い、クラウドを信頼し、計算処理をクラウドにオフロードするシンクライアント・デバイス・モデルを検討することは当然の流れでしょう。しかし、現時点でシンクライアント・モデルは、まだユーザー体験とセキュリティーにおいて技術的な課題を抱えています。

この記事では、モバイル OS 設計のさまざまな側面を検証し、将来のモバイル OS アーキテクチャーについて我々の見解を述べます。

ユーザー体験、電力管理、セキュリティー、オープン性、クラウド対応のトピックについて、各セクションで説明し、そして、最後に議論と要点を述べます。

ユーザー体験 (UX)

最近のクライアント・デバイスの特性を示すのに従来の「パフォーマンス」は適切ではありません。パフォーマンスはソフトウェアの定常実行状態を示し、多くの場合、プロセッサーやほかのサブシステムの総スループットで表されます。 ユーザー体験はユーザー入力によるシステムの動的状態の遷移を示します。 ユーザー体験の質は、応答性、スムーズさ、一貫性、精度といったユーザーが知覚可能な要素によって判断されます。従来のパフォーマンスによって、個々のユーザー操作を測定することはできますが、すべてのユーザー操作を総合的に評価することはできません。そのため、従来のパフォーマンス最適化手法をそのまま適用して、ユーザー体験を最適化することはできません。エンドユーザーに快適なエクスペリエンスを提供するため、デバイスのユーザー操作の最適化について見てみましょう。

モバイルデバイスにおけるユーザー操作

市販されている一部の Android* デバイスに関する最近のパフォーマンス測定結果によると、グラフィック、メディア、ブラウズの一般的なベンチマークにおいて、デバイス X はデバイス Y と比べて一貫してパフォーマンスが悪いことが分かりました。しかし、ユーザーが知覚可能なエクスペリエンスについてはデバイス X のほうがデバイス Y よりも優れていました。この原因は、従来のベンチマークや従来の方法で設計されているベンチマークでは、ユーザー操作が評価されず、システムとサブシステムの計算能力 (実行された命令数など) やスループット (処理されたディスクの読み取り数など) を測定しているためです。

例えば、動画再生の評価について考えてみます。従来のベンチマークは、FPS (1 秒あたりのフレーム数) やフレーム・ドロップ･レートのような評価基準のみを使用して、動画の再生パフォーマンスを測定します。この方法は、ユーザー体験を評価する上で少なくとも 2 つの問題があります。1 つ目は、動画再生は一連の操作の一部でしかないことです。通常、ユーザーは次のような一連の操作を行います:

プレイヤーを起動する > 再生を開始する > 再生位置を探す > 動画を再生する > メイン画面に戻る

そのため、動画再生のパフォーマンスが優れていても、実際の動画再生のユーザー体験を評価することはできません。ユーザー操作の評価は、従来のパフォーマンス評価の上位セットと言えます。

もう 1 つの問題は、ユーザー操作のスムーズさを判断する主な評価基準として FPS を使用しても、それが常にユーザー体験の質に反映されないことです。例えば、Gallery3D アプリケーションで画像をフリックした場合、デバイス Y ではスクロール時に画像が途切れましたが、デバイス Y の FPS 値のほうがデバイス X よりも高くなりました。2 つのデバイスの相違点を数値化するため、図 2 と図 3 に示すように、デバイス X とデバイス Y の両方において、Gallery3D アプリケーションで画像のフリック操作中の各フレームのデータを収集しました。各フレームのデータは縦棒で表しています。x 軸はフレームが描画された時間、棒の高さはフレームの描画にかかった時間です。図から、デバイス X の FPS 値のほうがデバイス Y よりも明らかに低いことが分かります。また、デバイス X のほうが最大フレーム時間が小さく、30ms を超えるフレームが少なく、フレーム時間の差異が小さいことも分かります。つまり、画像のフリック操作のユーザー体験を評価するには、最大フレーム時間やフレーム時間の差異のような評価基準も考慮すべきです。

図 2: デバイス X 上の Gallery3D アプリケーションにおけるフリック操作のフレーム時間 – 出典: インテル コーポレーション (2012 年)

図 3: デバイス Y 上の Gallery3D アプリケーションにおけるフリック操作のフレーム時間 – 出典: インテル コーポレーション (2012 年)

比較のため、図 4 にデバイス Y を最適化した後のフリック操作のフレームデータを示します。すべての評価基準が向上し、フレーム時間の分布がより一定しているように見えます。

ユーザー体験はユーザー入力によるシステムの動的状態の遷移を示します。優れたユーザー体験は、応答性、スムーズさ、一貫性、精度といったユーザーが知覚可能な要素によってもたらされます。従来のパフォーマンスは、すべてのユーザー操作を総合的に評価するのではなく、個々のユーザー操作を測定します。

図 4: 最適化後のデバイス Y 上の Gallery3D アプリケーションにおけるフリック操作のフレーム時間 – 出典: インテル コーポレーション (2012 年)

ユーザー体験は、映画を鑑賞したり、音楽を聴いたりするのと同じで、主観的なものであるという点も重要です。現在の学術研究では、眼球追跡、心拍数のモニタリング、またはユーザーのフィードバックなど、さまざまな方法を用いてユーザー体験の理解に努めています。この記事では、ソフトウェア・エンジニアリングの観点から、ユーザー操作を系統的に解析して最適化するため、操作を 4 つのカテゴリーに分類します。

• ユーザー、センサー、ネットワークなどからのデバイスへの入力: 入力に対してデバイスが想定どおり正確に、あるいはファジーに動作するかどうかを評価します。タッチスクリーンからの入力では、タッチの速度、圧力、範囲などを測定します。
• 入力に対するデバイスの応答性: 入力に対するデバイスの応答性を評価します。
• システム状態の遷移: 画面上のグラフィックの遷移がどの程度スムーズに行われるかを評価します。これは、入力に対するデバイスの応答を追跡することで評価できます。
• デバイスの連続制御: デバイスの入力は単一のこともあれば、場合によってはジェット機のゲームを操作したり、アプリケーション・アイコンをドラッグしたりというように、画面上のグラフィック・オブジェクトを制御することもあります。このカテゴリーでは、デバイスの制御性を評価します。

これらのカテゴリーの中で “デバイスへの入力” と “デバイスの制御” は、ユーザー体験においてユーザーがどのようにデバイスを操作するかという面に関連しています。”入力に対するデバイスの応答性” と “システム状態の遷移” は、ユーザー操作に対してデバイスがどのように対応するかという面に関連しています。ユーザー操作のライフサイクルを上記のカテゴリーに分類可能なシナリオに関連付け、シナリオごとに測定および最適化すべきソフトウェアの評価基準を特定することができます。

ユーザー操作の最適化

前述したように、ユーザー体験を測定する明確で客観的な方法はありません。ここでは、ユーザー操作の測定に関して次の条件を設定しました。

• 知覚可能である: 人が知覚可能な評価基準でなければなりません。そうでないと、ユーザー体験に無関係なものになってしまいます。
• 測定可能である: 異なる条件下で測定可能な評価基準でなければなりません。評価基準は、特定の条件下でのみ測定可能な特定のインフラストラクチャーに依存すべきではありません。
• 繰り返し可能である: 測定結果は、何回測定を行っても、繰り返し得られるものでなければなりません。測定のたびに結果が大きく異なる場合、その評価基準は適切ではありません。
• 比較可能である: 測定したデータは異なるシステム間で比較できるものでなければなりません。ソフトウェア･エンジニアが評価基準に基づいて異なるシステムを比較できる必要があります。
• 合理的である: ソフトウェア動作の因果関係を明らかにするのに役立つ評価基準でなければなりません。つまり、ソフトウェア動作に関連付けることができ、ソフトウェアの実行に基づいて計算可能な評価基準にすべきです。
• 検証可能である: 最適化の検証に利用できる評価基準でなければなりません。最適化を行う前と行った後の測定結果に、ユーザー体験の変化が反映されるべきです。
• 自動化可能である: ソフトウェア・エンジニアリングの観点から、ほぼ自動で測定できる評価基準が望ましいでしょう。これは、特に回帰テストやコミット前テストなどで役立ちます。これはユーザー体験の解析と最適化には直接関係ないため、厳密には必須条件ではありません。

測定条件に従って、デバイスのユーザー操作とそれに対するデバイスの反応に注目してみましょう。デバイスのユーザー操作では、主に 2 つの分野を測定します。

• 精度/ファジーさ: タッチスクリーン、センサー、その他のソースからの入力において、システムでサポートされている精度、ファジーさ、解像度、範囲を評価します。例えば、システムでサポートされている圧力のレベル、サンプリングされるタッチイベントの座標と画面上の指先追跡の近さ (精度)、同時にサンプリングされる指の本数などを評価します。
• 一貫性: 画面上の指先とドラッグされたグラフィック・オブジェクトの間の距離を評価します。また、傾きにより制御される水の流れとデバイスの斜角の角度の差のような、ユーザー操作とセンサー制御オブジェクトの一貫性も評価します。

ユーザー操作に対するデバイスの反応でも 2 つの分野を測定します。

• 応答性: 入力がデバイスに送られてからデバイスが視認できるレスポンスを行うまでの時間を評価します。動作の完了にかかった時間も評価します。
• スムーズさ: 最大フレーム時間、フレーム時間の差異、FPS、フレーム・ドロップ･レートなどによりグラフィックの遷移のスムーズさを評価します。前述のように、FPS だけではユーザー体験のスムーズさは正確に判断できません。

これら 4 つの測定分野について、用いる評価基準が明確になったら、その評価基準がどのように “良” レベルのユーザー体験につながるかを理解する必要があります。ユーザー体験は各自の生理学的状態と好みに大きく依存する主観的なものなので、評価基準がどのような値であったら “良” レベルのユーザー体験と言えるのか、常に科学的な結論が得られるとは限りません。そのような場合、ここでは業界標準値を使用します。表 1 にいくつかの業界標準値を示します。

	最良	良	可
応答遅延	≤ 100ms	≤ 200ms	≤ 500ms
グラフィック・アニメーション	≥ 120fps	≥ 60fps	≥ 30fps
動画再生	≥ 60fps	≥ 30fps	≥ 20fps

表 1: ユーザー体験の業界標準値の例 – 出典: インテル コーポレーション (2011 年)

ユーザー体験を最適化する場合、人間の性質を考慮して次の 2 つの点に注意する必要があります。

通常、”良” レベルのユーザー体験は、評価基準の値の範囲内になります。この範囲よりも “良い” 値であっても、”より優れた” ユーザー体験がもたらされるとは限りません。ユーザーはその範囲よりも良い値を知覚できない可能性があります。

ここで紹介した値は、典型的なユーザーと一般的な状況における大まかなガイドラインです。例えば、経験豊富なゲームプレイヤーは 120fps のアニメーションでは満足しないかもしれません。一方、よく設計された漫画アニメは 20fps でもスムーズに動作するかもしれません。

次に、ユーザー体験の最適化手法を見てみましょう。次のステップにまとめることができます。

ステップ 1: ユーザーからユーザー体験に関する報告を受けるか、手動で操作の問題を見つけます。これには、高速度カメラやその他の手法を利用することができます。

ステップ 2: ユーザー体験の問題をソフトウェアで確認できる症状に変換するソフトウェア・シナリオと評価基準を定義します。

ステップ 3: 繰り返し測定可能な方法で問題を再現するソフトウェアのワークロードを作成します。ワークロードを実行すると、ユーザー体験の問題を示す評価基準の値が得られます。

ステップ 4: ワークロードと関連ツールを使用して、ソフトウェアの解析と最適化を行います。同じワークロードを使用して最適化されたかどうかを検証します。

ステップ 5: ユーザーからフィードバックを受け取り、より多くのアプリケーションを試して、ユーザー体験の向上を確認します。

これらの手法に基づいて、我々は Android* デバイスの一般的な使用事例をすべてカバーした Android* Workload Suite (AWS)^[33] を開発しました。また、ソフトウェアのユーザー操作の解析を支援する UXtune^[34] というツールキットも開発しました。従来のパフォーマンス･チューニング・ツールと異なり、UXtune はユーザー可視イベントと低レベルのシステムイベントを関連付けます。次のステップとして、我々は現在 Android* 以外のシステムへの移植に取り組んでいます。

ユーザー体験のモバイル OS 設計

Android* における経験から、UX の最適化はより複雑ではあるものの、次の 4 つの理由から並列アプリケーションの最適化に似ていることが分かりました。

• UX は複数のハードウェア・コンポーネント、複数のソフトウェア・プロセス、およびそれらの相互作用と関係しています。
• UX はバッテリー寿命とデバイス温度にも関係しているため、クライアント・デバイス上の UX では電力消費を考慮する必要があります。
• UX では、フレーム時間の差異がないスムーズな動作のように、正確なタイミングが求められます。速すぎず、遅すぎず、正確なタイミングで行わなければなりません。これは、リアルタイム要件に似ています。
• アニメーションがヒントとして使用されているだけなのか、あるいは UX に不可欠なものなのか、応答性を高めるのにフレームをいくつかドロップできるかなど、モバイル OS 設計で考慮すべき主観的要素が UX には含まれています。

我々が経験的に学んだ重要なことの 1 つは、特定の操作のクリティカル・パスを理解することです。並列アプリケーションのチューニングと異なり、モバイル OS 設計では関連するハードウェア・コンポーネントとソフトウェア・スレッド間で明示的な同期が常に行われるわけではありません。次に例を示します。

• すべてのアプリケーションは、イベントループにより要求を処理します。スレッド A がスレッド B に要求する場合、関数を直接呼び出す代わりに、スレッド B へメッセージを送信する可能性があります。このメッセージはスレッド B のイベントループに追加され、処理されるのを待機します。イベントループに複数のイベントがある場合、スレッド A は要求がどの程度早く処理されるかを制御することはできません。
• 別の例として、スレッド A が一連の処理を実行し、スレッド B にメッセージを送信して残りの処理とユーザーへの応答を任せるケースについて考えてみます。スレッド A がすべての処理を順番どおりに実行しなくてもよいのであれば、できるだけ早期にスレッド B へメッセージを送信することで、スレッド B はより早くユーザーに応答できます。

電力に関して重要なことは、従来のパフォーマンスの最適化に反し、迅速なユーザー体験が必ずしも良いとは限らないことです。ユーザーが知覚可能な最良の応答レベルにシステムがすでに達している場合、次の最適化ステップは最良の知覚可能な範囲内で最も遅くすることです。例えば、ゲームが 60fps で問題なく動作する場合、モバイル OS は CPU 使用率と CPU 周波数の両方をできるだけ低く抑えるように試みるべきです。この 2 つのケース (速いほうが良いと遅いほうが良い) は、常に明確に区別する必要があります。それぞれのケースでは最適化手法が大きく異なります。複数のコアと GPU が利用可能な場合、上記の 2 つのケースの違いはより明確になるでしょう。コア数の増加は、一般的に “速いほうが良い” シナリオには有利ですが、バッテリー寿命のような “遅いほうが良い” シナリオには不利です。コアを有効/無効にする処理のレイテンシーはタッチ操作よりも長いため (通常 100ms ～ 500ms の範囲)、モバイル OS はスマートポリシーを使用してこれらの処理を行う必要があります。並列アプリケーションのパフォーマンス・チューニングでは、デバッグ時に “実行の再現” が役立ちます。通常、1 つのマルチスレッド・アプリケーションを (つまり、1 つのプロセス内で) 再現します。しかし UX の場合、システム全体が協調して、IPC を利用して CPU、GPU、ディスプレイ・コントローラー (DC) 間で操作が相互処理されます。そのため、従来の再現手法は役に立ちません。

電力管理 (PM)

これまでも電力管理はモバイル OS の設計における重要な課題でしたが、今後はさらに重要になるでしょう。モバイル・プラットフォーム向けアプリケーションの増加に伴い、モバイルデバイスの電力需要は急速に高まりつつあります。しかし、バッテリー・テクノロジーの開発の遅れと、ポケットに収まるより洗練されたデザインのコンパクトなフォームファクターに対するニーズの高まりから、バッテリー容量の拡大がこれに対応することは難しいでしょう。モバイルデバイスの電力管理はますます複雑な問題となっており、その解決には全体的なアプローチが求められています。

プロセッサーの電力管理

この 10 年間に、モバイル OS は電力管理の分野において確実に前進しています。長い間、プラットフォームの総電力消費の中でプロセッサーは最も大きな割合を占めていたため、初期のモバイル OS の電力管理はプロセッサーを中心としたものでした。最近のプロセッサーは、拡張版 Intel SpeedStep® テクノロジーのような動的な周波数と電圧のスケーリングをサポートしています。このようなプロセッサー機能により、モバイル OS は、現在実行中のワークロードに必要な計算能力に応じて、プロセッサーの周波数や電圧をランタイムに動的に調整できるようになりました。プロセッサーの消費電力はコアの電圧と周波数の 2 乗に比例するため、アクティブな状態のプロセッサーの電力消費を大幅に抑えることができます。アクティブ状態のプロセッサーの電力管理を行う例として、Linux* カーネルの cpufreq サブシステムがあります。動的な周波数と電圧のスケーリングに加えて、最近のプロセッサーは通常、消費電力の異なる複数のアイドル状態をサポートしています。アイドル状態の深さが深いほど低消費電力ですが、その状態へ移行するときと、その状態から別の状態へ移行するときにより長いレイテンシーが必要になります。モバイル OS は、予想されるアイドル状態と、ほかのサブシステムやユーザー領域による QoS の制約に基づいて、適切なアイドル状態に移行するようにプロセッサーに指示します。アイドル状態のプロセッサーの電力管理を行う例として、Linux の cpuidle サブシステムがあります。

デバイスの電力管理

モバイル OS の電力管理は、プロセッサー単独からデバイス全体の電力管理に移りました。特に、ランタイムに I/O デバイスの電力を管理するメカニズムが登場しました。I/O デバイスのランタイム電力管理は、ランタイムに I/O デバイスがアイドル状態であることを検出すると、必要に応じて自動的にその I/O デバイスを低消費電力状態に移行させます。アイドル状態の I/O デバイスの電力管理に加えて、アクティブ状態の I/O デバイスの電力消費を抑える革新技術もあります。例えば、最近の GPU は CPU と同様に動的な周波数と電圧のスケーリングをサポートし始めました。GPU の動的な周波数と電圧のスケーリングは、モバイル 3D グラフィックの消費電力を最大で 50% 削減します。さらに、I/O デバイスは CPU の介入がなくても動作できるほど高性能になってきています。例えば、表示パネルのセルフリフレッシュのようなテクノロジーは、モバイルデバイスで本を読むときなど、静的イメージにおいて電力消費を大幅に抑えられます。この場合、表示パネルはローカルメモリーからレンダリングし、従来であればレンダリング中に動作していた CPU、メモリー、ディスプレイ・エンジン、ディスプレイ・ポートを含む多くのハードウェア・コンポーネントを停止することができます。

モバイル OS の電力管理

Android* は、Linux* カーネルにデバイスのランタイム電力管理インフラストラクチャーが導入される前に躍進を遂げたため、Android* デバイスのバッテリー寿命を長持ちさせる Opportunistic Suspend と呼ばれる独自のアプローチを採用しています。デバイスのランタイム電力管理機能を使用しないで、Android* は有効な処理が行われていないとき (どの処理もウェイクロックを保持していない場合) は積極的にシステムをサスペンド状態にしようと試みます。

Windows* 8 には、コネクトスタンバイと呼ばれる新しいシステムの電力状態が追加されています。すべてのシステム・アクティビティーを中断する従来の S3 スタンバイと異なり、システムは超低消費電力状態で実行を継続するため、ユーザーはメールなどを最新の状態に保つことができます。Windows* 8 のコネクトスタンバイは、プロセッサーのアイドル電力管理とデバイスのランタイム電力管理のテクノロジーに基づいています。

サスペンドベースとアイドルベース、どちらの電力管理アプローチにとってもソフトウェアの状態は最も重要な課題です。そのようなシステムでは、バッテリー寿命はアプリケーションの動作に大きく依存します。最近の調査では、無料の Android* アプリケーションはバックグラウンドでウェイクロックを保持し、システムがサスペンド状態にならないようにして、電力の 75% を広告に費やしていることが報告されています。Windows* 8 でも、1 つのアプリケーションが意味もなくビジー状態であり続けることで、システム全体がコネクトスタンバイ状態に移行することができなくなります。そのようなアプリケーションがあっても、より高度なメカニズムによりシステムの電力管理をもっと強固なものにすべきであるという考え方がある一方、そのようなメカニズムは悪質なアプリケーションの増殖につながるだけだという考え方もあります。

オープン性

オープン性もモバイル OS の主要なトレンドです。モバイル OS におけるオープン性とは、目的に応じてモバイル OS を使用、貢献、カスタマイズ、革新する機会と自由度を示します。オープン性に関する開発者の観点の調査^[6] では、開発者がプラットフォームのオープン性を判断する要素を識別しています。オープン性は、モバイル・エコシステムを発展させるために重要な要素であるため、ここではエコシステムの観点からオープン性のトレンドについて検証します。

モバイル・エコシステムの提供者にとってのオープン性

モバイル・エコシステムの提供者には、モバイルデバイスを製造および販売するメーカー (OEM)、ネットワーク接続とその他の付加価値サービスを提供するサービス・プロバイダー (通信事業者)、利用者 (エンドユーザー)、商用アプリケーションを開発する ISV、およびアプリケーションの開発、さらにモバイル OS がオープンソースの場合はその開発と進化にも貢献するコミュニティー開発者が含まれます。

モバイル OS のオープン性の基準は、モバイル・エコシステムの提供者ごとに異なります。通信事業者の場合、さまざまなデバイスにわたっていかに簡単でスムーズにサービスを移行、移植、配備、実行できるかによりモバイル OS のオープン性が決定されます。モバイル・デバイス・メーカーの場合、さまざまなプラットフォームにわたって、モバイル OS 自体をどの程度カスタマイズし、他社との差別化を図れるかによりオープン性が決定されます。さらに、一貫したユーザー体験のデバイスをいかに簡単に製作できるかということも重要です。ISV とコミュニティー開発者の場合、独創的なアイデアを基に新しいアプリケーションをいかに簡単に作成できるか、アプリケーション開発への投資をどのように最大化できるか (一度プログラミングするだけでさまざまなデバイスで実行できるか) によりオープン性が決定されます。エンドユーザーまたはモバイルデバイスの利用者の場合、さまざまなデバイス間におけるユーザー体験の不整合性とアプリケーションの互換性を気にせずに、簡単にアプリケーションを数多くストアからダウンロードできるかによりオープン性が決定されます。オープン性は、モバイル OS のライフサイクルをとおして、人々にモバイル OS 自体の開発と進化に貢献する機会も与えます。

モバイル OS のオープン性の進化

数年前、モバイルデバイスのほとんどは携帯電話で、音声通話、電話帳、メール機能が使用されていました。利用者はデバイスの出荷時に組込まれているアプリケーションのみ使用することができ、アプリケーション開発者およびサードパーティーの ISV は、OS の開発元と契約を結ばない限りソースコードにアクセスすることはできませんでした。このようなモバイル OS は完全なクローズドシステムで、通常その所有権はモバイル・デバイス・メーカーにありました。モバイル OS の開発元だけがアプリケーションの開発方法を知っていたため、通信事業者がサービスを提供するには OS の開発元と緊密に協力する必要がありました。

その後、携帯電話からスマートフォンへ移行するにつれ、通話、連絡先の保存、メールの送信だけでなく、Web 閲覧や音楽/動画再生のような多くの機能が求められるようになりました。モバイル OS の開発元は、より多くの開発者が人々のニーズにあった多種多様なアプリケーションを開発できるように API や SDK のような関連ツールを提供しているため、モバイルデバイス向けにあらゆるアプリケーションを開発することができます。このようなオープン性により、アプリケーション開発者はモバイル OS 向けのアプリケーションを自由に作成でき、利用者はデバイスにプリインストールされているアプリケーションだけでなく、さまざまなアプリケーションを購入し、インストールできるようになりました。オープン性はアプリケーション開発者と利用者に利点をもたらしたため、ほとんどのモバイル OS において API と SDK の提供は “不可欠” なものになりました。そのようなオープン性を備えたモバイル OS の例として、Apple の iOS があります。近年、API と SDK の提供に加えて、すべてのソースコードを公開するモバイル OS が増えています。誰でもすべてのソースコードを参照することが可能で、モバイル OS 自体のコード、進化、カスタマイズに貢献することができます。API と SDK を提供するだけの場合と比べて、オープンソースのモバイル OS はさらに多くの自由度をもたらします。モバイル・デバイス・メーカーは、オープンソースの OS に基づいてさまざまなデバイスのプラットフォームで実行する独自のモバイル OS を構築することができます。通信事業者は、オープンソースの OS とそのバリエーションを実行するさまざまなデバイスにわたって、サービスを構築し配備することができます。オープンソースのモバイル OS は、簡単なアプリケーションの作成に必要なものをすべて開発者に提供します。結果的に、このようなオープン性は、より広範なアプリケーションとデバイスの選択肢をモバイルデバイスのエンドユーザーにもたらします。最後に、オープンソースのモバイル OS の進化と形成には、誰でも参加することができます。これは、世界中のコミュニティーの開発者にとって非常に魅力的なことです。Android* OS もオープンソースのモバイル OS の良い例です。この数年間のスマートフォン市場における Android* OS の成功とシェア拡大は、オープンソースのモバイル OS として Android* OS がどれほど成功しており、急成長を遂げているかを示しています。

将来のモバイル OS におけるオープン性は、モバイル・エコシステム・フレンドリーな、特にアプリケーション開発者と利用者に魅力的なモバイル・プラットフォームを構築する重要な要素の 1 つです。ほとんどのソフトウェアにおいて、1 つのビルドですべてのプラットフォームに対応し、一貫したユーザー体験を提供できることが求められるコンピューティング・コンティニュアムでは、モバイル OS のオープン性は必要不可欠です。

クラウド対応

クラウドはモバイルユーザーに広く使用されてきました。クラウドサービスのほとんどは Web サイトとして提供され、モバイルブラウザーから利用できます。Web アプリケーションによって提供されるクラウドサービスはますます増えており、それらはアプリケーション・ストアからインストールされ、モバイル・クライアント上でネイティブ・アプリケーションのように実行します。ブラウザーでも、スタンドアロンの Web アプリケーションでも、モバイル OS 設計では次のことを考慮すべきです。

HTML5 のサポート

Web アプリケーションがクラウドサービスを統合し、優れたユーザー体験を提供するためには、HTML5 のサポートが不可欠です。

使用されている Web エンジン: ここでは、主要なモバイルブラウザーで使用されている Web レイアウトエンジンと JavaScript エンジンを示します。Chrome* はデスクトップで成功を収めており、モバイルでも Android* のデフォルトのブラウザーに採用される可能性があります。Webkit* は iOS と Android* で使用されています。

HTML5 テストの Web サイト^[9] では、さまざまなモバイルデバイスのブラウザーの HTML5 サポートにスコアを付けています。表 2 から iOS、Android*、Windows* Phone はすべて、ブラウザーで HTML5 をサポートしていることが分かります。Google は Android* 4.0 で Chrome* を採用し、モバイル OS のリーディング・ブラウザーに躍り出ようとしています。モバイル OS に新規参入した Tizen* は、第 1 回の Tizen Developer Conference で公開された開発デバイスで最高スコアを獲得しています。各モバイル OS が競って HTML5 サポートに取り組んでいることが分かります。

	レイアウトエンジン	JavaScript エンジン	スコア + ボーナス
iOS 5.1 上の Safari	Webkit*	SquirrelFish Extreme (SFX)	324 + 9
Android* 4.0 上の Android* ブラウザー	Webkit*	V8	273 + 3
Windows* Phone 8 上の IE	Trident*	Chakra*	300 + 6
Tizen* 1.0	Webkit*	SFX	400 + 15 **
Android* 4.0 上の Chrome* ベータ版	Webkit*	V8	364 + 10
Opera* Mobile 12	Presto*	Carakan*	369 + 11
Firefox* Mobile 10	Gecko*	SpiderMonkey*	325 + 9

表 2: Web レイアウトエンジン、JavaScript エンジン、および html5test.com のスコア
(出典: ^[9]。** Tizen* 1.0 のスコアは最新の Tizen* 開発デバイスで行ったインテルでの測定。)

Opera* や Firefox* のようなサードパーティーのブラウザーは厳しい状況にあり、独自のホストモバイル OS を持つ戦略が必要です。サードパーティーのブラウザーはモバイル OS 開発を制御できないため、ビルトインブラウザーが HTML5 をサポートする場合、それに対抗するのは容易ではないでしょう。Firefox* は、ホストモバイル OS として Boot To Gecko* の採用を検討しています。また、YouTube^[10] の動画に、Asus EeePC に搭載された Opera* OS のプレビューがあります。

モバイル OS ベンダーは、HTML5 のサポートはますます重要になると考えており、コア・コンピテンシー (核となる能力) として捉えています。ブラウザーベンダーもそれぞれの製品をモバイル OS のデフォルトにするべく可能性を模索しています。

Web アプリケーション

Web アプリケーションは、Web テクノロジーを基に開発されたクライアント側のアプリケーションを定義します。クライアント側の開発に必要な API を提供することで、豊富な機能を提供します。Web アプリケーションは、インターネットに接続されていなくても、デバイスにインストールし、実行することができます。また、Web アプリケーションは、ネイティブ・アプリケーションとしてローカルのデバイスとリソースを利用でき、アプリケーション・ストアで販売することで、クラウドサービスの配信と支払いによる利点が得られます。

Web アプリケーションはただブラウザーから URL を指定してアクセスできるだけのものではなく、W3C の複数のワーキンググループで関連機能の定義が行われています。これらの取り組みは、Web Applications Working Group が中心となって進められています。^[11]

Web アプリケーションを利用できるようにするため、OS は Web ランタイム、Web フレームワーク、開発ツールを含む Web アプリケーション・プラットフォームを提供する必要があります。

• Web アプリケーションの実行に必要な主要機能を提供する Web ランタイム: Web ランタイムは、ブラウザーから派生した機能ですが、OS ランタイムに統合されます。HTML5 エンジンとローカルデバイスにアクセスする API を提供します。また、アプリケーションのライフサイクル管理 (インストール/アップデート/アンインストール/起動)、OS 統合 (デスクトップ統合、セキュリティー・ポリシー、OS サービスへのアクセス) など、OS ランタイムに統合される機能も提供します。
• Web アプリケーション開発に必要な豊富なライブラリーを提供する Web フレームワーク: 一例として、jQueryMobile や Sencha が挙げられます。これらのフレームワークは、iOS および Android* で一般的に使用されています。
• 柔軟な開発ツール: 開発ツールは多種多様で、Web アプリケーション開発者が好みに応じて選択できるようにする必要があります。Tizen* SDK 1.0^[12] のように豊富な機能を備えた SDK スイートもあれば、appMobi XDK^[13] のようにブラウザーベースのものや、01.org^[14][15] の RIB および Web Simulator のように単なるツール群もあります。

最近のトレンドとして、モバイル OS は、高性能でハイパフォーマンスな Web ランタイム、機能が豊富な Web フレームワーク、柔軟な開発ツールを提供する必要性に迫られています。

クラウド・コンピューティングにおいてセキュリティーは常に重要なトピックと言えます。モバイル OS における HTML5 のクラウド統合では、次の機能が必要です。

• Web ランタイムでのサンドボックスのサポート: Web アプリケーションは個別のプロセスで実行し、Web ランタイムによって管理されるべきです。ブラウザーまたは Web ランタイムのサンドボックスは、最近のモバイル OS のほとんどでサポートされています。
• JavaScript* コードの保護: JavaScript* はスクリプト言語なので、コードを保護する最良の方法はサーバー側でコードを実行することです。

クロスプラットフォームのサポート

HTML5 がクロスプラットフォームに対応していることはよく知られています。しかし、実際には、モバイル OS ごとに HTML5 サポートは異なり、HTML5 はまだ標準化されていません。PhoneGap* は独自のデバイス API を提供することで、クロスプラットフォームの HTML5 に対応するべく開発されました。Apple* iOS、Android*、Windows* Phone はすべて PhoneGap* をサポートしています。PhoneGap* は W3C に準拠し、進化し続けています。その他の Web API プロバイダーもそれぞれのアイデアを W3C の HTML5 標準規格に組込もうとしています。

統一された HTML5 標準規格を策定しようという動きがありますが、それは容易ではありません。モバイル OS ベンダーは、それぞれのアイデアが標準規格に組込まれる前に独自にそれらを実装するでしょう。Apple*、Google*、Microsoft* はすべて、W3C の標準規格の策定に積極的に関わっています。その他のモバイル OS ベンダーも、それぞれのモバイル OS の存続のため、W3C に準拠または参加する傾向にあります。

パフォーマンス

HTML5 でアプリケーションを作成する際に、モバイル・アプリケーション開発者が直面する問題として最も多いのはパフォーマンスの問題です。モバイルデバイス向けの最適化は、HTML5 がモバイル業界で実際に成功するために取り組まなければならない重要な作業です。モバイル OS の最適化において、次の分野が最も重要であると考えられます。

• ハードウェア・アクセラレーション: グラフィックとビデオには、ハードウェア・アクセラレーションを使用すべきです。WebGL* に対応したプラットフォームはますます増えています。
• マルチスレッド・サポート: HTML5 で Web Workers を主要機能としてサポートすべきです。
• JavaScript エンジンの最適化: SFX と V8 はともに JIT (Just In Time) に対応しています。
• ネイティブまたはハイブリッド・アプリケーションのサポート:Web アプリケーションでは、既存のネイティブ・ライブラリーを再利用するのも 1 つの手段です。この機能を提供する Android* NDK は Android* アプリケーションで広く使用されています。ただし、Web アプリケーションではあまり一般的ではありません。Chromium の NaCL はこれをサポートしています。

クラウドとの統合

HTML5 の強力な機能に加えて、クラウドとクライアントのシームレスな統合はさらに重要です。これは、Web アプリケーションだけでなく、ネイティブ・アプリケーションにも言えることです。統合の重要な理由として次のものが挙げられます。

• クラウドストレージのシームレスな統合: クライアントは、ネイティブストレージを使用するのと同じように、クラウドストレージを使用すべきです。そのためには、クラウドストレージとモバイル OS を緊密に統合する必要があります。Apple* は iCloud* と iOS 5 を完全に統合しています。また、Google Drive* は Google* の各種 Web サービスと統合されています。
• クラウド API へのアクセス: クラウドのクライアント側で、モバイル OS は Web アプリケーションとネイティブ・アプリケーション向けに、クラウドのクライアント API (通常は RESTful、SOAP、または Query API) にアクセスする使いやすいライブラリーを提供すべきです。
• アカウント管理: クラウドとの統合により、1 つのアカウントで複数のクライアントがクラウドを共有するため、同期の管理が必要になります。アカウントはモバイル OS で緊密に統合され、対応するクラウドサービスとローカルリソースにアプリケーションが安全にアクセスできるように提供されるべきです。クラウドとの統合の有用性を拡大するため、モバイル OS で同期と通知は重要な機能です。 

議論と要点

ここでは、現在市販されている主要なモバイル OS について述べてから、この記事を要約します。

Apple* iOS

Apple* はモバイル OS の設計をリードしてきました。iPhone* と iPad* はわずか数年で世界中に普及しました。どちらの製品も Apple* iOS を搭載しています。

ユーザー体験: iOS は優れたパフォーマンスを提供し、ほかのモバイル OS のベンチマークとしてよく使用されます。Apple* は継続的に UX パフォーマンスを向上しています。iPhone 4S は、特にインターネットとブラウザーにおいて、前世代よりもパフォーマンスが大幅にアップしました。^[1] 多数の新機能が追加されているため、パフォーマンス要件は高くなっています。非公式の調査^[1] では、iPhone* 3GS で iOS 4.x から 5.x にアップグレードした後、UX パフォーマンスの低下が見られました。

電力管理: iOS の電力最適化は、新機能の電力需要に対応できていないように見受けられます。モバイル・ネットワーク管理会社の Arieso* は、iPhone* 4S のデータ消費量は、仮想パーソナル・アシスタント機能 Siri のようなオンラインサービスの追加により、前世代の iPhone* モデルの 2 倍に増えていると予測しています。当然、電力消費も増加しているでしょう。^[3]

オープン性: iOS はクローズドモバイル OS と見なされます。PPO (Perceived Platform Openness) の概念に関する研究報告^[6] では、プラットフォームのオープン性の度合いは開発者の見識によって決定されると定義しています。

クラウド対応: HTML5 対応の iOS 5.0 は、優れたクラウド・クライアントであり、デフォルトで iCloud* ストレージと統合されています。

Google* Android*

Android* は Google* を中心とする Open Handset Alliance により開発され、現在モバイルデバイス向けのオペレーティング･システムとして広く使用されています。Android* オープンソース・プロジェクトは、エンドユーザーのモバイル体験を向上する実用的で優れた製品を作り上げることを目標としています。^[16]

ユーザー体験: Android* のユーザー体験チームは、3 つの包括的な目標 (“魅力がある”、”生活をシンプルにする”、”驚くような”) を含む設計方針^[17] を定義しました。^[18] 最新の Android* デバイスと iOS デバイスは、バッテリー寿命とベンチマークのテストにおいて同様の結果になりました。^[19]

電力管理: Android* はウェイクロックを保持する処理がない場合、積極的にデバイスをサスペンド状態にして電力消費を抑えます。^[20] しかし、Android* はサードパーティーのアプリケーションがバックグラウンドで実行するのを許可しているため、それらが意味もなくウェイクロックを保持していると電力が浪費されます。

セキュリティー: Android* は、セキュリティーを強化するため、各アプリケーションをサンドボックス環境で実行します。これは、アプリケーションごとに一意のユーザー ID を割り当て、アプリケーションをユーザーとして個別のプロセスで実行することで行われます。^[21]

オープン性: Google* は Apache* ライセンスの下で Android* のコードをオープンソースとして公開しており、Android* の開発および保守は Android* オープンソース・プロジェクトで行われています。しかし、Google* は通常、Android* の新しいバージョンごとに厳選したメーカー 1 社と協力してフラッグシップ・デバイスを製作し、そのデバイスがリリースされた後にのみ新しいコードを公開します。Android* エコシステムでは、断片化が大きな懸念になっています。Android* は Android* 互換性プログラムを立ちあげ、Android* 向けに開発されたアプリケーションがすべての Android* デバイスで動作することを保証する互換性テストスイートを提供しています。

クラウド対応: Google* はクラウド分野で大きくリードしていますが、まだ Apple* の iCloud* のような統合ソリューションの提供には至っていません。

Microsoft* Windows* Phone

Microsoft* は Windows* Phone と呼ばれる新しい設計のモバイル OS をリリースしました。Windows* Mobile 6.5 から Windows* Phone 7 への設計変更から、新しい OS のいくつかの特性が分かります。

ユーザー体験: 以前の入力スタイルからタッチスクリーン・ベースのユーザー操作への変更に伴い、Microsoft* は Windows* Phone と Windows* Mobile 間でアプリケーションの互換性を保持しない決断を下しました。^[23] Android* の AppWidget 設計と同様に、Windows* Phone もホームスクリーンにライブタイルの概念を採用しています。^[28]

電力管理: セキュリティー設計と同様に、Windows* Phone のバッテリー寿命設計は、Windows* CE と Windows* Mobile エクスペリエンスから多大な恩恵を受けています。特に注目に値するのは、Windows* Phone ではメインの配色テーマのデフォルトとして黒を採用しています。これは、黒のピクセルは光を反射しないため、OLED 画面の電力消費を抑えられるからです。^[32]

セキュリティー: Windows* Phone では、従来の Windows* Mobile のエンタープライズ向けの設計からエンドユーザー向けの設計に変化しています。エンタープライズ製品で培ったセキュリティーの経験は今後も役立つでしょう。^[31]

オープン性: Windows* Phone が登場する前に、Microsoft* は新しい OS 向けのプログラム開発を支援するため Windows* Phone 用の SDK をリリースしました。^[24] Windows* Phone Marketplace は 35 の国/地域でサービスを提供しています。^[25] 現在採用されているプログラミング言語は C# と Visual Basic* です。これらは Windows* 開発者にとって目新しいものではないため、言語の習得のしやすさはこれまでと変わらないことが予想されます。

クラウド対応: Windows* Phone は急速にクラウド対応に取り組んでいます。Windows* Phone 8 は、HTML5 を完全にサポートし、複数のタブで並列にページをロードできるとされる Internet Explorer* 10 と統合されます。^[29] さらに、Skype* も OS に完全統合されます。^[26] Windows* Phone の新しい概念の 1 つはハブで、類似のサービス機能を 1 つのハブにまとめます。これは、クラウドサービスにおいて Windows* Phone のユーザー体験を大幅に向上すると考えられています。^[27] Windows* Phone のソフトウェア・フレームワーク設計は、画面とクラウドの 2 つの部分からなります。クラウド部分は、特に “開発者ポータルサービス” と “クラウドサービス” 向けに設計されています。

この記事では、ユーザー体験、バッテリー寿命、クラウド対応、セキュリティー、オープン性を考慮した独自の解析モデルを使用して、モバイル OS 設計の重要な側面について検証しました。これらは次世代のモバイル OS 設計で注目すべき要素です。

将来のモバイル OS は、利用可能なハードウェア設計にも依存します。ソフトウェアとハードウェアの両方を考慮し、インターネットの進化も踏まえた設計がモバイルシステムを成功へと導くでしょう。

参考文献 (英語)

[1] http://www.youtube.com/watch?v=ng33wXDkyRM

[2] http://www.anandtech.com/show/4951/iphone-4s-preliminarybenchmarks-800mhz-a5-slightly-slower-gpu-than-ipad-2

[3] http://www.arieso.com/news-article.html?id=89

[4] https://ssl.apple.com/ca/ipad/business/docs/iOS_Security_Mar12.pdf

[5] http://www.techrepublic.com/blog/security/comparing-android-and-iossecurity-how-they-rate/5774 [6] http://www.user.tu-berlin.de/komm/CD/paper/090322.pdf

[7] http://www.apple.com/icloud/

[8] http://www.networkworld.com/community/blog/apples-ios-5-and-cloud

[9] http://html5test.com/results/mobile.html

[10] http://www.youtube.com/watch?v=mWSPNDD0tek

[11] http://www.w3.org/2012/webapps/charter/Overview.html

[12] https://developer.tizen.org/sdk

[13] http://www.appmobi.com/

[14] https://01.org/projects/rapid-interface-builder-rib

[15] https://01.org/projects/web-simulator

[16] https://www.mylookout.com/mobile-threat-report

[17] http://www.juniper.net/us/en/local/pdf/additional-resources/jnpr-2011-mobile-threats-report.pdf

[18] http://webupon.com/security/information-systems-attacker-motivations/

[19] http://source.android.com/tech/security/index.html

[20] http://www.w3.org/2011/webappsec/

[21] http://www.trustedcomputinggroup.org

[22] http://www.globalplatform.org/specifications.asp

[23] http://channel9.msdn.com/Events/TechEd/NorthAmerica/2010/WPH201

[24] http://www.engadget.com/2010/09/16/microsoft-demoes-twitter-andnetflix-apps-for-windows-phone-7-r/

[25] http://blogs.windows.com/bloggingwindows/2011/07/06/windows-phone-around-the-world-language-support-in-mango/

[26] http://wmpoweruser.com/microsoft-reps-claiming-windows-phone-8-definitely-coming-to-second-gen-handsets-probably-to-first-gen/

[27] http://www.engadget.com/2010/03/18/windows-phone-7-series-thecomplete-guide/

[28] http://www.engadget.com/2010/02/15/windows-phone-7-is-official-andmicrosoft-is-playing-to/

[29] http://pocketnow.com/windows-phone/exclusive-windows-phone-7-webbrowser-comparison

[30] http://arstechnica.com/microsoft/news/2011/04/windows-phone-7-mango-one-heck-of-an-upgrade.ars

[31] http://arstechnica.com/microsoft/news/2010/03/windows-phone-7-seriesin-the-enterprise-not-all-good-news.ars

[32] http://www.neowin.net/news/interview-windows-phone-7-battery-life-copypaste-multitasking-and-more

[33] http://software.intel.com/en-us/articles/aws-android-workload-suite-foruser-interaction-measurement/

[34] http://software.intel.com/en-us/articles/quantify-and-optimize-the-userinteractions-with-android-devices/

著者紹介

Xiao-Feng Li (xiao-feng.li@intel.com): インテル社のシステム・ソフトウェア最適化センターのアーキテクト。インテルでの勤続年数は 12 年で、並列システム、コンパイラー設計、ランタイム・テクノロジーの分野において豊富な技術経験を持ち、これまでに 20 の学術論文を発表し、10 の米国特許を所有しています。2 年前に、インテルのプラットフォームで最高の Android* ユーザー体験を提供するべく評価および最適化の取り組みを開始しました。前職は Nokia 研究センターの技術マネージャーで、コンピューター・サイエンスの博士号を取得しており、Apache ソフトウェア財団のメンバーでもあります。
Xiao-Feng の個人のホームページ: http://people.apache.org/~xli (英語)

Yong Wang (yong.y.wang@intel.com): インテル社のオープンソース・テクノロジー・センターのシニア・ソフトウェア・エンジニア。インテルでの勤続年数は 7 年で、仮想化、マネージャビリティー、OSV イネーブリングを含むさまざまなプロジェクトに従事してきました。最近では、Moblin*、Meego*、Tizen*、Android* のような広範なモバイル OS の電力管理に取り組んでいます。北京航空航天大学でコンピューター・サイエンスの修士号を取得しています。趣味はスポーツと読書です。

Weihua Jackie Wu (jackie.wu@intel.com): インテル社のオープンソース・テクノロジー・センターでモバイル OS および HTML5 ツールの開発チームを指揮しているエンジニアリング・マネージャー。以前はリサーチエンジニアとして、ワイヤレス・ネットワークと高電力効率の通信の研究に取り組んでいました。2004 年にインテルに入社する前は、中国科学院で組込みオペレーティング・システムとスマートフォン製品の開発に従事していました。北京航空航天大学で機械工学の修士号を 2002 年に、学士号を 1999 年に取得しています。また、2 つの米国特許を所有しています。

Kerry Jiang (kerry.jiang@intel.com): インテル社のシステム最適化テクノロジー・センター (SOTC) のソフトウェア・マネージャー。インテルでの勤続年数は 8 年で、そのうち 4 年は Android* の最適化と MeeGo SDK を含む、IA ベースのオープンソースのモバイル OS 向けソフトウェアに取り組んできました。前職は、Motorola でモバイル・プラットフォームと 2G ワイヤレス・ベース・ステーションのソフトウェア開発に従事していました。電子工学の修士号を取得しています。

Bingwei Liu (bing.wei.liu@intel.com): インテル社のオープンソース・テクノロジー・センターのエンジニアリング・マネージャー。インテルでの勤続年数は 11 年で、Linux* OS、オープンソース・ソフトウェア、およびシステム・エンジニアリング分野で豊富な経験があり、エンタープライズからクライアント・プラットフォームまで幅広く取り組み、現在はモバイル OS に専念しています。コンピューター・サイエンスの修士号を取得しています。

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。