Android中Fragment管理及重叠问题的解决方法

一、fragment介绍

fragment在3.0被引入以后,项目使用fragment越来越多,特别是主界面是底部tab页点击切换更换内容，当然啦， fragment 在项目中存在着广泛的时候，例如通常在首页的设计中，通常底部的每一个 navigation 都对应这一个对应的 fragment ，使用 fragment 减轻了对应 activity 的职责，让 fragmen t充当了部分的activity的职责。而且使用 fragment 的时候，提高了代码和布局的封装和复用，这个优势也是特别的明显。

fragment 拥有自己的生命周期管理，但是它是依赖对应的activity的。

嗯，生命周期的介绍不是本篇的重点，贴个图加深一下印象。

二、fragment的栈管理及其生命周期

addtoshow

fragmenttransaction transaction = manager.begintransaction();
 string tag = to.getclass().getsimplename();
 transaction.add(from.getcontainerid(), to, tag)
   .addtobackstack(tag)
   .hide(from)
   .show(to)
   .commit();

如果使用 add() 和 hide() 来控制跳转的话，对应的生命周期是这样的：

e/tag: onattach: fragment09
 e/tag: oncreate: fragment09
 e/tag: oncreateview: fragment09
 e/tag: onstart: fragment09
 e/tag: onresume: fragment09
 e/____tag____: onclick: 2131558527
 e/tag: onattach: fragment10
 e/tag: oncreate: fragment10
 e/tag: onhiddenchanged: fragment09不可见了！
 e/tag: oncreateview: fragment10
 e/tag: onstart: fragment10
 e/tag: onresume: fragment10

如果此时从第二个 fragment 再次返回到第一个 fragment ：

e/tag: onhiddenchanged: fragment10不可见了！
 e/tag: onhiddenchanged: fragment09可见了！！
 e/tag: onpause: fragment10
 e/tag: onstop: fragment10
 e/tag: ondestroyview: fragment10
 e/tag: ondestroy: fragment10
 e/tag: ondetach: fragment10

可以对应上面的图片，当返回的时候是直接销毁的当前的 fragment 的，然后第一个 fragment 只是从不可见的状态变为了可见的状态，并没有走相关的生命周期，所以 hide() 的方法不会触发 onpause() 等生命周期回调方法。

那么如果我们锁屏了或者切换任务之后再切换回来的话：

e/tag: onpause: fragment09
 e/tag: onpause: fragment10
 e/tag: onstop: fragment09
 e/tag: onstop: fragment10
 e/tag: onstart: fragment09
 e/tag: onstart: fragment10
 e/tag: onresume: fragment09
 e/tag: onresume:不可见的 fragment09
 e/tag: onresume: fragment10
 e/tag: onresume:可见的 fragment10

这里可以看到，所有的 fragment 都回去随着 activity 去回调相关方法，不管它是否可见。

replaceto

fragmenttransaction transaction = manager.begintransaction();
 string tag = to.getclass().getsimplename();
 transaction.replace(from.getcontainerid(), to, tag)
   .addtobackstack(tag)
   .commit();

replace() 的方法其实就是相当于 remove() 移除之前添加到这个容器中的所有 fragment 然后再 add() 添加当前的。那么既然会调用 remove() 方法，所以生命周期就是这样的啦：

e/tag: onattach: fragment09
 e/tag: oncreate: fragment09
 e/tag: oncreateview: fragment09
 e/tag: onstart: fragment09
 e/tag: onresume: fragment09
 e/tag: onresume:可见的 fragment09
 e/____tag____: onclick: 2131558527
 e/tag: onattach: fragment10
 e/tag: oncreate: fragment10
 e/tag: onpause: fragment09
 e/tag: onstop: fragment09
 e/tag: ondestroyview: fragment09
 e/tag: oncreateview: fragment10
 e/tag: onstart: fragment10
 e/tag: onresume: fragment10
 e/tag: onresume:可见的 fragment10

