最大限の応答性と実用性 ("すばやく滑らか" な動作) を実現しながら消費電力を最低限に抑えることは、エンジニアリング面の課題としてかなり大きなものです。この取り組みのスタート地点となるのは、Windows が適切なリソース使用レベルをサポートできるようにする私たちの努力ですが、アプリ開発者の皆さんによるリソース使用量を意識した開発なくしては、達成することはできません。電力効率はあらゆるフォーム ファクターと利用シナリオに影響します。つまり、消費電力を抑えることはだれにとっても良いことなのです。Windows 8 PC はこの分野において大きく前進しますが、このイノベーションは WinRT に含まれる新しいランタイム モデルを基盤とするものとなります。既存のデスクトップ アプリケーションに、機能や互換性を維持しながら後付けできる類のものではないためです。既にこのブログで触れた状態移行やセットアップと同様に、電力消費は Windows 8 において新しいシナリオに向けた刷新が行われた分野の一つです。既存の x86 ベースの PC では、従来どおりのサポートが引き続きすべて提供され、デスクトップでの作業はすべてこれまでどおりに維持されます (そしてもちろん、これまで見てきたように、多くの改善も施されています)。さまざまな SoC ハードウェア (Intel を含め) において新しい製品が登場してくるにつれ、このレベルの電力効率はより一般的なものとなってくるはずです。ここではデスクトップ アプリの電力消費量を改善するために行われた取り組みについても一部お話ししますが、一日中使用、常時接続というシナリオを実現するうえで主役となるのは、新しい電源管理機能に対応した新世代のハードウェアで動作する、WinRT 向けに書かれた新しいアプリです。

今回の記事は、それぞれ Fundamentals (基礎技術) チームと User Experience (ユーザー エクスペリエンス) チームのリード プログラム マネージャーである Sharif Farag と Ben Srour が執筆しました。

–Steven


Windows 8 におけるバッテリ寿命向上に向けた取り組みについては、既にいくつか記事を公開してきました。Pat Stemen の「電力効率と汎用性に優れた Windows の実現」では、System-on-a-Chip (SOC) ハードウェアで提供予定の、スマートフォンに似た新しい電力モード、Connected Standby (接続維持スタンバイ) についてお話ししました。「バッテリ消費を抑えながらライブ タイルの更新を行う」では、バッテリを浪費する背景的なアクティビティの発生を抑えつつ常に新鮮な情報をユーザーに届ける、ライブ タイルについてご説明しました。今回の記事では、実行中のアプリの機能を損なうことなく電力消費を最低限に抑えるために Windows 8 で行われたいくつかのイノベーションについて、新たにご紹介していきます。

Pat の記事にあるように、CPU、ディスク、メモリ等のリソースはそれぞれ対応する電力コストを持つため、これらを消費するアプリケーションも、電力消費量に影響します。このため、アプリケーションをアクティブに使用している間は必要なだけのリソースを与え、他のことをしている間はリソース使用量を必要最低限のレベルに抑えることが重要になります。これはもちろん OS そのものにも当てはまることです。Pat の記事でもこれについて一部触れましたが、実はこの分野では何百もの細かい改良が施されています。OS のリソース使用量とアクティビティを抑えるこれらの取り組みを、私たちは "電力衛生" 面での改良と呼んでいます。ただしこれらの改良については、手を加えすぎてユーザーが期待する機能性を損なうことがないよう、注意を払いました。たとえば、ユーザーがなんらかのアクティビティを開始してから別のアプリケーションに切り替えた場合、そのアクティビティは完了させる必要があります。

たとえば、ライブ タイルについての記事に対して、ItsMe さんから次のようなご質問をいただきました。

"バックグラウンドでのコピー ジョブはどうでしょう。たとえば Word 文書を読み書きするためにエクスプローラーをバックグラウンドに回したら、まさか再度エクスプローラーを全画面表示するまでコピー ジョブも中断するということですか?"

