片段popbackstack行为在25.1.0和25.1.1中被破坏 [英] fragment popbackstack behaviour broken in 25.1.0 and 25.1.1

问题描述

由于支持版本25.1.0和最新版本25.1.1，我在替换/添加片段时出现了奇怪的行为. 已报告25.1.0 Android的问题-fragmentTransaction.replace()在支持库25.1.0上不起作用

Since support version 25.1.0 and the most recent 25.1.1 I got strange behaviour with fragment replacing/adding. There have been issues reported for 25.1.0 Android - fragmentTransaction.replace() not works on support library 25.1.0

但是现在在25.1.1中，我遇到了类似的问题.为了重现我创建的示例应用程序的行为，您可以在 https://github.com/holoduke/fragmenttest

But now in 25.1.1 i got similar issues. To reproduce the behaviour i created sample app which you can find at https://github.com/holoduke/fragmenttest

基本上，这是一个带有片段容器的Activity.可以使用几个片段，通过按一个按钮可以将它们动态地相互替换.我们首先从mainActivity本身添加FragmentA.

It is basically one Activity with a fragment container. A couple of fragments are available which will be dynamically replace each other by pressing a button. We start with adding FragmentA from the mainActivity itself.

    FragmentManager fm = getSupportFragmentManager();
    FragmentTransaction ft = fm.beginTransaction();

    Fragment f = new FragmentA();
    fm.popBackStackImmediate(null, FragmentManager.POP_BACK_STACK_INCLUSIVE);
    f.setRetainInstance(false);
    ft.replace(R.id.fragmenttarget, f);
    ft.addToBackStack(null);
    ft.commit();

一切正常，一切正常.在25.0.1、25.1.0和25.1.1中

All good Works fine. in both 25.0.1, 25.1.0 and 25.1.1

fragmentA中现在有3个按钮，它们将全部用fragmentA，fragmentB或fragmentC替换当前片段

Now in fragmentA there are 3 buttons which will all replace the current fragment with either fragmentA, fragmentB or fragmentC

添加片段B和C的代码与片段A几乎相同，除了我们尚未定义:

the code for adding fragment B and C is almost the same as fragment A except we have not defined:

fm.popBackStackImmediate(null, FragmentManager.POP_BACK_STACK_INCLUSIVE);

添加片段B或C时，将执行以下代码:

when fragment B or C is added the following code is executed:

    FragmentManager fm = getSupportFragmentManager();
    FragmentTransaction ft = fm.beginTransaction();

    Fragment f = new FragmentB();
    f.setRetainInstance(false);
    ft.replace(R.id.fragmenttarget, f);
    ft.addToBackStack(null);
    ft.commit();

在25.0.1、25.1.0和25.1.1中都保持良好状态. 如果将fragmentB和C添加两次，则fm.getBackStackEntryCount()会增加.很好.

Still all good in both 25.0.1, 25.1.0 and 25.1.1. If you add fragmentB and C a couple of times the fm.getBackStackEntryCount() is increasing. Thats good.

现在很奇怪. 我们要添加带有popStackImmediate的FragmentA(以清除历史记录) 这三个支持版本的行为都快要疯了.

Now the weird part. We want to add FragmentA with popStackImmediate (to clear history) Here the behaviour of both 3 support versions are going mad.

让我们说您在所有3个版本中都执行了以下bavhiour:

Lets say that you execute the following bavhiour in all 3 versions:

1. 启动应用
2. 替换为片段B
3. 替换为片段C
4. 替换为片段B
5. 替换为片段C
6. 替换为片段A

在25.0.1中，一切正常.清除后堆栈，并在FragmentA中调用onCreateView和ActivityCreated.

in 25.0.1 everything works out fine. the backstack is cleared and onCreateView and ActivityCreated is called in FragmentA.

在25.1.0中，用FragmentA替换后，onCreateView和ActivityCreated被调用了两次.不好.

in 25.1.0 somehow after replacing with FragmentA the onCreateView and ActivityCreated are called 2 times. Not good.

甚至更糟.在用fragmentA替换后，将为后堆栈中的所有视图调用onCreateView和ActivityCreated.现在多数民众赞成在有趣的权利:)

in 25.1.1 its even worse. after replacing with fragmentA, for all views in the backstack the onCreateView and ActivityCreated are called. Now Thats funny right :)

只需试用我的示例应用程序并查看logcat.更改app.gradle文件中的支持版本以查看差异.

Just try out my sample app and look in the logcat. change the support version in app.gradle file to see the differences.

如果有人也能够认识到这个问题，我将感到非常高兴，因此我们可以找到一种方法来克服甚至解决这个问题.

I would be glad if someone is able recognise this issue as well, so we can find a way to overcome or even solve this issue.

推荐答案

我遇到了同样的问题，并通过比较25.0.1-> 25.1.1 FragmentManager.class 找到了解决方案.尝试使用 setAllowOptimization 方法.

Well, I faced with the same problem and found a solution by comparing 25.0.1 -> 25.1.1 FragmentManager.class. Try to use setAllowOptimization method of FragmentTransaction.

这篇关于片段popbackstack行为在25.1.0和25.1.1中被破坏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！