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息息相关。尽情期待。
网友评论