1.简述
在很多分析WindowManagerService的文章中都把它称为Android GUI系统的“导演“，那既然身为导演自然就需要做”指导工作、分析剧本“的工作，这些工作反应在GUI中就是计算window的大小、执行动画、更新surface等。而这些关键工作在android api版本23以前（包括api 23）是由performLayoutAndPlaceSurfacesLockedInner这个方法实现的。
2.api 23以前的核心方法——performLayoutAndPlaceSurfacesLockedInner
Android api 23以前在需要刷新系统UI的时候，例如切换Activity窗口，需要调用WMS的成员函数performLayoutAndPlaceSurfacesLocked来实现：
该方法中具体的实现是一个do while循环中的performLayoutAndPlaceSurfacesLockedLoop 方法，这个循环的次数是6（暂不清楚这个6是如何而来）。
在这个方法中终于见到了WMS中最为复杂的方法performLayoutAndPlaceSurfacesLockedInner，这个近600行的代码中包含了计算窗口大小、执行窗口动画、刷新surface等工作。
关键的代码在于这个try...catch中，里面对于窗口的变更进行计算，并且通过SurfaceControl对应到Surfacelinger中。 现在Android已经逐渐开始支持多屏幕显示，因此在这个方法里的先获取到的DisplayContents的数量，然后在for循环中更新到每一个显示屏幕中（目前基本上只有1）。关于layout的计算都在do...while这个循环中，循环跳出的条件是displayContent.pendingLayoutChanges != 0，也就是说当还有未处理的“layout changes”的时候会继续执行计算，而每轮循环末尾都会对这个displayContent.pendingLayoutChanges 进行赋值。当这个do...while结束之后进行的是对窗口需要执行动画的计算，而后执行各个窗口的动画。
之后的代码都属于收尾工作，包括销毁不可见的窗口，删除正在退出的WindowToken等。
最后执行的是scheduleAnimationLocked，里面是触发动画下一帧的逻辑，具体就是在下一个vsync信号来时触发调用计算窗口透明度、尺寸、旋转角度等值，然后将这些值设置到SurfaceFlinger中。
这么一个洋洋洒洒600行代码的方法，使得开发者阅读起来相当困难，在维护上肯定也轻松不到哪里去，估计谷歌也考虑到了这点，因此在api 24之后估计对这个方法进行了改造，他们直接将WMS中的performLayoutAndPlaceSurfacesLockedInner方法去掉转而新建了专门做计算的WindowSurfacePlacer类。
3.api 24之后的改动，WindowSurfacePlacer类分析
WindowSurfacePlacer的出现原因可能是因为WMS的performLayoutAndPlaceSurfacesLockedInner方法过于臃肿影响可读性（其实WindowSurfacePlacer里也没好到哪儿去），更重要的原因为了实现7.0中的多窗口功能。
在api 24的WMS中出现了一个方法——continueSurfaceLayout。这个方法作用简单来说就是布局，跟进去后会发现它调用的是WindowSurfacePlacer的performSurfacePlacement，
继而调用的是performSurfacePlacementLoop->performSurfacePlacementInner。是不是有点面熟？没错，原来WMS的窗口计算、通知绘制的逻辑被搬到了这儿。
与之前performLayoutAndPlaceSurfacesLockedInner不同的是，现在把do...while循环放到了更外层的方法中。至此WMS中最为复杂的方法分析告一段落，可见虽然方法比较复杂，但是条理还是非常清楚的。后续的文章我还会继续分析Android 7.0（api 24）上多窗口的三种模式（多屏模式、画中画模式、Freeform模式）的具体实现，当然与AMS，WMS息息相关。尽情期待。