このご質問に対する答えはノーです。もちろんファイル コピーは従来どおりに扱われます。コピー ジョブを開始してから他のアプリケーションに切り替えてもコピーが中断されることはなく、バックグランドで処理が続行されます。これは、PC の使用を続けた場合でも、スクリーン セーバーやロック画面が表示されるまで放置した場合でも同様です。アクティブでなくなったアプリが中断されるのは Metro スタイル アプリの場合だけで、ファイル コピーのような OS の基本的な機能は対象外です。

フォアグラウンド処理への注力

Windows 8 では、まず大多数の Metro スタイル アプリが対象となるルールを決めました。アプリが画面上に表示されていない場合や、画面がオンになっていない場合は、アプリはバッテリを消費するべきではない、というものです。これは、WinRT やユーザー モデルからマルチタスクという概念がなくなっているいう意味ではありません。現代的なハードウェアの能力、ネットワーク接続への需要、フォーム ファクター、信頼性/セキュリティ/プライバシーをコードに反映する方法やするべき場面についての考え方は、変わってきています。例外はありますが (たとえばバックグラウンドでのメール同期やデスクトップ ツールなど)、多くのケースでは、アプリの作業のほとんどはユーザーがアクティブに操作をしているときに行われるものと思われます。このため、フォアグラウンドにないアプリでは、処理を完全に中断するか、アプリから使用できる共通のバックグラウンド機能群 (ファイル コピーなど) を用意し、これらに沿ってリソースを限定的に使用させることを目指しました。

よって、アプリには基本的に次の 3 つの状態があることになります。

  1. フォアグラウンドでアクティブに実行されている状態
  2. バックグラウンドで中断している状態
  3. 定義済みのバックグラウンド処理を行っている状態    
フォアグラウンドでアクティブに実行されている状態

アプリをフォアグラウンドでアクティブに実行している場合、特に難しいことはありません。アプリは通常どおり実行され、CPU、ディスク、メモリ、その他のリソースを必要なだけ使うことができます。この点では Metro スタイル アプリは従来の Windows アプリケーションとなんら変わりありません。これには、単一のアプリを全画面表示で実行している状態も、スナップ機能によって画面に 2 つのアプリを並べている状態も含まれます。また、この状態は画面がオンになっている場合にのみ当てはまります。画面がオンになっていなければユーザーが PC を操作しているとは見なされないためです。

高速で応答性に優れたアプリを開発するにあたっては、考慮するべき要素はたくさんあります。文字ベースのプログラミングから GUI プログラミングに移行する際は、さまざまなコンセプトの根本的な違いを乗り越える必要がありましたが、これと同様に、電力やリソースの消費量を意識したアプリの開発には、いくつかの新しいアプローチが必要となります。たとえば Windows プログラミングの初期の頃には、WNDPROC という概念を嫌い、割り込みをトラップしてキー入力を直接解釈する方が良いと考えるプログラマもいました。メッセージ ベースのアプローチはこれを覆すもので、解釈は Windows が引き受け、アプリがキー入力を意識する必要があるときは Windows がそのことをアプリに通知するという、従来とはかなり異なる図式でした。市場に出る PC の 75% がバッテリ駆動となった現在、プログラマにアプローチの再考が求められるのは当然と言えるかもしれません。

こういった背景から、ハードウェアの進化やユーザー ニーズの変化を意識し、将来を見据えてアプリ開発を考えることが重要になります。ユーザーが求める節電性能やバッテリ寿命を実現するため、既存のアプリケーション モデルを進化させることが求められています。もちろん、繰り返し述べてきたとおり、現在お持ちのデスクトップ アプリケーションは、Windows 8 でも Windows 7 とまったく同じように動作し、動作が改善されている点さえ数多くあります。しかし長期的には、Windows はより小さな電力でより多くを達成できるような形に向かっています。エンターテインメントからプロフェッショナルの作業、そしてその間のありとあらゆる使用シーンにおいてそれを実現するのは、さまざまな新しいアプリケーションです。処理に利用できるリソースも、必要とされるリソースも、行われる処理の種類も、変貌しつつあります。Windows 8 は、この機会を活かせるような新しい機能の提供を目指すものです。

