Sviluppo con pacchetti di asset e riduzione dei pacchetti

Importante

Se si intende inviare l'app allo Store, è necessario contattare il Windows per gli sviluppatori e ottenere l'approvazione per usare i pacchetti di asset e la funzionalità di ripiegamento dei pacchetti.

I pacchetti di asset possono ridurre le dimensioni complessive dei pacchetti e il tempo di pubblicazione per le app in Store. Per altre informazioni sui pacchetti di asset e su come velocizzare le iterazioni di sviluppo, vedere Introduzione ai pacchetti di asset.

Se si sta pensando di usare i pacchetti di asset per l'app o si sa già che si vuole usarla, probabilmente ci si chiede come i pacchetti di asset modificheranno il processo di sviluppo. In breve, lo sviluppo di app per l'utente rimane lo stesso: ciò è possibile a causa della ripiega dei pacchetti per i pacchetti di asset.

Accesso ai file dopo la suddivisione dell'app

Per comprendere in che modo la suddivisione dei pacchetti non influisce sul processo di sviluppo, è prima necessario tornare indietro per comprendere cosa accade quando si suddivide l'app in più pacchetti (con pacchetti di asset o pacchetti di risorse).

A livello di alto livello, quando si suddivideno alcuni file dell'app in altri pacchetti (che non sono pacchetti di architettura), non sarà possibile accedere a tali file direttamente rispetto alla posizione in cui viene eseguito il codice. Questo perché questi pacchetti vengono tutti installati in directory diverse da quelle in cui è installato il pacchetto dell'architettura. Ad esempio, se si sta facendo un gioco e il gioco è localizzato in francese e tedesco ed è stato compilato per computer x86 e x64, è necessario avere questi file del pacchetto dell'app all'interno del bundle di app del gioco:

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

Quando il gioco viene installato nel computer di un utente, ogni file del pacchetto dell'app avrà la propria cartella nella directory WindowsApps. Pertanto, per un utente francese che esegue Windows a 64 bit, il gioco sarà simile al seguente:

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

Si noti che i file del pacchetto dell'app che non sono applicabili all'utente non verranno installati (i pacchetti x86 e tedesco).

Per questo utente, il file eseguibile principale del gioco si trova all'interno della cartella MyGame_1.0_x64 e verrà eseguito da tale cartella e in genere avrà accesso solo ai file all'interno di questa cartella. Per accedere ai file nella cartella MyGame_1.0_language-fr, è necessario usare le API MRT o PackageManager. Le API MRT possono selezionare automaticamente il file più appropriato dalle lingue installate. Per altre informazioni sulle API MRT, vedere Windows. ApplicationModel.Resources.Core. In alternativa, è possibile trovare il percorso installato del pacchetto in lingua francese usando la classe PackageManager. Non si deve mai presupporre che il percorso installato dei pacchetti dell'app possa cambiare e variare tra gli utenti.

Ripiegamento del pacchetto di asset

Quindi, come è possibile accedere ai file nei pacchetti di asset? È anche possibile continuare a usare le API di accesso ai file usate per accedere a qualsiasi altro file nel pacchetto dell'architettura. Ciò è dovuto al fatto che i file dei pacchetti di asset verranno ripiegati nel pacchetto dell'architettura quando viene installato tramite il processo di ripiegamento del pacchetto. Inoltre, poiché i file dei pacchetti di asset in origine devono essere file all'interno dei pacchetti dell'architettura, ciò significa che non è necessario modificare l'utilizzo dell'API quando si passa dalla distribuzione di file separati alla distribuzione in pacchetto nel processo di sviluppo.

Per altre informazioni sul funzionamento della folding dei pacchetti, si inizierà con un esempio. Se si dispone di un progetto di gioco con la struttura di file seguente:

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

Se si vuole suddividere il gioco in 3 pacchetti: un pacchetto di architettura x64, un pacchetto di asset per audio e un pacchetto di asset per i video, il gioco verrà suddiviso in questi pacchetti:

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
        `-- ...

Quando si installa il gioco, il pacchetto x64 verrà distribuito per primo. I due pacchetti di asset verranno comunque distribuiti nelle proprie cartelle, proprio come MyGame_1.0_language-fr dell'esempio precedente. Tuttavia, a causa della ripiega dei pacchetti, anche i file del pacchetto asset saranno collegati in modo rigido per essere visualizzati nella cartella MyGame_1.0_x64. Pertanto, anche se i file vengono visualizzati in due posizioni, lo spazio su disco non è doppio. Il percorso in cui verranno visualizzati i file del pacchetto asset è esattamente il percorso in cui si trova rispetto alla radice del pacchetto. Ecco quindi come sarà il layout finale del gioco distribuito:

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)

Quando si usa la suddivisione dei pacchetti per i pacchetti di asset, è comunque possibile accedere ai file suddivisi in pacchetti di asset nello stesso modo (si noti che la cartella architecture ha la stessa struttura della cartella del progetto originale) ed è possibile aggiungere pacchetti di asset o spostare file tra pacchetti di asset senza influire sul codice.

A questo punto, per un esempio di folding dei pacchetti più complesso. Si supponiamo di voler dividere i file in base al livello e che, se si vuole mantenere la stessa struttura della cartella del progetto originale, i pacchetti dovrebbero avere un aspetto simile al seguente:

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

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

In questo modo le cartelle e i file di livello 1 nel pacchetto MyGame_Level1 e le cartelle e i file di livello 2 nel pacchetto MyGame_Level2 verranno uniti nelle cartelle Audio e Video durante la ripiegamento del pacchetto. Pertanto, come regola generale, il percorso relativo designato per i file in pacchetto nel file di mapping o nel layout di creazione pacchetti per MakeAppx.exe è il percorso da usare per accedervi dopo la creazione del pacchetto.

Infine, se sono presenti due file in pacchetti di asset diversi che hanno gli stessi percorsi relativi, si verifica un conflitto durante la ripiega del pacchetto. Se si verifica un conflitto, la distribuzione dell'app genererà un errore e avrà esito negativo. Inoltre, poiché la compressione dei pacchetti sfrutta i collegamenti rigidi, se si usano pacchetti di asset, l'app non sarà in grado di essere distribuita in unità non NTFS. Se si sa che l'app verrà probabilmente spostata in unità rimovibili dagli utenti, non è consigliabile usare i pacchetti di asset.