weixin_39702448的博客

在判断完mActiveSyncs是否为空之后，会将其移入mTmpFinishQueue中，然后再将元素从mTmpFinishQueue中依次从头移除，即(3)处所示，然后再在mActiveSyncs中找到该元素对应的索引，正常情况下grpIdx是大于等于0的，因为可以看到mTmpFinishQueue就是mActiveSyncs拷贝过来的，但是在（5）处会进入到tryFinish的流程中，这里可能会移除mActiveSyncs中的group对象，所以不排除这种可能，所以这里的注释就是这个意思。

因为项目涉及一些启动相关的方案，以及平常处理问题的时候会遇到很多启动响应的问题，所以对启动动效的拉起流程进行一个全面的梳理，同时也借此即会对U版本的动效流程做一个初步的了解吧。启动的流程就先不展开细说了，直接跳到开启启动动效处理的地方。在代码（1）处，创建了一个动效的Transition类的对象，这个Transition类表示的是视图树中，从一种状态过渡到另一种状态的过渡动画。

可以看到在构造函数中只有一行代码（9），这里其实就是给Transaction赋了一个id，如（11）处所示，其实和我们的上层代码中的SyncGroup的构造有点相似，不过他加入了线程的pid，放在了64位int数据的高32位，低32位则是一个自增的idCounter。此方法是类SurfaceComposerClient的一个内部类Transaction的构造方法，查看其定义在SurfaceComposerClient.cpp中，这些类的声明在对应的.h文件中，就不去一个一个说了。

***/根据定义，BLASTSyncEngine有这五个功能：1）开启一个syncset，同时传递一个listener，int id startSyncSet(TransactionReadyListener) 这里的ID将会被放在一组准备好的WindowContainer中传递给TransactionListener。而这就意味着这些WindowContainer已经调用了onTransactionReady。

在上一篇代码分析中，知道了在应用侧创建的WindowContainerTransaction会通过WindowOrganizer中的applySyncTransaction方法发送到系统侧，然后再系统侧维护的窗口管理库中应用这些修改。方法有点长，但是其实一大半都是注释，首先还记的在WindowOrganizer中调过来时，这个参数列表中的Callback和t分别是什么吗？答案是SyncCallback中的mWCT和SyncCallback的this。

1）、根据需要修改的地方构建WindowContainerTransaction类对象wct；2）、通过wct构建SyncCallback类对象cb，然后将cb放入SyncTransactionQueue类的对象mQueue中；3）、调用cb的send()方法，通过WindowOrganizer的applySyncTransaction方法，将wct传送到系统侧；

windowContainerTransaction类的对象是用来存储对windowContainer的修改的一个集合，windowContainer。因为应用侧是无法直接操作windowContainer的，如果应用侧需要修改windowContainer的话，需要通过系统侧对windowContainer进行修改，这就涉及了信息的跨进程传输了。所以首先，WindowContainerTransaction类应该是一个磕跨进程传输的类。看到定义：也证实了这个猜测，其实现了Parcelable接口。

窗口中容器类介绍：本节内容较多，建议结合前面的内容一起阅读：1、2、3、

3、 然后在屏幕上显示窗口的时候需要有一个先后顺序，所以对WindowState也会有一定的排序，而且在使用窗口的时候，还会把相同类型的窗口聚类到一块，通过一个WindowState的容器进行统一的管控，即统一的类WindowToken，不过WindowToken是系统窗口的聚类，应用窗口的聚类则是ActivityRecord。在前一节讲了窗口的排序逻辑，分别是应用窗口、系统窗口、和子窗口，但是这里讲的比较散，没有一个宏观的概念。关于DisplayContent中排序的算法，最好的方法就是直接看代码。

在详解。

WindowManagerService是SystemServer中的一个服务，主要功能是管控窗口的服务，在各个应用进程中都有自己的代理，WindowManager（也可以说WindowManagerGlobal）， WindowManager和WindowManagerService之间的沟通则是通过IWindowSession的子类Session类完成，在ViewRootImpl类中会持有一个IWindowSession类型的对象mWindowSession。

关于addView方法，我说下我的理解，首先说明下这个方法的起源，addView方法的声明在ViewManager.java中。这里插入一个类图，方便起见我就用自己之前画的一张图，可以看到，有两个类都继承自ViewManager类，分别是ViewGroup和WindowManager。根据子类的实现分别看下他们继承了addView之后是怎么实现该方法的。

看这里，FrameLayout就是继承自ViewGroup，而ViewGroup又实现了ViewParent，其实我们常见的View都是继承自View并且实现了ViewParent，所以这里就可以看到ViewRootImpl和View是不一样的东西，而ViewRootImpl之所以能作为DecorView的ParentView就是因为他实现了ViewParent，所以他是可以作为View的父节点的，因为父节点的类型只要是ViewParent就行。然后再看到这里，很明显了吧，已经把view赋值给root了。

对了，那window就可以类比成一张纸，在纸上我们就可以画画了，那画是不是就可以比作我们看到的手机界面了。那这里就涉及到了一个管理的类了，WindowManager，WindowManager是接口，所以需要实现后才能实例化，而唯一实现这个接口的就是WindowManagerImpl类，不过WindowManagerImpl类其实就是你那个什么都不会的领导，最后的活都是苦*的你来干，也就是WindowManagerGlobal，这里要是再详细说就要一点功夫了，今天先说到这。理解了这些概念就该看代码了。

这是因为Window就是一个抽象的类，我们要管理Window，自然就想到了WindowManager了，顾名思义嘛，window的管理者。所以这里也有个addView方法是从ViewGroup这里继承来的，所以ViewGroup其实和WindowManager的addView方法都继承自ViewManager，他们就像兄弟一样的关系，只不过ViewGroup里的addView方法添加的是View，WindowManager里的addView方法添加的是Window罢了。这里方法实现太长，只看关键部分。

其实这个问题从trace文件就可以看出来了，再onCreate方法，其实在perffeto中就很容易就看到了，在启动的trace中onCreate这个Tag是在帧绘制之前就完成的，那我们看到界面的前提不是得是帧绘制完成了嘛，所以在onCreate方法中的setContentView是可以修改应用界面的布局，但是他只是修改界面的布局的参数，这时候界面还没绘制，界面最终的显示，还需要将这个布局参数交付给doFrame流程进行绘制和SF进行合成渲染最后送显完成显示。