如果說程序可以簡單理解成“指令和數據的集合”，那么你在任何平臺上編程都難以離開數據存儲，在Android平臺上自然也不會例外。說到數據的存儲，對于Key-Value對應的數據存取，Android提供SharedPreferences的方式可以進行方便的操作。大家也都覺得它的使用很簡單，但是有時候簡單的地方也會發生問題，而且你很難查覺到問題根源在這個地方。
面試題：修改SharedPreferences后兩種提交方式有什么區別？
SharedPreferences類是一個接口類，真正的實現類是SharedPreferencesImpl。修改SharedPreferences需要獲取它的Editor，在對Editor進行put操作后，最后通過commit或者apply提交修改到內存和文件。當然有了兩種都可以提交的方法，肯定要區別一下的。從實現類SharedPreferencesImpl的源碼上看也很容易看出兩者的區別：
commit這種方式很常用，在比較早的SDK版本中就有了，這種提交修改的方式是同步的，會阻塞調用它的線程，并且這個方法會返回boolean值告知保存是否成功（如果不成功，可以做一些補救措施）。
而apply是異步的提交方式，目前Android Studio也會提示大家使用這種方式。
還有一點用得比較少的，就是SharedPreferences還提供一個監聽接口可以監聽SharedPreferences的鍵值變化，需要監控鍵值變化的可以用registerOnSharedPreferenceChangeListener添加監聽器。
public interface SharedPreferences {
/**
* Interface definition for a callback to be invoked when a shared
* preference is changed.
*/
public interface OnSharedPreferenceChangeListener {
void onSharedPreferenceChanged(SharedPreferences sharedPreferences, String key);
}
多進程操作和讀取SharedPreferences的問題
前段時間，項目組里發現一個偶現的問題，從Http明明獲取了正確的數據保存到SharedPreferences，但立即再從SharedPreferences讀取這個值時發現是初始值。開始大家一直把精力放在Http的請求上，最后才發現是SharedPreferences多進程間數據共享會導致的問題。
在SDK 3.0及以上版本，可以通過Context.MODE_MULTI_PROCESS屬性來實現SharedPreferences多進程共享。如下設置：
public static SharedPreferences getSharedPreferences(String name) {
if (null != context) {
if (Build.VERSION.SDK_INT >= 11) {
return context.getSharedPreferences(name, Context.MODE_MULTI_PROCESS);
} else {
return context.getSharedPreferences(name, Context.MODE_PRIVATE);
}
}
return null;
}
本來以為通過MODE_MULTI_PROCESS屬性使用SharedPreferences就可以實現不同時程間共享數據，但是在真正使用中確發現有會有一定概率出現這個取值出錯（變為初始值）問題。
最后發現在官網上Google也在SDK 6.0的版本將這個MODE_MULTI_PROCESS標識為deprecated（不贊成使用）。目前來說，越來越多的項目在不斷的膨脹，為了降低單個進程的內存占用率，使用"android:process"配置一些組件在單獨的進程中運行已經是司空見慣了，所以大家在遇到自己的項目有多進程時，要注意一下SharedPreferences的問題。
小結
在一個進程中，SharedPreference往往建單個實例就可以了，一般不會出現并發沖突，如果對提交的結果不關心的話，建議使用apply，當然需要確保提交成功且有后續操作的話，還是需要用commit的。
因為SharedPreferences在多進程方面的問題，大家也可以思考下能不能自己實現一個加強版的SharedPreferences解決這些問題，網上也有一些開源的替代方案，如Github上的tray。（建議大家先想一下，再看這個項目。）
