Windows 8時代のアプリ開発

10,326
-1

Published on

第8回.NET中心会議「Windows 8時代の開発」
基調講演資料

Published in: Technology
0 Comments
15 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
10,326
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
81
Comments
0
Likes
15
Embeds 0
No embeds

No notes for slide

Windows 8時代のアプリ開発

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

    Clipping is a handy way to collect important slides you want to go back to later.

×