Explore the life cycle of fragment when writing Android applications with examples

Managing the lifecycle of a fragment is somewhat like managing the lifecycle of an activity. Fragment can exist in three states:

Resumed:

The fragment is in a running activity and is visible.

Paused:

Another activity is at the top level, but the activity where the fragment is located is not completely covered (the activity at the top level is translucent or does not occupy the whole screen).

Stoped:

Fragment is not visible. It may be that the activity in which it is located is in the stopped state or the fragment is deleted and added to the back stack. Fragments in this state still exist in memory.

Similarly, similar to activity, you can save the state of the fragment in a bundle, which is needed when the activity is recreated. You can save the state in the onsaveinstancestate() method and restore it in oncreate() or oncreateview() or onactivitycreated().

The biggest difference between the life cycle of fragment and activity is the process stored in the backward stack. Activity is automatically pushed into the stop stack by the system when stopping, and this stack is managed by the system; Fragment is a backward stack managed by the push activity, and it is pushed only when you delete the fragment and explicitly call the addtobackstack () method.

However, the lifecycle of managing fragments is very similar to that of managing activities. What you need to think about is how the life cycle of an activity affects the life cycle of a fragment.

You should have seen a lot about the following fragment life cycle diagram:

But recently, when I was writing pagemanager (manage page Jump), I found that when switching pages, the previous page went directly to ondestoryview and then went back to oncreate. If I used hide and show, I didn't go through the life cycle. I looked at the apidemo code, found the reason and sorted it out. There are two ways to switch fragments. One is to add a new one and put the old hide, The other is replace. The old fragment is fragment1 and the new is fragment2, ignoring the non critical life cycle.

When switching using the add method: load fragment1

Cut to fragment2 with the following code:

Fragment1 does not take any life cycle, but calls the onhiddenchanged method

Back to fragment1, remove fragment2:

Fragment1 still does not go through any life cycle, and calls the onhiddenchanged method

When switching in this way, the fragment will not go to ondestoryview when hidden, so it will not go to oncreateview when displayed. All views are always saved in memory. Use the replace method: the life cycle of loading fragment1 is the same as above:

Switch to fragment2:

Fragment1 goes through its life cycle this time

Fragment1 and fragment2 may be mixed in the real print. You can see that fragment1 has gone ondestory and has been completely recycled! Then cut back to fragment1

Because fragment1 has been recycled, go oncreate and fragment2 is recycled.

These two methods obviously do not meet my needs and are different from the life cycle diagram. Because I need things like register and unregister broadcastreceiver when the user sees / cannot see the fragment (onhiddenchanged can also be implemented, but the onhiddenchanged method will not be used when loading the display for the first time and destroying it), and I don't want the user to recreate the whole fragment when returning to the previous fragment, because it consumes resources.

After reading apidemo, I found that the replace method is also used, but I missed one line:

Add this line when replacing. You can put the original fragment into the stack and use the ondestoryview method, but not the ondestory. When returning, you can directly oncreateview instead of oncreate. Return and call the popbackstack() method directly: