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.7k
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
Kotlin Multiplatformで MIDI 1.0/2.0 ライブラリを作っている話
atsushieno
1
380
building_audio_plugin_ecosystem_on_Android.pdf
atsushieno
0
930
get updated to the latest realtime audio processings knowledge base (2023) (再履修: 2023年までの リアルタイムオーディオ処理)
atsushieno
1
950
learning how DAWs work, with Zrythm
atsushieno
0
960
What for, Where and How to Adopt MIDI 2.0
atsushieno
0
1.1k
audio plugin format study meetup 2022.7.6 (JP)
atsushieno
0
1.4k
CLAPオーディオプラグイン is 何?
atsushieno
1
1k
MML to MIDI 2.0 to DAW
atsushieno
1
1.8k
Designing Audio Plugin Framework for Android
atsushieno
1
1.1k
Other Decks in Programming
See All in Programming
ここ1~2年くらいで 使えるようになった(主要ブラウザーの最新版 がすべて対応した ) ウェブの新機能について ランダムに喋る!
myzkyy
9
6.4k
受託開発でGitLab CI を活用していく
xiombatsg
1
100
品質とスピードを両立: TypeScriptの柔軟な型システムをバックエンドで活用する
kosui
4
860
オブジェクト指向は必要なのか / Is object-oriented needed?
kishida
27
19k
生成 AI の中身を覗いてみよう〜基礎から医療現場での応用まで〜
soh9834
2
760
DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁
pospome
24
7.3k
ISUCONってなんだか難しそう……!!でも、初めてのISUCONにPHPで挑戦してきました!
kotomin_m
1
300
PHPでOfficeファイルを取り扱う! PHP Officeライブラリを プロダクトに組み込んだ話
hirobe1999
0
840
C# 大統一理論推進委員会 会員のための Unity Package Manager プロジェクト構成案
monry
PRO
0
580
せっかくモデル図描くのなら、嬉しいことが多い方がいいよね!
kuboaki
1
1.7k
品質が高いコードって何?Rev2.1
ickx
1
490
Prepare for Jakarta EE 11 - Performance and Developer Productivity
ivargrimstad
0
490
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
57
14k
Code Review Best Practice
trishagee
54
15k
A Philosophy of Restraint
colly
195
15k
Rebuilding a faster, lazier Slack
samanthasiow
72
8.2k
JazzCon 2018 Closing Keynote - Leadership for the Reluctant Leader
reverentgeek
178
11k
Ruby is Unlike a Banana
tanoku
95
10k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
24
2.2k
Web development in the modern age
philhawksworth
201
10k
Done Done
chrislema
178
15k
How To Stay Up To Date on Web Technology
chriscoyier
781
250k
Statistics for Hackers
jakevdp
789
220k
Six Lessons from altMBA
skipperchong
19
2.9k
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の実装(まだまだ実験的)