SharedPreferences sharedPreferences = getSharedPreferences("appSetting", MODE_PRIVATE);
        SharedPreferences.Editor editor = sharedPreferences.edit();
        editor.putBoolean("IsFirstView", false);
        editor.putString("AppName", "SharePreferences Demo");
        editor.commit();//同步提交到磁盘文件，因而会出现阻塞等的现象，如果要确保提交成功，尽量使用commit
        editor.apply();//先提交到内存，然后异步提交到磁盘，效率更高，但没有返回消息。

        Boolean isFirstView = sharedPreferences.getBoolean("IsFirstView", false);
        System.out.println("IsFirstView : " + isFirstView);
        String appName = sharedPreferences.getString("AppName", "");
        System.out.println("AppName : " + appName);
        String author = sharedPreferences.getString("author", "author null");
        System.out.println("Author : " + author);

09-12 10:34:50.627    2669-2669/com.example.ibm.dataoperate I/System.out﹕ IsFirstView : false
09-12 10:34:50.627    2669-2669/com.example.ibm.dataoperate I/System.out﹕ AppName : SharePreferences Demo
09-12 10:34:50.651    2669-2669/com.example.ibm.dataoperate I/System.out﹕ Author : author null

This constant was deprecated in API level 17.
Creating world-readable files is very dangerous, and likely to cause security holes in applications. It is strongly discouraged; instead, applications should use more formal mechanism for interactions such as ContentProvider, BroadcastReceiver, and Service. There are no guarantees that this access mode will remain on a file, such as when it goes through a backup and restore. File creation mode: allow all other applications to have read access to the created file.

Commit your preferences changes back from this Editor to the SharedPreferences object it is editing. This atomically performs the requested modifications, replacing whatever is currently in the SharedPreferences.

Note that when two editors are modifying preferences at the same time, the last one to call apply wins.

Unlike commit(), which writes its preferences out to persistent storage synchronously, apply() commits its changes to the in-memory SharedPreferences immediately but starts an asynchronous commit to disk and you won't be notified of any failures. If another editor on this SharedPreferences does a regular commit() while a apply() is still outstanding, the commit() will block until all async commits are completed as well as the commit itself.

As SharedPreferences instances are singletons within a process, it's safe to replace any instance of commit() with apply() if you were already ignoring the return value.

You don't need to worry about Android component lifecycles and their interaction with apply() writing to disk. The framework makes sure in-flight disk writes from apply() complete before switching states.

The SharedPreferences.Editor interface isn't expected to be implemented directly. However, if you previously did implement it and are now getting errors about missing apply(), you can simply call commit() from apply().