Xamarinを支える技術

 Xamarinを支える技術

Chalk Talk session at de:code 2017

24837993455f54c957883ba1f1db7f2d?s=128

Atsushi Eno

May 23, 2017
Tweet

Transcript

  1. 6.

    Build 2017で正式リリース 実態 Xamarin Studioです。 新機能 (一応触れておきます) Azureサポートの統合 C# 7サポート

    .NET Coreサポート Unity for VSMac ASP.NETプロジェクトのサポート Multiplatformライブラリ (Nugetizer 3000) Xamarin.IoT Android designer refresh IDEに統合されたAndroid SDK Manager
  2. 7.

    Mono 5.0: more .NET unification コンパイラ Roslynベースのcscがついに登場、C# 7をサポート(mcsはC# 6まで) ※MonoDevelopはv6.0からRoslynだった

    ランタイム デバッグシンボルファイルがmdbからPortable PDBに切り替わった クラスライブラリ 一部referencesourceからcorefxへの切り替えなど
  3. 10.

    Multiplatform Library bait & switch方式のNuGetパッケージを自動生成 Bait & switch方式…についてはここでは説明しません baitを自動生成するApiIntersect +

    自動化ビルドタスク NuGetパッケージング プロジェクト (.nuproj) デフォルトで含まれる NuGet.Build.Packaging nugetパッケージがキモ 参照プロジェクトを追加するとビルド結果のnupkgに含まれるようになる nuprojのプロパティでPCLプロファイルを選択するとbaitも生成されて含まれる
  4. 13.

    コード生成エンジンの位置付け Monoランタイムの構成 Mscorlib(ライブラリ) - C#で実装されている mono(ランタイム) - Cで実装されている Monoランタイムの仕事 ネイティブのI/Oやスレッド処理など(主にmono/io-layer)

    メモリ管理(主にmono/sgen) MSIL(mscorlibを含む)をロードして解釈する部分(主にmono/metadata) MSILをコンパイルして対象CPUに合わせたコードを生成する(主にmono/mini)
  5. 15.

    Interpreter vs. JIT 仮想マシンコードMSILを実行するやり方 バイトコード命令をフェッチして、解釈して実行する(インタープリタ) CPU命令に変換して、それをそのまま実行する(コードジェネレータ) JIT(実行時変換) vs. AOT(事前変換) 200x:

    「Monoランタイム = JIT」の時代 2002年ころまでのmonoはインタープリタ (mint)、それ以降は基本的にJIT (mini) 200x年代後半まではJITの最適化だけやっていられた平和な(?)時代
  6. 16.

    「安全な」コード生成が必要な環境の登場 Google NaCl / PNaCl ブラウザ上でネイティブコードを実行 = 危険 一部のコード生成を強制的に安全化(一部x86ジャンプ命令の書き換え etc.)

    iPhone SDK 一部の許されたアプリにしかコード生成が実行できない環境 AOTで対応 iPhone以前から組み込み環境向けに実現していた 組み込みMonoについて: Essential Xamarin -Yin/陰-
  7. 21.

    さまざまなGenerics なぜ.NETでのみ問題? .NET: reified genericsの世界(MSIL中でも<T>, IList`1) Java: erased genericsの世界(制約型あるいはjava.lang.Objectに置き換え) C++:

    コンパイル時に型ごとに異なるネイティブコードが生成される cf. RTTI (Javaも将来的にreified genericsになりそう) ※ジェネリクスについては6/24の「generics勉強会」で!
  8. 27.

    Mono for WebAssembly? ブラウザで実行するMSILコード 過去の取り組み MSILからJSを生成(Script#、Bridge.NET、JSIL) ブラウザ プラグイン(Silverlight、Unity Web Player、PNaCl)

    現代的な取り組みならWebAssemblyサポートではないか ilwasm ... で出来るレベルではなさそう Web APIへアクセスできるかという問題? => WebSharp WebAssembly post-MVP: ネイティブGC統合や動的ライブラリなど、課題はある
  9. 29.

    まとめ Mono/Xamarinは未来の実行環境に対応できる? JIT: 仮想マシン命令からCPU命令を生成 AOT: 動的コード生成の禁止に対応 iOS LLVM backend: mono固有のコード生成エンジン以外に対応

    bitcode: 安全な実行コードを意識した仮想マシン命令に対応 WatchOS WebAssemblyの時代にも生き残れる? Xamarinが将来求められる動作環境は?
  10. 31.

    Xamarin Live Player (XLP) preview 由来はContinuous Coding http://praeclarum.org/post/132881570743/live-coding-with-xamarin-ios さらに遡るとInstant programming

    AppleのPlayground 詳しくは http://qiita.com/atsushieno/items/141f790a9bbaa93b62c1 Inspector 技術的にはInspectorを利用 変更点 C#はRoslynベース、実機で実行、デバッグ機能追加、主な対象がFormsのみに
  11. 32.

    xaml-standard XAMLを使ったUIマークアップの共通化? ”XAML Standard proposals are filed as issues serving

    as living documents describing the current thinking about a XAML feature/API." まだ何も言っていないに等しい…? 何が共通化できるの? 未定(RFC) どうやって実現するの? 未定 「というか、whatやhowよりwhyでしょ。何でそんなことしたいの?」
  12. 34.

    Embeddinator-4000 What's this? ネイティブ(Java/Kotlin/Obj-C/Swift)アプリケーション上にXamarinを組み込む 基本的にネイティブを使いつつ部分的に.NETのコードを使えるようにする Embedded mono + strongly typed

    .NET API 自分の.NET APIからC API / Java API (まだ無い) / Obj-C APIを自動生成 ツールチェイン - CppSharpを活用 C++ Interopの実装(まだまだ実験的)