Windows Store 開発者向けブログ
Windows 8 アプリ開発者ブログ
IEBlog 日本語
Windows チームの各ブログ (英語)
Inside Windows Live ブログ (英語)
Windows 8 Consumer Preview をダウンロード
Dev Center - Metro スタイル アプリ
@buildwindows8 をフォロー (英語)
Build Windows カンファレンス (英語)
Windows 8 Consumer Previewフォーラム
Windows Metro スタイル アプリ
Windows 8 のエンジニアリングの根本的な原理は、メモリ使用量などの基本的な部分に表れています。Windows 8 を構築するにあたって、私たちはコア システムが必要とする全体的なランタイム メモリの量を大幅に減らすことを目指しました。これはだれもが望んでいることですが、いくつものアプリを同時に実行したいユーザーや、メモリが 1 ~ 2 GB しかないシステムを使っているユーザーにとってはなおさらです。この投稿では、メモリが 1 GB しかない第 1 世代の ATOM ベースのネットブックを例に取り上げます。これは、2008 年の Windows 7 PDC で取り上げたものとまったく同じものです。メモリ使用量削減への私たちの取り組みを詳しく説明するこの記事は、Performance (パフォーマンス) チームのグループ プログラム管理者である Bill Karagounis が執筆しました。--Steven
Windows 8 のシステム要件や Windows 8 をホスティングするデバイスを決めるうえで、Windows 8 のランタイム メモリ使用量は重要な要因となります。皆さんもご存じのように、Windows 8 では、低い電力消費量が特長の SoC ベースのデバイスでも完全なエクスペリエンスを提供するため、複数のアプリを同時に実行したり、デバイスの全体的な応答性を持続させるために多くのメモリを確保することは、より重要な課題になっています。
つい見落としてしまいがちですが、省電力プラットフォームでメモリ使用量を最小限に抑えることは、バッテリの長寿命化につながります。つまりどういうことでしょう? どのような PC でも、常に RAM が電力を消費しています。OS が大量のメモリを使用するようになれば、デバイス メーカーはより多くの物理 RAM を搭載せざるを得なくなります。より多くの RAM がボードに搭載されると、その消費電力も増加し、バッテリの寿命は減ってしまいます。たとえばタブレット デバイスに搭載されている RAM が増えれば、コーヒー テーブルに放置されている間も最新の情報を取得しつつ待機しているタブレットのバッテリー寿命が、場合によっては何日も短くなってしまうのです。
開発当初からの Windows 8 の目標は、システム要件を Windows 7 と同じにすることでした。メモリの使用効率をさらに向上させることができれば、公式なシステム要件が同じでも、より多くのリソースをアプリ用に確保することができるでしょう。2009 年の、いわゆる "ロー エンド" のハードウェアの仕様はどのようなものだったかを考えると興味深いものがあります。256 MB メモリのモジュールなど、今やどこを探しても見つかりません。私たちは Windows 7 時代のハードウェアを使用しているユーザーが簡単に既存のマシンを Windows 8 にアップグレードし、新しい機能を活用できるようにしたいと考えました。また、パフォーマンス テスト環境にはあえて古いマシンも残しているのですが、そこで得られた結果からすると、Windows 7 以前のマシンの多くでも十分に Windows 8 を実行できる見込みです。
Windows 8 開発における重要な使命の一つとして、既存の機能が使用するメモリや全体的なメモリの消費量を減らす方法を模索しながら、新しい機能のためのリソースを確保するということがありました。私たちが自ら設定したこの目標に向かって、Windows 8 の開発は順調に進みつつあります。
Windows 8 と Windows 7 のメモリ使用を大まかに比較する最も簡単な方法は、両方のオペレーティング システムを 1 GB RAM マシン (OS の RAM の最小要件) にインストールして、何度か再起動した後にしばらくアイドル状態にしてから使用メモリを比較することです。
Windows タスク マネージャーのメイン ビューには、"使用中" のメモリの統計値に基づいた、システム メモリの使用率が表示されます (このドキュメントに詳細が記載されています)。以下の画像は、Steven が先日の //build/ 基調講演で使った、3 年ものの古いネットブックで Windows 7 を実行してアイドル状態になっているときと、同じマシンで Windows 8 を実行したときのメモリ消費量を比較したものです。
図 1 - Windows 7 SP1 のメモリ使用率
図 2 - Windows 8 のメモリ使用率
マシンを構成するハードウェア、ドライバーのメモリ使用状況、さらには稼働時間もばらつきの原因となるため、メモリ使用率はマシンによって (または同じマシンでもタイミングによって) 変わりますが、ご覧のとおり Windows 8 は Windows 7 よりも優れたパフォーマンスを見せています。
テスト マシンについて、もう 1 つおもしろいことをお教えしましょう。デバイス マネージャーで、ディスプレイ アダプターを無効にしてみてください (グラフィック ドライバーがアンロードされます)。通常、このような状態でマシンを実行することはありませんが、こうすることによって、Windows 自体のメモリ使用率をより正確に把握することができます。上記マシンのグラフィック ドライバーを無効にして、しばらくアイドル状態にしておくと、使用メモリは 200 MB よりも少なくなります。
メモ: Windows 8 には、クリーン インストールの状態でも、機能が拡張された Windows Defender テクノロジが含まれています。マルウェアからのユーザーの保護についての Jason のブログにもあると���り、このテクノロジには初めて完全なマルウェア対策機能が組み込まれ、さらに、使用するメモリおよびリソースも最適化されています (この機能は Windows 7 のクリーン インストールには含まれていません。Windows 7 にはセキュリティ ソフトウェアをインストールすることをお勧めします)。
Windows 8 では、OS の使用メモリを最小限に抑えるために何百もの変更が行われています。中でも大幅なメモリ使用量削減につながったものをいくつかご紹介したいと思います。
稼働中の標準的な PC の RAM のコンテンツを調べてみると、メモリの多くの部分が同じコンテンツを含んでいます。システム RAM に保存されたデータに重複があるということは、サービスや OS コンポーネントにさえ使用メモリを削減する余地があることを意味します。
では、どうすれば削減できるのでしょう。アプリケーションが、後で使用するためにメモリを割り当て、すべて同じ値に初期化している場合があります。しかし、ユーザーが結局その機能を呼び出さず、あらかじめ割り当てたメモリが使用されずに終わることもあります。実行中の複数のアプリケーションが同時にこのような割り当てを行うと、システム内に重複する内容のメモリが複数存在することになります。
メモリの集約とは、通常のアクティビティの実行中に Windows がシステム RAM の内容を効率的に分析し、システム メモリ全体にわたって重複する内容を検出する手法です。検出された重複部分は解放され、同じ内容は 1 つだけ確保されます。その後、実際にメモリへの書き込みが必要になれば、Windows はそのアプリケーション専用に同内容のコピーを作成し、割り当てます。この作業はすべてメモリ マネージャーが舞台裏で行い、アプリケーションに影響が出ることはありません。この手法により、10 MB ~ 100 MB 単位でメモリを解放することができます (解放できる量は同時に実行されているアプリケーションの数によって異なります)。
常に実行するよう構成されている OS サービスは、背景的なメモリ消費のかなりの部分を占めます。Windows 8 の計画時に OS サービスを評価した結果、13 のサービスを削除し、一部のサービスを "手動" によって開始するようにしたほか、"常に実行中" だったサービスの一部を "オンデマンドによる開始" モデルに変更することにしました。このモデルでは、OS の "トリガー" (デバイスが接続される、ネットワーク アドレスが利用可能になる等) が発生すると、次の動作が行われます。
プラグ アンド プレイ、Windows Update、およびユーザー モードのドライバー フレームワーク サービスが、Windows 7 では常に実行中であったのに対し、Windows 8 では、すべてトリガーによって開始されることにお気付きになるでしょう。
もちろん Windows 8 では数多くの新機能 (および新しいコード) も追加されています。その一部は新たなサービスという形で組み込まれていますが、このうち自動的に開始されるのは 2 つだけで、それ以外はすべて手動またはトリガーによって開始されるサービスとなっています。
Windows がアプリケーションを実行し、システムのハウスキーピング処理を行う際に、プログラム ファイルおよびデータはディスクからメイン メモリに読み込まれます。Windows 7 および Windows 8 の開発過程を通じて現在まで、私たちは通常の実行時のメモリの断片 (ページ) を分析し、これらがどのくらいの頻度で参照されるのかを調べてきました。ここで基本となる考え方は、メモリ ページの割り当てというコストがかかる以上、使用 (参照) 頻度もそれに見合ったものでなければならない、というものです。必要ではあるものの使用頻度がそれほど高くないのであれば、他のものと統合すればいいのです。
Windows 7 のリリース後間もなく、NT の黎明期 (1990 年代初頭) から使用されている Windows の低レベルのコンポーネントの一部に対して、似たような手法を使ってみました。具体的には、コードを再設計し、データ構造を変えることにより、メモリの "ホット" な (頻繁に参照される) 部分と "コールド" な部分を完全に分離しました。ホットなアイテムを密に統合することにより、全体的なランタイム メモリ使用量を削減することができました。
OS に対する低レベルでの変更という性質上、スケジュールのなるべく早い段階で作業を終えて、変更の検証に十分なだけのランタイムを確保する必要がありました。結果として Windows 8 には早期からこの変更が組み込まれ、現在までにほぼ 2 年間にわたり、何千人ものマイクロソフトの従業員が日常業務に使用してきています。そして、平均的なマシンで使用メモリが何十メガ バイトも削減されるという、安定した結果が出ています。
今年の 6 月、Steven と Julie が Metro スタイル UI を初めて披露しました。タブレット ユーザーの多くは、主にこの環境で、Metro スタイルのアプリを中心に Windows を活用されることと思いますが、同じデモの中で、Windows 8 では既存のアプリケーションを使い慣れたデスクトップ環境で使用できるという点もご紹介しました。
ユーザーがほとんどの時間を没入型の Metro スタイル UI を使用して過ごすデバイスが出てくるだろうということに、メモリの観点から注目しました。この場合 Windows 8 では、デスクトップ環境に特化した OS コンポーネントの初期化を、必要なときにしか行いません。これもメモリ使用量の削減に役立っており、現時点でおよそ 23 MB の節約となっています (タスク マネージャーはデスクトップで実行されるため、上の画像の数値にはその分のメモリ使用量も反映されています)。
アプリケーションやシステム コンポーネントによるメモリ割り当ての優先度設定についても、Windows 8 では枠組みが改良されています。つまり、どのメモリを確保し、どのメモリを解放すべきかについて、Windows がより適切な判断を下すことができるようになっているのです。
たとえば、ウイルス対策プログラムは、他のプログラムがファイルを開こうとすると、そのファイルに対してさまざまなチェックを行います。ウイルス対策プログラムがウイルス署名をチェックするために割り当てるメモリは、通常は一回限りのものです (そのメモリが再度必要になることは、ほぼあり得ません)。Windows 7 では、こういったメモリも、システム内の他のメモリ (たとえば、実行中の Microsoft Excel のインスタンスが割り当てたメモリなど) と同じ優先度で扱われます。メモリが不足してくるとメモリの解放が行われますが、実行中の他のアプリケーション (Excel など) の応答性確保に必要なメモリがその対象となってしまうこともあります。システムの応答性の観点から見ると最良とは言えない選択です。
Windows 8 では、どのプログラムもメモリを "優先度: 低" として割り当てることができます。これは Windows への重要なシグナルで、メモリ残量が逼迫したときには容量確保のためにそのメモリを解放しても問題がなく、システムの応答性を維持するのに必要な他のメモリには影響しないことを示すものです。
ここまで、Windows 8 における使用メモリ削減に向けた、私たちの哲学とアプローチをご紹介してきました。いくつかのサンプルの結果をご覧いただき、これまでにこの分野で行ってきたエンジニアリングの作業についてもわずかながら触れました。ここでお話しできなかったのは、Windows 8 のアプリケーション モデルと、新しい Windows 8 アプリをより "メモリ フレンドリ" なものにするために行われた、プロセス ライフサイクルへの変更点です。これも Windows の刷新の一環として非常に重要な部分ですので、//build/ のコンテンツ (英語)、および今後の投稿をご覧ください。
Windows の進歩はかなり長い道のりを歩んできましたが、まだ終わりではありません。どうぞご期待ください。
--Bill Karagounis