Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Xamarinを支える技術
Search
Atsushi Eno
May 23, 2017
Programming
2
2.9k
Xamarinを支える技術
Chalk Talk session at de:code 2017
Atsushi Eno
May 23, 2017
Tweet
Share
More Decks by Atsushi Eno
See All by Atsushi Eno
Some Music Libraries for Kotlin (with some .NET -> Kotlin migration stories)
atsushieno
0
180
Building App Extensions equivalents on Android (maybe?)
atsushieno
1
380
Taking trends in music app development into the future mobile ecosystem
atsushieno
0
340
DTM entry level hands-on
atsushieno
0
450
[COSCUP2024] Catching up Trends in Audio App Development
atsushieno
0
830
Building Kotlin Multiplatform Libraries in 2024
atsushieno
0
4.1k
Kotlin Multiplatformで MIDI 1.0/2.0 ライブラリを作っている話
atsushieno
1
780
building_audio_plugin_ecosystem_on_Android.pdf
atsushieno
0
1.2k
get updated to the latest realtime audio processings knowledge base (2023) (再履修: 2023年までの リアルタイムオーディオ処理)
atsushieno
1
1.2k
Other Decks in Programming
See All in Programming
20250628_非エンジニアがバイブコーディングしてみた
ponponmikankan
0
680
Deep Dive into ~/.claude/projects
hiragram
14
2.5k
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
760
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
7.2k
Flutterで備える!Accessibility Nutrition Labels完全ガイド
yuukiw00w
0
160
ruby.wasmで多人数リアルタイム通信ゲームを作ろう
lnit
3
470
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
770
明示と暗黙 ー PHPとGoの インターフェイスの違いを知る
shimabox
2
510
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
120
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
320
プロダクト志向ってなんなんだろうね
righttouch
PRO
0
190
PipeCDのプラグイン化で目指すところ
warashi
1
270
Featured
See All Featured
4 Signs Your Business is Dying
shpigford
184
22k
A designer walks into a library…
pauljervisheath
207
24k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
Into the Great Unknown - MozCon
thekraken
40
1.9k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
[RailsConf 2023] Rails as a piece of cake
palkan
55
5.7k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Navigating Team Friction
lara
187
15k
Designing for humans not robots
tammielis
253
25k
The World Runs on Bad Software
bkeepers
PRO
69
11k
RailsConf 2023
tenderlove
30
1.1k
Visualization
eitanlees
146
16k
Transcript
https://pawoo.net/@atsushieno Licensed under cc-by 4.0
この チョークトーク セッション Speaker Visual Studio for Mac (2017年5月Xamarinリリースのキモ) Xamarinを支えるコード生成エンジン
その他の未来的トピック 難易度高いって聞いたけど
この チョークトーク セッション前にお願いしたいこと スライドは公開しています https://speakerdeck.com/atsushieno/ から探してください。 そういうわけで写真撮影は不要です。 SNSに流したいでしょうから撮影はご自由に(他参加者には配慮してください)。 評価は適切にしてください
past, present and future
Visual Studio for Mac
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
Mono 5.0: more .NET unification コンパイラ Roslynベースのcscがついに登場、C# 7をサポート(mcsはC# 6まで) ※MonoDevelopはv6.0からRoslynだった
ランタイム デバッグシンボルファイルがmdbからPortable PDBに切り替わった クラスライブラリ 一部referencesourceからcorefxへの切り替えなど
MSBuildに切り替わった どういう意味…? これまでのはMono版の実装 xbuild github/Microsoft/msbuildの統合 Windowsべったりの初期コードをXamarinが合併前から協力して修正 現在は.NET Coreサポートでも利用 Cscタスクはcsc(.exe)を呼び出す 新しいエンジンだと不安が…
プロジェクトによる ※WindowsではもともとMSBuildしかなかった プロジェクト オプションで切り替え可能(だけど新msbuildに依存しているかも)
予測されるトラブル(!) MDBが無い 下位VS/XS互換性が無いNuGetパッケージがビルドされる ※Xamarin.Forms 2.4 mdbの存在を前提にしたツールがクラッシュする(!?) C#コンパイルが遅くなった …10倍くらい。mcsはかなり最適化されていた(例: @csc.rspが無い) ビルドタスクがエラーを出すようになった
実装が根本的に変わったので互換性問題が生じるカスタムタスクが多々あるかも preview中にハマった例: Xamarin.FormsのXamlC / XamlG
Multiplatform Library bait & switch方式のNuGetパッケージを自動生成 Bait & switch方式…についてはここでは説明しません baitを自動生成するApiIntersect +
自動化ビルドタスク NuGetパッケージング プロジェクト (.nuproj) デフォルトで含まれる NuGet.Build.Packaging nugetパッケージがキモ 参照プロジェクトを追加するとビルド結果のnupkgに含まれるようになる nuprojのプロパティでPCLプロファイルを選択するとbaitも生成されて含まれる
Azure統合 クローズドソースなので多くは語れませんが… MonoDevelop.ConnectedServices ここはオープンソース Azure実装 ある程度はNuGetパッケージでWindows VSと共通化しているが、独自実装が多い NuGetパッケージもプロプラエタリでLinuxサポートも無い…今後の課題 NuGetパッケージ中心なのでAPIを知っていれば独自拡張も作りやすい?
Xamarinを支える コード生成エンジン
コード生成エンジンの位置付け Monoランタイムの構成 Mscorlib(ライブラリ) - C#で実装されている mono(ランタイム) - Cで実装されている Monoランタイムの仕事 ネイティブのI/Oやスレッド処理など(主にmono/io-layer)
メモリ管理(主にmono/sgen) MSIL(mscorlibを含む)をロードして解釈する部分(主にmono/metadata) MSILをコンパイルして対象CPUに合わせたコードを生成する(主にmono/mini)
C#のコードがコンピュータ上で動くまで C#コンパイラがC#ソースをMSIL(.exeや.dll)に変換する .NETの仮想マシンがMSILをそのコンピュータ上のCPU命令として実行する
Interpreter vs. JIT 仮想マシンコードMSILを実行するやり方 バイトコード命令をフェッチして、解釈して実行する(インタープリタ) CPU命令に変換して、それをそのまま実行する(コードジェネレータ) JIT(実行時変換) vs. AOT(事前変換) 200x:
「Monoランタイム = JIT」の時代 2002年ころまでのmonoはインタープリタ (mint)、それ以降は基本的にJIT (mini) 200x年代後半まではJITの最適化だけやっていられた平和な(?)時代
「安全な」コード生成が必要な環境の登場 Google NaCl / PNaCl ブラウザ上でネイティブコードを実行 = 危険 一部のコード生成を強制的に安全化(一部x86ジャンプ命令の書き換え etc.)
iPhone SDK 一部の許されたアプリにしかコード生成が実行できない環境 AOTで対応 iPhone以前から組み込み環境向けに実現していた 組み込みMonoについて: Essential Xamarin -Yin/陰-
不完全AOTと完全AOT 不完全? AOT不可能/困難な部分はJITで実行していた(不完全AOT) しかしそれでは完全AOTが「必須の」環境でコードが実行できない (※hybrid AOT - 不完全AOTのこと) どんな場面でAOTが困難/不可能? 非コンパイル済みコード(動的なコード)の実行
※System.Reflection.Emit ジェネリック型を使うメソッドがいろいろ鬼門
.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
Generic Code Sharing ジェネリックコード共有 具体型ごとに異なるネイティブコードを生成していたらパフォーマンスが悪い そのため、JITはネイティブコードを共通化できる部分はコードを共通化している Monoでは2005年前後にがんばって実装していた = 共通化できない部分は、実行時のジェネリック引数型から動的に生成
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; }
さまざまなGenerics なぜ.NETでのみ問題? .NET: reified genericsの世界(MSIL中でも<T>, IList`1) Java: erased genericsの世界(制約型あるいはjava.lang.Objectに置き換え) C++:
コンパイル時に型ごとに異なるネイティブコードが生成される cf. RTTI (Javaも将来的にreified genericsになりそう) ※ジェネリクスについては6/24の「generics勉強会」で!
ネイティブコード生成のオプション コード生成には多様な特徴・選択肢がある(べき) 例: メモリ容量の厳しい環境 例: 時間をかけて実行効率の高いコード生成が行える 例: X86のことしか考えていない(例えばendianness) →いくつかはmonoのビルド オプションや実行時オプションに
LLVMの登場 LLVMとは何か? コンパイラ用の抽象的なバイトコードを提供するコンパイラ インフラストラクチャ LLVM IR(intermediate representation) 任意の言語コンパイラのフロントエンド: C、C++、Objective-C、swift、... 任意のコード生成のバックエンド:
x86、x86_64、ARM、MIPS、… (from "AOSA" - LLVM
mono-llvm LLVMフロントエンドとしてのMSIL処理系 LLVMフロントエンドがプログラミング言語である必要はない mono-llvmの意義 LLVMがサポートするさまざまなバックエンドを利用可能 LLVMが実装しているネイティブコード生成の最適化を利用可能 ランタイムサイズが肥大化する ちなみに.NET Coreの場合 Ryujit
vs. LLILC (alive?)
Apple WatchOSとtvOSのサポート WatchOSとtvOSは何が特別なのか iOSと異なり「完全な」LLVM IR(bitcode)が要求される mono-llvmは全てのMSILコードを全てbitcodeに変換していたわけではない がんばって対応した
WebAssembly ブラウザで実行するネイティブコード 発端はasm.js ネイティブコードを実行するための仕様という意味ではPNaCLの改善版といえる WebAssemblyの命令セット (MIR) 処理系中立で安定した命令集合 LLVM bitcodeやPNaCLとは異なる目的(あちらは最適化) Safariや
Edgeでも 実装している Think Web (TechBooster)
Mono for WebAssembly? ブラウザで実行するMSILコード 過去の取り組み MSILからJSを生成(Script#、Bridge.NET、JSIL) ブラウザ プラグイン(Silverlight、Unity Web Player、PNaCl)
現代的な取り組みならWebAssemblyサポートではないか ilwasm ... で出来るレベルではなさそう Web APIへアクセスできるかという問題? => WebSharp WebAssembly post-MVP: ネイティブGC統合や動的ライブラリなど、課題はある
Mono for WebAssembly? dnfdn
まとめ Mono/Xamarinは未来の実行環境に対応できる? JIT: 仮想マシン命令からCPU命令を生成 AOT: 動的コード生成の禁止に対応 iOS LLVM backend: mono固有のコード生成エンジン以外に対応
bitcode: 安全な実行コードを意識した仮想マシン命令に対応 WatchOS WebAssemblyの時代にも生き残れる? Xamarinが将来求められる動作環境は?
その他の未来的トピック
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のみに
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でしょ。何でそんなことしたいの?」
Xamarin.Forms v3 Forms embedding Formsのページをプラットフォーム ネイティブのコントロールとして作成可能に これでFormsのページナビゲーションモデルからおさらばできる プラットフォームの追加 Xamarin.Mac、GTK#、WPF その他
CSS方式のスタイリング、FlexLayoutもどき、初期化時のみのバインディング、 fast rendererへの切り替え
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の実装(まだまだ実験的)