Most people die at the age of 20 or 30. They become their own shadow. The future life is just to copy themselves day by day. —— Roman Rowland's John Christopher
Today, I was asked a few basic questions. I didn't pay attention to them. I made an embarrassing reply. I took this opportunity to sum up.
This article answers the difference between Shared Preferences'common and apply methods. To be honest, the usual time to use is to choose the apply method, in which the specific difference is not in-depth study, it is time to look at the source code to explore.
commit method
First look at the source code explanation of the original taste.
/**
* 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();The commit method has the following characteristics from source code interpretation
- The stored procedure is atomic operation.
- The commit method has a return value, which is set to true successfully or false otherwise.
- At the same time, the last setup of a Shared Preferences setting value overrides the previous value directly.
- If you don't care whether the setup is successful or not, and you set the value in the main thread, it is recommended to use the apply method.
apply method
/**
* 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();apply has the following features
- Storage procedures are also atomic operations.
- apply does not return a value, and it is impossible to know if the storage is successful.
- apply writing process is divided into two steps. The first step is to write to memory synchronously, and the second step is to write to physical disk asynchronously. And the write process blocks other write operations on the same SharedPreferences object.
Atomic operation means "an uninterruptible operation or a series of operations". It is popular to say that once an operation begins, it will not be interrupted before the end. For example, a common + + I operation is not atomic, because it actually contains three steps: 1-reading the value of i, 2-adding 1,3-writing to the value of I read. Looking at these three steps separately, they are all atomic operations, but together they are non-atomic operations.
summary
Commit is relatively inefficient compared with apply. commit directly writes content to physical media, while apply submits content to memory synchronously, and then asynchronously writes content to physical media. This obviously improves efficiency.
There are several questions to be summarized in the following chapters.
1. The Activity interface shows which method to call back completely
2. ActivityA jumps to ActivityB. What is the situation of self-life cycle callbacks?
3. Types of wakelock