1、調用 getSharedPreferences();創建壹個 SharedPreferences 對象，其中會先判斷是否存在對
應 xml 文件，如果發現存在則會有壹個預加載操作，這個操作是把 xml 文件的內容通過 I/O 操作和 XmlUitl 解析後存入壹個 map 對象中，所以我們調用 SharedPreferences::getString();等 get 操作實際上是不會對文件做 I/O 操作，而是直接訪問剛剛的 map 集合的內容，這提高了效率，如果對應的 xml 不存在則重新創建壹個對應的 xml 文件。
2、put 寫操作:寫操作也有兩步，壹是把數據先寫入內存中，即 map 集合，二是把數據寫入硬盤文件中。這樣才能保證數據的完整性，寫操作有兩個提交的方式:
從源碼解釋看commit方法有下面的特點
存儲的過程是原子操作commit方法有返回值，設置成功為ture，否則為false
同時對壹個SharedPreferences設置值最後壹次的設置會直接覆蓋前次值
如果不關心設置成功與否，並且是在主線程設置值，建議用apply方法
apply特點如下
存儲的過程也是原子操作
apply沒有返回值，存儲是否成功無從知道。
apply寫入過程分兩步，第壹步先同步寫入內存，第二部在異步寫入物理磁盤。並且寫入的過程會阻塞同壹個SharedPreferences對象的其他寫入操作。
明顯註意到apply方法沒有返回值，用戶沒法知道是否提交成功。且直觀上來講多了兩個Runnable的實現。提交過程采用子線程提交，為異步提交。
對於提交到內存和磁盤寫入操作都廣泛使用了synchronized關鍵字來保證其線程安全。最後還使用了阻塞操作，來等待其余的線程操作完畢。所以commit操作在多線程下是線程安全的。且註意到使用了try-catch來確保提交過程不可中斷。
對比總結：
commit和apply都是原子性操作，其中commit不可打斷。
commit有相應的返回值，可以知道操作是否成功，apply沒有返回值。
commit提交是同步過程，效率會比apply異步提交的速度慢。
commit方法將修改的數據提交到內存，然後同步提交到硬件磁盤，因此，在多個並發的提交commit的時候，他們會等待正在處理的commit保存到磁盤後在操作，從而降低了效率。
apply是將修改的數據提交到內存，然後異步的提交到硬件磁盤。