4

CGImageSourceCreateThumbnailAtIndex(...) を使用して、何千もの CGImage オブジェクトを作成する必要があります。

問題は、 simple のCGDataProviderCreateWithURL(...)後に を使用するCGImageSourceCreateThumbnailAtIndex(...)と、システムがファイルの内容を (非アクティブなメモリに) キャッシュするため、パフォーマンスが大幅に低下することです。

最も近い解決策：

ここ[NSData dataWithContentsOfURL:inURL options:NSUncachedRead error:nil]では、 を使用しCGImageSourceCreateWithData(...)て、システムによるファイルのキャッシュを防止することが提案されました。

最も近い解決策の問題

このソリューションでは、サムネイルを作成する前にファイル全体をメモリに読み込む必要があるため、パフォーマンスが大幅に低下します。

私がすでに試したこと：

  1. 使用していますが[NSData dataWithContentsOfURL:inURL options:NSUncachedRead|NSDataReadingMappedAlways error:nil];、オプションを無視しているようですNSUncachedRead（ファイルは非アクティブなメモリにキャッシュされています）。

  2. を使用しCGDataProviderCreateWithURLますが、ファイルもキャッシュします。

  3. 編集: @justinCGDataProviderが提案したように CGDataProviderCreateSequential(...) で作成されたカスタムを使用しますが、CGImageSourceCreateThumbnailAtIndex.CGImageSourceCreateWithDataProviderCGDataProviderCopyData

ファイル全体をメモリにロードせずにキャッシュせずにサムネイルを取得する方法の提案はありますか?

PS画像ソースとサムネイルを作成するときにすでに設定kCGImageSourceShouldCacheしてkCFBooleanFalseいますが、ファイルの読み取り時にキャッシュされる生データではなく、デコードされたデータのみに関連しているようです。

編集：私は10.8を使用しています。CGImageSourceCreateWithDataProvider などの関数の実装は、他のプラットフォーム/バージョンでは異なる場合があります。

4

1 に答える 1

1

マップされたメモリ、仮想メモリ、およびディスク キャッシングがターゲット システムで実際にどのように機能するかを確実に理解することを強くお勧めします (注: 実装は OS X リリースによって異なります)。私がこれを言うのは、大多数の Cocoa 開発者が OS X でのディスク キャッシングとメモリ マッピングをあまりよく理解していないからです。それにもかかわらず、私はそれと戦うために (そしてバグを報告するためにさえ) 多くの時間を費やした非常に少数の 1 人です。文字通り何千ものメディア資産を開いたり閉じたりすることは、キャッシングが真のショーストッパーまたは少なくともパフォーマンスの障害になる可能性がある適切なケースの 1 つです。

キャッシュを回避するには: を使用してデータ プロバイダーを作成しCGDataProviderCreateSequential、ファイルを開く独自のリーダー実装を実装します (例: を使用)。その後、読み取り前のオプションをfopen使用してキャッシュを無効にします。次に、データが必要になるたびにディスクに実行するか、読み取るデータ用に最適化された独自のキャッシュ戦略を実装できます (たとえば、ファイルの読み取り中にヘッダーをメモリにキャッシュし、画像データをディスクから直接読み取ります)。ファイルが背後で変更されないようにすると、生活が楽になります。とにかく、理論的には良さそうです。F_NOCACHEfcntl

于 2013-05-14T01:04:48.773 に答える