連絡先を管理する基本的なiPhoneアプリがあるとします。私は "名前"、 "アドレス"と "写真"の属性を持つ "連絡先"という名前のエンティティを持っています。アプリのメインビューは、各連絡先の名前を表示する単なるテーブルビューです。ユーザーは各名前をクリックして、対応する写真とアドレスを表示することができます（別のビューコントローラーで）。コアデータの取得を簡単に行うための簡単な方法
問題は、写真のサイズが非常に大きいことです。
管理対象オブジェクトをフェッチすると、すべての属性もメモリに取り込まれますか？この場合、アプリケーションがすべての写真（およびアドレス）をフェッチしているので、アプリケーションをロードしてテーブルビューに名前を表示するには時間がかかるでしょうか？
この理由から、メインビューをよりスムーズに（そして読み込み速度が速く）するには、「名前」属性のみを持つ新しい「ContactFacade」エンティティを作成する必要がありますその連絡先に関する詳細を含む「連絡先」エンティティへのの関係
エンチラダ、
大きなBLOBは常に「リーフ」エンティティにする必要があります。 AリーフのエンティティにはNSData BLOBと逆の関係のみが含まれています。これにより、iOS v5/Mac OS X Lionのファイルシステムでの自動BLOB保存を簡単に利用することができます。重要なことに、-refreshObject:mergeChanges:を慎重に使用することで、BLOBを強制的にメモリ、場合によっては行キャッシュから強制的に取り出すことができます。
大きなデータのコアデータのファイルマッピングBLOBは、大きなファイルを開くためにメモリマッピングを使用しないということです。これはメモリ上の常駐フットプリントに当てはまります。メモリの警告が来たら、これらのBLOBを明示的にアンロードする必要があります。
アンドリュー
コアデータは、あなたのためにこれを補うものです。実際に表示する必要があるまで、すべての写真などをフェッチしません。 UIはブロックされません。
優れた例として、iTunes UのStanford iOSクラス、特にCore Data講義とCore Dataデモ（講義13と14）をご覧ください。現在のプロジェクトで使用しているFetchResultsControllerに簡単に接続できるCoreDataTableViewControllerもあります。そこ
http://www.stanford.edu/class/cs193p/cgi-bin/drupal/node/289
例のアプリは、大きな写真を表示するだけでなく、ネットワークから効率的にそれをしません。
は、ディスク上のファイルとして保存し、唯一のコアデータにファイル名を格納し、代わりにコアデータの画像を格納する、
ダミアン
をお楽しみください。
ファイルからイメージを読み取るためにUIImageを使用すると、自動的にRAMから自身を削除し、必要に応じて自分自身をRAMに戻します。
本当に良いパフォーマンスが必要な場合は、画像が小さいか、または2つのサイズ（サムとフルサイズ）があることを確認する必要があります。
また、使用する画像形式にも注意してください。 PNGはより多くのディスク領域を使用しますが、レンダリングに必要なCPU時間はJPEGよりも少なくて済みます。
Appleは、「大きなデータオブジェクト（BLOB）」と呼ばれる彼らのCore Data Performanceページ上の小さなセクションを持っています。興味の一部は次のとおりです。小型のために
控えめなサイズのBLOB（およびCLOBの）に、あなたはデータのための 別々のエンティティを作成し、属性の代わり における対1の関係を作成する必要があります。
私は、この変更を実装した後、私のアプリで大幅なパフォーマンスの向上が見られました。しかし、地図上に表示するために1回のリクエストで300以上のオブジェクトを取得する必要がある状況にあった。あなたの状況ではNSFetchedResultsControllerを使用してテーブル内のデータを管理することができます。これにより、データの小さなサブセットにフェッチが制限されます。
http://stackoverflow.com/questions/2131722/coredata-for-iphone-storing-imagesの複製としてフラグが設定されています。 – bneely