Chrome UI 框架分析 一、总体结构 1、概述 代码结构 UI 部分的通用代码放在 src/chrome/views 目录下。其中： control 目录中为各种控件，如 Label、Textfield 等，这个目录最为庞大。 widget 目录中为系统相关的 UI 底层细节，特别是 UI 消息机制。 window 目录中为 UI Frame 相关的细节，例如窗口的标题栏、系统按钮以及、Frame、Dialog 等的代理接口。 focus 目录下为焦点管理、快捷键相关代码。 animation 中为与动画相关的代码。 主要特点 1、采用 DUI 技术，大部分窗口和控件都是 DUI 的。 2、虚窗口的基类是 View，每个 View 可以包含子 View，他们组织成一棵树结构。 3、真窗口的基类是 Widget，它处理与操作系统相关的最原始的消息，在 windows 上，它处理所有窗口消息。Window 是顶层窗口的基类，包括气泡、漂浮窗口、对话框、主窗口等。 4、View 树的根节点是 RootView，这个 View 的主要用途就是从 Widget 中接收 UI 消息，进行分发，包括排版与绘制，它是整个窗口树的根。 5、NonClientView 表示整个实际的窗口树的根，是 RootView 唯一的子节点。RootView向上和 OS 层打交道，而 NonClientView 则专注于下层的控件 View。NonClientView表示整个非客户区的 View，包括标题栏、窗口图标、关闭按钮、最大化与最小化按钮、边框等，它负责非客户区的排版与绘制，这类可以被派生，以实现各种不同的客户区。ClientView 是客户区的根，负责客户区的排版与绘制。 6、排版由专门的 LayoutManager 负责。 7、界面绘制上，绘制引擎（Canvas）与窗框系统分开。可以根据实际情况使用不同的图形引擎（Skia 与 D2D）。一般情况下，绘图采用 Skia，字体用 windows 的 GDI，Skia保证可以跨平台。绘制引擎提供了裁剪、平移变换等机制，使得 View 可以只重绘一部分，而且支持紧急与非紧急绘制。 8、控件消息的响应采用 Listener 模式。 9、绘制通过任务机制实现，从 Task 派生出一个 PaintTask，其 Run 函数中实现绘制，该任务被放到 MessagePumpForUI 的任务队列中，每次消息循环的时候取出来执行。 10、广泛采用设计模式，顶层窗口的实现大类运用了代理模式，复杂的界面元素采用MVC 模式实现界面（排版、绘制、界面消息响应）与逻辑的分离。 UI 核心类与模块的关系如下图所示： UI 的基础代码可以分为消息循环（MessagePumpForUI 与MessageLoopForUI...
