Partager via

Ressources de fichier dans MRM

  • Article

Les ressources de fichier dans MRM sont essentiellement les mêmes que les ressources de chaîne, sauf qu’à l’exécution, la propriété ResourceCandidate.Kind sera Path au lieu de String. Les valeurs de ressources ne sont que des chaînes - les noms de fichiers - et non le contenu réel des fichiers. En fait, dans la plupart des cas, les fichiers indexés n’ont même pas besoin d’exister lors de la compilation.

Si votre application cible utilise le runtime MRT intégré (Windows.ApplicationModel.Resources), vous pouvez utiliser ResourceCandidate.GetValueAsFileAsync ou ResourceCandidate.GetValueAsStreamAsync pour localiser et charger automatiquement le fichier. Si vous utilisez la version MRT du SDK WinApp (Microsoft.Windows.ApplicationModel.Resources), vous devrez charger manuellement le fichier vous-même. Vous pouvez également choisir de charger manuellement le fichier avec le runtime MRT intégré.

Il existe deux façons d’ajouter des fichiers à l’indexeur MRM :

  • MrmIndexFile est la fonction la plus générale et la plus flexible.
  • MrmIndexFileAutoQualifiers déduit automatiquement à la fois le nom de la ressource et les qualificateurs à partir du nom du fichier.

Notez que MrmIndexResourceContainerAutoQualifiers n’ajoute pas une ressource de fichier à l’indexeur ; à la place, il charge le fichier nommé lors de la compilation et copie directement les ressources intégrées dans l’indexeur.

Comme alternative à la référence des fichiers par nom, vous pouvez utiliser MrmIndexEmbeddedData pour intégrer directement les données dans le fichier PRI - veuillez consulter la section Données intégrées ci-dessous pour plus d’informations.

Noms des fichiers

Le principal objectif des ressources basées sur des fichiers est de passer une chaîne à des fonctions telles que CreateFile(), fopen(), ou le constructeur std::fstream. Étant donné que le chemin final sur disque des fichiers n’est généralement pas connu lors de la compilation, les noms de fichiers sont généralement des chemins relatifs qui seront résolus par rapport au répertoire de travail de l’application (ou un autre répertoire bien connu) à l’exécution. Bien qu’il soit possible d’inclure une chaîne arbitraire comme nom de fichier (y compris des chemins absolus ou des chemins réseau), cela est généralement peu utile.

Racine du projet et noms de fichiers relatifs

Lors de la création d’un indexeur via l’une des fonctions MrmCreateIndexer..., vous devez spécifier un paramètre projectRoot. Ce paramètre est utilisé par MrmIndexResourceContainerAutoQualifiers pour localiser les fichiers sur le disque à analyser, et par MrmIndexFileAutoQualifiers pour calculer les chemins relatifs à partir des chemins absolus. Il est ignoré par MrmIndexFile.

Données intégrées

Intégrer des fichiers sous forme de données peut réduire l’espace de stockage requis pour votre application et améliorer ses performances par rapport à la référence des noms de fichiers. Néanmoins, il existe quelques inconvénients à utiliser cette fonctionnalité, en particulier pendant le développement d’applications en boucle interne.

Sur un système Windows typique, chaque fichier gaspille en moyenne 2 Ko d’espace disque en raison de la façon dont l’espace disque est alloué. Pour les applications contenant de nombreux petits fichiers (comme des icônes), cette moyenne peut être encore plus élevée. En intégrant directement les données binaires des fichiers dans le fichier PRI, cet espace par fichier n’est pas gaspillé.

De plus, le chargement de fichiers de ressources externes est plus lent que la lecture des données binaires directement à partir du fichier PRI, car chaque opération d’ouverture de fichier nécessite des accès supplémentaires au disque, des contrôles de sécurité, etc. Le fichier PRI est toujours chargé en tant que fichier mappé en mémoire, donc l’accès aux données est plus rapide.

Malgré ces avantages, l’utilisation de données binaires intégrées a des limitations, notamment pendant le développement en boucle interne :

  • Les temps de compilation sont augmentés, car les fichiers contenant les données binaires doivent être chargés et ajoutés à l’indexeur. L’ajout de ressources basées sur des fichiers ne nécessite aucun accès supplémentaire au disque lors de la compilation (l’accès au disque est différé jusqu’à l’exécution).
  • Le débogage des problèmes avec le fichier PRI (via les vidages XML) est plus difficile, car au lieu de noms de fichiers lisibles par l’homme, le vidage XML contiendra des données binaires encodées en BASE64. De plus, les fichiers de vidage XML seront nettement plus volumineux, rendant le débogage plus compliqué.
  • Étant donné que le contenu des fichiers est intégré directement dans le fichier PRI, il n’est plus possible de remplacer les ressources à la volée. Tout changement apporté à une ressource intégrée nécessitera une reconstruction complète du fichier PRI. Étant donné que les ressources basées sur des fichiers ne contiennent que le nom de fichier, les fichiers de ressources réels peuvent être mis à jour à tout moment.
  • Pour les applications empaquetées, les ressources d’image listées dans le manifeste AppX, comme les icônes du menu Démarrer, ne peuvent pas être intégrées et doivent être spécifiées comme ressources de fichier.

Pour ces raisons, une règle générale consiste à utiliser des ressources basées sur des fichiers pendant le développement en boucle interne, mais à envisager l’utilisation de ressources binaires intégrées pour les builds de production finale (à l’exception des ressources du manifeste). Pour les applications empaquetées, envisagez de placer les ressources du manifeste AppX (telles que les icônes du menu Démarrer) dans un répertoire séparé des autres ressources afin de simplifier le processus de build (les ressources du manifeste AppX sont ajoutées sous forme de fichiers, et les autres ressources sous forme de données intégrées).