SharedPreference is often used when storing data in android, and the editor's commit method is always used when submitting data. Today, I accidentally saw that the system uses apply, and after reading the introduction of the method, it turns out that this method can also submit data.
The apply method is described in the official SDK as follows:
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().
The difference between these two methods is:
1. apply has no return value and commit returns boolean to indicate whether the modification is submitted successfully
2. apply is to atomically submit the modified data to the memory, and then submit it to the hardware disk asynchronously, while commit is submitted synchronously to the Hardware disk, therefore, when multiple concurrent commits are submitted, they will wait for the commit being processed to be saved to disk before operating, thus reducing efficiency. Apply is only atomically submitted to the content, and the function that calls apply will directly overwrite the previous memory data, which improves a lot of efficiency to a certain extent.
3. The apply method will not prompt any failure prompts.
Since sharedPreference is a single instance in a process, there is generally no concurrency conflict. If you don't care about the result of the submission, it is recommended to use apply. Of course, if you need to ensure that the submission is successful and there are follow-up operations, you still need to use commit.