I am cang Wang, the following is my series of related articles, interested can refer to, you can give a like or follow my article. [Android] How to make a chapter list of apps with a crash rate of less than three per thousand

One of the weird Fragments issues I’ve encountered recently is that many apps use Viewpager+Fragments to display layouts, especially on the home page. If your app has several activities open in the stack, and suddenly crashes, it will normally, after the crash is caught, resume and try to resume the Activity at the top of the stack before the crash. For such a crash, the Activity will no doubt use onSaveInstanceState before crashing and onRestoreInstanceState when resuming. However, when an Activity that contains ViewPager+Fragments is triggered to resume, you may find that these Fragments leak memory. Analysis: This is not easy to detect. When viewing the app object using a Profile, you will find that these Fragments have been created twice, which cannot be detected by LeakCanary because it is the main Activity that leaks. Also, the Fragment displayed at the top is not a Fragment held by the Activity. If some data is retrieved from the Activity, it will not be displayed. Reason: Looking through the source code, we can see the following code for restoring FragmentActivity and the onCreate process for rebuilding FragmentActivity

/** * Save all appropriate fragment state. */ @Override protected void onSaveInstanceState(Bundle outState) { super.onSaveInstanceState(outState); // Record which Fragments are created markFragmentsCreated(); // Save the state of Fragments Parcelable p = mfragments.saveallState ();if(p ! = null) { outState.putParcelable(FRAGMENTS_TAG, p); }... } @SuppressWarnings("deprecation")
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        
        mFragments.attachHost(null /*parent*/);

        super.onCreate(savedInstanceState);

        if(savedInstanceState ! = null) { Parcelable p = savedInstanceState.getParcelable(FRAGMENTS_TAG); . / / the stack Fragments could recover mFragments restoreAllState (p, nc! = null ? nc.fragments : null); ... } mFragments.dispatchCreate(); }Copy the code

If a Fragment is broken, onSaveInstanceState will record that it has been created and saveAllState will be called. Then onCreate will call restoreAllState to restore the Fragment. A new fragment is then created. Normally, super.onCreate will be executed before the subclass is called, and Fragments will be restored before the subclass Activity onCreate. Then re-go through the onCreate process and re-create the ViewPager and Fragments. Fragments will then be created twice. Workaround: There is no way to know the TAG of a restored mFragments, so the Activity cannot be tagged.

1. At the time of onSaveInstanceState, don’t call the super method, direct call FragmentActivity. OnStateNotSaved (), truncation mFragments directly to return stack. However, onSaveInstanceState will not be able to recover and may have unknown errors, so 2 is not adopted. In onCreate process, judge supportFragmentManager first. If there is a corresponding fragments could fragments, and then if there is not create many times, in supportFragmentManager directly. The fragments could get.

Failure, the supportFragmentManager fragments could clear is invalid, supportFragmentManager. Fragments could is inequitable in FragmentActivity mFragments

The onRestoreInstanceState life cycle is after onCreate and before onResume, so some operations that go through recovery can only be done in onResume. 2. Application. LifeRecyleCallback unable to listen to the implementation of onRestoreInstanceState.