Fragment fragmentA=new FragmentA();
fragmentTransaction.replace(R.id.fragment_container, fragmentA);
对于上面的代码，我刚开始的理解是将fragment_container所有的fragment清除，然后将fragmentA添加进去。
但是碰到一个很奇怪的问题：
一言不合上代码：
第一个按钮调用的是jump方法，第二个调用的是jumpNotBackStack。
第一个调用的是replace方法，第二个调用的是add方法。
动图里显示在做add的时候出现了两个fragment画面，这个不足为奇。但是在点击replace的时候
看到只移除了一个视图，将显示第2个的fragment移除，然后添加了一个fragment。并没有将之前的所有fragment全部移除，这个对于replace的理解有些出入，这是为什么呢？
我们先了解FragmentTransaction是什么
FragmentTransaction fragmentTransaction= fragmentManager.beginTransaction();这样拿到一个事物操作对像，那么到底是是如何处理事务的呢，再做进栈退栈的时候都发生了什么？
其实就是BackStackRecord对象。BackStackRecord对象是FragmentTransaction的具体实现者。
所以我们来了解下BackStackRecord
BackStackRecord提供了操作fragment的方法有 add() ,replace(),remove(),hide()等方法。
看看add方法
public FragmentTransaction add(int containerViewId, Fragment fragment) {
doAddOp(containerViewId, fragment,null, OP_ADD);
return this;
}
这里的doAddOp最终会转换成Op对象存储起来，我们知道一个事务可以做很多动作，所以事务的动作都封装成了Op对象，再用链表的形式连接起来。
看看怎么入栈的，调用addToBackStack方法：
事务的执行都要先commit.看看commit做了什么
这里是FragmentManager的addBackStackState方法，实际上时间事务对象添加到一个事务集合中。
入栈的过程基本到此为止。
那么出栈发生了那些呢。首先，出栈这说的说的不够准确，应该说的是事务的回滚。这么说
当这个事务之前做的动作是1：添加A; 2：删除B ; 3:隐藏C
那么回滚的动作就是 1：显示C ; 2: 添加B; 3:删除A。
也就是说将之前的过程反着来一遍。
看看如何出栈的，也就是如何做事务的回滚的。
来看看BackStackRecord的popFormBackStack()
入栈和出栈的脉络已经梳理差不多了。
饶了这么大的弯子，来看看replace为什么没有把所有fragment删完？
根据上面的，我们需要看看commit之后的run方法了。并且指令时replace的代码块。
看源码得知，删除的时候是遍历mAdded去删除的
那么mAdded是怎么个列表呢？
这里看到了在做添加fragment的时候就将其添加到mAdded集合里。
那么在什么移除呢？
下面两个地方：
这么粗略看下来，在replace的时候，会遍历已经被add过的并且没有被移除或销货的fragment列表。
进行逐个调用removeFragment将其移除。感觉replace就是一键清除已添加的所有frament。
但是呢，事实证明不是这样的。调用replace方法，还会存在一个以上的fragment。这倒就是为什么呢？
返回来仔细看看执行replace命令的代码块，问题肯定是出现在这里。
当我再去仔细看这块代码的时候，发现，这是再边遍历边删除。这样mAdded是遍历不完整的。
拿动图来说一下这个情况：
当点击add按钮的时候，页面上同时存在了两个fragmet这个是合理的。
这个时候mAdded里有两个fragment。
再点击replace的时候，执行了遍历清楚mAdded里的fragment。第一次循环，i==0:mAdded.size()=2;
调用removeFragment后i==1;mAdded.size()==1;因为1不小于1所以循环结束了。也就只执行了一次删除操作，没有完整的遍历。所以replace之后，还会有一个fragment存在。所以就有了动图中的效果。
不知道这个是有意为之还是bug。
如果是有意为之我又实在想不出为的什么意图呢？
