Delen via

Bestandsbronnen in MRM

  • Artikel

Bestandsresources in MRM zijn in wezen hetzelfde als tekenreeksresources, behalve dat tijdens runtime de eigenschap ResourceCandidate.Kind wordt Pad in plaats van tekenreeks. De resourcewaarden zijn alleen tekenreeksen , de bestandsnamen en niet de werkelijke bestandsinhoud. In de meeste gevallen hoeven de bestanden die worden geïndexeerd niet eens te bestaan tijdens het bouwen.

Als uw doeltoepassing gebruikmaakt van de ingebouwde MRT-runtime (Windows.ApplicationModel.Resources), kunt u ResourceCandidate.GetValueAsFileAsync of ResourceCandidate.GetValueAsStreamAsync gebruiken om het bestand automatisch voor u te zoeken en te laden. Als u de WinApp SDK-versie van MRT (Microsoft.Windows.ApplicationModel.Resources) gebruikt, moet u het bestand zelf handmatig laden. U kunt er ook voor kiezen om het bestand handmatig te laden met de buit-in MRT-runtime.

Er zijn twee manieren om bestanden toe te voegen aan de MRM-indexeerfunctie:

Houd er rekening mee dat MrmIndexResourceContainerAutoQualifiers geen bestandsresource aan de indexeerfunctie toevoegt; in plaats daarvan wordt het benoemde bestand tijdens de build-tijd geladen en worden de ingesloten resources rechtstreeks naar de indexeerfunctie gekopieerd.

Voor een alternatief om te verwijzen naar bestanden op naam, kunt u MrmIndexEmbeddedData gebruiken om gegevens rechtstreeks in het PRI-bestand in te sluiten. Zie Ingesloten gegevens hieronder voor meer informatie.

Naamgevingsbestanden

Het primaire doel van een bestandsresource is om een tekenreeks door te geven aan functies zoals CreateFile(), fopen()of de std::fstream constructor. Omdat het uiteindelijke pad naar de schijf van de bestanden doorgaans niet bekend is tijdens het bouwen, zijn bestandsnamen meestal relatieve paden die tijdens runtime worden omgezet in de werkmap van de app (of een andere bekende map). Hoewel het mogelijk is om willekeurige tekenreeksen op te nemen als bestandsnaam (inclusief absolute paden of netwerkpaden), is dit meestal niet nuttig.

Projecthoofdmap en relatieve bestandsnamen

Wanneer u een indexeerfunctie maakt via een van de functies MrmCreateIndexer..., moet u een projectRoot parameter opgeven. Deze parameter wordt gebruikt door MrmIndexResourceContainerAutoQualifiers om de bestanden op schijf te vinden die moeten worden geparseerd en door MrmIndexFileAutoQualifiers om relatieve paden van absolute paden te berekenen. Het wordt genegeerd door MrmIndexFile.

Ingesloten gegevens

Het insluiten van bestanden als gegevens kan de benodigde opslagruimte voor uw app verminderen en de prestaties verbeteren ten opzichte van het verwijzen naar bestandsnamen. Niettemin zijn er enkele nadelen van het gebruik van deze functie, met name tijdens het ontwikkelen van binnenlussen-apps.

Op een typisch Windows-systeem verspilt elk bestand gemiddeld 2 kB schijfruimte vanwege de manier waarop schijfruimte wordt toegewezen. Voor apps die veel kleine bestanden (zoals pictogrammen) bevatten, kan dit gemiddelde nog hoger zijn. Door de binaire bestandsgegevens rechtstreeks in het PRI-bestand in te sluiten, wordt deze ruimte per bestand niet verspild.

Bovendien is het laden van externe bronbestanden langzamer dan het lezen van binaire gegevens rechtstreeks uit het PRI-bestand, omdat voor elke open bewerking voor bestanden extra schijftoegang, beveiligingscontroles enzovoort zijn vereist. Het PRI-bestand wordt altijd geladen als een geheugentoewijzingsbestand, zodat het openen van de gegevens sneller is.

Ondanks deze voordelen heeft het gebruik van ingesloten binaire gegevens beperkingen, met name tijdens het ontwikkelen van interne lus:

  • Buildtijden worden verhoogd, omdat de bestanden met de binaire gegevens moeten worden geladen en aan de indexeerfunctie moeten worden toegevoegd. Het toevoegen van op bestanden gebaseerde resources vereist geen extra schijftoegang tijdens de build (de schijftoegang wordt uitgesteld tot runtime).
  • Foutopsporingsproblemen met het PRI-bestand (via XML-dumps) is moeilijker, omdat in plaats van door mensen leesbare bestandsnamen de XML-dump base64-gecodeerde binaire gegevens bevat. Daarnaast zijn de XML-dumpbestanden aanzienlijk groter, waardoor foutopsporing moeilijker wordt.
  • Omdat de inhoud van de bestanden rechtstreeks in het PRI-bestand is ingesloten, is het niet langer mogelijk om assets on-the-fly te verwisselen. Elke wijziging in een ingesloten resource vereist een volledige herbouw van het PRI-bestand. Omdat resources op basis van bestanden alleen de bestandsnaam bevatten, kunnen de werkelijke assetbestanden op elk gewenst moment worden bijgewerkt.
  • Voor verpakte apps kunnen de afbeeldingsbronnen die worden vermeld in het AppXManifest, zoals pictogrammen van het menu Start, niet worden ingesloten en moet worden opgegeven als bestandsbronnen.

Om deze redenen is een algemene vuistregel het gebruik van op bestanden gebaseerde resources tijdens het ontwikkelen van een interne lus, maar overweeg om ingesloten binaire resources te gebruiken voor uiteindelijke productie-builds (met uitzondering van de Manifest-resources). Voor verpakte apps kunt u overwegen om de AppXManifest-resources (zoals pictogrammen van het startmenu) in een afzonderlijke directoy van andere resources te plaatsen om het bouwproces te vereenvoudigen (AppXManifest-resources worden toegevoegd als bestanden en andere resources die als ingesloten gegevens worden toegevoegd).