私は長い間、店内の同僚の多くの間でCore Dataに対する疑念と敵意さえあり、一部はフレームワークにさえ触れていないことに気付きました。 そこに何があり、新しいプラットフォームの私の開発の始めに、私はそのような人々のコメントに従って彼に偏っていました。 しかし、自分で製品に触れることなく、偏見や神話に屈するべきではありません。 「システムに反対」したが、ツールをまだ完全に理解していない人のために、この記事を捧げます。 My Worldソーシャルネットワーク用のモバイルクライアントを開発するという実際のタスクに基づいた小さな例を基に、「落とし穴」のいくつかについてお話しし、初心者の開発者の注意をコアデータの使用を最適化する重要なポイントに引き付けたいと思います。 読者は、コアデータのコア要素（ NSManagedObjectContext



、 NSPersistentStoreCoordinator



など）が必要であり、少なくとも表面的にはAPIに精通している理由を既に理解していると想定されます。



私たちの場合：さまざまなメタ情報を含む大量の写真を保存および構成できるアプリケーションを開発する必要があります。 これを行うには、コアデータが必要です...それだけです。

コアデータスタック

したがって、最初にすべきことは、正しいコアデータスタックを準備することです。 幸いなことに、普遍的なソリューションがあります。誰もが知っているWWDC 2013のベストプラクティスだと思います。







スタックは2つのコンテキストに分割されます。メインコンテキストは、データを読み取るためにメインスレッドで使用されます。 バックグラウンドコンテキスト-大量のデータを編集、貼り付け、削除します。 つまり、すべての変更がバックグラウンドコンテキストで発生し、メインコンテキストで読み取り専用操作のみを実行するように、アプリケーションのアーキテクチャを最初に構築することをお勧めします。



あらゆる種類の分岐コンテキストを説明するスタックのアーキテクチャについて多くの記事が書かれていることに注意したい。 私の意見では、彼らはコアデータの使用を開始するためのしきい値を上げるだけで、初心者の開発者がフレームワークを使用するのを怖がらせるだけです。 実際、アプリケーションの90％については、上記のモデルで十分であり、1つのメインコンテキストでさらに9％で十分であり、残りのハードコアハードコアのみがより複雑なものを必要とします。

微妙な瞬間

• iOS 7 sqlite以降では、ストレージは以前のバージョンとは異なり、 WAL（Ahead Log書き込み）ログモードで動作し、1回の書き込み操作と複数の読み取り操作を並行して実行できます。 iOS 6を突然サポートする場合、 NSSQLitePragmasOption
  
  
  
  を使用してiOS 4以降のバージョンでスタックコーディネーターを作成するときにこのモードを有効にすることは可能ですが、これには問題が伴います。 また、iOS 6では、2つのコーディネーターを含むスタックで、通知を介してコンテキストを同期するときに、それらのオブジェクトが更新されない場合があります 。 したがって、iOS 6では、共通のコーディネーターを持ち、ロギングモードに煩わされない2つのコンテキストを持つスタックを使用することをお勧めします。アクティブなデバイスの割合は非常に低くなります。
• WALは、壊れた手動移行とバックアップエラーの可能性のある形式で、タイムドマイニングも保存します。 ディスク上のストレージは3つのファイル（dbname.sqlite、dbname.sqlite-wal、dbname.sqlite-shm）の形式で編成されているため、手動バックアップを編成する場合は、それらをすべて保存することを忘れないでください。 Appleのエンジニアは、WALファイルの存在を忘れていたようです。そのため、Migration Managerを使用するときに、データベースを壊すこともできます。 私自身も同様の問題に遭遇していません。詳細はこちらをご覧ください 。
• Core Dataの典型的なマニュアルとXcodeのプロジェクトテンプレートでは、スタックをAppDelegate
  
  
  
  クラスに直接配置し、アプリケーションの起動時に必要なものをすべて初期化することをAppDelegate
  
  
  
  しています。 ただし、アプリケーションでデータベースを操作することが一時的またはオプションである場合（たとえば、アプリケーションにユーザーを登録した後にのみ必要であり、ゲストアクセスでは必要ない場合）、スタックを「横向き」にすることは理にかなっています。 これを行うには、個別のSingleton
  
  
  
  クラスが適しています。このクラスは、本当に必要になったときにすぐに初期化されます。 これにより、メモリが大幅に節約され、アプリケーションの起動時間が短縮されます。

