広がる .Net

23,880 views

Published on

2013/06/08 (土)
Build Insider オフラインイベントにて発表

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

No Downloads
Views
Total views
23,880
On SlideShare
0
From Embeds
0
Number of Embeds
12,553
Actions
Shares
0
Downloads
0
Comments
0
Likes
33
Embeds 0
No embeds

No notes for slide

広がる .Net

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

×