MRTK Modularisierung — MRTK2

Eine der großartigen neuen Features von Mixed Reality Toolkit v2 ist die Komponentenisierung verbessert. Wo immer möglich, werden einzelne Komponenten von allen, aber der Kernebene der Stiftung isoliert.

Minimierte Abhängigkeiten

MRTK v2 wurde absichtlich entwickelt, um modular zu sein und Abhängigkeiten zwischen Systemdiensten zu minimieren (z. B. räumliches Bewusstsein).

Aufgrund der Art einiger Systemdienste (z. B. Eingabe und Teleportierung) gibt es eine kleine Anzahl von Abhängigkeiten.

Obwohl erwartet wird, dass Dienste eine oder mehrere Datenanbieterkomponenten benötigen, gibt es keine direkten Verknüpfungen zwischen ihnen. Das gleiche gilt für SDK-Features (z. B. Benutzeroberflächenkomponenten).

Komponentenkommunikation

Um sicherzustellen, dass keine direkten Verbindungen zwischen Komponenten vorhanden sind, nutzt MRTK v2 Schnittstellen, um zwischen Diensten, Datenanbietern und Anwendungscode zu kommunizieren. Diese Schnittstellen werden definiert, und alle Kommunikation werden über die Mixed Reality Toolkit-Kernkomponente weitergeleitet.

Minimieren des MRTK-Importbedarfs

In diesem Moment wird MRTK als einzelnes Foundation-Paket importiert (die Existenz des Beispielpakets wird ignoriert, was ein vollständig optionales Paket ist). Es ist möglich, diesen Fußabdruck zu verkleineren, indem die importierten Dateien manuell verkleinert werden, obwohl dies ein sehr manueller Prozess ist, der keine gut definierte Anleitung hat.

Es ist möglich, beliebige Elemente während des Imports des Foundation-Pakets zu deaktivieren. Es wird jedoch nicht empfohlen, dies in einer frühen Phase der Entwicklung zu tun, da sie die Funktionalität unterbrechen kann. Nachdem Sie den endgültigen Featuresatz einer App ermittelt haben, können nicht benötigte Anbieter und Dienste in den folgenden Ordnern geschnitten werden:

• MRTK/Services
• MRTK/Anbieter
• MRTK/SDK/Features

Hinweis

MRTK v2.x erfordert den Inhalt des Ordners "Assets/MRTK/Core".

Nächste Features

Anwendungsarchitektur

MRTK wird Unterstützung haben, um Anwendungen zu ermöglichen, die mit einer Vielzahl von Architekturen erstellt werden können, einschließlich:

• MixedRealityToolkit-Dienst-Locator
• Einzelne Dienste
• Benutzerdefinierter Dienst-Locator
• Hybridarchitektur

Bei der Auswahl einer Anwendungsarchitektur ist es wichtig, die Entwurfsflexibilität und die Anwendungsleistung zu berücksichtigen. Die hier beschriebenen Architekturen werden nicht für jede Anwendung geeignet sein.

MixedRealityToolkit-Dienst-Locator

MRTK aktiviert (und konfiguriert automatisch) Anwendungsszenen, um die Standard-Dienst-Locator-Komponente MixedRealityToolkit zu verwenden. Diese Komponente enthält Unterstützung für die Konfiguration von MRTK-Systemen und Datenanbietern über Konfigurationsinspektoren und verwaltet Komponentenlebensdauern und Kernverhalten (z. B. wann aktualisiert werden soll).

Alle Systeme werden im Kernkonfigurationsinspektor dargestellt, unabhängig davon, ob sie im Projekt vorhanden oder nicht aktiviert sind. Weitere Informationen finden Sie im Mixed Reality Konfigurationshandbuch.

Einzelne Dienstkomponenten

Einige Entwickler haben den Wunsch geäußert, einzelne Dienstkomponenten in die Anwendungsszenehierarchie einzuschließen. Um diese Nutzung zu ermöglichen, müssen Dienste entweder in einer benutzerdefinierten Registrierungsstelle gekapselt werden oder selbst registrieren / selbst verwalten.

Ein Selbstregistrierungsdienst implementiert und registriert sich IMixedRealityServiceRegistrar selbst, sodass der Anwendungscode die Dienstinstanz über eine Registrierung ermitteln könnte.

Ein Selbstverwaltungsdienst könnte als Singleton-Objekt in der Szenenhierarchie implementiert werden. Dieses Objekt würde eigenschaft bereitstellen und instanzieren, mit der anwendungscode direkt auf Dienstfunktionen zugreifen kann.

Benutzerdefinierter Dienst-Locator

Einige Entwickler haben die Möglichkeit angefordert, eine benutzerdefinierte Dienst-Locator-Komponente zu erstellen. Benutzerdefinierte Dienst-Locators würden die IMixedRealityServiceRegistrar Schnittstelle implementieren und den Lebenszyklus und das Kernverhalten aktiver Dienste verwalten.

Hybridarchitektur

MRTK unterstützt eine Hybridarchitektur, in der Entwickler die vorherigen Ansätze nach Bedarf oder Wunsch kombinieren können. Beispielsweise könnte ein Entwickler mit dem MixedRealityToolkit Dienst-Locator beginnen und einen Selbstregistrierungsdienst hinzufügen.

Hinweis

Wenn Sie sich für eine Hybridarchitektur entscheiden, ist es wichtig, jede Duplizierung der Arbeit zu berücksichtigen (z. B. das Erwerben von Controllerdaten aus mehreren Komponenten).