モデル設計

コアデータを使用する場合、データスキーマを考慮することが最も重要なポイントです。 アーキテクチャ設計の段階で行われた間違いを修正すると、開発者は多くの時間と神経を費やすことができます。 戦闘に入ってもモデルが変わらない場合に最適です。 実際には、Migration Managerを使用した手動移行に頼る必要がなく、すべての変更がLightweight Migrationによって飲み込まれた場合、完了です。 このステップにできるだけ多くの時間を費やし、モデルのさまざまなバリエーションを試してみてください。



アプリケーションに戻って、次の目標を達成する必要があります。

-UIに影響を与えることなく写真をサーバーと同期します （完了！これにはスタック内のバックグラウンドコンテキストを使用します）。

-メイン画面には、日付順に並べられたすべての写真が表示されます。

-セカンダリ画面で写真をグループ化します。グループ化基準はいいねの数で、グループ内の写真は日付でさらに並べ替えられます。



最初に、問題の解決に真正面から取り組み、エンティティが1つだけになるモデルを作成します。すべてのメタ情報を含む写真です。







それは非常に簡単に判明し、もし私たちが怠け者の開発者であれば、作業は終了していたでしょう（そして誰か他の人が記事を書いたでしょう:)）。



テストのために、メイン画面で簡単なNSFetchRequest



が必要であると仮定します。その結果はUICollectionView



表示されUICollectionView



。







また、追加の画面で、 NSFetchedResultsController



の全機能を使用してセクションを作成し、並べ替えます。







モデルを決定したら、iPhone 5で10,000枚の写真のパフォーマンスベンチマークを行います。 以下、モデルに関連する典型的な操作についてモデルをテストします。

• 10,000個のオブジェクトを挿入して、コンテキストを保存します
• 1つのフィールド（この場合は日付）でソートされた10,000個のオブジェクトすべてのリクエスト
• NSFetchedResultsController
  
  
  
  を使用して、2つのフィールドでソートし、セクションを形成する（いいねの数と日付でソートし、いいNSFetchedResultsController
  
  
  
  数でセクションを形成する）
• ブロックデータサンプリングの有効性を評価するために、30に等しいfetchBatchSize
  
  
  
  （電話のギャラリー画面の推定写真数）を使用するすべて同じコントローラー

テーブル内のすべてのデータはそれぞれ秒単位で与えられます。iPhone5に10,000枚の写真を挿入するのに2秒弱かかります。

操作\モデルタイプ	モデルV1
インセット（10000オブジェクト）	1.952
NSFetchRequest（1並べ替え）	0.500
NSFetchedResultsController（2種類）	0.717
NSFetchedResultsController（2ソート+ batchSize）	0.302

指数

実行時間は取るに足らないように見えるかもしれませんが、最適化の可能性を無視しないでください。 さらに、古いデバイスでは、操作がはるかに遅くなりますので、忘れないでください。 最初の最適化は最も簡単で誰もが知っているものです-作成するクエリに参加するフィールド、つまりdateとlikesにインデックスを追加しようとします：

操作\モデルタイプ	モデルV1	V1 +インデックス	差分
挿入（10000オブジェクト）	1.952	2.193	+ 12％
NSFetchRequest（1並べ替え）	0.500	0.168	-66％
NSFetchedResultsController（2種類）	0.717	0.657	-8％
NSFetchedResultsController（2ソート+ batchSize）	0.302	0.256	-15％

最小限のコストでかなり良いパフォーマンスを発揮します。 レコードを追加する時間が長くなっていることに注意してください。これは、インデックスを作成する必要があるためです。 そのため、本当に必要な場合にのみインデックスを使用することが重要です。 可能性のあるすべてのフィールドにIndexed



付けて、これによりアプリケーションが高速化されると考えて、自分自身を傷つけます。



インデックスからすべてのジュースを絞りましたか？ NSFetchedResultsController



が単純なNSFetchRequest



よりも大幅に「加速」されていることに気付くかもしれませNSFetchRequest



。 問題は何ですか？

複合インデックス

