特集: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と同じなので、以下の連載記事を参照してほしい。

 簡単にいうと、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つの言語/フレームワーク


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

注目のテーマ

業務アプリInsider 記事ランキング

本日 月間
ソリューションFLASH