Xamarin.Mac registrar

In diesem Dokument wird der Zweck von Xamarin.Mac registrar und die verschiedenen Verwendungskonfigurationen beschrieben.

Übersicht

Xamarin.Mac schließt die Lücke zwischen der verwalteten Welt (.NET) und der Runtime von Cocoa, sodass verwaltete Klassen nicht verwaltete Objective-C Klassen aufrufen und zurückgerufen werden können, wenn Ereignisse auftreten. Die Arbeit, die zum Vorformen dieser "Magie" erforderlich ist, wird von der registrar verarbeitet und wird im Allgemeinen aus der Sicht ausgeblendet.

Es gibt Auswirkungen dieser Registrierung auf die Leistung, insbesondere auf die Startzeit der Anwendung, und es kann manchmal hilfreich sein, ein wenig von den Vorgängen "unter der Haube" zu verstehen.

Configurations

Grundsätzlich kann der registrarAuftrag des Unternehmens beim Start in zwei Kategorien unterteilt werden:

  • Überprüfen Sie jede verwaltete Klasse auf die von NSObject abgeleiteten Klassen, und erfassen Sie eine Liste von Elementen, die für die Objective-C Laufzeit verfügbar gemacht werden sollen.
  • Registrieren Sie diese Informationen bei der Objective-C Runtime.

Im Laufe der Zeit wurden drei verschiedene registrar Konfigurationen erstellt, um verschiedene Anwendungsfälle abzudecken. Jede hat unterschiedliche Build- und Laufzeitfolgen:

  • Dynamische registrar – Verwenden Sie während des Starts die .NET-Reflektion, um jeden geladenen Typ zu überprüfen, die Liste der relevanten Elemente zu ermitteln und die native Runtime zu informieren. Diese Option fügt dem Build keine Zeit hinzu, ist aber beim Start sehr teuer (bis zu mehreren Sekunden).
  • Statische registrar – Berechnen Sie während des Buildvorgangs den Satz der zu registrierenden Elemente, und generieren Sie Objective-C Code für die Registrierung. Dieser Code wird während des Startvorgangs aufgerufen, um alle Elemente schnell zu registrieren. Fügt eine erhebliche Pause für den Build hinzu, kann jedoch einen erheblichen Zeitaufwand ab dem Anwendungsstart erzielen.
  • "Partielle" statisch : Ein neuerer "Hybrid"-Ansatz, der die meisten Vorteile beider bietet. Da die Exporte aus Xamarin.Mac.dll konstant sind, speichern Sie eine vorberechnete Bibliothek, um ihre Registrierung zu verarbeiten, und verknüpfen Sie diese in. Verwenden Sie Reflektion, um Benutzerbibliotheken zu behandeln, aber da Benutzerbibliotheken viel weniger Typen exportieren, die die Plattform bindungen, ist dies häufig ziemlich schnell. Eine vernachlässigbare Buildzeit wirkt sich auf die Buildzeit aus und reduziert einen Großteil der "Kosten" für dynamische.

Heute ist partielle statisch die Standardeinstellung für Debugkonfigurationen, und Statisch ist die Standardeinstellung für Releasekonfigurationen.

Es gibt einige Szenarien:

  • Nach dem Start geladene Plug-Ins mit klassen, die von NSObject abgeleitet sind
  • Dynamisch erstellte Klasseninstanzen, die von NSObject abgeleitet werden

, wobei die registrar nicht wissen kann, dass sie einen Typ zu Beginn registrieren muss. Die ObjCRuntime.Runtime.RegisterAssembly -Methode wird bereitgestellt, um zu registrar informieren, dass zusätzliche Typen berücksichtigt werden müssen.