对比上面的log来看的话，当 remove() 调用之后， fragment 会执行 onpause() ， onstop() ， ondestroyview() 会一次被调用，但是 ondestroy() ， ondetach() 是不会被调用的，这就是说它的视图会被摧毁了，那么重新回来的时候，就得重新创建：

e/tag: onpause: fragment10
 e/tag: onstop: fragment10
 e/tag: ondestroyview: fragment10
 e/tag: ondestroy: fragment10
 e/tag: ondetach: fragment10
 e/tag: oncreateview: fragment09
 e/tag: onstart: fragment09
 e/tag: onresume:可见的 fragment09

同样的，锁屏了或者切换任务之后再切换回来的话：

e/tag: onstart: fragment10
 e/tag: onresume:可见的 fragment10
 e/tag: onpause: fragment10
 e/mainactivity: onsaveinstancestate: 保存当前tag
 e/tag: onstop: fragment10
 e/tag: onstart: fragment10
 e/tag: onresume:可见的 fragment10

可以看到，当使用了 replace() 之后，这些情况之下只会有top的 fragment 来响应对应的生命周期。在上面的 add() 中，两个 fragment 都走了相关的生命周期的。

那么问题来了：什么时候使用 replace() 什么时候使用 add() 和 hide() 的呢？！其实对比来看，主要就是效率的问题和相关生命周期问题。

效率问题：

如果使用 replace() 就意味着每次的需要走 oncreateview() 再次去重新填充布局。如果在 oncreateview() 方法中还包含了初始化数据的话，也意味着相关的也要重新执行一次。

数据、页面刷新问题：

如果你使用 replace() 从 afragment 跳转到 bfragment ， bfragment 中更新了相关数据会影响到 afragment 的相关 view 展示的话，这里也会有问题，就算你使用 eventbus 什么的通知了， afragment 的确可以改变，但是当你切回到 afragment ，它会走 oncreateview() 重新创建相关布局，除非你保存到了全局，初始化的时候再次设置，那么之前发送的数据就会丢失了。

生命周期匹配问题：

生命周期的方法都是匹配成对出现的，上面说到的 replace() 方法中，a替换的时候走了以下三个生命周期回调方法：

e/tag: onpause: fragment09
 e/tag: onstop: fragment09
 e/tag: ondestroyview: fragment09

当回退到它的时候，对应的三个生命周期回调就被调用了：

e/tag: oncreateview: fragment09
 e/tag: onstart: fragment09
 e/tag: onresume:可见的 fragment09

但是使用 add() 和 hide() 的时候就会比较尴尬，你会发现它的 onpause() 和 onresume() 方法完全不匹配了。只要 add() 了，即使你调用 hide() ，不会影响它的生命周期回调，也不会有 onpause() 等回调。这也就出现了当我们锁屏或者切换任务回来的话，所有add进来的 fragment 都会执行一遍相关生命周期回调方法：

e/tag: onpause: fragment09
 e/tag: onpause: fragment10
 e/tag: onstop: fragment09
 e/tag: onstop: fragment10
 e/tag: onstart: fragment09
 e/tag: onstart: fragment10
 e/tag: onresume: fragment09
 e/tag: onresume:不可见的 fragment09
 e/tag: onresume: fragment10
 e/tag: onresume:可见的 fragment10

所以，如果你做统计相关的，这里可能就有点儿小问题了。当然，它显示与否并不是完全不可知的。

在 fragment 中可以通过 ishide() 的方法，或者 onhiddenchanged(boolean hiden) 的方法来获取当前是否是 hide 状态。

所以总结起来就是使用 add() 、 hide() 的方式，需要注意 onresume() 等回调方法的不匹配情况和获取数据的时机，应该在可见的时候（ ishidden() 返回 false 的时候）才去请求相关数据。

使用 replace() 的话就是要注意频繁的布局填充还有就是 fragment 与 fragment 之间的数据传递情况。

状态保存

fragment重叠异常情况

肯定碰到过fragment重叠显示的问题吧！？

 

 

这个主要就是 activity 帮我们在作相关的恢复状态的时候出现的问题。在设置中将不保留后台进程打开，方便产生对应的情况：

