一、SharedPreferences簡介
? ? ? ?Android 中的 SharedPreferences（后續簡稱SP）是輕量級的數據存儲方式，能夠保存簡單的數據類型，比如 String、int、boolean 值等。應用場合主要是數據比較少的配置信息。其內部是以 XML 結構保存在 /data/data/包名/shared_prefs 文件夾下，數據以鍵值對的形式保存。
? ? ? ?使用Preference來存取數據，用到了SP接口和SP的一個內部接口SharedPreferences.Editor，這兩個接口在android.content包中。
? ? ? ?調用Context.getSharedPreferences(String name,int mode)方法得到SP接口。該方法的第一個參數是文件名稱，第二個參數是操作模式。操作模式有三種：MODE_PRIVATE（私有）、MODE_WORLD_READABLE（可讀）、MODE_WORLD_WRITEABLE（可寫）。
? ? ? ?SP提供了獲得數據的方法，如getString(String key,String defValue)、getInt(String key,int defValue)等。調用SP的edit()方法返回SharedPreferences.Editor內部接口，該接口中提供了保存數據的方法，如putString(String key,String value)，putInt(String key,int value)等，調用該接口的commit()方法可以將數據進行保存。
二、SP性能優化點
SP性能變差的原因有很多。
1、原生API的限制
（1）IO瓶頸
IO瓶頸造成SP性能差是最大的原因，解決了IO瓶頸，80%的性能問題就解決了。
SP的IO瓶頸包括讀取數據到內存與數據寫入磁盤兩部分。
讀取數據到內存有兩個場景會觸發：
- SP文件沒有被加載到內存時，調用getSharedPreferences方法會初始化文件并讀入內存。
- 版本低于android_H或使用了MULTI_PROCESS標志時，每次調用getSharedPreferences方法時都會讀入。
我們可以優化的便是(2)了。每次加載數據到內存太過影響效率。
H以下版本留存率已經很低了，基本可以忽略。
對于MULTI_PROCESS，可以采用ContentProvider等其他方式，效率更好，而且可避免SP數據丟失的情況。
數據寫入磁盤也有兩個場景會觸發：
- Editor的commit方法，每次執行時同步寫入磁盤。
- Editor的apply方法，每次執行時在單線程池中加入寫入磁盤Task，異步寫入。
commit和apply的方法區別在于同步寫入和異步寫入，以及是否需要返回值。
在不需要返回值的情況下，使用apply方法可以極大的提高性能。
同時，多個寫入操作可以合并為一個commit/apply，將多個寫入操作合并后也能提高IO性能。
（2）鎖性能差
SP的get操作，會鎖定SharedPreferences對象，互斥其他操作。
SP的put操作，getEditor及commitToMemory會鎖定SharedPreferences對象，put操作會鎖定Editor對象，寫入磁盤更會鎖定一個寫入鎖。
由于鎖的緣故，SP操作并發時，耗時會徒增。減少鎖耗時，是另一個優化點。
由于讀寫操作的鎖均是針對SP實例對象的，將數據拆分到不同的sp文件中，便是減少鎖耗時的直接方案。
降低單文件訪問頻率，多文件均攤訪問，以減少鎖耗時。
用開發機進行了簡單的性能測試(寫入均使用apply，若使用commit則多線程耗時更高):
讀寫同一文件，10個線程每個讀寫10次數據:
耗時80-130ms
讀寫10個文件，每個文件由1個線程讀寫10次數據:
耗時30-70ms
2、對SP的不當封裝也會間接造成數據讀寫性能差。
由于我們項目采用了插件化，所以對SP的操作涉及到了跨進程訪問。
我們采用ContentProvider方案支持跨進程訪問，并對所有SP操作均套上了ContentProvider進行訪問。
隨著項目越來越龐大，通過ContentProvider訪問造成的耗時性能也成了問題。
對ContentProvider操作SP測試，耗時是直接操作SP的4倍左右。
所以，最近項目中進行了SP的處理，對于不需要跨進程的SP操作去掉了ContentProvider，盡可能減少無謂耗時。
三、SP優化的建議
1、盡量不要直接調用SharedPreferences進行讀寫操作。
若直接調用getSharedPreferences(fileName,mode).edit().putString(key,value)，則對數據的操作直接耦合了fileName和key，后續想調整file和key會比較困難。
可以考慮封裝一下，譬如：
public void saveUserId(){getSharedPreferences(fileName,mode).edit().putString(“user_id”,value);
}
這樣做可以直接對數據訪問，而與fileName與key解耦，后續拆分與調整時會很方便。
2、將SP作為耗時操作對待，盡量減少無謂的調用。
譬如以下代碼，SP讀一次即可：
if(sp.getUserId()>0){int id=sp.getUserId();...
}
五、其他程序訪問本程序的配置數據方式
? ? ? ?通過SharedPreferences創建的配置文件，不需要指定路徑和文件后綴名，讀取的時候也是。通常情況下，配置只是提供給本應用程序使用的。在這里我們介紹一個小知識點，即其他程序想使用本應用程序的配置，那應該如何使用SharedPreferences呢？如下：
Context otherAppContext = createPackageContext("com.gary.appdisplaycontrol", Context.CONTEXT_IGNORE_SECURITY);
SharedPreferences sharedPreferences = otherAppContext.getSharedPreferences("preferences",Context.MODE_WORLD_READABLE|Context.MODE_MULTI_PROCESS);
備注：必須要添加Context.MODE_MULTI_PROCESS屬性，否則會遇到其他程序讀取數據未更新問題。
