Risorse file in MRM
Le risorse di file in MRM sono essenzialmente le stesse delle risorse stringa, ad eccezione del fatto che in fase di esecuzione la proprietà ResourceCandidate.Kind sarà Path anziché String. I valori delle risorse sono solo stringhe, ovvero i nomi di file, e non il contenuto effettivo del file. Infatti, nella maggior parte dei casi i file indicizzati non devono nemmeno esistere in fase di compilazione.
Se l'applicazione di destinazione userà il runtime MRT predefinito (Windows.ApplicationModel.Resources), è possibile usare ResourceCandidate.GetValueAsFileAsync o ResourceCandidate.GetValueAsStreamAsync per individuare e caricare automaticamente il file. Se si usa la versione winApp SDK di MRT (Microsoft.Windows.ApplicationModel.Resources), è necessario caricare manualmente il file manualmente. È anche possibile scegliere di caricare manualmente il file con il runtime MRT buit-in.
Esistono due modi per aggiungere file all'indicizzatore MRM:
- MrmIndexFile è la funzione più generale e flessibile.
- MrmIndexFileAutoQualifiers deduce automaticamente sia il nome della risorsa che i qualificatori dal nome del file.
Si noti che MrmIndexResourceContainerAutoQualifiers non aggiunge una risorsa file all'indicizzatore, ma carica il file denominato in fase di compilazione e copia direttamente le risorse incorporate nell'indicizzatore.
Per un'alternativa a fare riferimento ai file in base al nome, è possibile usare MrmIndexEmbeddedData per incorporare i dati direttamente nel file PRI. Per altre informazioni, vedere Dati incorporati di seguito.
Lo scopo principale della risorsa basata su file è passare una stringa a funzioni come CreateFile(), fopen() o il costruttore std::fstream . Poiché il percorso finale su disco dei file in genere non è noto in fase di compilazione, i nomi di file sono in genere percorsi relativi che verranno risolti nella directory di lavoro dell'app (o in un'altra directory nota) in fase di esecuzione. Anche se è possibile includere qualsiasi stringa arbitraria come nome file (inclusi i percorsi assoluti o di rete), questo in genere non è utile.
Quando si crea un indicizzatore tramite una delle funzioni MrmCreateIndexer... è necessario specificare un parametro projectRoot . Questo parametro viene usato da MrmIndexResourceContainerAutoQualifiers per individuare i file su disco da analizzare e da MrmIndexFileAutoQualifiers per calcolare i percorsi relativi dai percorsi assoluti. Viene ignorato da MrmIndexFile.
L'incorporamento dei file come dati può ridurre lo spazio di archiviazione necessario per l'app e aumentarne le prestazioni rispetto ai nomi file di riferimento. Tuttavia, esistono alcuni svantaggi per l'uso di questa funzionalità, in particolare durante lo sviluppo di app a ciclo interno.
In un sistema Windows tipico, ogni file perde una media di 2 kb di spazio su disco a causa della modalità di allocazione dello spazio su disco. Per le app che contengono molti file di piccole dimensioni (ad esempio icone), questa media può essere ancora più elevata. Incorporando i dati del file binario direttamente nel file PRI, questo spazio per file non viene sprecato.
Inoltre, il caricamento di file di risorse esterne è più lento rispetto alla lettura dei dati binari direttamente dal file PRI, poiché ogni operazione di apertura file richiede accessi aggiuntivi su disco, controlli di sicurezza e così via. Il file PRI viene sempre caricato come file mappato alla memoria, quindi l'accesso ai dati è più veloce.
Nonostante questi vantaggi, l'uso di dati binari incorporati presenta limitazioni, in particolare durante lo sviluppo di cicli interni:
- I tempi di compilazione vengono aumentati, poiché i file contenenti i dati binari devono essere caricati e aggiunti all'indicizzatore. L'aggiunta di risorse basate su file non richiede alcun accesso aggiuntivo al disco in fase di compilazione (l'accesso al disco viene posticipato fino al runtime).
- Il debug dei problemi relativi al file PRI (tramite dump XML) è più difficile, poiché invece dei nomi file leggibili dall'utente il dump XML conterrà dati binari con codifica BASE64. Inoltre, i file di dump XML saranno notevolmente più grandi, rendendo più difficile il debug di eventuali problemi.
- Poiché il contenuto dei file è incorporato direttamente nel file PRI, non è più possibile scambiare asset in tempo reale. Qualsiasi modifica a qualsiasi risorsa incorporata richiederà una ricompilazione completa del file PRI. Poiché le risorse basate su file includono solo il nome file, i file di asset effettivi possono essere aggiornati in qualsiasi momento.
- Per le app in pacchetto, le risorse dell'immagine elencate in AppXManifest, ad esempio le icone del menu Start, non possono essere incorporate e devono essere specificate come risorse file.
Per questi motivi, una regola generale generale consiste nell'usare le risorse basate su file durante lo sviluppo di cicli interni, ma è consigliabile usare risorse binarie incorporate per le compilazioni di produzione finali (ad eccezione delle risorse manifesto). Per le app in pacchetto, è consigliabile inserire le risorse AppXManifest (ad esempio le icone del menu Start) in un directoy separato da altre risorse per semplificare il processo di compilazione (le risorse AppXManifest vengono aggiunte come file e altre risorse aggiunte come dati incorporati).