然后在第二个页面时回到首页，再次进入，我们先来看看一个异常的情况的log:

e/tag: onattach: fragment09
 e/tag: oncreate: fragment09
 e/tag: onattach: fragment10
 e/tag: oncreate: fragment10
 e/tag: oncreateview: fragment09
 e/tag: oncreateview: fragment10
 e/tag: onattach: fragment09
 e/tag: oncreate: fragment09
 e/tag: oncreateview: fragment09
 e/tag: onstart: fragment09
 e/tag: onstart: fragment10
 e/tag: onstart: fragment09
 e/tag: onresume:不可见的 fragment09
 e/tag: onresume:可见的 fragment10
 e/tag: onresume:可见的 fragment09

尼玛，发现问题没？我们的 fragment9 居然创建了两次。一个和之前是一样的，不可见的，另外一个居然是可见的，而且还在最上面。所以这个就造成了 fragment 重叠的情况。

还有一种情况就是断点发现某个 fragment 初始化成功了，布局也有了，但是里面的view全是空的，这个情况我也遇到过。

为什么会出现这个问题？因为在这种异常情况下，会触发 android 的临时数据保存机制， fragment 是它临时保存的重点对象。所以之前的两个 fragment 相关状态都被保存下来了！但在 activity 的 oncreate() 中我是这样写的话：

fragmentsutil.loadroot(r.id.fragment_container, fragment9.newinstance());

那么就是说不管是否有保存的状态我都去再次创建加载一次 fragment9 了，所以这个就导致了 fragment9 创建了两次（一次是系统恢复出来的，相关状态也是正常的，一次就是我们在 oncreate() 中创建出来的）。那么要避免这个问题就要在 savedinstancestate 这个东西上想想办法了。既然它已经保存了相关的 fragment 了，我们就不用去再次创建咯！

@override
protected void oncreate(bundle savedinstancestate) {
 super.oncreate(savedinstancestate);
 setcontentview(r.layout.activity_main);
 butterknife.bind(this);
 manager = getsupportfragmentmanager();
 if (savedinstancestate == null) {
  log.e(tag, "onsaveinstancestate: 恢复相关状态！！");
  fragmentsutil.loadroot(r.id.fragment_container, fragment9.newinstance());
 }
}

所以说呢， savedinstancestate 还是不能忽略的。不过到这里就以为完了的话就太低估 fragment 的坑了， 如果你的 support-library 是低于24的，那么即使判断了 savedinstancestate 再去创建但是也有可能出现重叠的情况！

这里要说说 fragmentstate 这个类，它是用来保存 fragment 的相关状态的。

发现情况没？？在之前的 fragmentstate 中并没有保存 mhidden 的状态！

另外也搜索到了 相关issue提交 ，但是在 android 的 revision-history 中并没有看到提及的相关bug修复。所以具体什么时候正式加了 mhidden 的字段也就没有考证出来了。

聊了这么多，最后说说解决方案呗，其实原理很简单，既然它没有自动保存，那么我们就在保存状态的时候手动把 mhidden 状态保存，在初始化的时候根据保存的 mhidden 状态手动显示或者隐藏。

@override
public void onsaveinstancestate(bundle outstate) {
 //手动保存
 outstate.putboolean(arg_is_hidden, ishidden());
 super.onsaveinstancestate(outstate);
}
 //oncreate的时候调用
public void initfragments(bundle savedinstancestate, basefragment fragment) {
 if (savedinstancestate == null) {
  return;
 }
 boolean issupporthidden = savedinstancestate.getboolean(arg_is_hidden);

 fragmenttransaction ft = manager.begintransaction();
 if (issupporthidden) {
  ft.hide(fragment);
 } else {
  ft.show(fragment);
 }
 ft.commit();
}

最后封装了一个简单的工具类和 basefragment , 用于处理 fragment 相关的事务的。

总结

以上就是这篇文章的全部内容了，希望本文的内容对各位android开发者们能有所帮助，如果有疑问大家可以留言交流。