特集：WinRT登場で変わる開発技術と開発言語 Windows 8時代のアプリ開発とWinRT 岩永 信之 2012/06/01
Page1 Page2 Page3 Page4

■新API「WinRT」

　まず、WinRTの立ち位置について簡単に説明しておこう。図6に示すような、「振り子の真ん中」と考えると分かりやすいだろう。ネイティブから.NETへと、一度大きく振れた後、結局はその両者の中間くらいに落ち着いている。

図6: WinRTの立ち位置

　1990年代、ネイティブ（C++）での開発が中心だったころ、以下のような点が問題となっていた。

• メモリ管理が大変
• セキュリティ保証が大変
• 複数のCPUへの対応が大変
• COMの実装・利用が面倒

　そこで、2000年代に入って登場したのが.NETで、以下のような機能を備えている。

• メタデータ（共通型システム）
• 異なる言語間での連携や、バージョン管理のための型情報を持つ
• メモリ自動管理
• アプリでやりたいことに直結しない割に大変なメモリ管理を自動化する
• 中間コード
• CPUごとの最適化はフレームワークが行ってくれるため、各言語のコンパイラ作成者の負担が小さくなる

　ただ、2000年代の問題は、.NETに寄りすぎていたことである。.NET対応言語の間ではメタデータが有効に機能したが、その外の世界とのつながりは希薄だった。

　分かりきったことだが、手軽さを犠牲にしてでも、「手動メモリ管理」や「CPU依存の最適化」によって限界まで性能を引き出す必要のある部分が存在する。特に、OSに近い低層のAPIはほぼ必ずネイティブで書く必要がある。実際、2000年代には、まずネイティブでだけAPIが提供され、しばらく間を空けて.NETラッパーが公開されるということが多かった。

　そこで、2010年代に入った今、ネイティブと.NETの連携強化という形で、振り子の真ん中に落ち着くこととなった。

●言語プロジェクション

　言語間の連携強化は、図7に示すような、「WinMD」というメタデータ仕様によって実現している。WinMDは、ファイル形式的には.NETのメタデータと同じである。すなわち、.NETのメタデータを、.NET以外の世界にも広げたものだ。

図7: Windows Metadataによる言語間の連携強化

　WinMDのファイル形式が同じでも、WinRTコンポーネントとして言語をまたいで使うためには、以下のようないくつかの制限も存在する。

• 構造体はpublicなフィールドしか持てない
• クラスはsealed（継承不可）な必要がある
• ジェネリックは事前に定義されたIVector<T>（Windows.Foundation.Collections名前空間）などの型に限られる

　また、言語ごとにその言語らしい書き方ができるように、以下のような規約ベースの置き換えも行われていて、これを「言語プロジェクション」と呼ぶ。

• IVector<T>インターフェイスは.NETからはIList<T>（System.Collections.Generic名前空間）に見える
• メソッド名は、JavaScriptから参照する際には小文字始まりに変換される（例えば「GetX」であれば、JavaScriptからは「getX」で参照する）

○壁のない世界

　この言語プロジェクションは、「壁のない世界」を目指すものだといえるだろう。初心者と上級者の間に（1990年代のC++とVisual Basicの間のような）壁があってはいけない。サーバ開発とクライアント開発の間で壁があってはいけない。「言語が違うからできない」とか、「フレームワークが違うからできない」とかいう言葉が出てくるようではいけない。

　.NETの時代も、WinRTの時代も、マイクロソフトが目指すのはこの「壁のない世界」である。

　筆者の個人的な意見であるが、このメタデータ形式が「WinMD（Windows Matadata）」というように、「Windows」の名を冠するのは失策ではないかと思う。「壁のない世界」というのは、Windows／マイクロソフト技術に閉じていい目標ではないし、閉じる必要性もないものだろう。

●現代風に再設計したAPI

　ネイティブの復権があったといっても、古臭い昔ながらの状態に戻るわけではない。WinRTは、.NETでの経験を生かした現代的な設計になっている。ここでは、以下の3つの観点から説明していこう。

• オブジェクト指向API
• 非同期API
• XAML UI

○オブジェクト指向API

　.NETを参考にしているだけあって、WinRTのAPIはきっちりとオブジェクト指向になっている。リスト1に、WinRTの利用例（C#から利用）を示そう。

using (IRandomAccessStream readStream =   await sampleFile.OpenAsync(FileAccessMode.Read)) {   using (var dataReader = new DataReader(readStream))   {     var size = (uint)readStream.Size;     var bytesLoaded = await dataReader.LoadAsync(size);     var fileContent = dataReader.ReadString(bytesLoaded);   } }

リスト1: WinRT APIの利用例

　「IRandomAccessStream」や「DataReader」がWinRTの提供している型である。

　「.NETのライブラリ」といわれても分からないくらいだろう。WinMDのおかげで、P/Invoke のような面倒も必要ない。Variant型のような緩い型が出てこないのもありがたいところである。

○非同期API

　WinRTでは、50ミリ秒以上かかる可能性のあるAPIは非同期APIしか提供しない方針を取っている。

　時間のかかる処理をしている間、スレッドをブロックしてしまうのは、OSにとって思った以上に大きな負担となる。また、処理を待っている間、UIをフリーズさせてしまうと、エンド・ユーザーの印象は非常に悪くなる。時間のかかる処理に対して同期APIを提供しても、悪い結果しか招かないのである。

　非同期処理は面倒という問題もあったが、WinRTと同時期にリリースされる予定のC# 5.0／Visual Basic 11では、非同期処理を簡単化するための「非同期メソッド」という機能（async／awaitキーワード）が追加されている。実は先ほどのリスト1でも使っているが、await演算子を使うことで、同期処理とほぼ同じ書き方で、スレッドをブロックせずに非同期処理を行える機能である。

　非同期処理に関しては、以下の記事を参考にしてほしい。

• フリーズしないアプリケーションの作り方

○XAML UI

　WinRTでは、WPF／Silverlightから引き続き、XAMLを使ってUIを記述する。XAMLという仕組み自体はWPFやSilverlightと同じなので、以下の連載記事を参照してほしい。

• 連載：WPF入門
• 連載：次世代技術につながるSilverlight入門

　簡単にいうと、XAMLは以下のような目的を持っている（図8）。

• ツールとの連携
• 階層構造を表現しやすい
• 書けるものをUI関連に絞る

図8: XAMLの目的

　ちなみに、XAMLは、XMLタグからWinRTの（WPFやSilverlightでは.NETの）型のインスタンスを生成する仕組みで、型を作ることで自由にUI要素を追加できる。WinRTの場合は、WinMDを介することで、ネイティブ（C++）でも.NETでもUI要素を作れるようになっている。

　ここまで、技術選択するための視点でWindows 8やWinRTの特徴を説明した。次のページからは、そのWinRTによるMetroスタイル・アプリを採用すべきなのか、それとも従来のWebアプリやデスクトップ・アプリを採用した方がよいのかについて考察していく。

INDEX
	特集：WinRT登場で変わる開発技術と開発言語
	Windows 8時代のアプリ開発とWinRT
	1．Windows 8概要 - 多様化への対応
	2．新API「WinRT」
	3．Windows 8時代の多様な選択肢（1）：MetroとWeb／デスクトップの対比
	4．Windows 8時代の多様な選択肢（2）：選択可能な3つの言語／フレームワーク

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）