关于Android系统中Activity和Fragment的自动重建调研

最新推荐文章于 2025-06-03 15:54:46 发布

原创最新推荐文章于 2025-06-03 15:54:46 发布 · 2.2k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#Android

Android 专栏收录该内容

5 篇文章

订阅专栏

本文探讨了Android中Activity和Fragment在系统回收后如何自动重建的问题，包括onSaveInstanceState()保存状态，系统根据Bundle恢复Activity和Fragment。文章列举了两种解决方案：1）根据Bundle状态决定是否创建Fragment；2）在onCreate()传入空Bundle避免系统重建。同时，指出了自定义Fragment需有无参构造函数，并建议避免自定义构造函数。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在Activity转入后台之前，系统会回调onSaveInstanceState()函数以保存该Activity的当前状态和信息，其中包括了保存在FragmentManager中Fragments的信息
protected void onSaveInstanceState(Bundle outState) {
   super.onSaveInstanceState(outState);
   Parcelable p = mFragments.saveAllState();
   if (p != null) {
       outState.putParcelable(FRAGMENTS_TAG, p);
   }
}

系统会在内存较低时回收后台app的资源，当之前被回收的Activity又被重新打开时，系统会传入一个保留状态信息的Bundle参数，也就是前面的onSaveInstanceState中保存的Bundle。
这时Activity会根据Bundle中的信息重建之前保留的状态，包括重建之前的Fragments，如果在onCreate或其他的生命周期函数中显式的新建了一样的Fragment，那么这个Fragment将会被新建和添加到Activity两次，从而产生严重的逻辑问题
protected void onCreate(Bundle savedInstanceState) {
   ......
   NonConfigurationInstances nc = (NonConfigurationInstances)
           getLastNonConfigurationInstance();
   if (nc != null) {
       mAllLoaderManagers = nc.loaders;
   }
   if (savedInstanceState != null) {
       Parcelable p = savedInstanceState.getParcelable(FRAGMENTS_TAG);
       mFragments.restoreAllState(p, nc != null ? nc.fragments : null);
   }
   mFragments.dispatchCreate();
}

Call Stack：
08-07 16:25:52.080: E/Fragment1(24058): com.example.testf.Fragment1.<init>(Fragment1.java:20)
08-07 16:25:52.080: E/Fragment1(24058): java.lang.Class.newInstanceImpl(Native Method)
08-07 16:25:52.080: E/Fragment1(24058): java.lang.Class.newInstance(Class.java:1319)
08-07 16:25:52.080: E/Fragment1(24058): android.support.v4.app.Fragment.instantiate(Fragment.java:420)
08-07 16:25:52.080: E/Fragment1(24058): android.support.v4.app.FragmentState.instantiate(Fragment.java:101)
08-07 16:25:52.080: E/Fragment1(24058): android.support.v4.app.FragmentManagerImpl.restoreAllState(FragmentManager.java:1833)
08-07 16:25:52.080: E/Fragment1(24058): android.support.v4.app.FragmentActivity.onCreate(FragmentActivity.java:264)
08-07 16:25:52.080: E/Fragment1(24058): android.support.v7.app.ActionBarActivity.onCreate(ActionBarActivity.java:122)
08-07 16:25:52.080: E/Fragment1(24058): com.example.testf.ActivityB.onCreate(ActivityB.java:22)

08-07 16:25:52.080: E/onAttach(24058): com.example.testf.Fragment1.onAttach(Fragment1.java:27)
08-07 16:25:52.080: E/onAttach(24058): android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:905)
08-07 16:25:52.080: E/onAttach(24058): android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1136)
08-07 16:25:52.080: E/onAttach(24058): android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1118)
08-07 16:25:52.080: E/onAttach(24058): android.support.v4.app.FragmentManagerImpl.dispatchCreate(FragmentManager.java:1922)
08-07 16:25:52.080: E/onAttach(24058): android.support.v4.app.FragmentActivity.onCreate(FragmentActivity.java:266)
08-07 16:25:52.080: E/onAttach(24058): android.support.v7.app.ActionBarActivity.onCreate(ActionBarActivity.java:122)
08-07 16:25:52.080: E/onAttach(24058): com.example.testf.ActivityB.onCreate(ActivityB.java:22)

解决方案：
1. 在Activity的onCreate或其他的生命周期函数中判断当前是否处于被系统重建的状态（判断Bundle是否为空即可），如果是的话就跳过新建Fragment的部分让系统来重建Fragment并且恢复其状态
   优点：Activity的所有状态被恢复后和被回收之前看起来一样，用户体验较好
   缺点：在一些复杂界面（如涉及嵌套Fragment的界面）判断逻辑复杂，增加了错误的可能性

2. 在Activity的onCreate调用其父类函数时传入空的Bundle参数，这样系统就没有信息来重建任何Fragments，而自定义的新建Fragment逻辑得以正确的执行。
   优点：实现简单，不容易产生错误
   缺点：重建后的Activity是初始状态而非用户离开时的状态，用户体验较差

结论：笔者认为Activity实现者应该根据具体情况来选择使用哪种解决方案，或者有更好的方案欢迎一起讨论

附:
系统在重建Fragments时会使用反射的方法去创建实例，所以自定义的Fragment必须带有一个无参数的构造函数，否则系统会抛出InstantiationException挂掉程序
另外google的官方文档建议不要自定义任何的构造函数，而在onAttach()中完成初始化的工作