windows 8時代のアプリ開発
DESCRIPTION
第8回.NET中心会議「Windows 8時代の開発」基調講演資料TRANSCRIPT
まもなくやってくるWindows 8 時代のアプリ開発
岩永 信之
Windows 8
現在の状況と、来たる Windows 8
現在 とにかく多様化
ハードウェア x86/x64 と ARM デスクトップ / ノート PC 、 Slate 、 Phone
標準 vs プラットフォーム固有 間口の広さ ⇔ 表現力、性能、進化の速さ
言語・フレームワーク .NET 、ネイティブ( C++ )、 JavaScript
Windows 8/Windows RT ARM 対応、 Metro UI 、 WinRT
Windows 8x86/x64
Windows RTARM
CPUデスクトップ MetroUI
今まで通りの Windows• Win32 API を使う
提供はするものの…• Office などバンドル品のみ• 自由なアプリ配布無理
新環境• x86/x64/ARM 共通• ネイティブの場合、
3 バイナリ必要• WinRT API を使う• App Store 配布• 審査あり
Metro: 新 UI
デスクトップ(今まで通り)• マウスとキーボード操作• タスク バーとウィンドウ
Metro (新 UI )• タッチ向け UI• 全画面、フリックで切り替え
OK
☎1
Metro UI と WinRT
☎1OK
デスクトップ Metro
Win32
伝統の API
C 言語スタイル
WinRT
新 API
OOP スタイル
主に Metro 用呼べなくはない(あまり意味ない)
主にデスクトップ用 一部だけ許可( DirectX など)
Metro: XAML と HTML5 XAML か HTML5 で開発
Windows Kernel
WinRT ( Windows Runtime ) API
XAML HTML5
.NET C++ JavaScript
WPF や Silverlight と同じ開発スタイル 標準+ WinRT API
多様化に対するささやかな抵抗
言語プロジェクション 言語 / フレームワークを超えてコンポーネント共有
WinRTコンポーネント
C++, C#, VBで書ける
C++ アプリ
Pro
jectio
n
CLR
Pro
jectio
n
C#/VB アプリ
Chakra
Pro
jectio
nHTML+JavaScrip
tアプリWindows
Metadata
.NET のメタデータを.NET 以外の世界に広げたも
の
C++ で書かれていても、.NET からは .NET クラスに見
える
WinRT
.NET の反省点と、 WinRT
ネイティブと .NET と WinRT WinRT = 振り子の真ん中
1990 年代ネイティブC++COM
2000 年代.NETC#, VB, F#, …
2010 年代WinRTネイティブ /.NET/JavaScript 連携
ネイティブ時代の課題
• メモリ管理が大変• セキュリティ保証が大
変• COM 大変• 複数 CPU 対応が大変
ネイティブ
全部をネイティブで書きたくな
い
ネイティブ→ .NET
• メモリ管理が大変• セキュリティ保証が大
変• 複数 CPU 対応が大変• COM 大変
ネイティブ
• メタデータ• メモリ自動管理• 中間コード
.NET
.NET 時代の課題
低層 API は必ずネイティブ 連携が面倒 .NET 向けラッパーの登場までにタイムラグ
• メタデータ• メモリ自動管理• 中間コード
.NET
手軽さを犠牲にしてでも性能が欲しい場面は残る• メモリ手動管理したい• CPU 依存の最適化をした
い
.NET→WinRT メタデータの適用範囲を拡大
.NET とネイティブが対等 ネイティブ API が即 .NET から使える JavaScript にも対応
• メタデータ• メモリ自動管理• 中間コード
.NET ネイティブ JavaScript
メタデータ WinMD ( Windows Matadata )
ただし、現代風に再設計
言語プロジェクション 規約ベースで .NET/ ネイティブ /JavaScript 相互運
用 .NET の CTS (共通型システム)を、ネイティブと
JavaScript にも広げたもの WinMD ( Windows Metadata )
相互運用のために必要なメタデータ ファイル形式的には .NET のメタデータ仕様と同じ .NET と比べると使える型に制限あり
壁のない世界 壁があっちゃいけない
サーバーとクライアント開発で 初心者とプロで
言語が違うからできない フレームワークの作法が違うからできない
言語やフレームワークを超えた相互運用
WinMD ( Windows Matadata )
Not Only "Win" 壁があっちゃいけない
サーバーとクライアント開発で 初心者とプロで
言語が違うからできない フレームワークの作法が違うからできない
言語やフレームワークを超えた相互運用
WinMD ( Windows Matadata )
あまり名前が良くない• WinRT 用なのは残念• Windows に閉じていい技術じゃない• 壁のない世界を Windows 以外にも欲しい
現代風に再設計 .NET を参考にしたオブジェクト指向 API
脱Win32 脱 Variant
非同期 API XAML UI
.NET を参考に 言われなければ .NET のライブラリかと間違うレベ
ル
型はしっかりしている( Variant とかない) P/Invoke不要
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); }}
例
※IRandomAccessStream や DataReader が WinRT クラス
非同期 API WinRT の方針 :
スレッドをブロックするのは思った以上にコストになる UI スレッドを止めるとユーザーの印象悪い
同期処理するとまずい まずいものは最初から提供しない
50ミリ秒以上かかる可能性のある API は非同期 API しか提供しない
XAML UI: 登場以前 プログラミング言語での UI記述の限界
private void UpdatePageData(){ panel.RemoveAll();
for (int i = 0; i < pageItems.Count; i++) { var item = pageItems[i]; var cardCharacter = item.Card; CardThumbnailView card = card = CreateCardThumbnail(item); thumbnailList.Add(card); card.isDeckSet = item.IsDeckSet;
card.gameObject.SetActiveRecursively(true); panel.AddItem(card.gameObject); }} • どこで、だれが、何を生成しているか全然わからない
• 実行してみるまで表示結果がわからない• きっちりしたコード書くの大変 (不正になりがち )
前と変わってないものまで再生成ビューに状態持っちゃってて、
仮想化†できない
† 画面に見えている分だけビューを生成
XAML UI: UI に特化した言語 ということで XAML†
WPF/Silverlight の延長
XAML
ツール連携 :表示結果が常に見える
HTML 的な階層記述
XAML UI: データ バインディング ビューからのデータ、ロジックの分離
public class CardViewModel{ public string ImagePath { get; }}public class CardListViewModel{ public IList<CardViewModel> CardList { get; }}
XAML
C# など
ビュー ( 表示部分 ) を記述
モデル ( データ、ロジック ) を記述
+View.DataContext = new CardListViewModel { … };
<ItemsControl ItemsSource="{Binding CardList}"> <ItemsControl.ItemTemplate> <DataTemplate> <Image Source="{Binding ImagePath}" Width="168" Height="254" /> </DataTemplate> </ItemsControl.ItemTemplate></ItemsControl>
「ここに X を表示したい」
という印だけを入れる
XAML UI: 共通型システム WinRT クラスを書けば、 UI 要素を増やせる
WinMD を介して言語中立 C++ .NET: C#, VB, etc.
<ItemsControl ItemsSource="{Binding CardList}"> <ItemsControl.ItemTemplate> <DataTemplate> <Image Source="{Binding ImagePath}" Width="168" Height="254" /> </DataTemplate> </ItemsControl.ItemTemplate></ItemsControl>
単なるクラスのインスタンス生成
XAML UI: 共通型システム WinRT クラスを書けば、 UI 要素を増やせる
× コードで UI 作ったり、 ×独自属性増やしたりはどうかと思う
div = body.appendChild( div = document.createElement( "div" ) );$.extend( div.style, { minHeight: "100px", height: "auto", padding: 0, borderWidth: 0});
<div data-win-control="WinJS.Binding.Template"> <div data-win-bind="style.backgroundColor: backgroundColor"></div> <div data-win-bind="textContent: title"></div> <div data-win-bind="textContent: description"></div></div>
多様な選択肢
それぞれにとっての WinRT
それぞれの利用場面
選択肢
Metro 以外
Web と Metro デスクトップ
.NETネイティ
ブC++
HTML5JavaScri
pt
Metro
それぞれの利用場面は?それぞれにとって WinRT とは?
選択肢
Metro 以外
Web デスクトップ
.NETネイティ
ブC++
HTML5JavaScri
pt
Metro
Web = 標準ベース Web VS Metro
標準 VS プラットフォーム固有
環境 A
…
環境 B環境 C
…
標準化指向•○ 広い窓口•× 機能が限られる•× 標準化に時間がかかる
単一ベンダー指向•○ 高機能•○ 迅速な新機能提供•× 狭い窓口
クロス プラットフォームを狙うなら標準ベースで
高度な UI がほしければ
プラットフォーム固有機能を使う
クロス プラットフォーム クロスに作るのはそう簡単じゃないけれども
ブラウザー依存排し切れない どうせ UI は作り直し
タッチかマウスか、画面サイズどのくらいか
やっぱりかなり間口が広い 数倍大変でも、数倍以上のアクセス見込めるなら
まず第一に Metro の「高機能」が必要かどうか要検討
必要ないなら Web
Metro に求める「高機能」 パフォーマンス
DirectX ユーザー データ
Music/Pictures/Videos Library ハードウェア
Microphone 、 Webcam 、 Location 無制限の通信
Proximity: 近距離デバイス間通信 認証
ドメイン参加 スマート カードなどでのハードウェア認証
選択肢
Metro 以外
Web デスクトップ
.NETネイティ
ブC++
HTML5JavaScri
pt
Metro
デスクトップ アプリ いきなりすべての PC がタッチ UI になるわけない 段階移行?
できるところからタッチ化 今はマウス&キーボードで、将来タッチ化
両方? 出先ではタッチ、オフィスではマウス&キーボード
今、デスクトップ アプリを作るなら?
注意 : ARM版( Windows RT )は Metro のみ。デスクトップ不可
Metro に近いのは? アセンブリ構造が一番近いのは Silverlight
ただ、同じ XAML UI な WPF も十分近い WinRT=脱Win32
Win32 が色濃いものはつらい ×Windows フォーム ×MFC
ただ 1つだけ言えること UI は陳腐化が激しい
View は短めの周期で差し替わる View は極力小さく作るべき
View を小さく作る工夫 MVVM パターン
異なる UI フレームワークで Model を共有 Portable Class Library Project Linker
この辺りを押さえれば、WPF/Silverlight から Metroへの移行WPF/Silverlight と Metro 同時開発だいぶ楽
Portable Class Library 異なるフレームワークで共通して使えるライブラリ
使えるクラスは共通部分に限られる
※現状だと「共通部分」が狭すぎて使い勝手はあまり良くない。本格化はもう 1 世代後かも。
ターゲットを切り替えることで使えるクラスが変わる
Project Linker 複数のプロジェクト間でソースコードを自動共有
リンク
※現状、 VS 2010 のみ
共有元を指定
Silverlight か WPF か? 要件次第
Silverlight デプロイ簡単 Smooth Streaming とかメディア系強い
WPF フル機能の .NET Windows 8 であれば .NET 4.5 標準搭載
選択肢
Metro 以外
Web デスクトップ
.NETネイティ
ブC++
HTML5JavaScri
pt
Metro
.NET にとって : デスクトップと Metro
☎1OKデスクトップ Metro
CLR ( .NET の実行環境)
標準ライブラリ• UI• File• Network
標準ライブラリ• LINQ• Task• MEF• …
WinRT• UI• File• Network• …
アプリ アプリ
• LINQ• Task• MEF• …
実行環境は共通
WinRT との重複削除ついでにレガシー削除
.NET にとって : WinRT かなり、 Silverlight の延長
Silverlight も、中身はかなり Internal Call つまり、中身はネイティブで、インターフェイスだけ .NET 一般開発者もそれできるようにしたようなもの
ネイティブだけど ネイティブと意識せず タイムラグ 0 で利用可能
結局、今まで通り
むしろ恩恵
なんだかんだ言って .NET は一番恩恵受けてる
.NET にとって : WinMD/ 言語プロジェクション
.NET for Metro
*.cs
winmd
exe/lib
*.cs
*.exe*.dll
*.winmd
CLRネイティブ /JavaScript
デスクトップと同じ実行環境
ネイティブやJavaScript から使いた
ければプロジェクト タイプを
WinMD に
.NET アプリ / ライブラリ*.winmd
*.exe*.dll*.js
WinRT
.NET
.NET for Metro Style WinRT との重複削除
UI 、ファイル操作、通信ソケット、 etc. レガシー削除
非ジェネリック コレクション → ジェネリック版のみ XmlSerializer → LINQ to XML のみ
元々ポータビリティを考えて作らないと、デスクトップ版からの移植そこそこ大変 View からの分離 レガシーは使わない まず、 Portable Class Library 化を考える
WinRT→.NET WinMD を介して通常の .NET 型に見える
WinRT 型→ .NET 型に、規約ベースで置き換え
.NET の型 WinRT の型
IList<T> IVector<T>
IReadOnlyList<T> IVectorView<T>
IEnumerable<T> IIteratable<T>
IDictionary<T> IMap<T>
対応表(一部)
.NET→WinRT 利用可能な型
プリミティブ( int とか)、 string TimeSpan 、 DateTimeOffset など
利用可能なユーザー定義型 class は sealed (継承不可)なもののみ struct は public なフィールドだけ持つもののみ ジェネリックは、 IVector<T> など、決まった型のみ
選択肢
Metro 以外
Web デスクトップ
.NETネイティ
ブC++
HTML5JavaScri
pt
Metro
ネイティブにとって : WinRT 基本的に COM
C++/CX を使えば、自前実装不要 Win32 API の呪縛からの脱却
WinRT は、現代的なすっきりしたクラス ライブラリになってる
WPF 的な UI のネイティブ実装 C++ から WPF 的なものが使える ある意味では WPF のパフォーマンス改善
ネイティブの位置づけ .NET でできることをネイティブでやっても意味な
い
ネイティブ
標準 C++
C++ AMPC++ /CX GPU
利用
.NET/JavaScript連携
Component Extensions Accelerated Massive Parallelism
性能が欲しければGPU を活用
DirectX
性能が欲しければ GPU を活用
全部をネイティブでやらない
C++/CX (1) WinRT は内部的には COM なのだけども
COM めんどくさい
C++ with Component Extensions ( C++/CX ) C++/CLI に似た構文で、 COM コードを生成
(あくまでネイティブ)public ref class ImageWithLabelControl sealed : public Windows::UI::Xaml::Controls::Control { public: property Platform::String^ Label { Platform::String^ get() { return (Platform::String^)GetValue(LabelProperty); } void set(Platform::String^ value) { SetValue(LabelProperty, value); } }};
※ WRL というライブラリを使って、自前で COM実装も可能
C++/CX (2) オーバーヘッドを最小に
*.winmdメタデータ
プレーンなネイティブ コード
プレーンなネイティブ コード
オーバーヘッドなしで参照可能(単なる仮想関数呼び出しに)
他の COM コンポーネントと相互運用可能(プレーンなネイティブ コードのラッパー)
.NET や JavaScript と相互運用可能(メタデータのみ。実際に呼ばれるのは ↓の COM )
COM 相当のネイティブ コード
*.cpp
CX
*.cpp
通常の
C++ AMP C++ Accelerated Massive Parallelism
C++ で GPGPU† するための拡張 構文的には restrict句の追加のみ ほとんどライブラリ
† General-purpose computing on GPU ( GPU による汎用目的計算)
int aCPP[] = {1, 2, 3, 4, 5};int bCPP[] = {6, 7, 8, 9, 10};int sumCPP[5] = {0, 0, 0, 0, 0};
array_view<int, 1> a(5, aCPP);array_view<int, 1> b(5, bCPP);array_view<int, 1> sum(5, sumCPP);
parallel_for_each(sum.extent, [=](index<1> idx) restrict(amp) { sum[idx] = a[idx] + b[idx]; });
ライブラリ提供
CPU実行か GPU実行かを restrict句で指定
選択肢
Metro 以外
Web デスクトップ
.NETネイティ
ブC++
HTML5JavaScri
pt
Metro
JavaScript にとって : WinRT WinRT の UI (要するに XAML )は使わない
IE と同じ描画エンジン( Trident )で IE と同じ JavaScript実行エンジン( Chakra )
UI
FileNetwor
k
Trident/Chakra
*.js *.html
WinJS(JavaScriptライブラリ )
WinRT
.NET/ ネイティブ
*.winmd
JavaScriptあくまで標準
HTML5 + JavaScript
+α
WinRT のXAML UI は
使わない
+α
標準+ α (1): Metro に求める「高機能」 ユーザー データ
Music/Pictures/Videos Library ハードウェア
Microphone 、 Webcam 、 Location 無制限の通信
Proximity: 近距離デバイス間通信 認証
ドメイン参加 スマート カードなどでのハードウェア認証
標準+ α (2 ): WinJS XAML 相当の UI を書くための JavaScript ライブラ
リ ↓こんな HTML を書く
data- なんとか属性… 独自属性使ってデータ バインディング
Blend5 で編集可能 処理を行ってくれてるのは WinJS 中の JavaScript
一応は、 HTML5 の規格の範囲
<div data-win-control="WinJS.Binding.Template"> <div data-win-bind="style.backgroundColor: backgroundColor"></div> <div data-win-bind="textContent: title"></div> <div data-win-bind="textContent: description"></div></div>
HTML5+JavaScript の位置づけ UI 用
+α がある時点で“別物”とはいえ… HTML5 と JavaScript になじんだ UI デザイナーは多い
ロジックは… ViewModel まで .NET で作って、 WinMD経由で参照す
るのがよいかも
WinJS を使うかどうか WinJS を使わない
UI 部分に関しては完全に「標準」 UIガイドラインに沿った UI を 1 から自前で作る必要あ
り 沿っていないと審査で落ちる可能性あり ゲームならあまりうるさく言われない
WinJS を使う ガイドライン通りの UI に +α の部分を覚えるのはそれなりの負担
なら XAML でいいのでは…
まとめ
Metro 以外
Web デスクトップ
.NETネイティ
ブC++
HTML5JavaScri
pt
Metro
Web VS Metro フル機能使いたかったら Metro で
GPU Music/Pictures/Videos Library Microphone 、 Webcam 、 Location Proximity: 近距離デバイス間通信 ドメイン参加 スマート カードなどでのハードウェア認証
そんなの要らなかったら Web で
デスクトップ 段階移行 or 同時開発
同じ XAML UI の Silverlight か WPF ならそこそこ楽 確実に言えること :
UI 技術は陳腐化が激しい View を極力小さく
Silverlight か WPF か 要件次第。それぞれの特徴を活かして
Metro: .NET Silverlight か WPF の経験者なら苦もなく作れる
XAML: Silverlight の延長線上 WinMD: .NET のメタデータの延長線上
開発しやすさは .NET が一番 特に非同期処理には async/await ( C# 5.0 ) サーバーとのコード共有の要求もたぶん出てくる
2重開発避けるためにも、サーバー側でも使える .NET
Metro: ネイティブ .NET でできることをネイティブでやっても意味な
い
ハイ パフォーマンス 特にゲームや大規模データ処理
DirectX, C++ AMP
GPU の活用
Metro: HTML5+JavaScript UI 用
ロジックは .NET や C++ で書いてしまう WinMD経由で参照
利点は UI デザイナー人口多いこと Metro HTML は標準+ α だけど…
+ α ある時点で…