前几天，把项目中的support library的版本号从25.0.1升级到25.1.0之后，出现了好多莫名其妙的bug，后来经过排查才发现是升级版本号之后，Fragment切换时生命周期函数的执行顺序发生了变化。网上也有反馈，下面把这个坑整理一下，希望能帮大家提个醒。
在25.1.0以前，通过FragmentTransaction的replace方法从FragmentA切换到FragmentB的时候，生命周期函数的执行顺序如下：
D/FragmentA: onPause()
D/FragmentA: onStop()
D/FragmentB: onStart()
D/FragmentB: onResume()
先执行FragmentA的onPause和onStop，然后再执行FragmentB的onStart和onResume。
但是25.1.0之后，从FragmentA切换到FragmentB的时候，生命周期函数的执行顺序变成：
D/FragmentB: onStart()
D/FragmentB: onResume()
D/FragmentA: onPause()
D/FragmentA: onStop()
先执行了FragmentB的onStart和onResume方法，然后才执行FragmentA的onPause和onStop方法。而我们的项目中，分别在onStart和onStop方法中执行了一些操作，这样执行的顺序完全变了，导致了一些bug。
想要恢复成以前的执行顺序也是有办法的，可以调用FragmentTransaction.setAllowOptimization(false)方法，这样生命周期函数的执行顺序和之前是一样的。
getFragmentManager()
.beginTransaction()
.setAllowOptimization(false)
.replace(R.id.container, FragmentA.newInstance(), FragmentA.class.getSimpleName())
.commit();
关于这个问题的更多解释说明可以参考这个issues_230415，github上面有人已经写了一个小Demo，可以从log信息里面看到执行的顺序。还有Google上搜到的一篇文章，虽然是日语写的，不过大概也能猜出来写的是什么意思吧，放在这里供大家参考。
另外还有几个问题，可以参考StackOverflow上的这个问题，对应的讨论在issues_230191里面也有。我们的项目中遇到了setVisibility的问题，但是目前并没有发现导致问题的原因，而且大家对于问题的表述不尽相同，所以我也不知道应该如何处理更好。我们的项目中暂时还是回退到25.0.1版本，等到25.1.0版本的bug解决之后再做处理。
目前发现的升级到25.1.0之后的问题就是这些，以后如果还有新的问题再来补充，希望对大家有帮助。同时，如果大家发现升级之后的问题，也可以在下面留言，大家共同讨论讨论。
网友评论