フォアグラウンド ベースのアプローチで、すばやく滑らかで応答性に優れたアプリを開発するにあたっては、同時実行が重要な要素となります。//build/ カンファレンス (英語) では、新しいツールや API を使った高度な同時実行性を持つアプリケーションの開発についてご紹介しました。これによって、さまざまなシナリオをコード化する際の考え方の幅が広がります。たとえば、バックグラウンド処理を行うために別個のアプリを必要のないときも常時実行しておくのではなく (これはバッテリの浪費につながります)、代わりに新たに提供される OS のバックグラウンド タスク (英語) インフラストラクチャを活用して、電力効率に優れた方法で必要なバックグラウンド処理を行うことができます。バックグラウンド タスクはさまざまな方法で呼び出しが可能で、プッシュ通知や時間指定イベントのほか、ネットワーク データの受信によっても呼び出すことができます。さらに、PC がコンセントにつながっていることを自動認識し、アプリのバックグラウンド処理の頻度を上げることも可能です。コードを常時実行するのではなく、必要なときにだけ実行することになるため、バッテリ寿命の面で総合的に大きなメリットがあります。たとえばニュースリーダー アプリで、アプリを起動すると最新のコンテンツがすぐに利用できるよう、PC がコンセントにつながっている夜中のうちに自動的にコンテンツをダウンロードしておく、というような動作が可能です。しかも、これによってタスクを完了するための能力が制約を受けることは一切ありません。重要なシステム リソースに対する影響を最低限に抑えつつタスクを完了させる、新しい方法です。

アプリのコードをバックグラウンドで処理する方法を改善したことに加え、非同期プログラミングがより簡単で強力なものとなるよう、ツールのインフラストラクチャと WinRT の API にもさまざまな改良が施されています。高速で応答性に優れたアプリは、非同期プログラミングという強固な基盤によって実現されます。//build/ カンファレンスのメイン セッションで、Anders Hejlsberg が大規模なアイテム カタログの閲覧に使用する WinRT による非同期的なユーザー エクスペリエンスを披露 (英語) していますが、このようなテクニックを活用することで、アプリで優れたシナリオや優れたフォアグラウンド パフォーマンスを実現すると共に、バッテリ寿命を延ばすことができます。

バックグラウンドで中断している状態

アプリを起動してから他のアプリケーションに切り替えると、元のアプリは中断されます。これが第 2 の状態です。この状態になると、Windows スケジューラ (プロセスやスレッドの CPU アクセスのスケジュール設定を行うコンポーネント) はそのアプリを CPU スケジュールに含めなくなります。オペレーティング システムがスケジュール設定しなければ、そのアプリは CPU を使用しないため、CPU を低電力状態にすることが可能になります。CPU を低電力状態にすることは、バッテリ寿命を改善するうえで非常に重要です。これはアプリのデバッグを行っている際にプロセスを "一時停止" させた状態とよく似ているため、開発者にとっては親しみのあるアプローチかもしれません。つまり、そのアプリの実行中のスレッドがすべて停止した状態です。アプリを中断した場合も、これと似たような、キャッシュされた状態になります。アプリの初期化は完了しているため、瞬間的にアプリを切り替えできるメリットがあります。アプリがフォアグラウンドに戻ったときには、オペレーティング システムのスケジューラが許可するだけで、アプリの処理を再開することができます。

この新しいアプリ中断状態の優れた点は、再度アクティブにしたときに即座に使用できるという点です。中断中のアプリに切り替えると、アプリが即座に再開し、中断したときとまったく同じ状態に戻ります。これによって、これまでの Windows ではあり得なかったほどすばやく、多数のアプリを切り替えることが可能になっています。PC 上でいくつアプリが動いているかを気にする必要はなくなります。状況を常時表示できるライブ タイルと、アプリの状態を保存/復元できる機能により、優れたアプリを常に実行中であるかのように扱うことができます。

たとえば、今後乗る予定の飛行機のフライトを管理するアプリがあったとします。ライブ タイルの通知によって、アプリが中断されていても、バックグラウンドで実行されていない場合であっても、次のフライトのステータスが表示されます。アプリに切り替えると、最後に使用したときの状態 (たとえばフライトの検索画面など) に、まるで使用を中断していなかったかのように戻ることができます。アプリが実行中かどうかという概念が抽象化されたため、アプリの起動とアプリへの切り替えは基本的に同じものとなっています。切り替えの方法がバック スタックであっても、Alt + Tab であっても、[Start] (スタート) 画面であっても、中断中のアプリには即座に戻ることができます。

