original source : https://stackoverflow.com/a/58663143/3151712
There are two different lifecycles because the Fragment itself lives longer than the Fragment’s view.
There are a number of events that can cause the Fragment’s view to be destroyed, but currently keep the Fragment itself alive:
- Putting the Fragment on the back stack (i.e., when you
navigate()to another Fragment)
detach()on a Fragment
setMaxLifecycle(Lifecycle.State.CREATED)on a Fragment
In these cases, the Fragment’s view is destroyed, moving the Fragment view lifecycle to
DESTROYED. However, the lifecycle of Fragment itself is not destroyed – it generally stays as
CREATED. This means that the Fragment can go through multiple cycles of
onDestroyView() while only going through
Where this becomes a problem is when it comes to how
LiveData works. When you
LiveData automatically unregisters the observer when the lifecycle reaches
DESTROYED. But if you use the Fragment’s lifecycle to
onCreateView(), etc., that registered observer will still exist after
onDestroyView(), despite the view being destroyed. This means that the second time your Fragment goes through
onCreateView(), you’ll actually create a second active Observer, with both running simultaneously. Then three Observers the next time and on and on.
By using the view LifecycleOwner in
onViewCreated(), you ensure that you’ll only have one active Observer running at a time and that Observers tied to previous view instances are correctly destroyed along with the view. Therefore, yes, you should always use
getViewLifecycleOwner() as the LifecycleOwner when in
onViewCreated(), including when using Data Binding.
Of course, if you’re registering an Observer in
onCreate(), then the view LifecycleOwner does not exist yet (it is created right before
onCreateView()) and you don’t have the multiple registration problem, which is why the Lint check specifically does not apply to any registrations done at
onCreate() time. In those cases, using the Fragment’s lifecycle itself is absolutely correct.
As per the Fragments: Past, Present, and Future talk, one future improvements for Fragments is going to be combining the two lifecycles together, always destroying the Fragment whenever the Fragment’s view is destroyed. This is not yet available in any shipped version of Fragments, alpha or otherwise.