Jak funguje Xamarin.Mac

Ve většině případů nebude vývojář nikdy muset mít obavy o interní "Magic" v Xamarin. Mac, ale s hrubou znalostí o tom, jak všechno funguje v digestoři, pomůžeme jak interpretovat stávající dokumentaci v jazyce C# Lens a ladit problémy, když k nim dojde.

V Xamarin. Mac, aplikační mosty dva světů: je k dispozici Objective-C modul runtime obsahující instance nativních tříd ( NSString , NSApplication atd.) a modul runtime jazyka C# obsahující instance spravovaných tříd ( System.String , atd HttpClient .). V rámci těchto dvou světů vytvoří Xamarin. Mac obousměrný most, takže aplikace může volat metody (selektory) v Objective-C (například NSApplication.Init ) a Objective-C může volat metody C# aplikace zpátky (jako metody v delegátu aplikace). Obecně jsou volání do aplikace Objective-C zpracovávána transparentně prostřednictvím Objective-C kódu a některé běhové kódy.

Vystavení tříd/metod jazyka C# pro Objective-C

Objective-CChcete-li však volat zpět do objektů C# aplikace, musí být vystaveny způsobem, který Objective-C může pochopit. To se provádí pomocí Register atributů a Export . Podívejte se na následující příklad:

[Register ("MyClass")]
public class MyClass : NSObject
{
   [Export ("init")]
   public MyClass ()
   {
   }

   [Export ("run")]
   public void Run ()
   {
   }
}

V tomto příkladu Objective-C bude modul runtime nyní znát třídu volanou MyClass Selektory s názvem init a run .

Ve většině případů se jedná o implementaci podrobností, kterou může vývojář ignorovat, protože většina zpětných volání, která aplikace obdrží, bude buď prostřednictvím přepsaných metod base třídy (například AppDelegate , Delegates ,), DataSources nebo na základě base předaných do rozhraní API. Ve všech těchto případech nejsou Export atributy nezbytné v kódu jazyka C#.

Runthrough konstruktoru

V mnoha případech vývojář bude potřebovat vystavit rozhraní API pro konstrukci tříd C# aplikace do Objective-C modulu runtime, aby bylo možné vytvořit instanci z míst, jako je například při volání ve scénáři nebo XIB soubory. Tady je pět nejběžnějších konstruktorů používaných v aplikacích Xamarin. Mac:

// Called when created from unmanaged code
public CustomView (IntPtr handle) : base (handle)
{
   Initialize ();
}

// Called when created directly from a XIB file
[Export ("initWithCoder:")]
public CustomView (NSCoder coder) : base (coder)
{
   Initialize ();
}

// Called from C# to instance NSView with a Frame (initWithFrame)
public CustomView (CGRect frame) : base (frame)
{
}

// Called from C# to instance NSView without setting the frame (init)
public CustomView () : base ()
{
}

// This is a special case constructor that you call on a derived class when the derived called has an [Export] constructor.
// For example, if you call init on NSString then you don’t want to call init on NSObject.
public CustomView () : base (NSObjectFlag.Empty)
{
}

Obecně by měl vývojář opustit IntPtrNSCoder konstruktory a, které jsou generovány při vytváření některých typů, jako je například vlastní NSViews . Pokud Xamarin. Mac potřebuje volat jeden z těchto konstruktorů v reakci na požadavek na Objective-C modul runtime a Vy jste ho odebrali, aplikace selže v nativním kódu a může být obtížné zjistit přesně problém.

Správa paměti a cykly

Správa paměti v Xamarin. Mac je v mnoha ohledech velmi podobná Xamarin. iOS. Je to také složité téma, které je nad rámec tohoto dokumentu. Přečtěte si prosím osvědčené postupy pro paměť a výkon.

Před kompilací času

Aplikace .NET se typicky nezkompiluje do strojového kódu, když jsou sestaveny, místo toho se zkompiluje do mezilehlé vrstvy s názvem IL, která při spuštění aplikace zkompiluje do strojového kódu kód za běhu.

Čas potřebný ke kompilaci modulu mono runtime do JIT může zpomalit spuštění aplikace Xamarin. Mac až do 20%, protože čas potřebný k vygenerování strojového kódu trvá déle.

Z důvodu omezení zavedených společností Apple v iOS není kompilace kódu IL v JIT k dispozici pro Xamarin. iOS. V důsledku toho jsou všechny aplikace Xamarin. iOS během cyklu sestavování zaplněné (AOT) zkompilovány do strojového kódu.

Novinka v Xamarin. Mac je možnost, že kód IL během cyklu sestavení aplikace je ve stromu AOT, stejně jako Xamarin. iOS může. Xamarin. Mac používá hybridní přístup k AOT, který kompiluje většinu potřebného strojového kódu, ale umožňuje, aby modul runtime zkompiluje potřebnou Trampolines a flexibilitu pro pokračování v podpoře reflexe. Emit (a další případy použití, které aktuálně pracují na Xamarin. Mac).

Existují dvě hlavní oblasti, kde může AOT pomáhat s aplikací Xamarin. Mac:

