MRM のファイル リソース

MRM のファイル リソースは、実行時に ResourceCandidate.Kind プロパティString ではなく Path になることを除いて、基本的に String リソースと同じです。 リソースの値は単なる文字列 (ファイル名) であって、実際のファイルの内容ではありません。 実際、ほとんどの場合、インデックス作成対象ファイルはビルド時に存在している必要もありません。

ターゲット アプリケーションで組み込みの MRT ランタイム (Windows.ApplicationModel.Resources) を使用する場合は、ResourceCandidate.GetValueAsFileAsync または ResourceCandidate.GetValueAsStreamAsync を使用して、自動的にファイルを検索して読み込むことができます。 WinApp SDK バージョンの MRT (Microsoft.Windows.ApplicationModel.Resources) を使用している場合は、自分でファイルを手動で読み込む必要があります。 また、組み込みの MRT ランタイムを使用してファイルを手動で読み込むこともできます。

MRM インデクサーにファイルを追加するには、次の 2 つの方法があります。

MrmIndexResourceContainerAutoQualifiers はインデクサーにファイル リソースを追加しません。代わりに、ビルド時に名前付きファイルを読み込み、埋め込みリソースをインデクサーに直接コピーします。

名前でファイルを参照する代わりに、MrmIndexEmbeddedData を使用して PRI ファイルに直接データを埋め込むことができます。詳細については、以下の「埋め込みデータ」を参照してください。

ファイルの名前付け

ファイルベースのリソースの主な目的は、CreateFile()fopen()、または std::fstream コンストラクターなどの関数に文字列を渡すことです。 通常、ファイルの最終的なディスク上のパスはビルド時に認識されないため、ファイル名は通常、実行時にアプリの作業ディレクトリ (またはその他の既知のディレクトリ) に対して解決される相対パスになります。 任意の文字列 (絶対パスやネットワーク パスを含む) をファイル名として含めることができますが、通常、これは役に立ちません。

プロジェクト ルートと相対ファイル名

MrmCreateIndexer... 関数のいずれかを使用してインデクサーを作成する場合は、projectRoot パラメーターを指定する必要があります。 このパラメーターは、MrmIndexResourceContainerAutoQualifiers では解析するディスク上のファイルを検索するために、また MrmIndexFileAutoQualifiers では絶対パスからの相対パスを計算するために使用されます。 MrmIndexFile では無視されます。

埋め込みデータ

データとしてファイルを埋め込むと、アプリに必要な記憶域スペースが減り、ファイル名の参照に対するパフォーマンスが向上します。 ただし、特に内部ループ アプリの開発中に、この機能を使用することにはいくつかの欠点があります。

一般的な Windows システムでは、ディスク領域の割り当て方法により、すべてのファイルで平均 2 kb のディスク領域が無駄になります。 多数の小さなファイル (アイコンなど) を含むアプリの場合、この平均値はさらに高くなる可能性があります。 バイナリ ファイル データを PRI ファイルに直接埋め込むことで、このファイルごとの領域は無駄になりません。

さらに、外部リソース ファイルを読み込む場合、ファイルを開く操作のたびに追加のディスク アクセスやセキュリティ チェックなどが必要になるため、PRI ファイルから直接バイナリ データを読み込む場合よりも遅くなります。 PRI ファイルは常にメモリマップ ファイルとして読み込まれるため、データへのアクセスが高速になります。

これらの利点はありますが、埋め込みバイナリ データの使用には、特に内部ループの開発中の制限があります。

  • バイナリ データを含むファイルを読み込んでインデクサーに追加する必要がある場合、ビルド時間が増加します。 ファイルベースのリソースを追加する場合、ビルド時に追加のディスク アクセスは必要ありません (ディスク アクセスはランタイムまで延期されます)。
  • PRI ファイルに関する問題の (XML ダンプ経由での) デバッグは困難です。これは、人間が判読できるファイル名ではなく、BASE64 でエンコードされたバイナリ データが XML ダンプに含まれるためです。 さらに、XML ダンプ ファイルのサイズが大幅に大きくなるため、問題のデバッグがさらに難しくなります。
  • ファイルの内容は PRI ファイルに直接埋め込まれるため、アセットをその場で交換できなくなります。 埋め込みリソースを変更する場合は、PRI ファイルを完全に再構築する必要があります。 ファイルベースのリソースにはファイル名のみが含まれるため、実際のアセット ファイルはいつでも更新できます。
  • パッケージ化されたアプリの場合、AppXManifest に一覧表示されているイメージ リソース ([スタート メニュー] アイコンなど) は埋め込めないため、ファイル リソースとして指定する必要があります

これらの理由から、一般的な経験則では、内部ループの開発中はファイルベースのリソースを使用しますが、最終的な運用ビルド (マニフェスト リソースを除く) には埋め込みバイナリ リソースの使用を検討してください。 パッケージ化されたアプリの場合は、AppXManifest リソース ([スタート メニュー] アイコンなど) を他のリソースとは別のディレクトリに配置してビルド プロセスを簡略化することを検討してください (AppXManifest リソースはファイルとして追加され、その他のリソースは埋め込みデータとして追加されます)。