让你不再俱怕Fragment State Loss

1114288530 7年前
   <p>使用过 Fragment 的人我相信对臭名昭著的状态丢失问题( IllegalStateException: Can not perform this action after onSaveInstanceState )一定不会陌生。曾经被这个问题困扰了很久,相信很多同学也是。花些时间来好好把它研究一下,以弄懂为何会有这样的问题产生,然后就可以解决问题,或者合理的规避问题。</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/e63c77992bb8aebe7396d17651065d86.png"></p>    <h2><strong>什么是状态恢复</strong></h2>    <p>安卓的状态恢复是一个比较令人困惑的特性,它源于拙劣的系统设计。当一个页面正在显示的时候,如果系统发生了一些变化,变化又足以影响页面的展示,比如屏幕旋转了,语言发生了变化等。安卓的处理方式就是把页面(Activity)强制杀掉,再重新创建它,重建时就可以读取到新的配置了。又或者,当离开了一个页面,再回到页面时,如果页面(Activity)因为资源不足被回收了,那么当再回到它时,系统也会重新创建这个页面。</p>    <p>状态恢复,是为了保持更好的用户体验,让用户感觉认为页面,是一直存在的,类似于处理器调用函数的保护现场和恢复现场。</p>    <p>Activity有二个钩子onSaveInstanceState和onRestoreInstanceState就是用来保存状态和恢复状态的。</p>    <p>当从Honeycomb引入了Fragment后,为了想让开发者更多的使用Fragment,或者想让Fragment更容易的使用,状态保存与恢复的时候也必须要把Fragment保存与恢复。Fragment本质上就是一个View tree,强行附加上一些生命周期钩子。所以,为了让页面能恢复成先前的样子,View是必须要重新创建的,因此Fragment是必须要恢复的。</p>    <p>Fragment的作用域是Activity, FragmentManager 管理着一个Activity所有的Fragment,这些Fragment被放入一个栈中。每个Fragment有一个 FragmentState ,它相当于Fragment的snapshot,保存状态时FragmentManager把每个Fragment的FragmentState存储起来,最终存储到Activity的savedInstanceState中。</p>    <h2><strong>为什么会有这个异常</strong></h2>    <p>既然状态的保存与恢复都必须要把Fragment带上,那么一旦当Fragment的状态已保存过了,那么就不应该再改变Fragment的状态。因此FragmentManager的每一个操作前,都会调用一个方法来检查状态是否保存过了:</p>    <pre>  <code class="language-java">private void checkStateLoss() {      if (mStateSaved) {          throw new IllegalStateException(                      "Can not perform this action after onSaveInstanceState");      }      if (mNoTransactionsBecause != null) {          throw new IllegalStateException(                      "Can not perform this action inside of " + mNoTransactionsBecause);      }  }  </code></pre>    <p>Fragment状态保存是在Activity#onSaveInstanceState时做的,会调用FragmentManager#saveAllState方法,来进行Fragment的状态保存,同时设置mStateSaved为true,以标识状态已被保存过。</p>    <h2><strong>发生的场景以及如何应对</strong></h2>    <h3><strong>FragmentTransaction#commit()</strong></h3>    <p>栈信息是这样子的:</p>    <p>java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState at android.support.v4.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1341) at android.support.v4.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1352) at android.support.v4.app.BackStackRecord.commitInternal(BackStackRecord.java:595) at android.support.v4.app.BackStackRecord.commit(BackStackRecord.java:574)</p>    <p>或者是这样的:</p>    <p>java.lang.IllegalStateException: Activity has been destroyed</p>    <p>at android.app.FragmentManagerImpl.enqueueAction(FragmentManager.java:1456)</p>    <p>at android.app.BackStackRecord.commitInternal(BackStackRecord.java:707)</p>    <p>at android.app.BackStackRecord.commit(BackStackRecord.java:671)</p>    <p>at net.toughcoder.miscellaneous.FragmentTestActivity</p>    <p>原因就是commit操作发生在了状态保存之后。Activity#onSaveInstanceState的调用是不受开发者控制的,并且不同的安卓版本之间存在差异。具体的可以参考大神的 文章 。</p>    <p>解决之道,如大神提的一样,就是保证Fragment的操作发生在Activity可见周期之内,换句话说,Fragment的操作应该发生在Activity#onResume与Activity#onPause之间,为什么限制这么死呢?一方面为了防止上面问题发生;另外,Fragment本质上是View,View的操作理应该是页面处于活动状态时才应该进行。</p>    <p>关键的点就是小心控制异步任务,在onPause或者最迟在onStop中要终止所有的异步任务。</p>    <p>另外,大招就是使用commitAllowStateLoss。</p>    <h3><strong>Activity#onBackPressed</strong></h3>    <p>还有一种情况,也会出现此异常,而且是在Activity中完全 没有Fragment的情况下:</p>    <p>java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState at android.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1434) at android.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:577) at android.app.Activity.onBackPressed(Activity.java:2751) at net.toughcoder.miscellaneous.FragmentStateLossActivity.onBackPressed(FragmentStateLossActivity.java:90) at net.toughcoder.miscellaneous.FragmentStateLossActivity$1.run(FragmentStateLossActivity.java:59) at android.os.Handler.handleCallback(Handler.java:751) at android.os.Handler.dispatchMessage(Handler.java:95) at android.os.Looper.loop(Looper.java:154) at android.app.ActivityThread.main(ActivityThread.java:6077) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)</p>    <p>或者是这样的:</p>    <p>java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState at android.support.v4.app.FragmentManagerImpl.checkStateLoss(FragmentManager.java:1500) at android.support.v4.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:584) at android.support.v4.app.FragmentActivity.onBackPressed(FragmentActivity.java:169) at net.toughcoder.miscellaneous.FragmentStateLossActivity.onBackPressed(FragmentStateLossActivity.java:90) at net.toughcoder.miscellaneous.FragmentStateLossActivity$1.run(FragmentStateLossActivity.java:59) at android.os.Handler.handleCallback(Handler.java:751) at android.os.Handler.dispatchMessage(Handler.java:95) at android.os.Looper.loop(Looper.java:154) at android.app.ActivityThread.main(ActivityThread.java:6077) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:865) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)</p>    <p>这二个异常都是发生在没有使用Fragment的Activity中。相当的诡异,根本没有用Fragment为何还会抛出State loss的异常。只能从栈信息中的方法开始分析:</p>    <p>Activity的onBackPressed :</p>    <pre>  <code class="language-java">public void onBackPressed() {      if (mActionBar != null && mActionBar.collapseActionView()) {          return;      }        if (!mFragments.popBackStackImmediate()) {          finishAfterTransition();      }  }  </code></pre>    <p>以及 FragmentActivity的onBackPressed :</p>    <pre>  <code class="language-java">public void onBackPressed() {      if (!mFragments.popBackStackImmediate()) {          supportFinishAfterTransition();      }  }  </code></pre>    <p>从其源码中不难看出,响应BACK键时,一定会去pop fragment。前面提到过, FragmentManager 在改变Fragment的状态前(增加,移除,改变生命周期状态都是改变状态)都会检查state loss:</p>    <pre>  <code class="language-java">@Override  public boolean popBackStackImmediate() {      checkStateLoss();      executePendingTransactions();      return popBackStackState(mActivity.mHandler, null, -1, 0);  }  </code></pre>    <p>前面说了,checkStateLoss其实就是检查mStateSaved这个变量是否为true。那么都哪里给它设置为true了呢?对于正统的Activity和Fragment(android.app.*),是在 onSaveInstanceState 时,且只有这时才设置:</p>    <pre>  <code class="language-java">Parcelable saveAllState() {      // Make sure all pending operations have now been executed to get      // our state update-to-date.      execPendingActions();        mStateSaved = true;      // other codes.  }  </code></pre>    <p>但是对于support包中的Fragment(android.support.v4.app.*)除了在onSaveInstanceState中设置以外,在 onStop 中也把mStateSaved置为true:</p>    <pre>  <code class="language-java">public void dispatchStop() {      // See saveAllState() for the explanation of this.  We do this for      // all platform versions, to keep our behavior more consistent between      // them.      mStateSaved = true;        moveToState(Fragment.STOPPED, false);  }  </code></pre>    <p>所以,无论你用的是哪个Fragment,如果onBackPressed发生在onSavedInstanceState之后,那么就会上面的crash。 Stack Overflow上面有类似的讨论,比较全面和票数较高就是这个和这个 。</p>    <p>二个讨论中,针对此场景的获得最多赞同的解法是,覆写Activity的onSaveInstanceState,然后不要调用super:</p>    <pre>  <code class="language-java">@Override  public void onSaveInstanceState() {      // DO NOT call super  }  </code></pre>    <p>从上面的分析来看,这个对于android.app.*中的Fragment是能解决问题的,因为是在Activity的onSaveInstanceState(super.onSaveInstanceState)中才把mStateSaved置为true,所以不调super,它就仍是false,当再pop时,也就不会抛出异常的。</p>    <p>但是这明显是一个拙劣的workaround,首先,你在防止系统保存fragment的状态,可能会引发一引起其他的问题;再有就是,对于support包,这还是不管用,你仍然能够遇到state loss exception,因为在其onStop时也会把mStateSaved置为true。</p>    <p>上面分析得出,问题产生的原因是onBackPressed发生在了onSavedInstance之后,那么的解法是,同样设置一个标志,如果状态已保存过,就不要再处理onBackPressed:</p>    <pre>  <code class="language-java">public class FragmentStateLossActivity extends Activity {      private static final String TAG = "Fragment state loss";      private boolean mStateSaved;        @Override      protected void onCreate(Bundle savedInstanceState) {          super.onCreate(savedInstanceState);          setContentView(R.layout.activity_fragment_state_loss);          mStateSaved = false;      }        @Override      protected void onSaveInstanceState(Bundle outState) {          // Not call super won't help us, still get crash          super.onSaveInstanceState(outState);          if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {              mStateSaved = true;          }      }        @Override      protected void onResume() {          super.onResume();          mStateSaved = false;      }        @Override      protected void onPause() {          super.onPause();      }        @Override      protected void onStop() {          super.onStop();          mStateSaved = true;      }        @Override      protected void onStart() {          super.onStart();          mStateSaved = false;      }        @Override      protected void onDestroy() {          super.onDestroy();      }        @Override      public boolean onKeyDown(int keyCode, KeyEvent event) {          if (!mStateSaved) {              return super.onKeyDown(keyCode, event);          } else {              // State already saved, so ignore the event              return true;          }      }        @Override      public void onBackPressed() {          if (!mStateSaved) {              super.onBackPressed();          }      }  }  </code></pre>    <p>为了更彻底的杜绝问题,应该是状态保存过后,都不应该处理KEY事件。</p>    <p>其实,这也是合理的,onBackPressed一般是由BACK触发的,与KEY事件一样,都属于用户交互事件,用户交互事件都应该在Activity处于活动期间来响应,特别是过了onStop以后,再处理这样的事件也是没有意义的。</p>    <p>通常情况下,是不会发生这样的问题的,因为一般情况下是由BACK键触发onBackPressed,onBackPressed中调用finish(),finish才会触发销毁生命周期(save instance,pause,stop,destroy),自然不会产生onBackPressed发生在它们之后,也就没有此异常。但假如,有人为处理BACK事件,或者涉及Webview的BACK处理时,就有可能异步处理BACK,从而产生这个异常。</p>    <p>其实,从根儿上来讲,这是Android的设计不完善导致的,再看下pop back的实现:</p>    <pre>  <code class="language-java">@Override  public boolean popBackStackImmediate() {      checkStateLoss();      executePendingTransactions();      return popBackStackState(mActivity.mHandler, null, -1, 0);  }  </code></pre>    <p>难道第一句不应该是先判断此栈是否为空吗?如果为空(压根儿就没有用Fragment),为什么要check state loss,为什么还要去executePendingTransactions()? 但是,它又不得不这样做,因为Fragment的很多操作是异步的,到这个时候,有可能某些Fragment已被用户commit,但是还没有真正的添加到stack中去,因为只有把所有的pending transactions执行完了,才能知道到底有没有Fragment,但是执行pending transactions就会改变fragment的状态,就必须要check state loss。</p>    <p>看来万恶之源就是Fragment的transactions都是异步的。Anyway,Fragment的设计是有很多缺陷的,因为这并不是系统设计之初就考虑到的东西,所以,不可能像水果里的ViewController那样健壮好用。作为我们开发者,要么就干脆不用它,要么就把它研究透彻再使用,否则将会陷入无尽痛苦之中。</p>    <h2><strong>参考资料</strong></h2>    <ul>     <li><a href="/misc/goto?guid=4959713301313377561" rel="nofollow,noindex">Fragment Transactions & Activity State Loss</a></li>    </ul>    <p> </p>    <p>来自:http://toughcoder.net/blog/2016/11/28/fear-android-fragment-state-loss-no-more/</p>    <p> </p>