Xamarinを支える技術

Chalk Talk session at de:code 2017

Transcript

1. https://pawoo.net/@atsushieno Licensed under cc-by 4.0
2. この チョークトーク セッション Speaker Visual Studio for Mac （2017年5月Xamarinリリースのキモ） Xamarinを支えるコード生成エンジン その他の未来的トピック 難易度高いって聞いたけど
3. この チョークトーク セッション前にお願いしたいこと スライドは公開しています https://speakerdeck.com/atsushieno/ から探してください。 そういうわけで写真撮影は不要です。 SNSに流したいでしょうから撮影はご自由に（他参加者には配慮してください）。 評価は適切にしてください
4. past, present and future
5. Visual Studio for Mac
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
7. Mono 5.0: more .NET unification コンパイラ Roslynベースのcscがついに登場、C# 7をサポート（mcsはC# 6まで） ※MonoDevelopはv6.0からRoslynだった ランタイム デバッグシンボルファイルがmdbからPortable PDBに切り替わった クラスライブラリ 一部referencesourceからcorefxへの切り替えなど
8. MSBuildに切り替わった どういう意味…? これまでのはMono版の実装 xbuild github/Microsoft/msbuildの統合 Windowsべったりの初期コードをXamarinが合併前から協力して修正 現在は.NET Coreサポートでも利用 Cscタスクはcsc(.exe)を呼び出す 新しいエンジンだと不安が… プロジェクトによる ※WindowsではもともとMSBuildしかなかった プロジェクト オプションで切り替え可能（だけど新msbuildに依存しているかも）
9. 予測されるトラブル(!) MDBが無い 下位VS/XS互換性が無いNuGetパッケージがビルドされる ※Xamarin.Forms 2.4 mdbの存在を前提にしたツールがクラッシュする(!?) C#コンパイルが遅くなった …10倍くらい。mcsはかなり最適化されていた（例: @csc.rspが無い） ビルドタスクがエラーを出すようになった 実装が根本的に変わったので互換性問題が生じるカスタムタスクが多々あるかも preview中にハマった例: Xamarin.FormsのXamlC / XamlG
10. Multiplatform Library bait & switch方式のNuGetパッケージを自動生成 Bait & switch方式…についてはここでは説明しません baitを自動生成するApiIntersect + 自動化ビルドタスク NuGetパッケージング プロジェクト (.nuproj) デフォルトで含まれる NuGet.Build.Packaging nugetパッケージがキモ 参照プロジェクトを追加するとビルド結果のnupkgに含まれるようになる nuprojのプロパティでPCLプロファイルを選択するとbaitも生成されて含まれる
11. Azure統合 クローズドソースなので多くは語れませんが… MonoDevelop.ConnectedServices ここはオープンソース Azure実装 ある程度はNuGetパッケージでWindows VSと共通化しているが、独自実装が多い NuGetパッケージもプロプラエタリでLinuxサポートも無い…今後の課題 NuGetパッケージ中心なのでAPIを知っていれば独自拡張も作りやすい?
12. Xamarinを支える コード生成エンジン
13. コード生成エンジンの位置付け Monoランタイムの構成 Mscorlib（ライブラリ） - C#で実装されている mono（ランタイム） - Cで実装されている Monoランタイムの仕事 ネイティブのI/Oやスレッド処理など（主にmono/io-layer） メモリ管理（主にmono/sgen） MSIL（mscorlibを含む）をロードして解釈する部分（主にmono/metadata） MSILをコンパイルして対象CPUに合わせたコードを生成する（主にmono/mini）
14. C#のコードがコンピュータ上で動くまで C#コンパイラがC#ソースをMSIL（.exeや.dll）に変換する .NETの仮想マシンがMSILをそのコンピュータ上のCPU命令として実行する
15. Interpreter vs. JIT 仮想マシンコードMSILを実行するやり方 バイトコード命令をフェッチして、解釈して実行する（インタープリタ） CPU命令に変換して、それをそのまま実行する（コードジェネレータ） JIT（実行時変換） vs. AOT（事前変換） 200x: 「Monoランタイム = JIT」の時代 2002年ころまでのmonoはインタープリタ (mint)、それ以降は基本的にJIT (mini) 200x年代後半まではJITの最適化だけやっていられた平和な(?)時代
16. 「安全な」コード生成が必要な環境の登場 Google NaCl / PNaCl ブラウザ上でネイティブコードを実行 = 危険 一部のコード生成を強制的に安全化（一部x86ジャンプ命令の書き換え etc.） iPhone SDK 一部の許されたアプリにしかコード生成が実行できない環境 AOTで対応 iPhone以前から組み込み環境向けに実現していた 組み込みMonoについて: Essential Xamarin -Yin/陰-
17. 不完全AOTと完全AOT 不完全? AOT不可能/困難な部分はJITで実行していた（不完全AOT） しかしそれでは完全AOTが「必須の」環境でコードが実行できない （※hybrid AOT - 不完全AOTのこと） どんな場面でAOTが困難/不可能? 非コンパイル済みコード（動的なコード）の実行 ※System.Reflection.Emit ジェネリック型を使うメソッドがいろいろ鬼門
18. .NET Generics: 静的コード生成の鬼門 ジェネリックメソッドは何が特殊なのか ジェネリック型の「インスタンス化」（ネイティブコード生成時）の問題 ジェネリックな値型が引数になると、確保するスタック領域のサイズが変わる Field Size Offset X 4 0 Y 2 4 Z 4 6 struct Foo<T> { public int X; public T Y; public int Z; } Field Size Offset X 4 0 Y 8 4 Z 4 12
19. Generic Code Sharing ジェネリックコード共有 具体型ごとに異なるネイティブコードを生成していたらパフォーマンスが悪い そのため、JITはネイティブコードを共通化できる部分はコードを共通化している Monoでは2005年前後にがんばって実装していた = 共通化できない部分は、実行時のジェネリック引数型から動的に生成
20. Generic Code Sharing Xamarin.iOSでの対応 一定のサイズまではどんな構造体にも対応できるよう、固定サイズでスタックを確保 Field Size Offset X 4 0 Y 2 4 Z 4 X+4 Field Size Offset X 4 0 Y 8 4 Z 4 X+4 struct Foo<T> { public int X; public T Y; public int Z; }
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勉強会」で！
22. ネイティブコード生成のオプション コード生成には多様な特徴・選択肢がある(べき) 例: メモリ容量の厳しい環境 例: 時間をかけて実行効率の高いコード生成が行える 例: X86のことしか考えていない（例えばendianness） →いくつかはmonoのビルド オプションや実行時オプションに
23. LLVMの登場 LLVMとは何か? コンパイラ用の抽象的なバイトコードを提供するコンパイラ インフラストラクチャ LLVM IR（intermediate representation） 任意の言語コンパイラのフロントエンド: C、C++、Objective-C、swift、... 任意のコード生成のバックエンド: x86、x86_64、ARM、MIPS、… (from "AOSA" - LLVM
24. mono-llvm LLVMフロントエンドとしてのMSIL処理系 LLVMフロントエンドがプログラミング言語である必要はない mono-llvmの意義 LLVMがサポートするさまざまなバックエンドを利用可能 LLVMが実装しているネイティブコード生成の最適化を利用可能 ランタイムサイズが肥大化する ちなみに.NET Coreの場合 Ryujit vs. LLILC (alive?)
25. Apple WatchOSとtvOSのサポート WatchOSとtvOSは何が特別なのか iOSと異なり「完全な」LLVM IR（bitcode）が要求される mono-llvmは全てのMSILコードを全てbitcodeに変換していたわけではない がんばって対応した
26. WebAssembly ブラウザで実行するネイティブコード 発端はasm.js ネイティブコードを実行するための仕様という意味ではPNaCLの改善版といえる WebAssemblyの命令セット (MIR) 処理系中立で安定した命令集合 LLVM bitcodeやPNaCLとは異なる目的（あちらは最適化） Safariや Edgeでも 実装している Think Web (TechBooster)
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統合や動的ライブラリなど、課題はある
28. Mono for WebAssembly? dnfdn
29. まとめ Mono/Xamarinは未来の実行環境に対応できる? JIT: 仮想マシン命令からCPU命令を生成 AOT: 動的コード生成の禁止に対応 iOS LLVM backend: mono固有のコード生成エンジン以外に対応 bitcode: 安全な実行コードを意識した仮想マシン命令に対応 WatchOS WebAssemblyの時代にも生き残れる? Xamarinが将来求められる動作環境は?
30. その他の未来的トピック
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のみに
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でしょ。何でそんなことしたいの?」
33. Xamarin.Forms v3 Forms embedding Formsのページをプラットフォーム ネイティブのコントロールとして作成可能に これでFormsのページナビゲーションモデルからおさらばできる プラットフォームの追加 Xamarin.Mac、GTK#、WPF その他 CSS方式のスタイリング、FlexLayoutもどき、初期化時のみのバインディング、 fast rendererへの切り替え
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の実装（まだまだ実験的）