このため、"実行中" のプログラムのリストは、実用的な意味では [Start] (スタート) 画面に表示されるプログラムのリストと変わりないことになります。なお、キーボード ユーザー向けの情報ですが、Alt + Tab では Windows 7 とまったく同じように実行中のアプリケーションを切り替えることができます。また、デスクトップ アプリの場合はタスク バーもまったく同じように動作します (さらにマルチモニター シナリオでの挙動には改良も施されています)。

アプリ中断のメリットは、バッテリ寿命やシステムのパフォーマンスに悪影響を与えることなく、非常にすばやいアプリ切り替えが可能な点にあります。起動に時間のかかるアプリに合わせてワークフローを最適化することが一般的だった従来のデスクトップ アプリとはまったく異なります。

一般に、バックグラウンド処理を行っていないアプリが中断されないケースは 2 種類あります。1 つ目は、現在ログインしているセッションでまだアプリを起動していない場合です。この場合はタイルをタップしてアプリを起動する必要があります。2 つ目のケースはもう少し興味深いものです。メモリ残量が少なくなってくると、中断中のアプリをシステムが自動的に終了させることがあります。メモリは有限なリソースであり、最も頻繁に使用しているアプリがすぐに反応できるようにすることを優先する必要があります。しばらく使用していないアプリがあるときに、オペレーティング システムでメモリが必要になると、中断中のアプリが終了されます。実際にこの動作が発生することは多くないはずです。メモリ マネージャーが中断中のアプリをディスクに保存するためです (ディスクは通常、物理メモリよりも容量に余裕があります)。この場合、再度これらのアプリに切り替えれば、すぐに使用することができます。しかし、中断中のアプリを終了することが必要なケースもあります。これは主に、1 つの PC に複数のユーザーがログインしている場合や、メモリ使用量の多いアプリを多数使用している場合などです。

アプリを自動的に終了する際は、アプリが最後に使用された日時や、アプリが占有しているメモリの量など、複数の要素が考慮されます。ユーザーがなるべくいつでも中断中のアプリに戻れるよう、オペレーティング システムによるアプリの自動終了はあまり発生しないことが理想的です。ただし、中断状態のアプリが終了されても、実質的な影響はかなり小さなものです。アプリ モデルの進化により、使用中にインクリメンタルに状態を保存したり、再起動した際に保存した状態を復元したりすることが可能なアプリの開発が容易になっているためです。たとえばフライト管理アプリの場合、別のアプリに切り替える際にフライト検索ページを表示していたことを記憶しておき、ユーザーが戻ってきた際には、たとえアプリが自動終了されていたとしても、記憶した情報を使って同じ状態を復元することが可能です。

ここで強調しておきたいのは、メモリを消費するアプリがいくつもバックグラウンドで中断されていても、PC のパフォーマンスやバッテリ寿命に悪影響を与えることはないという点です。実際のところ、ユーザーが直接的にアプリを管理したり閉じたりする必要はまったくありません。これは現在さまざまなコンピューティング デバイスで採用されているアプローチで、オペレーティング システムの設計に対する現代的な見方を反映したものです (一例として、iOS でのマルチタスク処理に関する Frasier Spears 氏のブログ記事 (英語) をご覧ください)。

パフォーマンスやバッテリ寿命を改善する目的でアプリを閉じる必要はないものの、まもなく公開される Windows 8 のベータ版でも、アプリを閉じることは可能です。アプリの状態が悪くなったときや、単に使い終えたアプリを視界から片づけたいときは、閉じる必要があるためです。アプリを閉じる操作は、マウス、タッチ操作、キーボード ショートカットのどれでも可能です。この点に関して行われた変更については、ベータ公開後に補足記事を投稿予定ですので、ぜひご注目ください。

Developer Preview ビルドでは、Stock、News、Weather などの付属アプリをいくつか起動してから新しいタスク マネージャーを開けば、アプリが中断された状態を確認することができます。CPU 使用率が 0% と表示されることにご注目ください。これは、アプリはメモリに読み込まれているものの、基本的には休眠状態にあるためで、この状態のアプリは、バッテリ寿命やパフォーマンスに悪影響を与えることはありません。

