这一节的内容在WMCore中，现在Transition已经走到COLLECTING状态了，并且可以收集动画参与者了。
那么Transition是在什么时候去收集动画参与者？回到我们最初的ActivityStarter.startActivityUnchecked：
在调用了TransitionController.createAndStartCollecting后，紧接着就是调用了TransitionController.collect。
这里看到TransitionController里面首先是判断了一下成员变量mCollectingTransition是否为空，如果不为空，才能将传参WindowContainer收集到该Transition中。
接下来我们重点分析Transition.collect，这里感觉不按照代码顺序分析似乎更有条理一点。
1 Transition.collect第1部分
1）、如果当前Transition的mState小于STATE_COLLECTING，那么就会异常。
2）、如果当前Transition的mState不是STATE_COLLECTING或者STATE_STARTED，那么就会返回。
这里说明了，只有处于STATE_COLLECTING或者STATE_STARTED的Transition才能收集动画参与者，太早或者太晚都不行。
2 Transition.collect第2部分
首先看这里needSync的逻辑。
如果，当前正在被收集的WindowContainer不是一个WallpaperWindowToken，
或者，当前参与者中不包含该WindowContainer所在的DisplayContent，
并且，该WindowContainer没有被瞬态隐藏（被Recents遮挡），
那么needSync就为true。
needSync为true，那么继续调用BLASTSyncEngine.addToSycnSet方法：
很简单，根据传入的Transition的ID找到对应的SyncGroup对象，然后继续调用SyncGroup.addToSync方法：
该方法内容主要是：
1）、如果当前WindowContainer通过getSyncGroup拿到的SyncGroup为空，说明当前WindowContainer还没有绑定一个SyncGroup，那么就将该WindowContainer添加到SyncGroup.mRootMembers中，并且通过WindowContainer.setSyncGroup方法，将WindowContainer的成员变量mSyncGroup设置为当前SyncGroup，完成绑定。
2）、调用WindowContainer.prepareSync方法。
关于这个prepareSync的逻辑，同样在我们之前分析BLASTSyncEngine的那篇文章中也比较系统的介绍过，因此这里简单再回顾一下。
首先是WindowContainer.prepare方法：
比较简单，调用子WindowContainer的prepareSync方法，然后将自身的mSyncState设置为SYNC_STATE_READY。
mSyncState有三种状态：
- SYNC_STATE_NONE，没有参与到一次同步（或Transition）中。
- SYNC_STATE_WAITING_FOR_DRAW，等待自身绘制完成。
- SYNC_STATE_READY，当前WindowContainer已经就绪，但是其子容器可能没有就绪。
一般来说，动画都伴随着界面的改变，比如我们从Launcher启动Contacts，Contacts是一个从无到有的过程，那么动画就需要等待Contacts的窗口绘制完成后才能进行。
因此再看重写了prepareSync方法的WindowState.prepareSync方法的内容：
重点其实就是这一句，将WindowState的mSyncState置为SYNC_STATE_WAITING_FOR_DRAW。
即对于非WindowState的WindowContainer，比如Task，ActivityRecord，它们在界面发生改变的时候是不需要重绘的，因此它们在prepareSync的时候就可以将mState设置为SYNC_STATE_READY。同理，判断一个Task或者一个ActivityRecord是否就绪，看的主要是它里面的WindowState是否就绪了。
而对于WindowState，在界面发生改变的时候，由于要重绘，并且重绘需要时间，因此WindowState在被添加到动画参与者集合的时候，会先被设置为SYNC_STATE_WAITING_FOR_DRAW。等到绘制完成，为该WindowState调用finishDrawing的时候，它的mSyncState会被设置为SYNC_STATE_READY，表示该窗口已经就绪，可以进行动画。
3 Transition.collect第3部分
接着看Transition的成员变量mParticipants：
是一个ArraySet类型的成员变量，看方法最后，是将参与当前Transition的WindowContainer添加进来了，那它的作用和SyncGroup的mRootMembers类似。
从第一部分关于needSync的分析看到，向SyncGroup.mRootMembers添加参与者的条件要比向Transition.mParticipants的条件苛刻一点，因为这个区别，这两个参与者集合中的内容可能不是完全相同的。
4 Transition.collect第4部分
最后我们再来看一下关于ChangeInfo的这部分。
4.1 例子1 ------ 新启动ActivityRecord
还以我们之前分析的从Launcher启动Contacts的流程来，那么在这个时间点，只创建了一个ActivityRecord对象，它的Task还没创建，那么通过Transition.getAnimatableParent获取的WindowContainer自然也就是null了，因此标黄的第一段逻辑就不走了，直接看第二段逻辑。
首先看下Transition.mChanges的定义：
一个包含了WindowContainer和ChangeInfo键值对的map。
这是我们第一次尝试将当前WindowContainer添加到动画参与者中，因此从Transition.mChanges中肯定是没有当前WindowContainer的，因此这里就会根据该WindowContainer创建一个ChangeInfo对象，并且将这两个对象组成的键值对保存到Transition.mChanges中。
ChangeInfo的构造方法为：
用来保存改变开始前的WindowContainer的一些信息，大概是这样的用法：
1）、在收集阶段，将基于WindowContainer的当前信息创建一个ChangeInfo，ChangeInfo里保存了我们对WindowContainer感兴趣的特定信息。
2）、发生一些改变。
3）、改变完成后，具体是在Transition.onTransactionReady的时候，拿第一步创建ChangeInfo和现在这个时候的WindowContainer的信息进行对比，从而得知当前WindowContainer在这个过程中发生了哪些变化。
4.2 例子2 ------ App切换
在第一个例子中，我们看到由于此时是ActivityRecord刚刚创建的时候，因此ActivityRecord的父容器为空，所以这里仅仅为正在收集的这个ActivityRecord创建了一个ChangeInfo的对象。然而更普遍的情况可能是，不仅为当前正在收集的这个WindowContainer创建了ChangeInfo，还可能会创建更多ChangeInfo对象， 即这段逻辑：
Transition.getAnimatableParent的定义为：
如果发生了App的切换，比如从Message界面点击Home回到Launcher，那么就会把Message和Launcher的Task收集起来，走到这里时，传参是Task类型的WindowContainer：
1）、首先Task通过getParent获取到父WindowContainer，即TaskDisplayArea。
2）、TaskDisplayArea复写了WindowContainer.canCreateRemoteAnimationTarget方法：
返回的是true，那么通过Transition.getAnimatableParent返回了TaskDisplayArea。
3）、最终会为TaskDisplayArea创建一个ChangeInfo对象，添加到Transition.mChanges中。
同理为TaskDisplayArea调用Transition.getAnimatableParent方法，获取到的则是DisplayContent，也会为DisplayContent创建一个ChangeInfo对象添加到Transition.mChanges中。
那么除了为Task创建ChangeInfo之外，这里还会为TaskDisplayArea以及DisplayContent创建ChangeInfo，并且加入到Transition.mChanges中。
最后再来对比一下SyncGroup.mRootMembers、Transition.mParticipants以及Transition.mChangs：
1）、Transition.mParticipants，保存的就是正在收集的那个WindowContainer。
2）、SyncGroup.mRootMembers，由于一些条件限制，保存的WindowContainer比Transition.mParticipants要少一点。
3）、Transition.mChangs，不仅保存了正在收集的那个WindowContainer对应的ChangeInfo对象，还可能保存了它的父WindowContainer对应的ChangeInfo对象。
5 其它collect的情况
看下Transition.collect都在哪些地方调用了：
并且它也会被TransitionController.collect调用，而TransitionController.collect被调用的地方同样也很多：
场景太多就不一一分析了，其实万变不离其宗，需要在什么节点把WindowContainer收集进来再去调用Transition.collect就行了，就像之前把ActivityRecord添加到openingApps和closingApps那样。