Compartilhar via

Recursos de arquivo no MRM

  • Artigo

Os recursos de arquivo no MRM são essencialmente os mesmos que os recursos de cadeia de caracteres, exceto que, em tempo de execução, ResourceCandidate.Kind, uma propriedade será Caminho em vez de Cadeia de caracteres. Os valores de recurso são apenas cadeia de caracteres, os nomes dos arquivos e não o conteúdo real do arquivo. Na verdade, na maioria dos casos, os arquivos que estão sendo indexados nem precisam existir no momento da compilação.

Se o aplicativo de destino estiver usando o runtime MRT interno (Windows.ApplicationModel.Resources), você poderá usar ResourceCandidate.GetValueAsFileAsync ou ResourceCandidate.GetValueAsStreamAsync para localizar e carregar automaticamente o arquivo para você. Se você estiver usando a versão do SDK do WinApp do MRT (Microsoft.Windows.ApplicationModel.Resources), deverá carregar manualmente o arquivo por conta própria. Você também pode optar por carregar manualmente o arquivo com o runtime MRT integrado.

Há duas maneiras de adicionar arquivos ao indexador MRM:

Observe que MrmIndexResourceContainerAutoQualifiers não adiciona um recurso de arquivo ao indexador, em vez disso, ele carrega o arquivo nomeado em tempo de compilação e copia os recursos inseridos diretamente para o indexador.

Para obter uma alternativa para referenciar arquivos por nome, você pode usar MrmIndexEmbeddedData para inserir dados diretamente no arquivo PRI, consulte abaixo Dados inseridos para obter mais informações.

Nomear arquivos

O objetivo principal do recurso baseado em arquivo é passar uma cadeia de caracteres para funções como CreateFile(), fopen() ou o construtor std::fstream. Como o caminho final em disco dos arquivos normalmente não é conhecido no momento da compilação, os nomes de arquivo geralmente são caminhos relativos que serão resolvidos no diretório de trabalho do aplicativo (ou em algum outro diretório conhecido) em tempo de execução. Embora seja possível incluir qualquer cadeia de caracteres arbitrária como o nome do arquivo (incluindo caminhos absolutos ou de rede), isso normalmente não é útil.

Nomes de arquivo raiz e relativos do projeto

Ao criar um indexador por meio de uma das funções MrmCreateIndexer..., você deve especificar um parâmetro projectRoot. Esse parâmetro é usado por MrmIndexResourceContainerAutoQualifiers para localizar os arquivos no disco a serem analisados e por MrmIndexFileAutoQualifiers para calcular caminhos relativos de caminhos absolutos. Ele é ignorado por MrmIndexFile.

Dados inseridos

A inserção de arquivos como dados pode reduzir o espaço de armazenamento necessário para seu aplicativo e aumentar seu desempenho em relação à referência a nomes de arquivo. No entanto, existem algumas desvantagens em usar esse recurso, principalmente durante o desenvolvimento de aplicativos de loop interno.

Em um sistema Windows típico, cada arquivo desperdiça em média 2 KB de espaço em disco devido à forma como o espaço em disco é alocado. Para aplicativos que contêm muitos arquivos pequenos (como ícones), essa média pode ser ainda maior. Ao inserir os dados do arquivo binário diretamente no arquivo PRI, esse espaço por arquivo não é desperdiçado.

Além disso, carregar arquivos de recursos externos é mais lento do que ler dados binários diretamente do arquivo PRI, pois cada operação de abertura de arquivo requer acessos adicionais ao disco, verificações de segurança e assim por diante. O arquivo PRI é sempre carregado como um arquivo mapeado na memória, portanto, o acesso aos dados é mais rápido.

Apesar desses benefícios, o uso de dados binários incorporados tem limitações, principalmente durante o desenvolvimento do loop interno:

  • Os tempos de compilação são aumentados, pois os arquivos que contêm os dados binários precisam ser carregados e adicionados ao indexador. A adição de recursos baseados em arquivo não requer acesso adicional ao disco no momento da compilação (o acesso ao disco é adiado até o tempo de execução).
  • Problemas de depuração com o arquivo PRI (por meio de despejos XML) são mais difíceis, pois em vez de nomes de arquivos legíveis por humanos, o despejo XML conterá dados binários codificados em BASE64. Além disso, os arquivos de despejo XML serão significativamente maiores, dificultando a depuração de quaisquer problemas.
  • Como o conteúdo dos arquivos é incorporado diretamente no arquivo PRI, não é mais possível trocar ativos em tempo real. Qualquer alteração em qualquer recurso inserido exigirá uma recompilação completa do arquivo PRI. Como os recursos baseados em arquivo incluem apenas o nome do arquivo, os arquivos de ativos reais podem ser atualizados a qualquer momento.
  • Para aplicativos empacotados, os recursos de imagem listados no AppXManifest, como ícones do Menu Iniciar, não podem ser inseridos e devem ser especificados como recursos de arquivo.

Por esses motivos, uma regra geral é usar recursos baseados em arquivo durante o desenvolvimento de loop interno, mas considere o uso de recursos binários inseridos para compilações de produção final (exceto para os recursos de manifesto). Para aplicativos empacotados, considere colocar os recursos do AppXManifest (como ícones do Menu Iniciar) em uma direção separada de outros recursos para simplificar o processo de compilação (os recursos do AppXManifest são adicionados como arquivos e outros recursos são adicionados como dados inseridos).