Fragivity is a single Activity framework based on fragments. Github.com/vitaviva/fr…

Developers working with similar frameworks are often concerned with the Lifecycle of fragments. Fragivity has done a number of optimizations in this area, addressing some of the pain points in other frameworks such as Navigation.

We are mainly concerned with life cycle performance in the following three cases:

  • The page is displayed or returned
  • Bright screen out
  • Configurations Change (screen rotation, etc.)

1. The page is displayed or returned

performance

When launching SecondFragment from FirstFragment:

SecondFragment => onCreate SecondFragment => onViewCreated SecondFragment => onActivityCreated SecondFragment => onStart  SecondFragment => onResume FirstFragment => onPause FirstFragment => onStopCopy the code
  • SecondFragment enters the creation process;
  • FirstFragment exits the foreground, but staysonDestroyViewBecause there is no need to rebuild the view on return

When returning a FirstFragment from SecondFragment:

SecondFragment  => onPause
SecondFragment => onStop
SecondFragment => onDestroyView
SecondFragment => onDestroy
FirstFragment => onStart
FirstFragment => onResume
Copy the code
  • SecondFragment enters the destruction process
  • FirstFragment returns to the foreground, but not againonCreateView

An improvement over other frameworks such as Navigation is the avoidance of recreating the view upon return, consistent with the Activity’s behavior.

Realize the principle of

Navigation will need to re-onCreateView on fallback since it switches fragments using replace. Fragivity uses add instead of replace to avoid Fragment reconstruction during fallback.

This approach presents a problem: The Fragment that is cut to the “background” is visually blocked, but in essence it is still attached. Its life cycle should be consistent with the Activity by default, so it needs to monitor the change of the BackStack. When the top of the stack changes (i.e. a new Fragment is added to the stack), Perform the performStop operation on the Fragment entering the background. The same is true when entering the “front desk”.

2. The bright screen out

performance

The current rollback stack has two pages: FirstFragment and SecondFragment. SecondFragment is at the top of the stack. Turn off/light up the screen now:

SecondFragment  => onPause
SecondFragment => onStop
Copy the code
SecondFragment  => onStart
SecondFragment => onResume
Copy the code
  • SecondFragment is consistent with the host Activity’s Lifecycle
  • The FirstFragment is also in the stack but is not affected because it is in the background

Realize the principle of

Fragivity uses add to switch fragments. Even if the Fragment is in the “background”, since it is attached, when the screen is lit, the default will be onStart and onResume with the Activity, which is obviously not what we want.

Fragivity encapsulates a proxy for all fragments entering the rollback stackReportFragment.

Sometimes it is not convenient to hook a Fragment directly from the system level. With ReportFragment, you can reduce the processing cost and have the opportunity to manipulate the propped object.

When the screen is lit, the stateChange distributed to the “background” Fragment is intercepted by the ReportFragment system so that it does not respond to the Activity lifecycle requirements.

Configurations Change 3. Configurations Change

performance

The current rollback stack has two pages: FirstFragment and SecondFragment. SecondFragment is at the top of the stack. Rotate the screen at this point:

SecondFragment  => onPause
SecondFragment => onStop
SecondFragment => onDestroyView
FirstFragment => onDestroyView
SecondFragment => onViewCreated
SecondFragment => onActivityCreated
SecondFragment => onStart
SecondFragment => onResume
Copy the code
  • A configuration change triggers a destroy rebuild. During the destruction process, all fragments in the stack are advanced toonDestroyView, fragments ofretainInstance=true, so it is not executedonDestroy. The “background” FirstFragment is already executedonStop, so only executeonDestroyView.

Fragments can only be rebuilt using the default constructor, so Fragivity sets retainInstance to true for all fragments that are pushed. This allows you to create a Fragment using a custom constructor without worrying about rebuilding

  • During the rebuild process, SecondFragment rebuilds normally, but FirstFragment does not rebuild because it is in the “background” to improve performance, only when it returns to the “foreground”

SecondFragment rotates the screen and then reprises it to FirstFragment:

SecondFragment  => onPause
SecondFragment => onStop
SecondFragment => onDestroyView
SecondFragment => onDestroy
FirstFragment => onViewCreated
FirstFragment => onActivityCreated
FirstFragment => onStart
FirstFragment => onResume
Copy the code
  • SecondFragment out of the stack is destroyed
  • FirstFragment comes to the foreground and enters the creation process

When the configuration changes cause the destruction and reconstruction, only the front Fragment is rebuilt at the first time. For the background Fragment, the reconstruction performance will not be affected when the number of fragments in the stack is large.

Realize the principle of

Also need to use ReportFragment to do some interception: whether “background” state is stored in ViewModel, identify its “background” identity when recovery and reconstruction, interception of dispatchResume.


FIN

This is the Lifecycle approach in Fragivity and hopefully will provide a reference for other similar requirements.