タスク マネージャーに Metro スタイル アプリが表示されており、そのうちのいくつかは [中断] と表示され、CPU 使用率が 0% になっている

Metro スタイル アプリはバックグラウンドでは中断状態となる

バックグラウンド処理を行っている状態

既に触れたとおり、開発者には、従来はバックグラウンド処理で行っていた作業を、バッテリ寿命に悪影響を与えることなく実現する方法を検討することが求められています。マルチタスク処理を求めるのも、単純にマルチタスク処理を有効にするのも容易なことですが、アプリが常にバックグラウンドでタスクを実行し続けていた場合、バッテリの長寿命化は無理な相談です (バッテリ寿命を改善することさえ難しいでしょう)。モバイル化と常時接続が進んだノート PC 中心の時代において、これは非常に重要なことです。そこで、Windows 8 と WinRT では、Metro スタイル アプリのバックグラウンド処理 (英語) を扱う新しい API 群を用意しました。

前述のように、デスクトップ アプリは従来どおりに動作しますが、一方で、バッテリ消費量の面でも現状どおりになります (ただし以下でご説明するように一部では改良が施されています)。

Windows 8 では、ユーザーが Windows に期待するようなリッチなアプリ性能やマルチタスク処理と、リソース使用量の節約とを、バランスよく両立することを目指しました。これを実現するため、対応するべき主要シナリオをリストアップし、それぞれについてリソース面で最も効率よく遂行する方法を模索しました。結果として得られた、バックグラウンドでのマルチタスク処理用の API 群により、アプリはリソースや電力の面で効率の良い方法でバックグラウンド処理を行うことができ、アプリ開発者は大量に余分な作業を強いられることなくアプリの中心的な機能に注力できるようになっています。

アプリがバックグラウンドで行う必要のある最も一般的なタスクを可能にするため、シナリオ ベースのアプローチで検討を行いました。WinRT において、Metro スタイル アプリがバックグラウンドで行うことのできるタスクは次のとおりです。

  • 音楽の再生
  • Web サイトからのファイルのダウンロードと Web サイトへのファイルのアップロード
  • ライブ タイルによる最新のコンテンツの表示
  • 印刷
  • VoIP 通話の受信
  • インスタント メッセージの受信
  • 電子メールの受信
  • コンテンツの共有 (Facebook への写真のアップロードなど)
  • テザリングされたデバイスとのコンテンツ (たとえば写真) の同期

これらのシナリオは、開発者が一般的に使用するパターンや、一般的に見られると予想されるパターンに基づいて選定されたものです。いくつかのシナリオでは結果として同じプラットフォームのアフォーダンスを使用することになりますので、Windows 8 の全体像とパワーを把握していただけるよう、それぞれ見ていきましょう。

シナリオ

説明

バックグラウンドでのダウンロード/アップロード

インターネット上のコンテンツにアクセスしたり、コンテンツをインターネット上に保存したりすることは、アプリにとってかなり一般的なシナリオです。アプリに切り替えたときに、できる限り最新のコンテンツがあらかじめ読み込まれていることが理想的です。これは雑誌やニュースをベースとするアプリで特に有効と思われます。アプリは新しいバックグラウンド転送 API (英語) を使用して、アップロードやダウンロードをバックグラウンドで行うことができます。この API は "完全仲介型" と呼ばれるもので、アップロードやダウンロードを OS 自体が行います。これによってアプリのコードを枠外に置くことができるため、バッテリ寿命を最大限に延ばすことができます。

バックグラウンド オーディオ

同時に複数のことを行うことが現実的なケースももちろんあります。音楽を聴きながらほかのことをするというのはその良い例でしょう。メディア アプリやコミュニケーション アプリはバックグラウンドでオーディオを再生 (英語) することができます。効率性を最大限に高めるため、オーディオを一時停止するとアプリも中断するようになっています。

共有

アプリが [共有] チャームを使ってクラウド サービスにコンテンツを送信している途中だった場合、バックグラウンドでもその処理を完了できるようになっています。

