2

アプリにローカルに保存する必要があるデータがいくつかあり、それを保存する最良の方法は何だろうと考えていました (パフォーマンスの観点から見て)。データは多くも少なくもありません。plist の観点から見ると、データは次のようになります。

 -root
    -main_block1
        -sub_block1
            -some_data
            -some_data
            -some_data

        -sub_block2
            -some_data
            -some_data
            -some_data

        -sub_block3
        -sub_block4
        ...
        -sub_blockn
    -main_block2
    -main_block3
    ...
    -main_blockn

約 3 ～ 10 個 (最大で 13 ～ 15 個だと思います) のメイン ブロックがあります。本編はタイトルが10文字程度の辞書程度と考えてください。各メイン ブロックには、辞書でもある 1 ～ 10 (最大 10) のサブ ブロックがあります。各サブ ブロックには、いくつかのプレーン テキスト データが含まれます。100 文字以下 (または 200 ～ 300 文字) の文字列。

このデータを読み取り、少し混ぜ合わせる必要があります (メイン ブロックを 1 つまたは 2 つ交換し、サブ ブロックを 1 つまたは 2 つ交換します)。

アプリにはすでにかなりのものがあるので、できるだけ速くする必要があるので、何を使用すればよいのでしょうか? プロパティ リスト ファイルですか、それとも SQLite データベースですか?
SQLiteデータベースは基本的に、その内容を操作するコードラッパーを含むテキストファイルであるため、私の状況ではplistファイルの方が高速になると思います...

前述のように、データは数十キロバイトを超えることはありません (希望しないでください:P)。

EDIT：少し情報を追加するには：メインブロックはこの順序でロードする必要があるビューであり、サブブロックはこの順序でロードする必要があるメインビューのサブビューです。一部のデータは、それらのビューに供給されるデータです。そのため、メイン ビューとサブビューの順序は時々変更され、ユーザーが決定したときにサブ ビューのデータが再ロードされます。これが少し役立つことを願っています。

4

2 に答える 2

3

場合によります。常にデータ構造を再参照し、毎回 plist をリロードする場合は、(開いたままにしておく) SQLite DB の方が高速です。データを一度だけロードして参照する場合は、plist が優先されます。もちろん、Core Data を単純な SQLite 関数に使用することもできます。

于 2013-08-08T15:29:58.293 に答える