Entwickeln mit Ressourcenpaketen und Paketfaltung

Bestandspakete können die Gesamtgröße der Verpackung und die Veröffentlichungszeit für Ihre Apps im Store verringern. Weitere Informationen zu Bestandspaketen und dazu, wie sie Ihre Entwicklungsiterationen beschleunigen kann, finden Sie unter "Einführung in Bestandspakete".

Wenn Sie über die Verwendung von Bestandspaketen für Ihre App nachdenken oder bereits wissen, dass Sie sie verwenden möchten, fragen Sie sich wahrscheinlich, wie Bestandspakete Ihren Entwicklungsprozess ändern werden. Kurz gesagt: Die App-Entwicklung bleibt für Sie unverändert. Dies ist aufgrund der Paketfaltung für Ressourcenpakete möglich.

Dateizugriff nach dem Teilen der App

Um zu verstehen, wie sich die Paketfaltung nicht auf Ihren Entwicklungsprozess auswirkt, gehen wir zunächst zurück, um zu verstehen, was passiert, wenn Sie Ihre App in mehrere Pakete aufteilen (mit Bestandspaketen oder Ressourcenpaketen).

Wenn Sie einige Der Dateien Ihrer App auf hoher Ebene in andere Pakete aufteilen (die keine Architekturpakete sind), können Sie nicht direkt auf diese Dateien zugreifen, wenn Der Code ausgeführt wird. Dies liegt daran, dass diese Pakete alle in anderen Verzeichnissen installiert werden, als das Verzeichnis, in dem ihr Architekturpaket installiert ist. Wenn Sie beispielsweise ein Spiel erstellen und Ihr Spiel in Französisch und Deutsch lokalisiert ist und Sie sowohl für x86- als auch für x64-Computer erstellt haben, sollten Sie diese App-Paketdateien im App-Bündel Ihres Spiels haben:

• MyGame_1.0_x86.appx
• MyGame_1.0_x64.appx
• MyGame_1.0_language-fr.appx
• MyGame_1.0_language-de.appx

Wenn Ihr Spiel auf dem Computer eines Benutzers installiert ist, verfügt jede App-Paketdatei über einen eigenen Ordner im WindowsApps-Verzeichnis . Für einen französischen Benutzer mit 64-Bit-Windows sieht Ihr Spiel also wie folgt aus:

C:\Program Files\WindowsApps\
|-- MyGame_1.0_x64
|   `-- …
|-- MyGame_1.0_language-fr
|   `-- …
`-- …(other apps)

Beachten Sie, dass die für den Benutzer nicht anwendbaren App-Paketdateien nicht installiert werden (die x86- und die deutschen Pakete).

Für diesen Benutzer befindet sich die haupt ausführbare Datei Ihres Spiels im Ordner MyGame_1.0_x64 und wird von dort ausgeführt, und normalerweise hat es nur Zugriff auf die Dateien in diesem Ordner. Um auf die Dateien im Ordner "MyGame_1.0_language-fr " zuzugreifen, müssten Sie entweder die MRT-APIs oder die PackageManager-APIs verwenden. Die MRT-APIs können automatisch die am besten geeignete Datei aus den installierten Sprachen auswählen. Weitere Informationen zu MRT-APIs finden Sie unter Windows.ApplicationModel.Resources.Core. Alternativ können Sie den installierten Speicherort des französischen Sprachpakets mithilfe der PackageManager-Klasse finden. Sie sollten niemals davon ausgehen, wo sich die Pakete Ihrer App befinden, da sich deren Standort ändern kann und je nach Benutzer unterschiedlich sein kann.

Faltung von Ressourcenpaketen

Wie können Sie also auf die Dateien in Ihren Bestandspaketen zugreifen? Nun, Sie können weiterhin die Dateizugriffs-APIs verwenden, die Sie für den Zugriff auf jede andere Datei in Ihrem Architekturpaket verwenden. Dies liegt daran, dass Bestandspaketdateien beim Installieren über den Paketfaltungsprozess in Ihr Architekturpaket gefaltet werden. Da Bestandspaketdateien ursprünglich Dateien in Ihren Architekturpaketen sein sollten, bedeutet dies, dass Sie die API-Verwendung nicht ändern müssen, wenn Sie von der Bereitstellung loser Dateien zur verpackten Bereitstellung in Ihrem Entwicklungsprozess wechseln.

Um mehr über die Funktionsweise der Paketfaltung zu erfahren, beginnen wir mit einem Beispiel. Wenn Sie über ein Spielprojekt mit der folgenden Dateistruktur verfügen:

MyGame
|-- Audios
|   |-- Level1
|   |   `-- ...
|   `-- Level2
|       `-- ...
|-- Videos
|   |-- Level1
|   |   `-- ...
|   `-- Level2
|       `-- ...
|-- Engine
|   `-- ...
|-- XboxLive
|   `-- ...
`-- Game.exe

