The difference between apply () and commit () methods of SharedPreferences.Editor
Documentation for commit ()
The official documents are 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 commit wins.
If you don't care about the return value and you're using this from your application's main thread, consider using apply () instead.
Documentation for apply ()
The official documents are 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 an 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.
Explain and explain
It is important to note that the commit () method is Added in API level 1, that is, sdk1 already exists.
The apply () method is of Added in API level 9.
Commit () has a return value, which returns true successfully, and the false.commit () method that returns failure commits synchronously to the hardware disk, so when multiple concurrent commit submissions are made, they will wait for the commit being processed to be saved to disk before operating, thus reducing efficiency.
Apply () does not return a value. Apply () commits the modified data to memory and then asynchronously commits it to the hardware disk.
Why is it recommended to use apply () instead of commit ()?
Answer: because the designers of Android have found that developers are not interested in the return value of commit, and it is less efficient to use commit than apply in data concurrent processing, apply.