CoreDataの内部を見てみましょう。 まず、このために、図のように、パラメーターの「-com.apple.CoreData.SQLDebug 1」をプロジェクトの実行図に追加して、コアデータクエリのログを有効にする必要があります。







次に、ストレージsqliteファイルが完全な状態で必要です。 シミュレータで作業する場合、Xcode 6はシミュレータのファイルシステムをディレクトリ「〜/ Library / Developer / CoreSimulator / Devices /」に保存します。 シミュレータディレクトリの名前は、デバイスのリストで表示できるIdentifier値に対応しています（Shitft + CMD + 2で開きます）。 次に、アプリケーションのディレクトリを探し、通常はアプリケーションのDocumentsディレクトリにある.sqliteファイルへのフルパスを見つけます。 デバイスのストレージにアクセスする場合、iExplorerアプリケーションを使用する最も簡単な方法は、デバイスのアプリケーションディレクトリを表示するファイルマネージャーとして使用することです。 そこから、ストレージファイル（.sqlite-walファイルと.sqlite-shmファイルを忘れないでください）を自分に都合の良いディレクトリにコピーできます。 次のコマンドを実行して、コンソールからリポジトリに接続するだけです。

 sqlite3 PATH/TO/SQLITE/FILE
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロジェクトを開始し、SQLを「 EXPLAIN QUERY PLAN 」ディレクティブにコアデータログからクエリを送信すると、sqliteで発生するプロセスの詳細を確認できます。 NSFetchRequest



実行されたときに実際に何が起こるか見てみましょう：

 sqlite> EXPLAIN QUERY PLAN SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZASSETURL, t0.ZCOUNTRY, t0.ZDATE, t0.ZHEIGHT, t0.ZLATITUDE, t0.ZLIKES, t0.ZLOCATIONDESC, t0.ZLONGITUDE, t0.ZSIZE, t0.ZWIDTH FROM ZCDTMOPHOTOV1INDEX t0 ORDER BY t0.ZDATE; 0|0|0|SCAN TABLE ZCDTMOPHOTOV1INDEX AS t0 USING INDEX ZCDTMOPHOTOV1INDEX_ZDATE_INDEX
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

予想どおり、SQLクエリはインデックスを使用しているため、大幅に高速化されています。 そしてNSFetchedResultsController



何が起こるか：

 sqlite> EXPLAIN QUERY PLAN SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZASSETURL, t0.ZCOUNTRY, t0.ZDATE, t0.ZHEIGHT, t0.ZLATITUDE, t0.ZLIKES, t0.ZLOCATIONDESC, t0.ZLONGITUDE, t0.ZSIZE, t0.ZWIDTH FROM ZCDTMOPHOTOV1INDEX t0 ORDER BY t0.ZLIKES DESC, t0.ZDATE DESC; 0|0|0|SCAN TABLE ZCDTMOPHOTOV1INDEX AS t0 USING INDEX ZCDTMOPHOTOV1INDEX_ZLIKES_INDEX 0|0|0|USE TEMP B-TREE FOR RIGHT PART OF ORDER BY
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでの状況はわずかに悪く、インデックスはいいねだけで機能し、一時的なバイナリツリーが作成されて日付順にソートされます。 クエリに参加する両方のフィールドの複合インデックスを作成することにより、この動作を簡単に最適化できます（注意：クエリに追加の条件（たとえば、WHERE、3番目のフィールド）が表示される場合は、複合インデックスに追加する必要があります。リクエストに応じて使用されることはありません）。 これは、データモデルインスペクターで非常に簡単に行われ、エンティティ写真のインデックスリストの複合インデックスに含まれるすべてのフィールドをコンマで示します。







SQLクエリがどのように処理されるかを見てみましょう。

 sqlite> EXPLAIN QUERY PLAN SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZASSETURL, t0.ZCOUNTRY, t0.ZDATE, t0.ZHEIGHT, t0.ZLATITUDE, t0.ZLIKES, t0.ZLOCATIONDESC, t0.ZLONGITUDE, t0.ZSIZE, t0.ZWIDTH FROM ZCDTMOPHOTOV1COMPOUNDINDEX t0 ORDER BY t0.ZLIKES DESC, t0.ZDATE DESC; 0|0|0|SCAN TABLE ZCDTMOPHOTOV1COMPOUNDINDEX AS t0 USING INDEX ZCDTMOPHOTOV1COMPOUNDINDEX_ZLIKES_ZDATE
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バイナリツリーの代わりに複合インデックスが使用されていることを確認できます。これは、パフォーマンスに影響を与えるほかありません。

