SharedPreferencesコミットデータの効率

ブラウザクライアントのデータ初期化データ最適化中に、SharedPreferencesを使用してデータを保存するのを何度も見たためです.クライアントのSharedPreferencesManagerのソースコードを調べてみると、私たちがデータを提出するときのコード形式は以下の通りです.
public void putFloat(String key, float value) { editor.putFloat(key, value); editor.commit(); }
すなわち、トランザクションを使用してデータをコミットすることは、クライアントにとって安全であり、データがタイムリーに書き込まれることを確保することができますが、これにより、commit操作自体に時間がかかり、複数回のcommitは必然的に時間と性能の大きなオーバーヘッドをもたらすという小さな問題も発生します.クライアントは1つのDemoをしてこの構想を調査して、コードは以下の通りです:1.毎回commitを使ってデータを提出して、50回循環して、毎回3本のデータを提出します
button.setOnClickListener(new OnClickListener() {

        @Override
        public void onClick(View v) {
             SharedPreferenceManager manager =SharedPreferenceManager.getInstance();
             Long startTime = Calendar.getInstance().getTimeInMillis();
             Log.e("start","~"+startTime );
             for(int i=0;i<50;i++){
                 manager.putIntCom("first"+i, 1);
                manager.putIntCom("second"+i, 2);
                 manager.putIntCom("third"+i, 3);
            }

//manager.commit(); Long endTime = Calendar.getInstance().getTimeInMillis(); Log.e(“endTime”,”~”+endTime ); Log.e(“time—->”, “”+(endTime-startTime)); Log.e(“average”, “”+(endTime-startTime)/50); } });
manager.putIntComの方法は以下の通りです.
public void putIntom(String key,int value){editor.putInt(key,value);editor.commit();}ログを見てみましょう:
04-05 03:38:54.224: E/start(9713): ~1333597134230 04-05 03:38:55.024: D/dalvikvm(9713): GC_FOR_MALLOC freed 2463 objects/413552 bytes in 107ms 04-05 03:38:55.774: D/dalvikvm(9713): GC_FOR_MALLOC freed 1698 objects/566968 bytes in 89ms 04-05 03:38:56.724: D/dalvikvm(9713): GC_FOR_MALLOC freed 1678 objects/507304 bytes in 48ms 04-05 03:38:58.254: D/dalvikvm(9713): GC_FOR_MALLOC freed 1600 objects/529256 bytes in 45ms 04-05 03:39:00.273: D/dalvikvm(9713): GC_FOR_MALLOC freed 1623 objects/505208 bytes in 44ms 04-05 03:39:01.264: D/dalvikvm(9713): GC_FOR_MALLOC freed 1600 objects/529216 bytes in 46ms 04-05 03:39:01.554: D/dalvikvm(9713): GC_FOR_MALLOC freed 1623 objects/505152 bytes in 47ms 04-05 03:39:01.874: D/dalvikvm(9713): GC_FOR_MALLOC freed 1600 objects/529216 bytes in 45ms 04-05 03:39:02.094: E/endTime(9713): ~1333597142101 04-05 03:39:02.094: E/time—->(9713): 7871 04-05 03:39:02.094: E/average(9713): 157
ログの最後の1つは、平均コミット時間が約157ミリ秒であることを示しています.もちろん、ここでは3つのレコードをコミットするたびに、commitは52ミリ秒ほどかかります.2.先にコミットし、最後にcommitメソッドwww.2 comを使用します.
button.setOnClickListener(new OnClickListener() {

         @Override
        public void onClick(View v) {
            SharedPreferenceManager manager =SharedPreferenceManager.getInstance();
            Long startTime = Calendar.getInstance().getTimeInMillis();
            Log.e("start","~"+startTime );
             for(int i=0;i<50;i++){
                 manager.putInt("first"+i, 1);
                 manager.putInt("second"+i, 2);
                manager.putInt("third"+i, 3);
            }
             manager.commit();
             Long endTime = Calendar.getInstance().getTimeInMillis();
             Log.e("endTime","~"+endTime );
             Log.e("time---->", ""+(endTime-startTime));
             Log.e("average", ""+(endTime-startTime)/50);
         }
     });

Manager.putInt()メソッド:
public void putInt(String key, int value){ editor.putInt(key, value); }
ログは次のとおりです.
04-05 03:36:46.214: E/start(9167): ~1333597006214 04-05 03:36:46.244: E/endTime(9167): ~1333597006253 04-05 03:36:46.244: E/time—->(9167): 39 04-05 03:36:46.254: E/average(9167): 0
ここに表示されているデータに驚きました!Sharedpreferencesの実現方法を調べてみましょう

private static final class SharedPreferencesImpl implements SharedPreferences

putXxxの実装では内部のMapキャッシュを使用してデータをMapに保存し、commitではMapを巡回してListener Listenersを介してデータファイルの更新を促す.

listener.onSharedPreferenceChanged(SharedPreferencesImpl.this, key);

デフォルトでは、onSharedPreferenceChangedメソッドは書き換えられていません.ここではAndroid自体が実現しています.しかし、commitメソッドは同期、遍歴などの操作に関連しており、それ自体が時間がかかることが確認できます.そのため、commitオペレーションを減らすこと自体が最適化できることです.
結論:Commit操作自体は比較的時間がかかり、データの安全を保証する場合、データのリアルタイム性の要求が高くないところで、できるだけ累計して変更し、一度に提出し、効率を高めることができる.