SharedPreferences的基本概念： 檔案儲存路徑：/data/data/<包名>/shared_prefs目錄下目錄下生成了一個SP.xml檔案 SharedPreferences物件本身只能獲取資料而不支援儲存和修改，儲存修改是通過Editor物件實現。實現SharedPreferences儲存的步驟如下： 　　一、根據Context獲取SharedPreferences物件 　　二、利用edit()方法獲取Editor物件。 　　三、通過Editor物件儲存key-value鍵值對資料。 　　四、通過commit()方法提交資料。 在程式程式碼中，通過getXXX方法，可以方便的獲得對應Key的Value值，如果key值錯誤或者此key無對應value值，SharedPreferences提供了一個賦予預設值的機會，以此保證程式的健壯性。如下圖執行結果中因為並無值為"NOT_EXIST"的Key，所以Log打印出的是其預設值：“none”。在訪問一個不存在key值這個過程中，並無任何異常丟擲。 SharedPreferences物件與SQLite資料庫相比，免去了建立資料庫，建立表，寫SQL語句等諸多操作，相對而言更加方便，簡潔。但是SharedPreferences也有其自身缺陷，比如其職能儲存boolean，int，float，long和String五種簡單的資料型別，比如其無法進行條件查詢等。所以不論SharedPreferences的資料儲存操作是如何簡單，它也只能是儲存方式的一種補充，而無法完全替代如SQLite資料庫這樣的其他資料儲存方式。 android中的四大儲存資料方式之一SharedPrerence的使用不必多少，官方文件說的很詳細，也很簡單。但是有一個需要注意的地方就是在android的api中，Editor提供了兩個提交的修改的方法：apply和commit，下面就來說說apply和commit把。相同點： 1.二者都是提交preference修改資料 2.二者都是原子過程。 區別： 1.apply沒有返回值而commit返回boolean表明修改是否提交成功 2.apply是將修改資料原子提交到記憶體，而後非同步真正提交到硬體磁碟；而commit是同步的提交到硬體磁碟，因此，在多個併發的提交commit的時候，他們會等待正在處理的commit儲存到磁碟後在操作，從而降低了效率。而apply只是原子的提交到內容，後面有呼叫apply的函式的將會直接覆蓋前面的記憶體資料，這樣從一定程度上提高了很多效率。 3.apply方法不會提示任何失敗的提示。 綜合上述，由於在一個程序中，sharedPreference是單例項，一般不會出現併發衝突，如果對提交的結果不關心的話，建議使用apply，當然需要確保提交成功且有後續操作的話，還是需要用commit的。 commit介紹：public abstract boolean commit () 修改你的preferences，從Editor到SharePreferences。它執行所請求的修改，替代SharedPreferences中的任何資料 當2個editor同時修改preferences ，最後一個commit成功。 如果不關注返回值或在程式的main執行緒使用時，推薦使用apply(). apply介紹：public abstract void apply () 區別： commit將同步的將資料寫到preferences；apply立即更改記憶體中的SharedPreferences，但是開始非同步提交到磁碟中。儲存失敗你也不會得到任何提示資訊， 如果在這個sharedPreferences有另外一個editor執行一個定期的commit，此時一個apply依舊未完成。commit將被阻塞，直到所有非同步操作完成，以及自己的commit。 由於SharedPreferences在程序中是單例項的。在忽悠返回值的前提下，取代任何例項的commit或apply都是安全的。