操作\モデルタイプ	モデルV1	V1 +インデックス	V1 +複合インデックス	差分（v1）
挿入（10000オブジェクト）	1.952	2.193	2.079	+ 7％
NSFetchRequest（1並べ替え）	0.500	0.168	0.169	-66％
NSFetchedResultsController（2種類）	0.717	0.657	0.331	-54％
NSFetchedResultsController（2ソート+ batchSize）	0.302	0.256	0.182	-40％

エンティティ分割

最適化のもう1つの機会は、特定のリクエストに必要な情報のみを含むエンティティの作成です。 私たちの構造には、コントローラーでの初期結果の発行の形成に関与しない多くの二次フィールドが含まれていることがわかります。 さらに、オブジェクトを操作する場合、Core Dataはそれらをメモリに完全に取り込みます。つまり、構造が大きいほど、より多くのメモリが消費されます（約8.iOS 8では、ストレージ内のオブジェクトを直接変更できるAPIが登場しました; APIは使用がかなり制限されています追加のコンテキスト同期要件）。 私たちのアプリケーションでは、レコードを2つに分けることで、写真自体とそのメタデータを示しています。







次のテストを実施し、そのようなモデルのインデックスの動作を調べます。

操作\モデルタイプ	モデルv2	V2 +インデックス	差分（V1 +インデックス）
挿入（10000オブジェクト）	3.218	3.524	+ 61％
NSFetchRequest（1並べ替え）	0.219	0.215	+ 28％
NSFetchedResultsController（2種類）	0.551	0.542	-18％
NSFetchedResultsController（2ソート+ batchSize）	0.387	0.390	+ 52％

このテストの結果は非常に興味深いものです。 インデックスを使用するこのモデルの速度は、それを使用しないモデルのエラーを考慮して同じであることに注意してください。 既知の方法を使用してより深く見ると、メタデータのJOINが最初に発生し、結合されたテーブルでのみソートが実行されるため、どちらの場合もインデックスは使用されないことがわかります。

 sqlite> EXPLAIN QUERY PLAN SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZASSETURL, t0.ZMETA FROM ZCDTMOPHOTOV2INDEX t0 LEFT OUTER JOIN ZCDTMOPHOTOMETAINDEX t1 ON t0.ZMETA = t1.Z_PK ORDER BY t1.ZLIKES DESC, t1.ZDATE DESC; 0|0|0|SCAN TABLE ZCDTMOPHOTOV2INDEX AS t0 0|1|1|SEARCH TABLE ZCDTMOPHOTOMETAINDEX AS t1 USING INTEGER PRIMARY KEY (rowid=?) 0|0|0|USE TEMP B-TREE FOR ORDER BY
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     ON t0.ZMETA = t1.Z_PK ORDER BY t1.ZLIKES DESC、t1.ZDATE DESC T1 ZCDTMOPHOTOMETAINDEXをJOIN ZCDTMOPHOTOV2INDEX T0 LEFT OUTER FROMを sqlite> EXPLAIN QUERY PLAN SELECT 0, t0.Z_PK, t0.Z_OPT, t0.ZASSETURL, t0.ZMETA FROM ZCDTMOPHOTOV2INDEX t0 LEFT OUTER JOIN ZCDTMOPHOTOMETAINDEX t1 ON t0.ZMETA = t1.Z_PK ORDER BY t1.ZLIKES DESC, t1.ZDATE DESC; 0|0|0|SCAN TABLE ZCDTMOPHOTOV2INDEX AS t0 0|1|1|SEARCH TABLE ZCDTMOPHOTOMETAINDEX AS t1 USING INTEGER PRIMARY KEY (rowid=?) 0|0|0|USE TEMP B-TREE FOR ORDER BY
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

要するに、このモデルは私たちには適していない。

正規化

