ios - 大規模な Core Data データベースのクラッシュの移行

Question

製品を Core Data ファイルに保存するアプリケーションがあります。これらの製品には、「変換可能な」データとして画像が含まれています。ここで、Lightweight migration を使用していくつかの属性を追加してみました。小さなデータベースでこれをテストしたところ、うまく機能しましたが、500 MB 近くの非常に大きなデータベースを使用すると、通常、メモリ不足のためにアプリケーションがクラッシュします。この問題を解決する方法を知っている人はいますか？

ありがとうございます！

Answer 1

他の移行オプションのいずれかを使用する必要があります。自動軽量移行プロセスは非常に便利です。ただし、データ ストア全体を一度にメモリにロードするという欠点があります。2 つのコピー、実際には、1 つは移行前用、もう 1 つは移行後用です。

まず、このデータを再作成または再ダウンロードできますか? その場合、古いバージョンから新しいバージョンへのカスタム マッピング モデルを使用できる可能性があります。カスタム マッピング モデルを使用すると、一部の属性が移行されないことを示すことができます。これにより、そのデータが破棄されるため、メモリの問題が軽減されます。その後、移行が完了したら、そのデータを再作成または再ダウンロードします。

そうでない場合... Apple は、複数のマッピング モデルを使用した複数パス手法を提案しています。大規模なデータ ストア サイズの原因となるエンティティ タイプが複数ある場合は、役立つ可能性があります。基本的に、異なるパスで異なるエンティティ タイプを移行することになるため、すべてを一度に読み込むオーバーヘッドを回避できます。

そうでない場合 (たとえば、肥大化がすべて同じエンティティ タイプのインスタンスから発生している場合)、独自のカスタム移行コードを記述するときが来ました。これには、2 つの Core Data スタック (1 つは既存のデータ、もう 1 つは新しいモデル) のセットアップが含まれます。既存のデータ ストアを実行し、新しいストアに新しいオブジェクトを作成します。これをバッチで行うと、メモリを制御下に置くことができます。一般的なアプローチは次のとおりです。

1. 新しいモデルで新しいインスタンスを作成し、属性のみをコピーします。関連オブジェクトが新しいデータ ストアに存在しない可能性があるため、まだリレーションシップを設定できません。NSManagedObjectID次のステップで使用するために、古いストアから新しいストアへの s の可変辞書マッピングを保持します。メモリ使用量を低く抑えるには:
   • 宛先ストア オブジェクトを作成したらすぐに、2 番目の引数にrefreshObject:mergeChangeswithを使用して、ソース オブジェクトのメモリを解放します。NO
   • 10 個のインスタンス (または 50 個など) ごとに、宛先の管理対象オブジェクト コンテキストに変更が保存され、次にresetそれが保存されます。間隔はバランスをとる行為です。頻繁に行うと不必要に速度が低下し、めったに行わないとメモリ使用量が増加します。
2. 宛先ストアでリレーションシップを設定する 2 番目のパスを実行します。ソース オブジェクトごとに、
   • 作成したオブジェクト ID マップを使用して、対応する宛先オブジェクトを見つけます。
   • ソース オブジェクトのリレーションを実行します。それぞれについて、オブジェクト ID マップも使用して、対応する宛先オブジェクトを見つけます。
   • 結果に基づいて宛先オブジェクトの関係を設定します。

その際に、データ ストアがこれほど大きい理由を考えてみてください。データ ストアに多数のバイナリ データ BLOB を格納していますか? その場合は、新しいモデルで「外部ストレージを許可する」オプションを使用していることを確認してください。