9行代码让你app内的Fragment对重叠说再见
总阅读次
原文链接:http://www.jianshu.com/p/c12a98a36b2b
在上一篇从源码角度分析,为什么会发生Fragment重叠?里,我们分析了造成Fragment重叠的原因,这一篇我会介绍几个解决方案,同时给出一个我的方案:9行代码让你app内的Fragment对重叠说再见!
通过findFragmentByTag() & getFragments()的解决方案
这两种方案在我这篇简书Fragment全解析系列(一):那些年踩过的坑里有比较详细的介绍,可以自行查看,这里不多做介绍,这两种方案也是最常见的解决方案。
缺点:
- 使用比较麻烦,代码量较多;
- 在Fragment嵌套的场景下,恢复会有问题,原因在于:页面重启后,在父Fragment没有初始化完成前,getChildFragmentManager()子栈内的子Fragment是空,只有父Fragment初始化完成后,子栈内的子Fragment才能正确获取到。
从源码角度想到的解决方案:自己保存Fragment的Hidden状态
下面这个方案,是我在完善Fragmentation库时想到的方案。
Fragmentation库前几天push了改变重大的0.7版本,应该算是比较成熟了,如果你重度使用Fragment或者想使用单Activity+多Fragment的组件架构的话,强烈推荐看看;对于各种复杂嵌套、同级Fragment的使用场景,你不必担心Fragment的重叠,同时大大简化Fragment的嵌套逻辑。
在上一篇分析中,我们知道了发生Fragment重叠的根本原因在于FragmentState没有保存Fragment的显示状态,即mHidden
,导致页面重启后,该值为默认的false,即show状态,所以导致了Fragment的重叠。
根据这个原因,我想到我们手动维护一个mSupportHidden
不就行了吗?
看下面的基类Fragment代码:
|
|
是的你没看错,只要上面的9行代码! FragmentState没帮我们保存Hidden状态,那就我们自己来保存,在页面重启后,我们自己来决定Fragment是否显示!
解决思路转变了,由Activity/父Fragment来管理子Fragment的Hidden状态转变为 由Fragment自己来管理自己的Hidden状态!
优点:不管多深的嵌套Fragment、同级Fragment等场景,全都可以正常工作,不会发生重叠!
缺点:暂时没有发现。
补充:
有些小伙伴反应还是会重叠,其实是因为加载根Fragment时没有经过判断的原因,当在类似onCreate
等初始化生命周期里加载根Fragment(即第一个Fragment)时,需要下面的判断,避免重复加载相同的Fragment:
|
|
最后
最后的方案用在了我的Fragmentation库中,在新的仿知乎的Demo里,各种复杂场景表现完美。
但是这个方案真的神奇的不可思议,在我的测试下,各种情况都正常适用,但是之前从没看到有人提到过该方案,所以如果你发现该方案有我没有考虑到的BUG,请第一时间告诉我!
最后是一点心得体会:
当遇到问题时,我们如果从源头思考:为什么会发生这个问题? 从源码角度分析问题,可能就会得到一个更好的解决问题的思路!
未经许可不得转载,转载请注明zilianliuxue的blog,本人保留所有版权。