API 経由で画像を配信する Web サービスを使用しているとします。すべてのイメージには UID があり、属性uid (int) とイメージ(変換可能)を持つ Core Data エンティティイメージがあります。
ここで、アプリのギャラリーに多くの画像を表示する必要があります (UID はわかっています)。どの画像が以前にダウンロードされて保存されたかはわかりません。ビューが読み込み中に UIActivityIndicator を表示し、ローカルに保存されるとすぐに画像を自動的に表示するように、バックグラウンドでコア データを含む画像を遅延ダウンロードするにはどうすればよいでしょうか (たとえば、NSFetchedResultsControllerDelegateプロトコルを使用して)。
その目的で UIImageView をサブクラス化すると便利ですか?
はい、これには Core Data を使用できますが、Core Data を使用して画像を保存するとパフォーマンスが低下することに注意してください。小さな画像 (サムネイルなど) を扱っている場合は無視できますが、非常に大きな画像の場合、パフォーマンスへの影響は目に見えます。大きな画像の場合は、画像をDocumentsフォルダー (またはサブフォルダー) に保存し、Core Data を使用して、ダウンロードされた画像やファイル名などを追跡します。ただし、画像が小さい場合は、すべてを適切に保ちます。コアデータの方がきれいです。
UIImageView画像のキャッシングからプレゼンテーション レイヤー (画像ビュー) を分離したい場合があるため、この目的でサブクラス化されたものを使用したくないでしょう。また、洗練されたユーザー インターフェイスのUIImageView場合、ユーザーが大量の画像コレクションをスクロールするときにオブジェクトが破棄または再利用される可能性があるため、UIImageViewとキャッシュ ロジックの間のハード リンクは望ましくない場合があります。また、ユーザー インターフェイスによっては、画像が UIImageView よりも広い範囲を指定する場合があります (たとえば、テーブルビューを使用している場合、ダウンロードした画像に基づいてセルの高さを調整したい場合があります)。UI が何を行うかの実装の詳細は、画像が使用されている場所 (UITableView、画像のグリッドを表示している UIScrollView など) によって異なります。
つまり、単純なユーザー インターフェイスの場合、おそらく a をサブクラス化できますが、UIImageView一般的には、画像の読み込みが完了したときに UI に通知するデリゲート プロトコルを使用して遅延読み込みを行う、カスタムの画像キャッシュ オブジェクトを用意することをお勧めします。
Core Data を使用して画像を保存するのではなく、ディスクに保存します。パフォーマンスの問題が発生するため、Core Data に 100k を超える画像を保存することに対して Apple 自身が警告しているドキュメントを見つけようとしていました。
ただし、役立つ可能性があるCore Data Image Caching について説明しているこの記事を見つけました。
また、別のスタック オーバーフローの投稿では、イメージをデータベースに保存するタイミングと、ディスク ストレージへの参照のみを使用するタイミングを教えてくれます。
Core Data が絶対に必要でない場合は、MWPhotoBrowser の使用をお勧めしますか?
https://github.com/mwaterfall/MWPhotoBrowser
ナビゲーション コントローラーにプッシュできるギャラリー ビュー コントローラーを生成することが不可欠です。ギャラリー ビュー コントローラーには、ピンチ ズーム、パンなどのスクロール可能な画像があり、写真を誰かにメールで送信することもできます。
また、アクティビティ インジケーターを使用して画像を遅延読み込みします。
簡単な答え: 車輪の再発明をせずにやりたいことすべて。