実験を続けます。 厳密なデータの正規化がコアデータに常に適しているとは限りません。 前のモデルの結果は予想からはほど遠いものでした。 修正してみましょう。 これを行うには、 日付を複製し、写真の本質にあるフィールドを気に入って （複合インデックスと日付用の別のインデックスを追加することを忘れずに）、クエリでLEFT OUTER JOINの必要性を回避するだけで十分です。 メタデータエンティティ内のこれらのフィールドを残すか削除するかは、状況に応じて決定する必要があります。 たとえば、撮影された写真のいいねの数に応じた国の評価でリクエストを行いたい場合、これらのフィールドを削除すると、JOINを行う必要がありますが、コミュニケーションの方向は異なります。 私たちのテストでは、エンティティのプロパティが複製されており、これはコアデータでは完全に正常です：







テスト結果を見てみましょう：

操作\モデルタイプ	モデルv3	Diff（V1 +複合インデックス）	差分（v1）
挿入（10000オブジェクト）	3.861	+ 86％	+ 98％
NSFetchRequest（1並べ替え）	0.115	-32％	-77％
NSFetchedResultsController（2種類）	0.283	-15％	-61％
NSFetchedResultsController（2ソート+ batchSize）	0.181	-1％	-40％

この実験は成功し、アプリケーションの主要な読み取り操作の高速化を達成しました。最速のフラットモデルと比較して最大40％、インデックスなしのオリジナルバージョンで最大80％です。

要約と微妙なポイント

• インデックスを使用し、クエリに関連するフィールドにのみ使用します。 複合インデックスの存在を忘れないでください
• さまざまなスキームを試し、そのパフォーマンスをテストします。 Xcode 6にはパフォーマンステストのサポートが組み込まれているため、非常に簡単です。
• CoreDataフレームワークがログを使用してSQLクエリを生成する方法を確認することを忘れないでください。 EXPLAIN QUERY PLANを使用して、sqliteがSQLクエリをダイジェストする方法を学習します。
• NSFetchedResultsController
  
  
  
  の結果にアクセスするときは、コントローラー自体が提供するアクセス方法のみを使用します。
  
  
  
  

   NSManagedObject *object = [controller objectAtIndexPath:indexPath];
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  fetchedObjects
  
  
  
  配列、またはNSFetchedResultsSectionInfoプロトコルを使用して、セクションオブジェクトの配列を使用しないでください。
  
  
  
  

   NSManagedObject *object = [[controller fetchedObjects] objectAtIndex:index]; //  NSArray *objects = [[[controller sections] objectAtIndex:sectionIndex] objects]; NSManagedObject *object = [objects objectAtIndex:index];
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  なぜですか？ サイズNのfetchBatchSize
  
  
  
  を使用する場合、コントローラーがリクエストを実行すると、最初のN個のオブジェクトのみがメモリにロードされます（ブロックサイズがセクションサイズより大きい場合は最初のセクション！）。 ロードされたブロックの外側の最初の障害オブジェクトまたは別のセクションのオブジェクトを要求するとすぐに、コントローラーは要求の結果に応じてフルパスを実行します。 つまり 、 N =ストレージリクエストのオブジェクト数/ fetchBatchSizeを実行します。 この操作は、すべての要素に対する単純な要求よりも約3〜4倍遅くなります。 objectAtIndexPath
  
  
  
  を介したアクセスを使用する場合objectAtIndexPath
  
  
  
  この動作は観察されません。 読者の中に、ドキュメンテーションに記載されていないような奇妙な振る舞いに光を当てることができる人がいればとてもうれしいです。
• 正規化は必ずしもコアデータの最適なソリューションではありません
• Cupertinoのステージから、新しいiPhoneが以前のものより2倍高速であると言われた場合、これを信じる必要があります。CoreDataの操作では、これらのステートメントはほぼ完全に確認されます。 その結果をまとめたファイルを用意しました。iPhone5Sのテストもあります。 ほとんどすべての結果で、前のモデルの2倍高速です。 したがって、現在のiPhone 4Sでは、これらの結果は約2倍遅くなります。もちろん、古いデバイスであっても同様です。 ここには、結果の概要表があります。これには、新しいiPhone 6の結果も含まれています。

置き換えることができるように、Core Dataはデータを操作するための単純な手段であるだけでなく、適切な人にとって強力なツールでもあります。 探索して実験してください。この記事があなたにとって何か新しいものを開き、プロジェクトでのコアデータのより効果的な使用に向けて押し進められることを願っています。 頑張って