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.8k
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
[COSCUP2024] Catching up Trends in Audio App Development
atsushieno
0
390
Building Kotlin Multiplatform Libraries in 2024
atsushieno
0
3.3k
Kotlin Multiplatformで MIDI 1.0/2.0 ライブラリを作っている話
atsushieno
1
640
building_audio_plugin_ecosystem_on_Android.pdf
atsushieno
0
1.1k
get updated to the latest realtime audio processings knowledge base (2023) (再履修: 2023年までの リアルタイムオーディオ処理)
atsushieno
1
1.1k
learning how DAWs work, with Zrythm
atsushieno
0
1.1k
What for, Where and How to Adopt MIDI 2.0
atsushieno
0
1.2k
audio plugin format study meetup 2022.7.6 (JP)
atsushieno
0
1.6k
CLAPオーディオプラグイン is 何?
atsushieno
1
1.3k
Other Decks in Programming
See All in Programming
タクシーアプリ『GO』のリアルタイムデータ分析基盤における機械学習サービスの活用
mot_techtalk
4
1.4k
Arm移行タイムアタック
qnighy
0
310
Nurturing OpenJDK distribution: Eclipse Temurin Success History and plan
ivargrimstad
0
880
Pinia Colada が実現するスマートな非同期処理
naokihaba
4
220
Flutterを言い訳にしない!アプリの使い心地改善テクニック5選🔥
kno3a87
1
150
Snowflake x dbtで作るセキュアでアジャイルなデータ基盤
tsoshiro
2
520
TypeScriptでライブラリとの依存を限定的にする方法
tutinoko
2
660
3rd party scriptでもReactを使いたい! Preact + Reactのハイブリッド開発
righttouch
PRO
1
600
subpath importsで始めるモック生活
10tera
0
300
聞き手から登壇者へ: RubyKaigi2024 LTでの初挑戦が 教えてくれた、可能性の星
mikik0
1
130
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
110
レガシーシステムにどう立ち向かうか 複雑さと理想と現実/vs-legacy
suzukihoge
14
2.2k
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
93
16k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Building Adaptive Systems
keathley
38
2.3k
Designing on Purpose - Digital PM Summit 2013
jponch
115
7k
The Cost Of JavaScript in 2023
addyosmani
45
6.7k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
GraphQLとの向き合い方2022年版
quramy
43
13k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Faster Mobile Websites
deanohume
305
30k
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の実装(まだまだ実験的)