Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to 広がる .Net
Similar to 広がる .Net (20)
More from 信之 岩永
Recently uploaded
Recently uploaded (8)
広がる .Net
- 1. 広がる.NET Framework 互換環境 ++C++; 岩永 信之 http://ufcpp.net
- 2. 2 セッションのゴール • .NET Framework互換環境について知ってもらう • どうして.NET (C#)？ • どういうことができるの？ • どういう環境があるの？ • どのくらいの幅カバーできるの？ • 注意点
- 4. 4 こんなの作ってます ゲーム ロジック iPhone ゲーム Android ゲーム Linux サーバー Windows デスクトップ 単体実行 ゲーム本体 • オフライン実行 • 中断・再開、通信対戦 サーバー • チート対策 デスクトップ • データ編集 • バランス調整 (シミュレーション) テスト実行
- 5. 5 こんなの作ってます ゲーム ロジック iPhone ゲーム Android ゲーム Linux サーバー Windows デスクトップ 単体実行 C#(.NET言語なら何でも) • #ifdef すらなく • 単一バイナリ(dll)
- 7. 7 何ができる • 通信の少ないクライアント実行 • チートできないサーバー実行 • データの編集ツール 地下鉄の中でも低ストレス 不正クライアントを作られても平気 複雑なデータの打ちこみ可能 早い段階でバランスの確認可能
- 8. 8 何を使ってできる • もちろん普通の.NET開発環境＋実行環境 • Visual Studio • Windows • .NET Framework • Mono†、Xamarin‡ • Unityゲーム エンジン※ †http://mono-project.com/ ‡http://xamarin.com/ ＊http://japan.unity3d.com/
- 9. Why and Why Not どうしてC# どうして他ではない
- 10. 10 どうしてC# • 最初（前作の初期）は • 会社として単一技術に依存しないため • Unityのプロジェクト“も”立ち上げた • 他にもRuby on Rails、Coffee Script、Node.js、… • Unity†なので必然的にC# • JavaScriptで大きめのアプリ書くとかちょっと… † Monoベースのクロス プラットフォーム ゲーム開発エンジン(iOS/Android対応)
- 11. 11 せっかくC#だから • C#なのにUnityでしか使わないとかもったいない • 前作からやりたかった • 今作は初期設計からきっちり • 様々なメリットあり ゲーム ロジック iPhone ゲーム Android ゲーム Linux サーバー Windows デスクトップ 単体実行 C#ならいろいろできる
- 12. 12 C#ならいろいろできる • システム開発向けの汎用言語 • 大規模化しても破綻しない • それなりのパフォーマンス • 動かせる環境 • GUI、コンソール、UIなし(単体テスト) • Windows、Linux、iOS、Android ×_ OK ×_ > ls Mode LastWriteTime Length Name ---- ------------- ------ ---- d---- 2013/05/17 18:36 ConsoleApplication1 d---- 2013/04/17 12:03 ConsoleApplication2 d---- 2013/05/07 12:27 ConsoleApplication3 d---- 2013/05/07 12:51 SamplesFromWeb d---- 2013/05/07 12:33 TfsUfcpp d---- 2013/04/25 16:53 WpfApplication1
- 13. 13 比較: HTML5 + JavaScript • HTMLは応答性的にきつくて • 通信量多い(Viewまで文字ベースで送信するので) • 画像リソースも毎回ダウンロードするのでかなりの負担 • 機種によって描画性能がまちまち • 思ったよりもクロス プラットフォーム感出ない • タッチ操作周りの挙動とか結構怪しい機種あり • 性能差があるだけでも「この機種ダメだ」な機種あり
- 14. 14 余談: 既存サーバー資産はPHP • 全面C#化はやってない • PHPからC#モジュールを呼ぶ • MonoでHTTPリスナー立てて、ローカルHTTP通信 • C#化してからの開発はハイペース • C#自体のパワー • クライアントでも使う (2重開発でない分、1つのコードに手間をかけれる)
- 15. 15 比較: C++ • ポータビリティ • ロジックだけならいいけども、UIは結局別 • UIからロジックをきれいに分離するのも、C++は結構大変 • なのでポータビリティ的にはそこまで優位はないと思う • パフォーマンス • CPUネイティブのパフォーマンスを必要とする作品を作ってない • CPU構造とかGPU利用まで考慮しないと、C++とC#の差はそこま で大きくない
- 17. 17 とはいえ いろいろ疑問はあると思います • Mono/Xamarin/Unityって？ • どのくらいの互換性が？ • 本当に大丈夫？ • コツとか気を付けるところはある？
- 19. 19 19 We love C# and .NET more than Microsoft does マイクロソフトよりもC#と.NETを愛している Miguel de Icaza†談 † GNOME、Monoプロジェクトを始めた人 XamarinのCTO https://twitter.com/migueldeicaza/status/278901886411751424
- 20. 20 余談: .NETが出た当時… • 知らない、わからないは論外として • いいとは思うけど… • マイクロソフトの技術だしちょっと… • オープンじゃないからダメ • なら、.NETをオープンにすればいいじゃない Mono
- 21. 21 .NET互換環境 • Mono • .NET Framework互換の実行環境 • Xamarin社 • Monoを主軸に製品を作っている会社 • Xamarin.iOS • Xamarin.Android • Unityゲーム エンジン • Monoベースのクロスプラットフォームなゲーム開発エンジン ※ 他にも.NET互換環境はあるものの、最近の流行りとして
- 22. 22 .NET互換環境 • Mono • Xamarin.iOS • Xamarin.Android • Unityゲーム エンジン Windows Max OS X Linux iOS Android
- 23. 23 異なるアプローチ • デスクトップ向けMono(Windows, Mac OS X, Linux) • Windows FormsやASP.NETも提供 • WPFは無理 • Xamarin.iOS/Xamarin.Android • Monoの基礎部分 ＋ ネイティブ相互運用 • Unityゲーム エンジン • Monoの基礎部分+ クロスプラットフォーム ゲームUI
- 24. 24 異なるアプローチ • デスクトップ向けMono(Windows, Mac OS X, Linux) • Windows FormsやASP.NETも提供 • WPFは無理 • Xamarin.iOS/Xamarin.Android • Monoの基礎部分 ＋ ネイティブ相互運用 • Unityゲーム エンジン • Monoの基礎部分+ クロスプラットフォーム ゲームUI • デスクトップだけだからできる • モバイルは絶望的 • それも、あまり高機能なもの (WPFとか)は期待薄
- 25. 25 異なるアプローチ • デスクトップ向けMono(Windows, Mac OS X, Linux) • Windows FormsやASP.NETも提供 • WPFは無理 • Xamarin.iOS/Xamarin.Android • Monoの基礎部分 ＋ ネイティブ相互運用 • Unityゲーム エンジン • Monoの基礎部分+ クロスプラットフォーム ゲームUI • UI部分はそれぞれのOSのマナーで書く
- 26. 26 異なるアプローチ • デスクトップ向けMono(Windows, Mac OS X, Linux) • Windows FormsやASP.NETも提供 • WPFは無理 • Xamarin.iOS/Xamarin.Android • Monoの基礎部分 ＋ ネイティブ相互運用 • Unityゲーム エンジン • Monoの基礎部分+ クロスプラットフォーム ゲームUI • 用途がゲームに限られていて、 機器性能をある程度絞れるからできる • それなりにオーバーヘッド大きい • 幅広い機器をターゲットにすればするほど大変
- 27. 27 クロスプラットフォームの注意点 • ほんとにクロスに使えるのは基礎部分だけなので注意 • System, System.Collections, System.Linq, System.Text, … • UIは、各OSのマナーに合わせて作るべき UIからのロジック分離が非常に大事
- 29. 互換性とバージョン
- 31. 31 .NET FrameworkとMono C# VB F# C# CLR Mono ランタイム .NET Full プロファイル .NET Core プロファイル .NET Full (サブセット) iOS向け プロファイル Android向け プロファイル .NET Framework Mono コンパイラー 実行環境 ライブラリ
- 32. 32 .NET FrameworkとMono C# VB F# C# CLR Mono ランタイム .NET Full プロファイル .NET Core プロファイル .NET Full (サブセット) iOS向け プロファイル Android向け プロファイル .NET Framework Mono コンパイラー 実行環境 ライブラリ ILの標準仕様に沿った結果を出力 • MS製C#コンパイラーの出力をMonoで実行可能 • 逆も可
- 33. 33 .NET FrameworkとMono C# VB F# C# CLR Mono ランタイム .NET Full プロファイル .NET Core プロファイル .NET Full (サブセット) iOS向け プロファイル Android向け プロファイル .NET Framework Mono コンパイラー 実行環境 ライブラリ これも仕様通り • GCの挙動が違ったりはするものの • アプリのレベルでの挙動は変わらない
- 34. 34 .NET FrameworkとMono C# VB F# C# CLR Mono ランタイム .NET Full プロファイル .NET Core プロファイル .NET Full (サブセット) iOS向け プロファイル Android向け プロファイル .NET Framework Mono コンパイラー 実行環境 ライブラリ 差が出るのはここ • どのクラスのどのメソッド が使えるか
- 35. 35 要点 • 参照できるライブラリが変わるだけ • 前述の通り: • UI部分は共通化できない • UIとロジックの分離必須 • ビルドさえ通ればだいたい動く • 仕様がしっかりしている • 後方互換性保たれている • “静的な言語”の利点
- 36. 36 Monoで使えるライブラリ • BCL†(基礎ライブラリ)に関してはかなり移植されてる • 後方互換性もあり † Basic Class Library Mono .NET Framework 2.6 3.5 2.10 4 3.0 4.5 大体、以下の通りバージョンを読みかえればOK Unity 4はMono 2.6ベース Xamarin 2.0はMono 2.10 (iOS/Androidともに)ベースまだβ版
- 37. 37 といっても C# 1.0 .NET 1.0 C# 2.0 .NET 2.0 • ジェネリック • イテレーター C# 3.0 .NET 3.5 • LINQ C# 4.0 .NET 4 • dynamic • Task C# 5.0 .NET 4.5 •async/await •Caller Info バージョンで言われてもわからないと思うので…
- 38. 38 機能でいうと Collections LINQ Task dynamic await/ async Caller Info 3.5 ○ ○ × × × × 4 ○ ○ ○ ○ × × 4.5 ○ ○ ○ ○ ○ ○ Mono 2.6 Unity 4 Mono 2.10 Xamarin 2.0 Mono 3.0
- 39. 39 注意: UnityのMono • UnityはMono自体のコードに結構手を入れている • 簡単にはMonoのバージョンを上げれない • いつまでたっても2.6(= .NET 3.5相当。つらい) オープンソースだからと言って中身に手を入れる怖さ
- 41. 41 互換環境って信用できるの？ • 聞こえてきそうな声: • Run anywhereって言ってるアレでもよく苦労するよ？ • バージョン違いですら問題出たりするのに • ライセンス問題とかないの？ • パフォーマンスは大丈夫？ 正直、.NETで苦労 したことない
- 42. 42 苦労したことない • マイクロソフトの下位互換性に対する努力の成果 • 90年代のDLL Hellの反省のたまもの • .NETはアセンブリとかメタデータの仕様がしっかりしてる • 参照順 • バージョニング • その移植なので、Monoもしっかりしてる
- 43. 43 Run anywhere度合(一般論) • 一般論として • 基礎部分ほどRun anywhere • 依存するライブラリが少ないほどRun anywhere • モジュール性が高く、依存関係の少ない書き方を • ビューとモデルの分離を クロスプラットフォームを売りにしたフレー ムワーク、プログラミング言語の利用者ほど、 移植性の低いコードを平気で書くので注意
- 44. 44 Run anywhere (Mono) • 前述の通り: • 基本クラス ライブラリは大部分問題なく動く • バージョンにだけ気を付ける • 後方互換性あり • UIは期待薄 • Unityがクロスプラットフォームだからといって、Unityに依存したコードは 極力少なくすべき
- 45. 45 問題1: private • 仕様外の部分は当たり前だけど互換性ない • クラスのprivateな部分には触れちゃダメ • 普通困らないけども… • BinaryFormatterとか、privateな部分に触れようとするライブラリもあるの で注意
- 46. 46 問題2: iOS上の制限 • iOS = 動的な処理を認めていない • MonoはAOT†で実行 制約あり • リフレクション全滅 • 値型のジェネリックに一部制限あり • 例えば、Nullable型に対するLINQで動かないものあり (早期に .Where(x => x.HasValue).Select(x => x.Value) 推奨) • 抽象メソッドの引数にジェネリックを使えない † Ahead of Time: コンパイル時に直接ネイティブ コード化
- 47. 47 問題3: 利用者側のマナーの問題も • 環境やバージョンが変わって動かない例: • パフォーマンスに依存するバグが残ってる • クラス パスの検索順が変わっただけで動かない • インターフェイスの戻り値をわざわざ具象クラスにダウンキャスト して使ってる さすがにこれは、 こういうコード書く方が悪い
- 48. 48 .NETの標準化 • 標準化 • Community Promise • 標準仕様に沿っている限り、マイクロソフトは特許権を主張しない ECMA ISO JIS C# ECMA-334 ISO/IEC 23270 JIS X 3015 CLI ECMA-335 ISO/IEC 23271 JIS X 3016
- 49. 49 Monoのライセンス† • コンパイラーやランタイムはGPL/LGPL • クラス ライブラリは MIT X11 • MEFやDLRなど、元々MS-PLなものはそれに準ずる • 別途、商用ライセンスあり • GPL/LGPLが適さない場合でも、Xamarin社と要相談 † http://www.mono-project.com/FAQ:_Licensing
- 50. 50 パフォーマンス • 起動後にパフォーマンスで困ることはそうないものの 起動時間がやっぱ長めという問題はある • モバイルにはCompile in the Cloud†みたいな仕組みが必要なんだと 思うけど… † Windows Phone 8で採用された手法 アプリ ストアのサーバー上でネイティブ化したものをクライアントに配布
- 52. 52 依存 • どのアセンブリがどのアセンブリを必要とするか 依存グラフ 依存度高 低 もちろん、線の本数 少ない方がいい
- 53. 53 依存度が高いと 53 • 修正（継続開発）が大変 • フレームワークの寿命に引きずられるリスク高 「リリースしたら開発終了」って時代じゃない • オンラインでサービス提供 • 継続的な機能追加 UI層は陳腐化が激しい • UI層は基本ライブラリよりもはるかに寿命が短い • 中核処理はUIと独立で、より長命なはず
- 55. 56 依存切り: フレームワーク • 例えばASP.NET MVC using System.Web; using System.Web.Mvc; namespace MvcApplication1.Controllers { public class HomeController : Controller { public ActionResult Index() { } } } こういうところに 中核処理を書いちゃダメ 画面側コード（この例だとコントローラー） ASP.NET依存
- 56. 60 まとめ • .NET Framework互換環境 • Mono、Xamarin、Unityゲーム エンジン • コード共有（バイナリで） • Windows、Linux、Mac OS X、iOS、Android… • GUI、コンソール、UIなし • 注意点 • 移植性が高いのは中核処理のみ、UIまでは無理 • 常に依存関係を意識した開発を