SharedPreferences你用对了吗
2018-08-24 本文已影响10人
AntDream
本文首发于公众号“AntDream”,欢迎微信搜索“AntDream”或扫描文章底部二维码关注,和我一起每天进步一点点
一般的使用套路
SharedPreferences sharedPreferences = context.getSharedPreferences("test", Context.MODE_PRIVATE);
SharedPreferences.Editor editor = sharedPreferences.edit();
editor.putString("name", "test");
editor.commit();
实际上,SharedPreferences提交更改除了commit还有一个方法apply
SharedPreferences sharedPreferences = context.getSharedPreferences("test", Context.MODE_PRIVATE);
SharedPreferences.Editor editor = sharedPreferences.edit();
editor.putString("name", "test");
//editor.commit();
editor.apply();
那这两者有啥区别呢?
/**
* 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.
*
* @return Returns true if the new values were successfully written
* to persistent storage.
*/
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 apply wins.
*
* <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.
*
* <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.
*
* <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.
*
* <p class='note'>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 <code>apply()</code>, you can simply call
* {@link #commit} from <code>apply()</code>.
*/
void apply();
把注释拿出来了,大家可以看下。
我们可以总结出来这么几点区别:
- commit和apply方法都是用来提交更改的,而且提交多次的话会以最后一次提交的为准,也就是最后一次的更改是最终的结果,这个很好理解。
- commit方法有返回值,提交成功会返回true,失败返回false;而apply方法没有返回值。
- commit方法是同步提交的,而apply方法是异步提交,不会阻塞当前线程。
那我们该怎么使用这2种方法呢?总结如下:
如果需要知道提交结果的返回值的话,那就只能用commit方法了,不过实际上我们很少需要知道。所以除非有必要,绝大多数情况下都推荐使用apply方法来提交更改,特别是在主线程当中。这样可以提高应用性能。
以上,希望能帮到大家。
欢迎关注我的微信公众号,和我一起每天进步一点点!
AntDream