- public void putFloat(String key, float value)
- {
- editor.putFloat(key, value);
- editor.commit();
- }
即我們每次都使用事務提交數據,這樣操作對客戶端來說是很安全的,能確保每次數據能夠及時寫入,但是,由此也帶來了一個小問題,那就是commit操作本身耗時時間時比較長的,多次commit必然會帶來時間和性能上的比較大的開銷。客戶端做了一個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 putIntCom(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
日志的最後一條顯示:平均提交耗時約為157毫秒,當然這裡每次提交3條記錄,那麼每次commit大概耗時52毫秒
2.采用先提交,最後一次性commit方法
- 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,將數據通過其監聽器Listeners提示更新數據文件。
- listener.onSharedPreferenceChanged(SharedPreferencesImpl.this, key);
默認情況下,我們沒有重寫onSharedPreferenceChanged方法,這裡就交由Android本身去實現了。但是可以確定的是commit方法涉及到同步,遍歷等操作,本身是比較耗時的。
所以減少commit操作本身就是一件可以優化的事情。
結論:
Commit操作本身比較耗時,在保證數據安全的情況下,在數據實時性要求不高的地方,可以盡量累計更改,一次提交,以提高效率。
更多Android相關信息見Android 專題頁面 http://www.linuxidc.com/topicnews.aspx?tid=11