ロック画面に表示するアプリ

ロック画面に表示するアプリでは通常、最新の情報をユーザーに通知する必要があり、これはアプリを使用していないときを含めていつでも起こり得ることです。最も一般的な例としては、電子メール、VoIP、IM などのアプリが挙げられるでしょう。ロック画面に表示するアプリは、バッテリ駆動時にバックグラウンドにあっても、また画面がロックされた状態でも、通知の表示やデータの同期を行うことができます。

印刷

ドキュメントの印刷は、印刷を行うアプリがバックグラウンドに移動された場合も行うことができます。

デバイスの同期

PC と接続したデバイス (たとえばカメラ) との同期は、アプリが画面上に見えていない状態でも行うことができます。

Windows 通知サービス (WNS) を使ったライブ タイル

アプリは Windows 8 PC にプッシュ通知を送ることで、アプリのライブ タイルに最新のコンテンツを提供し、(中断された状態でも) 常時動作しているような印象を与えることができます。

スケジュール設定された通知

アプリは、特定の時間にタイルを更新したり (例: 予定表に登録した用件の表示)、オフィスを出る前に片づける必要のある用事についてデスクトップに通知を表示したりすることができます。これらのイベントのスケジュール設定はアプリが行いますが、通知の表示は Windows が担当するため、バッテリへの影響は最低限に抑えられます。

バックグラウンド タスク

アプリは特定のイベントに応じてコードを実行する (英語) ことができます。たとえば、一定の頻度で実行することや、Windows や IM サービスにサインインしたときに実行することが可能です。ロック画面に表示するアプリでは、15 分ごとにコードを実行することができます。それ以外のアプリでは、A/C 電源に接続されている場合に 15 分ごとにコードを実行するよう設定することができます。

Connected Standby (接続維持スタンバイ) とスリープ対応マシン

Windows 8 リリースの頃には、これまでにないほど多様な PC が市場に出ていることが見込まれます。これらの多くでは、今日の Windows 7 マシンと同様の電源オプションが利用できます。完全な電源オフのほかに、ユーザーの操作に応じて、または一定時間アイドル状態に置かれることで、"スリープ" 状態に移行するというものです。スリープ中は、システムのアクティビティはすべて中断されます。

電力消費の状態は、0 ~ 60 秒では画面オン、60 ~ 120 秒では画面明度低下、120 ~ 180 秒では画面オフ、180 ~ 240 秒ではスリープ (S3)。デスクトップ アプリは 180 秒まで実行されたままで、PC がスリープ状態になると停止する。Metro スタイル アプリは 180 秒まで OS によって状態を管理され、PC がスリープ状態になると停止する。

スリープ対応 PC でのアプリケーションの実行状況 (初期設定)

上のグラフにあるとおり、PC がスリープ状態に入る直前のアイドル時には、デスクトップ アプリは従来の Windows と同じように実行中のままとなるのに対し、Metro スタイル アプリは前述のように OS によって管理されています。PC がスリープ状態に入ると、デスクトップ アプリも Metro スタイル アプリも完全に中断されます。バッテリ寿命の面ではこれは優れた対応です。スリープ状態のマシンでは、電力消費量は非常に少なくなります。しかしデータの鮮度という面ではやや見劣りします。スリープ状態のマシンでは、ライブ タイルの更新や新着メールのダウンロードは行われず、アラームやその他の通知の準備も行われません。

Pat が記事で説明したように、Windows 8 では、完全にオフにされることがめったにない新しい層の PC 向けに、スマートフォンに近い新たな電力状態が提供されます。通常は "System-on-Chip" (SoC) アーキテクチャがベースとなるこれらの PC では、非アクティブ時に完全にオフになる代わりに、オンのまま消費電力の非常に小さい状態に移行することができます。Connected Standby (接続維持スタンバイ) と呼ばれるこの新しい電力状態では、ネットワーク接続を活かしたさまざまな優れたシナリオが可能となります。たとえば、電子メールの常時取得、インスタント メッセージや電話の受信などに対応しつつ、驚異的なバッテリ寿命を実現することができます。下のグラフは、Connected Standby (接続維持スタンバイ) 状態でのデスクトップ アプリと Metro スタイル アプリの挙動を示したものです。このしくみを効果的に機能させるためには、前述のとおり非常に効果的にシステム リソースの節約が可能な Metro スタイル アプリだけではなく、デスクトップ アプリについても考慮する必要がありました。デスクトップ アプリは長年にわたり、システム リソースをすべて利用できる状態 (フォアグラウンドまたはバックグラウンドでの実行時) とまったく利用できない状態 (PC のスリープ時) の 2 種類だけを前提に設計されてきたため、Metro スタイル アプリよりも扱いが困難でした。

