chromeI排版绘制消息分发机制剖析.doc

Chrome UI框架分析 一、总体结构 1、概述 代码结构 UI部分的通用代码放在src/chrome/views目录下。其中： control目录中为各种控件，如Label、Textfield等，这个目录最为庞大。 widget目录中为系统相关的UI底层细节，特别是UI消息机制。 window目录中为UI Frame相关的细节，例如窗口的标题栏、系统按钮以及、Frame、Dialog等的代理接口。 focus目录下为焦点管理、快捷键相关代码。 animation中为与动画相关的代码。 主要特点 采用DUI技术，大部分窗口和控件都是DUI的。 虚窗口的基类是View，每个View可以包含子View，他们组织成一棵树结构。 真窗口的基类是Widget，它处理与操作系统相关的最原始的消息，在windows上，它处理所有窗口消息。Window是顶层窗口的基类，包括气泡、漂浮窗口、对话框、主窗口等。 View树的根节点是RootView，这个View的主要用途就是从Widget中接收UI消息，进行分发，包括排版与绘制，它是整个窗口树的根。 NonClientView表示整个实际的窗口树的根，是RootView唯一的子节点。RootView向上和OS层打交道，而NonClientView则专注于下层的控件View。NonClientView表示整个非客户区的View，包括标题栏、窗口图标、关闭按钮、最大化与最小化按钮、边框等，它负责非客户区的排版与绘制，这类可以被派生，以实现各种不同的客户区。ClientView是客户区的根，负责客户区的排版与绘制。 排版由专门的LayoutManager负责。 界面绘制上，绘制引擎（Canvas）与窗框系统分开。可以根据实际情况使用不同的图形引擎（Skia与D2D）。一般情况下，绘图采用Skia，字体用windows的GDI，Skia保证可以跨平台。绘制引擎提供了裁剪、平移变换等机制，使得View可以只重绘一部分，而且支持紧急与非紧急绘制。 控件消息的响应采用Listener模式。 绘制通过任务机制实现，从Task派生出一个PaintTask，其Run函数中实现绘制，该任务被放到MessagePumpForUI的任务队列中，每次消息循环的时候取出来执行。 广泛采用设计模式，顶层窗口的实现大类运用了代理模式，复杂的界面元素采用MVC模式实现界面（排版、绘制、界面消息响应）与逻辑的分离。 UI核心类与模块的关系如下图所示： UI的基础代码可以分为消息循环（MessagePumpForUI与MessageLoopForUI）、真窗口（Widget以及派生类）、虚窗口（View以及派生类）、窗口树的根（RootView以及派生类，它实际上是View的派生类）、消息分发与响应、排版（LayoutManager）、绘制（Canvas、CanvasPaint等）、焦点与快捷键管理（FocusManager）组成。这些是UI最底层、最核心的模块，控件建立在这些模块的基础之上。 类的继承关系图 View是所有控件、子窗口（虚窗口）的基类。View类的派生关系图： 这其中有一个庞大的分支为各种控件，具体有： 按钮 Button 菜单 Menu 滚动条 ScrollBar 表格 TableView 树控件 TreeView 组合框 ComboBox 列表框 ListBox 编辑框 TextField 静态控件 Label 超链接控件 Link 其中，树控件、编辑框采用windows自己的原生控件，其他控件均为DUI的。但是有些控件，如按钮等，chrome还包装了windows的原生控件。 Widget是所有真窗口的基类，它负责窗口的消息映射、子窗口的管理，每个Widget有一个RootView，作为窗口树的根，管理其子窗口。Widget类的派生关系图： WidgetWin有两类派生类，分别是气泡与漂浮窗口（地址栏自动提示窗口、标签拖出去形成的新窗口、信息气泡、菜单）；有标题栏与边框的窗口（对话框、主窗口）。WindowWin是所有有标题栏与边框的窗口的基类（对话框、主窗口）。WindowWin中有客户区（client_view_）与非客户区（frame_view_），WindowWin通过配置不同的客户区，可以形成不同的窗口。 WindowImpl是对窗口创建、风格与扩展风格、窗口过程管理的封装。 窗口的结构 窗口中最大的子窗口是RootView，它是窗口树的根，它有唯一的一个孩子NonClientView。NonClientView是逻辑上的根，它有两个孩子NonClientFrameView和ClientView，前者是窗口的非客户区，负责非客户区的绘制、消息响应；后者是窗口的客户区，负责客户区的绘制、消息响