Compartir a través de

Recursos de archivos en MRM

  • Artículo

Los recursos de archivo en MRM son básicamente los mismos que los recursos de cadena, salvo que en tiempo de ejecución, la propiedad ResourceCandidate.Kind será Path en lugar de String. Los valores de recurso son solo cadenas los nombres de archivo) y no el contenido real del archivo. De hecho, en la mayoría de los casos, los archivos que se indexan ni siquiera necesitan existir en tiempo de compilación.

Si la aplicación de destino va a usar el entorno de ejecución de MRT integrado (Windows.ApplicationModel.Resources), puede usar ResourceCandidate.GetValueAsFileAsync o ResourceCandidate.GetValueAsStreamAsync para buscar y cargar automáticamente el archivo. Si usa la versión del SDK de WinApp de MRT (Microsoft.Windows.ApplicationModel.Resources), debe cargar manualmente el archivo. También puede optar por cargar manualmente el archivo con el entorno de ejecución de MRT integrado.

Hay dos maneras de agregar archivos al indexador MRM:

Tenga en cuenta que MrmIndexResourceContainerAutoQualifiers no agrega un recurso de archivo al indexador; en su lugar, carga el archivo con nombre en tiempo de compilación y copia los recursos incrustados en el indexador directamente.

Para obtener una alternativa para hacer referencia a los archivos por nombre, puede usar MrmIndexEmbeddedData para incrustar datos directamente en el archivo PRI; consulte Datos incrustados a continuación para obtener más información.

Nomenclatura de archivos

El objetivo principal del recurso basado en archivos es pasar una cadena a funciones como CreateFile(), fopen()o el constructor std::fstream. Dado que la ruta de acceso final en disco de los archivos normalmente no se conoce en tiempo de compilación, los nombres de archivo suelen ser rutas de acceso relativas que se resolverán en el directorio de trabajo de la aplicación (o en algún otro directorio conocido) en tiempo de ejecución. Aunque es posible incluir cualquier cadena arbitraria como nombre de archivo (incluidas las rutas de acceso absolutas o de red), esto no suele ser útil.

Nombres de archivo relativos y raíz del proyecto

Al crear un indexador a través de una de las funciones MrmCreateIndexer..., debe especificar un parámetro projectRoot. MrmIndexResourceContainerAutoQualifiers usa este parámetro para buscar los archivos en disco que se van a analizar y MrmIndexFileAutoQualifiers lo usa para calcular rutas de acceso relativas desde rutas de acceso absolutas. MrmIndexFile lo omite.

Datos incrustados

Incrustar archivos como datos puede reducir el espacio de almacenamiento necesario para la aplicación y aumentar su rendimiento en relación con las referencias a nombres de archivo. Sin embargo, hay algunas desventajas de usar esta característica, especialmente durante el desarrollo de aplicaciones de bucle interno.

En un sistema Windows típico, cada archivo desperdicia un promedio de 2 kb de espacio en disco debido a la forma en que se asigna el espacio en disco. En el caso de las aplicaciones que contienen muchos archivos pequeños (como iconos), este promedio puede ser incluso mayor. Al incrustar los datos de archivos binarios directamente en el archivo PRI, este espacio por archivo no se desperdicia.

Además, cargar archivos de recursos externos es más lento que leer datos binarios directamente fuera del archivo PRI, ya que cada operación de apertura de archivos requiere accesos de disco adicionales, comprobaciones de seguridad, etc. El archivo PRI siempre se carga como un archivo asignado a memoria, por lo que el acceso a los datos es más rápido.

A pesar de estas ventajas, el uso de datos binarios incrustados tiene limitaciones, especialmente durante el desarrollo de bucles internos:

  • Los tiempos de compilación aumentan, ya que los archivos que contienen los datos binarios deben cargarse y agregarse al indexador. La adición de recursos basados en archivos no requiere acceso adicional al disco en tiempo de compilación (el acceso al disco se aplaza hasta el tiempo de ejecución).
  • La depuración de problemas con el archivo PRI (a través de volcados XML) es más difícil, ya que, en lugar de los nombres de archivo legibles, el volcado XML contendrá datos binarios codificados en BASE64. Además, los archivos de volcado XML serán significativamente mayores, lo que dificulta la depuración de los problemas.
  • Dado que el contenido de los archivos se incrusta directamente en el archivo PRI, ya no es posible intercambiar activos sobre la marcha. Cualquier cambio en cualquier recurso incrustado requerirá una recompilación completa del archivo PRI. Dado que los recursos basados en archivos solo incluyen el nombre de archivo, los archivos de recursos reales se pueden actualizar en cualquier momento.
  • En el caso de las aplicaciones empaquetadas, los recursos de imagen que aparecen en AppXManifest, como los iconos del menú Inicio, no se pueden incrustar y deben especificarse como recursos de archivo.

Por estos motivos, una regla general general consiste en usar recursos basados en archivos durante el desarrollo de bucles internos, pero considere la posibilidad de usar recursos binarios insertados para compilaciones de producción finales (excepto los recursos de manifiesto). En el caso de las aplicaciones empaquetadas, considere la posibilidad de colocar los recursos de AppXManifest (como iconos del menú Inicio) en un directorio independiente de otros recursos para simplificar el proceso de compilación (los recursos de AppXManifest se agregan como archivos y otros recursos agregados como datos incrustados).