電力消費の状態は、0 ~ 60 秒では画面オン、60 ~ 120 秒では画面明度低下、120 ~ 180 秒では画面オフ、180 ~ 240 秒では Connected Standby (接続維持スタンバイ)。デスクトップ アプリは 180 秒まで実行されたままで、PC が Connected Standby (接続維持スタンバイ) 状態になると停止する。Metro スタイル アプリは、PC が Connected Standby (接続維持スタンバイ) 状態になっているときを含め、常に OS によって管理される。

Connected Standby (接続維持スタンバイ) 対応 PC でのアプリケーションの実行状況

これを実現するため、Windows 8 では、Connected Standby (接続維持スタンバイ) 対応の新しいプラットフォーム専用に "Desktop Activity Moderator" と呼ばれるコンポーネントを追加しました。このコンポーネントは、デバイスが Connected Standby (接続維持スタンバイ) 状態になったときにデスクトップ アプリのリソース使用量を削減するためのものです。新しい低電力状態に入ったときにアプリがそのまま無制限に処理を続行した場合、PC のバッテリはすぐに消耗してしまいます。そこで、デスクトップ アプリケーションを中断させてリソース使用を停止し、バッテリ寿命を最大限に延ばす対応をとっています。アプリケーションからは、PC が従来のスリープ状態に入ったのと同じように認識されます。PC が Connected Standby (接続維持スタンバイ) から復帰すると、従来のスリープからの復帰時と同様にアプリも再開されます。

ただし、実際には Connected Standby (接続維持スタンバイ) に必要なシステム上のコンポーネントがいくつかあり、これらは中断させることができません。これにはドライバー、一部の同梱およびサード パーティ製サービス、そしてもちろん前述のバックグラウンド処理機能を利用する Metro スタイル アプリが含まれます。これらの多くは、ユーザーがデバイスの使用を再開したときにユーザーの入力に対応する機能や、ネットワーク関連の機能を提供するものです。Connected Standby (接続維持スタンバイ) 中の実行が許可されるコンポーネントは、バッテリ寿命への影響を注意深く評価したうえで選定されています。このほかに、システムのアクティビティに対応して稼働する必要のあるプロセスがいくつかあります。こういったプロセスは、特定のバックグラウンド アクティビティが発生するまではごく限られた時間枠でしか実行されませんが、アクティビティが発生すると制約なしで実行を許可されます。システムで発生したアクティビティに対応してスキャンを行うことの多いウイルス対策ソフトウェアはその好例と言えます。バックグラウンドのアフォーダンスを経由した電子メールの受信などのバックグラウンド アクティビティが発生すると、ウイルス対策ソフトウェアはその間だけ制約なしで処理を行うことができます。一方、ほとんどの時間はネットワークからのデータ受信アクティビティが発生しないため、その間はこれらのコンポーネントの処理はバッテリ寿命に影響しないよう抑制されます。

まとめ

ご覧いただいたとおり、Windows 8 のエンジニアリングにおいてはバッテリ寿命向上のため大幅な投資が行われています。新しく開発されたアプリケーション モデルが、ネットワーク接続を活用したエクスペリエンスを提供しつつ、安定して優れたバッテリ寿命を実現します。Windows 7 向けに設計されたアプリケーションには挙動の変化はなく、従来どおりの動作が可能です。一方で、新しい Metro スタイル アプリでは、オペレーティング システムが提供するバックグラウンド インフラストラクチャを活用することで、ネットワーク接続を活かしたエクスペリエンスを、優れた電力効率で実現することができます。

-- Sharif Farag、Ben Srour