Freigeben über

Dateiressourcen in MRM

  • Artikel

Dateiressourcen in MRM sind im Wesentlichen identisch mit Zeichenfolgenressourcen, mit der Ausnahme, dass zur Laufzeit die Eigenschaft ResourceCandidate.Kind Pfad anstelle von Zeichenfolge ist. Die Ressourcenwerte sind nur Zeichenfolgen – die Dateinamen – und nicht der tatsächliche Dateiinhalt. In den meisten Fällen müssen die indizierten Dateien nicht einmal zur Buildzeit vorhanden sein.

Wenn Ihre Zielanwendung die integrierte MRT-Runtime (Windows.ApplicationModel.Resources) verwendet, können Sie ResourceCandidate.GetValueAsFileAsync oder ResourceCandidate.GetValueAsStreamAsync verwenden, um die Datei automatisch zu suchen und zu laden. Wenn Sie die WinApp SDK-Version von MRT (Microsoft.Windows.ApplicationModel.Resources) verwenden, müssen Sie die Datei manuell laden. Sie können die Datei auch manuell mit der Buit-in MRT-Laufzeit laden.

Es gibt zwei Möglichkeiten zum Hinzufügen von Dateien zum MRM-Indexer:

Beachten Sie, dass MrmIndexResourceContainerAutoQualifiers dem Indexer keine Dateiressource hinzufügen. Stattdessen wird die benannte Datei zur Buildzeit geladen und die eingebetteten Ressourcen direkt in den Indexer kopiert.

Für eine Alternative zum Verweisen auf Dateien anhand des Namens können Sie MrmIndexEmbeddedData verwenden, um Daten direkt in die PRI-Datei einzubetten . Weitere Informationen finden Sie unten unter Eingebettete Daten.

Benennen von Dateien

Der Hauptzweck der dateibasierten Ressource besteht darin, eine Zeichenfolge an Funktionen wie CreateFile(), fopen() oder den std::fstream-Konstruktor zu übergeben. Da der endgültige Pfad der Dateien zur Erstellungszeit normalerweise nicht bekannt ist, sind Dateinamen in der Regel relative Pfade, die im Arbeitsverzeichnis der App (oder einem anderen bekannten Verzeichnis) zur Laufzeit aufgelöst werden. Obwohl es möglich ist, beliebige Zeichenfolgen als Dateinamen (einschließlich absoluter oder Netzwerkpfade) einzuschließen, ist dies in der Regel nicht hilfreich.

Projektstamm- und relative Dateinamen

Beim Erstellen eines Indexers über eine der MrmCreateIndexer...-Funktionen müssen Sie einen projectRoot-Parameter angeben. Dieser Parameter wird von MrmIndexResourceContainerAutoQualifiers verwendet, um die Dateien auf dem Datenträger zu analysieren, und von MrmIndexFileAutoQualifiers, um relative Pfade aus absoluten Pfaden zu berechnen. Es wird von MrmIndexFile ignoriert.

Eingebettete Daten

Das Einbetten von Dateien als Daten kann den für Ihre App erforderlichen Speicherplatz verringern und die Leistung relativ zum Verweisen auf Dateinamen erhöhen. Dennoch gibt es einige Nachteile bei der Verwendung dieses Features, insbesondere bei der Entwicklung von inneren Schleifen-Apps.

In einem typischen Windows-System verschwendet jede Datei durchschnittlich 2 KB Speicherplatz, da Speicherplatz auf dem Datenträger zugewiesen wird. Bei Apps, die viele kleine Dateien (z. B. Symbole) enthalten, kann dieser Durchschnitt sogar höher sein. Durch das direkte Einbetten der Binärdateidaten in die PRI-Datei wird dieser Speicherplatz pro Datei nicht verschwendet.

Darüber hinaus ist das Laden externer Ressourcendateien langsamer als das direkte Lesen von Binärdaten aus der PRI-Datei, da jeder Vorgang zum Öffnen von Dateien zusätzliche Datenträgerzugriffe, Sicherheitsüberprüfungen usw. erfordert. Die PRI-Datei wird immer als Speicherabbilddatei geladen, sodass der Zugriff auf die Daten schneller erfolgt.

Trotz dieser Vorteile hat die Verwendung eingebetteter Binärdaten Einschränkungen, insbesondere bei der Innerschleifenentwicklung:

  • Buildzeiten werden erhöht, da die Dateien, die die Binärdaten enthalten, geladen und dem Indexer hinzugefügt werden müssen. Das Hinzufügen dateibasierter Ressourcen erfordert zur Erstellungszeit keinen zusätzlichen Datenträgerzugriff (der Datenträgerzugriff wird bis zur Laufzeit zurückgestellt).
  • Das Debuggen von Problemen mit der PRI-Datei (über XML-Dumps) ist schwieriger, da anstelle von lesbaren Dateinamen das XML-Dump BASE64-codierte Binärdaten enthält. Darüber hinaus werden die XML-Speicherabbilddateien erheblich größer sein, wodurch das Debuggen von Problemen erschwert wird.
  • Da der Inhalt der Dateien direkt in die PRI-Datei eingebettet ist, ist es nicht mehr möglich, Ressourcen sofort auszutauschen. Jede Änderung an einer eingebetteten Ressource erfordert eine vollständige Neuerstellung der PRI-Datei. Da dateibasierte Ressourcen nur den Dateinamen enthalten, können die tatsächlichen Ressourcendateien jederzeit aktualisiert werden.
  • Bei verpackten Apps können die im AppXManifest aufgeführten Bildressourcen, z. B. Startmenüsymbole, nicht eingebettet werden und müssen als Dateiressourcen angegeben werden.

Aus diesen Gründen besteht eine allgemeine Faustregel darin, dateibasierte Ressourcen während der Innerschleifenentwicklung zu verwenden, aber erwägen Sie die Verwendung eingebetteter binärer Ressourcen für endgültige Produktionsbuilds (mit Ausnahme der Manifestressourcen). Bei verpackten Apps sollten Sie die AppXManifest-Ressourcen (z. B. Startmenüsymbole) in einem separaten Directoy von anderen Ressourcen platzieren, um den Buildprozess zu vereinfachen (AppXManifest-Ressourcen werden als Dateien hinzugefügt und andere Ressourcen als eingebettete Daten hinzugefügt).