commit()和apply()的區別

返回值

apply()沒有返回值，而commit()返回boolean表明修改是否提交成功。

操作效率

apply()是將修改資料原子提交到記憶體, 而後非同步真正提交到硬體磁碟,。

而commit()是同步的提交到硬體磁碟。

因此，在多併發commit()的時候，會等待正在處理的commit儲存到磁碟後再操作，從而降低了效率。

而apply只是原子的提交到內容，後面有呼叫apply的函式的將會直接覆蓋前面的記憶體資料，從一定程度上提高了效率。

建議

如果對提交的結果不關心的話，建議使用apply()，如果需要確保提交成功且有後續操作的話，還是需要用commit()。

多程序表現

是為了回答這個問題。

一句話：在多程序中，如果要交換資料，不要使用SharedPreference，因為在不同版本表現不穩定，推薦使用ContentProvider替代。

在有的文章中，有提到在多程序中使用SharedPreference新增下面標誌位就可以了。

MODE_MULTI_PROCESS

但是在官方文件中這樣提到：

This was the legacy (but undocumented) behavior in and
   before Gingerbread (Android 2.3) and this flag is implied when targetting such releases.  
   For applications targetting SDK versions greater than
 
 Android 2.3, 
   this flag must be explicitly set if desired.

@deprecated MODE_MULTI_PROCESS does not work reliably in some versions of Android, 
and furthermore does not provide any mechanism for reconciling concurrent modifications 
across processes.  Applications should not attempt to use it.  Instead, they should use an explicit 
cross-process data management approach such as
 
 ContentProvider

簡單解釋下，就是這個標誌位在2.3之前是預設支援的，但是在2.3之後，如果需要多程序訪問的情景，就需要顯示的宣告出來。

現在這個標誌位被廢棄了，因為在某些版本上表現不穩定。我們開發者不應該嘗試去使用它，因為他沒有提供任何併發機制，我們應該使用一種明確支援跨程序訪問的機制，比如ContentProvider。

使用細節

• ContextImpl中有一個靜態的ArrayMap變數sSharedPrefs，無論有多少個ContextImpl物件例項，系統都共享這一個sSharedPrefs的Map，應用啟動以後首次使用SharePreference時建立，系統結束時才可能會被垃圾回收器回收，所以如果我們一個App中頻繁的使用不同檔名的SharedPreferences很多時這個Map就會很大，也即會佔用移動裝置寶貴的記憶體空間。所以我們應用中應該儘可能少的使用不同檔名的SharedPreferences，取而代之的是合併他們，減小記憶體使用
• SharedPreferences在例項化時首先會從sdcard非同步讀檔案，然後快取在記憶體中；接下來的讀操作都是記憶體快取操作而不是檔案操作。
• 在SharedPreferences的Editor中如果用commit()方法提交資料，其過程是先把資料更新到記憶體，然後在當前執行緒中寫檔案操作，提交完成返回提交狀態；如果用的是apply()方法提交資料，首先也是寫到記憶體，接著在一個新執行緒中非同步寫檔案，然後沒有返回值。
• 在寫操作commit時有三級鎖操作，效率很低，所以當我們一次有多個修改寫操作時等都批量put完了再一次提交確認，這樣可以提高效率。

更多參考資料