• Lepší "nativní" protokoly chyb – Pokud dojde k selhání aplikace Xamarin. Mac v nativním kódu, což je běžný výskyt při vytváření neplatných volání rozhraní API pro kakao (například odeslání do metody, která ji nepřijímá), nativní protokoly selhání s bloky JIT jsou obtížné analyzovat. Vzhledem k tomu, že rámce JIT neobsahují ladicí informace, bude k dispozici více řádků s šestnáctkovými posuny a bez příplatku. AOT vygeneruje "reálné" pojmenované snímky a trasování jsou mnohem snazší pro čtení. To také znamená, že aplikace Xamarin. Mac bude lépe spolupracovat s nativními nástroji, jako je lldb a instrumentace.
• Lepší výkon při spuštění – u rozsáhlých aplikací Xamarin. Mac s více sekundami spuštění kompilace kódu JIT může trvat poměrně dlouhou dobu. Tento pracovní stranu používá AOT.

Povoluje se kompilace AOT.

v Xamarin. Mac je povolený AOT tak, že dvakrát kliknete na název Project v Průzkumník řešení, přejdete na sestavení Mac a přidáte ho do dalších argumentů mmp: field (kde je jedna nebo více možností řízení typu AOT, viz níže). Například:

Možnosti kompilace AOT

Existuje několik různých možností, které je možné upravit při povolování kompilace AOT v aplikaci Xamarin. Mac:

• none -Žádná kompilace AOT. Toto je výchozí nastavení.
• all – AOT zkompiluje všechna sestavení v MonoBundle.
• core – AOT zkompiluje Xamarin.MacSystemmscorlib sestavení a.
• sdk – AOT zkompiluje Xamarin.Mac sestavení a knihovny základních tříd (BCL).
• |hybrid – Přidáním této možnosti k jedné z výše uvedených možností povolíte hybridní AOT, který umožňuje odstraňování IL, ale bude mít za následek delší dobu kompilace.
• + – Obsahuje jeden soubor pro kompilaci AOT.
• - – Odebere z kompilace AOT jeden soubor.

Například --aot:all,-MyAssembly.dll by povolovala KOMPILACI AOT na všech sestaveních v MonoBundle --aot:all,-MyAssembly.dllMyAssembly.dll a --aot:core|hybrid,+MyOtherAssembly.dll,-mscorlib.dll by povolovala hybridní, kód AOT zahrnuje MyOtherAssembly.dll a vylučuje mscorlib.dll .

částečný static registrar

Při vývoji aplikace Xamarin. Mac může být minimalizován čas mezi dokončením změny a testováním, který je důležitý pro splnění konečných termínů vývoje. Strategie, jako je modulárníace základů kódu a testování částí, můžou přispět k menší době kompilace, protože omezují počet, kolikrát bude aplikace vyžadovat nákladný úplný znovu Build.

A novinkou pro Xamarin. Mac, částečně static (jako pioneered podle Xamarin. iOS), může výrazně zkrátit dobu spouštění aplikace Xamarin. Mac v konfiguraci ladění . Porozumění způsobu, jakým lze použít částečný statický Registrar , může při spuštění ladění skoro využít pětinásobné vylepšení, bude mít na výběr trochu pozadí registrar , čím je rozdíl mezi statickým a dynamickým a co tato "částečně statická" verze dělá.

o registrar

V digestoři jakékoli aplikace Xamarin. Mac leží rozhraní kakaové Framework od společnosti Apple a modulu Objective-C runtime. Vytvoření mostu mezi tímto "nativním světem" a "spravovaným světem" jazyka C# je primární zodpovědností Xamarin. Mac. Část tohoto úkolu je zpracována pomocí registrar , který je proveden uvnitř NSApplication.Init () metody. To je jeden z důvodů, proč je nutné nejprve volat jakékoliv použití rozhraní API kakaa v Xamarin. Mac NSApplication.Init .

registrarÚkolem je informovat Objective-C modul runtime o existenci tříd C# aplikace, které jsou odvozeny z tříd, jako jsou NSApplicationDelegate ,, NSViewNSWindow a NSObject . To vyžaduje skenování všech typů v aplikaci, aby bylo možné zjistit, co je potřeba registrovat, a jaké prvky na jednotlivých typech se mají ohlásit.

Tuto kontrolu je možné provést dynamicky, při spuštění aplikace s reflexí nebo staticky, jako v čase sestavení. Při výběru typu registrace by měl vývojář znát následující:

• Statická registrace může značně snížit dobu spuštění, ale může zpomalit sestavení výrazně (obvykle více než dvojnásobný čas sestavení ladění). Toto je výchozí nastavení pro sestavení pro konfiguraci vydaných verzí .
• Dynamická registrace zpozdí tuto práci, dokud aplikace nespustí a neskočí generování kódu, ale tato další práce může při spuštění aplikace vytvořit znatelné pozastavení (nejméně dvě sekundy). To je obzvláště důležité v sestavách konfigurace ladění, které jsou ve výchozím nastavení dynamická registrace a jejichž reflexe je pomalejší.

Částečná statická registrace, která se poprvé zavádí v Xamarin. iOS 8,13, dává vývojáři nejlepší z obou možností. Pomocí předběžného zpracování informací o registraci každého prvku v Xamarin.Mac.dll a odeslání těchto informací do knihovny Xamarin. Mac ve statické knihovně (které je nutné propojit pouze v době sestavení) Společnost Microsoft odebrala většinu času odrazu dynamického, registrar přičemž neovlivňuje dobu sestavení.

registrátor do dalších argumentů MMP "title =" Přidání částečného statického registrar do dalších argumentů MMP "data-LINKTYPE =" relativní cesta "/>

Další materiály

Tady jsou podrobnější vysvětlení, jak fungují interně:

• Objective-C Selectors
• Registrátor "data-LINKTYPE =" relativní cestu ">Registrar
• Xamarin Unified API pro iOS a OS X
• Základy Theading
• Delegáti, protokoly a události
• Upozorňován