Wenn Sie Ihr Spiel in 3 Pakete aufteilen möchten: ein x64-Architekturpaket, ein Bestandspaket für Audios und ein Bestandspaket für Videos, wird Ihr Spiel in diese Pakete unterteilt:

MyGame_1.0_x64.appx
|-- Engine
|   `-- ...
|-- XboxLive
|   `-- ...
`-- Game.exe
MyGame_1.0_Audios.appx
`-- Audios
    |-- Level1
    |   `-- ...
    `-- Level2
        `-- ...
MyGame_1.0_Videos.appx
`-- Videos
    |-- Level1
    |   `-- ...
    `-- Level2
        `-- ...

Wenn Sie Ihr Spiel installieren, wird das x64-Paket zuerst bereitgestellt. Dann werden die beiden Bestandspakete weiterhin in ihren eigenen Ordnern bereitgestellt, genau wie MyGame_1.0_language-fr aus unserem vorherigen Beispiel. Aufgrund der Paketbündelung werden die Ressourcenpaketdateien jedoch auch hart verknüpft, damit sie im Ordner MyGame_1.0_x64 erscheinen (auch wenn die Dateien an zwei Speicherorten angegeben sind, belegen sie nicht doppelt den Speicherplatz). Der Speicherort, an dem die Ressourcenpaketdateien angezeigt werden, ist genau der Speicherort, an dem sie sich relativ zum Stamm des Pakets befinden. So sieht das endgültige Layout des bereitgestellten Spiels wie folgt aus:

C:\Program Files\WindowsApps\
|-- MyGame_1.0_x64
|   |-- Audios
|   |   |-- Level1
|   |   |   `-- ...
|   |   `-- Level2
|   |       `-- ...
|   |-- Videos
|   |   |-- Level1
|   |   |   `-- ...
|   |   `-- Level2
|   |       `-- ...
|   |-- Engine
|   |   `-- ...
|   |-- XboxLive
|   |   `-- ...
|   `-- Game.exe
|-- MyGame_1.0_Audios
|   `-- Audios
|       |-- Level1
|       |   `-- ...
|       `-- Level2
|           `-- ...
|-- MyGame_1.0_Videos
|   `-- Videos
|       |-- Level1
|       |   `-- ...
|       `-- Level2
|           `-- ...
`-- …(other apps)

Wenn Sie die Paketfaltung für Bestandspakete verwenden, können Sie weiterhin auf die Dateien zugreifen, die Sie auf die gleiche Weise in Bestandspakete aufgeteilt haben (beachten Sie, dass der Architekturordner genau dieselbe Struktur wie der ursprüngliche Projektordner hat), und Sie können Bestandspakete hinzufügen oder Dateien zwischen Objektpaketen verschieben, ohne dass der Code beeinträchtigt wird.

Jetzt für ein komplizierteres Paketfaltungsbeispiel. Angenommen, Sie möchten Ihre Dateien stattdessen auf der Ebene aufteilen und wenn Sie die gleiche Struktur wie das ursprüngliche Projektverzeichnis beibehalten möchten, sollten Ihre Pakete wie folgt aussehen:

MyGame_1.0_x64.appx
|-- Engine
|   `-- ...
|-- XboxLive
|   `-- ...
`-- Game.exe
MyGame_Level1.appx
|-- Audios
|   `-- Level1
|       `-- ...
`-- Videos
    `-- Level1
        `-- ...

MyGame_Level2.appx
|-- Audios
|   `-- Level2
|       `-- ...
`-- Videos
    `-- Level2
        `-- ...

Dadurch können die Ordner und Dateien von Ebene1 im Paket MyGame_Level1 und von Ebene2 im Paket MyGame_Level2 während der Paketfaltung in den Ordnern Audios und Videos zusammengeführt werden. In der Regel ist der relative Pfad, der für verpackte Dateien in der Zuordnungsdatei oder im Verpackungslayout für MakeAppx.exe festgelegt ist, der Pfad, mit dem Sie nach der Paketfaltung darauf zugreifen sollten.

Wenn zwei Dateien in unterschiedlichen Objektpaketen vorhanden sind, die dieselben relativen Pfade aufweisen, führt dies zu einer Kollision während der Paketfaltung. Wenn eine Kollision auftritt, führt die Bereitstellung Ihrer App zu einem Fehler und schlägt fehl. Da die Paketfaltung harte Links nutzt, kann Ihre App nicht auf Nicht-NTFS-Laufwerken bereitgestellt werden, wenn Sie Ressourcenpakete verwenden. Wenn Sie wissen, dass Ihre App wahrscheinlich von Ihren Benutzern auf Wechseldatenträger verschoben wird, sollten Sie keine Asset-Pakete verwenden.