1.apply没有返回值而commit返回boolean表明修改是否提交成功2.apply是将修改数据原子提交到内存, 而后异步真正提交到硬件磁盘, 而commit是同步的提交到硬件磁盘3.apply方法不会提示任何失败的提示 apply的效率高一些，如果没有必要确认是否提交成功建议使用apply。
The SharedPreferences class provides a general framework that allows you to save and retrieve persistent key-value pairs of primitive data types. You can use SharedPreferences to save any primitive data: booleans, floats, ints, longs, and strings. This data will persist across user sessions (even if your application is killed).
调用 getSharedPreferences()获取对应的的文件，该函数实现功能如下：
- //Context类静态数据集合，以键值对保存了所有读取该xml文件后所形成的数据集合
- private static final HashMap<File, SharedPreferencesImpl> sSharedPrefs =
- new HashMap<File, SharedPreferencesImpl>();
可以看到他有一个Map， 而针对SharedPreferencesImpl里面，由会有map， 这样也就可以证明， 为什么SharedPreference被广泛使用了。 他在普通时刻，内容是从内存里面直接读取的， 只有在第一次启动时，是IO操作。
2. apply() 和 commit()的区别
/** boolean commit();的注释如下：
* Commit your preferences changes back from this Editor to the
* {@link SharedPreferences} object it is editing. This atomically
* performs the requested modifications, replacing whatever is currently
* in the SharedPreferences.
*
* <p>Note that when two editors are modifying preferences at the same
* time, the last one to call commit wins.
*
* <p>If you don't care about the return value and you're
* using this from your application's main thread, consider
* using {@link #apply} instead. 如果你不考虑返回值，你在主线程中已经使用commit，那么你可以考虑替换使用apply
*
* @return Returns true if the new values were successfully written
* to persistent storage.
*/
apply方法的注释：
* <p>Unlike {@link #commit}, which writes its preferences out
* to persistent storage synchronously, {@link #apply}
* commits its changes to the in-memory
* {@link SharedPreferences} immediately but starts an
* asynchronous commit to disk and you won't be notified of
* any failures. If another editor on this
* {@link SharedPreferences} does a regular {@link #commit}
* while a {@link #apply} is still outstanding, the
* {@link #commit} will block until all async commits are
* completed as well as the commit itself.
apply不同意commit，commit是同步的去更改硬盘上的东西，而apply是先直接更改内存中的， 然后异步的去更改应硬盘中的内容。
不用去担心线程安全问题， 因为如果一个其他的线程去commit，而刚好有一个还没有完成的apply，commit会被阻塞到异步线程提交完成。
*
* <p>As {@link SharedPreferences} instances are singletons within
* a process, it's safe to replace any instance of {@link #commit} with
* {@link #apply} if you were already ignoring the return value. 如果你真的可以忽略返回值，恰好SharedPreferences又是单例模式的，那就可以安全的用apply来替换commit
*
* <p>You don't need to worry about Android component
* lifecycles and their interaction with <code>apply()</code>
* writing to disk. The framework makes sure in-flight disk
* writes from <code>apply()</code> complete before switching
* states. 也不需要去关心android组件的声明周期。 框架会保证完成所有apply之后，才切换状态。