Dela via

Filresurser i MRM

  • Artikel

Filresurser i MRM är i stort sett samma som Strängresurser, förutom att egenskapen ResourceCandidate.Kind egenskapPath i stället för String. Resursvärdena är bara strängar – filnamnen – och inte det faktiska filinnehållet. I de flesta fall behöver filerna som indexeras inte ens finnas vid bygget.

Om målprogrammet använder den inbyggda MRT-körningen (Windows.ApplicationModel.Resources) kan du använda ResourceCandidate.GetValueAsFileAsync eller ResourceCandidate.GetValueAsStreamAsync för att automatiskt hitta och läsa in filen åt dig. Om du använder WinApp SDK-versionen av MRT (Microsoft.Windows.ApplicationModel.Resources) måste du läsa in filen manuellt. Du kan också välja att läsa in filen manuellt med buit-in MRT-körningen.

Det finns två sätt att lägga till filer i MRM-indexeraren:

Observera att MrmIndexResourceContainerAutoQualifiers inte lägger till en filresurs i indexeraren. I stället läser den in den namngivna filen vid byggtiden och kopierar de inbäddade resurserna direkt till indexeraren.

Om du vill ha ett alternativ för att referera till filer efter namn kan du använda MrmIndexEmbeddedData för att bädda in data direkt i PRI-filen – se Embedded-data nedan för mer information.

Namnge filer

Det primära syftet med filbaserad resurs är att skicka en sträng till funktioner som CreateFile(), fopen()eller std::fstream konstruktor. Eftersom den sista sökvägen på disken för filerna vanligtvis inte är känd vid bygget är filnamn vanligtvis relativa sökvägar som kommer att matchas mot appens arbetskatalog (eller någon annan välkänd katalog) vid körning. Även om det är möjligt att inkludera valfri godtycklig sträng som filnamn (inklusive absoluta sökvägar eller nätverkssökvägar), är detta vanligtvis inte användbart.

Projektrot och relativa filnamn

När du skapar en indexerare via en av MrmCreateIndexer... funktioner måste du ange en projectRoot- parameter. Den här parametern används av MrmIndexResourceContainerAutoQualifiers för att hitta filerna på disken för att parsa och av MrmIndexFileAutoQualifiers för att beräkna relativa sökvägar från absoluta sökvägar. Det ignoreras av MrmIndexFile.

Inbäddade data

Om du bäddar in filer som data kan du minska det lagringsutrymme som krävs för din app och öka dess prestanda i förhållande till att referera till filnamn. Det finns dock vissa nackdelar med att använda den här funktionen, särskilt under utveckling av appar med inre loopar.

I ett typiskt Windows-system slösar varje fil i genomsnitt 2 kB diskutrymme på grund av hur diskutrymme allokeras. För appar som innehåller många små filer (t.ex. ikoner) kan det här genomsnittet vara ännu högre. Genom att bädda in binära fildata direkt i PRI-filen slösas inte det här utrymmet per fil bort.

Dessutom går det långsammare att läsa in externa resursfiler än att läsa in binära data direkt från PRI-filen, eftersom varje filöppningsåtgärd kräver ytterligare diskåtkomster, säkerhetskontroller och så vidare. PRI-filen läses alltid in som en minnesmappad fil, så det går snabbare att komma åt data.

Trots dessa fördelar har användning av inbäddade binära data begränsningar, särskilt under utveckling av inre loopar:

  • Byggtiden ökar eftersom filerna som innehåller binära data måste läsas in och läggas till i indexeraren. Att lägga till filbaserade resurser kräver ingen ytterligare diskåtkomst vid byggtiden (diskåtkomsten skjuts upp till körning).
  • Det är svårare att felsöka problem med PRI-filen (via XML-dumpar), eftersom XML-dumpen i stället för läsbara filnamn kommer att innehålla BASE64-kodade binära data. Dessutom blir XML-dumpfilerna betydligt större, vilket gör det svårare att felsöka eventuella problem.
  • Eftersom innehållet i filerna bäddas in direkt i PRI-filen går det inte längre att växla ut tillgångar direkt. Alla ändringar av en inbäddad resurs kräver en fullständig ombyggnad av PRI-filen. Eftersom filbaserade resurser endast innehåller filnamnet kan de faktiska tillgångsfilerna uppdateras när som helst.
  • För paketerade appar kan de bildresurser som anges i AppXManifest , till exempel Start-menyikoner, inte bäddas in och måste anges som filresurser.

Av dessa skäl är en allmän tumregel att använda filbaserade resurser under utveckling av inre loopar, men överväg att använda inbäddade binära resurser för slutliga produktionsversioner (förutom manifestresurserna). För paketerade appar bör du överväga att placera AppXManifest-resurserna (till exempel Start-menyikoner) i en separat directoy från andra resurser för att förenkla byggprocessen (AppXManifest-resurser läggs till som filer och andra resurser läggs till som inbäddade data).