Android graphic: windows manager

学习目的：

我阅读过网络上相关的资料，有一些过度的简略，另一些，直接在分析代码，而忽略了思路的介绍，容易让人无所适从。

交代清楚是什么，比交代清楚过程更重要。首先要侧重交代一下重要的实体，作什么的？之间的大概关系。更细节的，须要交代一下流程。

  1） wms是android service中最复杂的一部分。理解它，对于理解android显示过程以及整个的工做流程，大有裨益。

2） 不须要深刻到每一行代码。首先须要知道它的做用，它和外部模块的交互做用；更进一步的，须要了解里面关键的数据结构和代码。

 

 

windows manager窗口管理要解决的问题是什么？

1）z-order的计算。须要计算哪些窗口应该显示，哪些窗口应该隐藏。

2）分发用户输入的事件。

　　　　windowmanagerService把窗口信息传递给InputManager，这样InputDispatcher就能根据当前窗口的状态进行消息处理。

 （引用自http://www.cnblogs.com/noTice520/archive/2012/10/25/2738050.html）

2） 窗口的显示和隐藏控制

4.      焦点窗口(focus window)管理

5.      输入法窗口管理和墙纸窗口管理

6.      切换动画

7.      系统消息收集和分发

 

采起的是什么架构？？

c-s模式。客户端有窗口管理相关的东西，服务器端有windows manager service。

 

Iwindow 接口的主要做用是，当用户有操做时，wms会经过Iwindow的接口，通知客户端（下文的viewrootimpl）

以下图所示。

 

IwindowSession 接口的主要做用是，当客户端要建立window，添加window， 从新布局等操做时，会经过该接口，向wms 申请服务。

以下图所示：

 

 

窗口管理在客户端的部分主要作什么？？？总结一下？？？

---》在客户端，window的建立过程须要从这里告诉server。须要处理添加视图。须要处理server段传递过来的输入输出事情，并做出相应。

另外，显示过程的measure, layout 过程也涉及了它？

 

首先关注一下客户端的几个重要的组成部分的意思。

Window

  按照google的解释，window是一个比较抽象的概念。

》》》》》》

Abstract base class for a top-level window look and behavior policy. An instance of this class should be used as the top-level view added to the window manager. It provides standard UI policies such as a background, title area, default key processing, etc.

》》》》》》

举个例子，实际app中,app activity建立出来后，显示ui 控件的那一层，就有一个window。假如弹出了一个对话框，这个对话框又会单首创建一个window。

（Q? window和dumpsys看到的layer数目是对应的吗？surfaceview是一个单独的window吗？window 还有什么具体的功能？？）

window 是抽象的基类。它的具体实现是一个叫作Phonewindow的类。

 

windowmanagerimpl

WindowManagerImp是窗口管理器在客户端的一个代理，经过它，能够和windows manager service通讯，申请一些服务。

 

decorview

decorview是定义在前面提到的phonewindow 类里面的一个内部类。它是一个viewgroup，至关因而子view的一个容器。

 

ViewrootImpl

viewroot 是一个很是重要的类。它和wms之间有两个binder接口通讯，一个是申请wms的服务的，一个被wms通知事件的。

它也是做图的起点。它里面的PerformTraversal 函数是做图的入口函数。这个函数从decorview出发，对真个的view hierachy作图。

  

在服务器端, windows manager service 会处理一些客户端很差处理的事情，好比

1）管理好window的建立和删除工做。

客户端建立window的请求会在wms中处理，wms会经过一个windowstate 类型的数组，保存好全部的window，这样才方便作z-order处理。

另外wms会帮忙客户端向surfaceflinger去申请建立surface。统一建立的surface 方便共享访问。客户端拿到surface后，方能够做图显示。

 2)

　　计算activity 窗口的大小。只有知道了这个大小，客户端才能进行随后的ui 元素的Measuare, layout, draw的工做。

　　 activity窗口的大小，由于涉及到了status bar, input window等东西，因此须要经过wms才能计算。

 

3）将各个窗口的属性，例如，大小、位置等属性，通知SurfaceFlinger服务了，也就是让SurfaceFlinger服务更新它里面的各个Layer的属性值，以即可以对这些Layer执行可见性计算、合成等操做，最后渲染到硬件帧缓冲区中去。SurfaceFlinger服务计算系统中各个窗口，即各个Layer的可见性，以便将它们合成、渲染到硬件帧缓冲区的过程能够参考前面Android系统Surface机制的SurfaceFlinger服务渲染应用程序UI的过程分析一文

 

 
3） 窗口的动画显示过程和窗口的可见性更新过程是wms最核心的部分

 4）

 

 下面表述一下主要的数据结构之间的关系：

　 这张图片不错，解释一下。图片表示的是通过windowManager.addview操做后，造成的数据结构之间的关系。

View 是decorview， 每个decorview会有一个viewroot对应着。每个viewroot 会有两个binder接口，负责和wms通讯。

一个activity 可能有多个decorview/viewroot, 有数组来保存他们。当须要Update /delete/ add view的时候，这个数组就有用。

 

（notes: 这里使用了一个数据结构：WindowManagerGlobal。它里面保存了进程里面全部的decorview, viewroot.它是一个singleton。为何windowmanagerimpl不是singleton??? 由于

假如弹出一个对话框，Dialog，它的构造函数里面，就会要求建立一个新的Phonewindow和windowmanagerimpl

因此一个activity里面，可能有多个windowmanagerimpl。可是这些windowmanagerimpl，共享了一个WindowManagerGlobal 。

）每个viewroot在server端，又对应了一个winowstate来记录窗口状态。

 

 

这张图表示了几个数据结构之间的关系。 首先会建立一个phonewindow，往这个window上面，添加一个decorview.

建立一个新的viewroot。viewroot建立的过程当中，会建立binder接口和wms通讯。

在wms那边，添加window的过程，会建立一个对应的windowstate.