Wpf逻辑树和可视化树

​ 在了解了wpf的基本的消息逻辑和渲染逻辑之后，我们可以来看看wpf的视图层，也就是要理解逻辑树和可视化树。

现在先来看一个简单的窗口：

<Window x:Class="SimpleWindow.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="301.316" Width="306.579">
    <StackPanel Margin="5">
        <Button Padding="5" Margin="5" Click="cmd_Click">First Button</Button>
        <Button Padding="5" Margin="5" Click="cmd_Click">Second Button</Button>
    </StackPanel>
</Window>

​ 添加的元素分类称为逻辑树。WPF编程人员需要耗费大部分时间构建逻辑树，然后使用事件处理代码支持他们。实际上，到目前为止介绍的所有WPF特性(如属性值继承、事件路由以及样式)都是通过逻辑树进行工作的。

​ 然而，如果希望自定义元素，逻辑树起不到多大帮助作用。显然，可使用另一个元素替换整个元素(例如，可使用自定义的FacyButton类替换当前的Button类)，但这需要更多工作，并且可能扰乱应用程序的用户界面或代码。因此，WPF通过可视化树进入更深层次。

​ 可视化树是逻辑树的扩展版本。它将元素分为更小的部分，换句话说，它并不查看被精心封装到一起的黑色方框，如按钮，而是查看按钮的可视化元素——使按钮具有阴影背景特性的边框(由ButtonChrome类表示)、内部的容器(ContentPresenter对象)以及存储按钮文本的块(由大家熟悉的TextBlock表示)。下图显示上面示例的可视化树。

​ 对于这两种树的区别，我们现在来进行一个更加细致的对比，来清晰他们的职责。

区别与联系的详细讲解

逻辑树 (Logical Tree) - “设计蓝图”

• 是什么: 它是 UI 的高级、概念性表示，是开发者眼中的 UI 结构。
• 作用: WPF 主要通过逻辑树来实现一些高级功能，例如：
  • 属性继承: DataContext, FontSize 等属性会沿着逻辑树向下传递给子元素。
  • 资源查找: 当您使用 {StaticResource} 时，WPF 会沿着逻辑树向上查找。
  • 数据绑定: ElementName 绑定是在逻辑树中进行的。

可视化树 (Visual Tree) - “建筑实体”

• 是什么: 它是 UI 的低级、完整的物理表示，是 WPF 渲染引擎眼中的 UI 结构。
• 作用: 可视化树是 WPF 完成实际工作的核心依据：
  • 渲染 (Rendering): 这是它最重要的工作。WPF 的渲染引擎会遍历可视化树，将每个视觉元素绘制到屏幕上。
  • 事件路由 (Event Routing): 鼠标、键盘等输入事件的隧穿 (Tunneling) 和冒泡 (Bubbling) 过程，是沿着可视化树进行的。
  • 命中测试 (Hit Testing): 当您移动或点击鼠标时，WPF 通过检查可视化树来判断您的指针具体悬停在哪一个视觉元素上。
  • 控件模板 (ControlTemplate): 可视化树的结构正是由控件的模板定义的。您可以通过修改模板来完全改变一个控件在可视化树中的结构，从而改变其外观。

​ 可视化样式改变可视化树中的元素。可使用Style.TargetType熟悉选择希望修改的特定元素。甚至当控件属性发生变化时，可使用触发器自动完成更改。不过，某些特定的细节很难甚至无法修改。

​ 可为控件创建新模板。对于这种情况，控件模板将被用于按期望的方式构建可视化树。

​ 非常有趣的是，WPF提供了用于浏览逻辑树和可视化树的两个类：System.Windows.LogicalTreeHelper和System.Windows.Media.VisualTreeHelper。

　　LogicalTreeHelper类允许通过动态加载XAML文档在WPF应用程序中关联事件处理程序。LogicalTreeHelper类提供了较少的方法，下表列出了这些方法。尽管这些方法偶尔很有用，但大多数情况下回改用特定的FrameworkElement类中的方法。

表 LogicalTreeHelper类的方法

​ 除了抓们用来执行低级绘图操作的一些方法外，VisualTreeHelper类提供的方法与LogicalTreeHelper类提供的方法类似，也提供了GetChildrenCount()、GetChild()以及GetParent()方法。

​ VisualTreeHelper类还提供了一种研究应用程序中可视化树的有趣方法。使用GetChild()方法，可以遍历任意窗口的可视化树，并且为了进行分析可以将它们显示出来。这是一种非常好的学习工具，只需要使用一些递归的代码就可以实现。

​ 然后接下来我们就可以来聊一下控件类的组成和继承关系了。在WPF中所有的控件都是继承DispatcherObject类，可以说在wpf中DispatcherObject是所有控件类的基类，而DispatcherObject却继承Object，而它所在的程序集是在WindowsBase.dll里。

看一张图，wpf控件继承关系图

再开始学习类的功能和逐步的继承之前，来聊一下我们之前提到的可视化树和逻辑树。

Visual - 可视化树的“入场券”

• 当继承到 Visual 这一层时，一个对象才开始具备了被渲染的能力（例如知道自己的尺寸、位置、如何绘制等）。
• 因此，可视化树 (Visual Tree) 就是由所有派生自 Visual 的类的实例所组成的结构。

FrameworkElement - 逻辑树的“入场券”

• FrameworkElement 在 UIElement 的基础上，引入了大量高级的框架级概念，如 DataContext, Style, Margin, Name, Binding 等。
• 这些概念大多与应用结构、数据流和布局逻辑相关，而不是纯粹的视觉渲染。
• 因此，逻辑树 (Logical Tree) 主要是由派生自 FrameworkElement 的类的实例组成的。
• 逻辑树代表了开发者在 XAML 中声明的、富有“逻辑”意义的控件结构。

Shape类

​ 形状控件是WPF一大系列控件。WPF所有的形状控件都继承于Shape基类。Shape是一个抽象基类，它不能被实例化，所以我们在使用时只能实例化它的子类。而Shape的父类是FrameworkElement，所以，所有的Shape子类都是一个UIElement 类，因此形状对象可以用在面板和大多数控件中。

Control类

​ Control是许多控件的基类。比如最常见的按钮（Button）、单选(RadioButton)、复选（CheckBox）、文本框（TextBox）、ListBox、DataGrid、日期控件等等。这些控件通常用于展示程序的数据或获取用户输入的数据，我们可以将这一类型的控件称为内容控件或数据控件，它们与前面的布局控件有一定的区别，布局控件更专注于界面，而内容控件更专注于数据（业务）。

​ Control类虽然可以实例化，但是在界面上是不会有任何显示的。只有那些继承了Control的子类（控件）才会在界面上显示，而且所呈现的样子各不相同，为什么会是这样呢？

​ 因为Control类提供了一个控件模板（ControlTemplate），而几乎所有的子类都对这个ControlTemplate进行了各自的实现，所以在呈现子类时，我们才会看到Button拥有Button的样子，TextBox拥有TextBox的样子

ItemsControl类

​ ItemsControl 用于生成内容的集合，也就是说如果要显示大量的数据以列表的形式展示，那么可使用集合控件，集合控件都是继承ItemsControl 类

ContentControl类

​ ContentControl是一个内容控件，它有一个Content属性，该属性的类型是object，它可以接收任意引用类型的实例。

Panel类

​ Panel其实是一个抽象类，不可以实例化，WPF所有的布局控件都从Panel继承而来

FrameworkElement类(FrameworkElement 类 (System.Windows) | Microsoft Learn)

​ FrameworkElement类继承于UIElement类，继承关系是：Object->DispatcherObject->DependencyObject->Visual->UIElement->FrameworkElement，它也是WPF控件的众多父类中最核心的基类，从这里开始，继承树开始分支，分别是Shape图形类、Control控件类和Panel布局类三个方向。

FrameworkElement类本质上也是提供了一系列属性、方法和事件。同时又扩展 UIElement 并添加了以下功能：

UIElement类(UIElement 类 (System.Windows) | Microsoft Learn)

​ UIElement类继承了Visual类，在WPF框架中排行老四，它定义了大量的路由事件和大量的依赖属性。大部分输入和聚焦行为也在UIElement类中定义。 这包括键盘、鼠标和触笔输入的事件，以及相关的状态属性。 其中许多事件是路由事件，许多与输入相关的事件既具有浮升路由版本，也具有事件的隧道版本。

Visual类(Visual 类 (System.Windows.Media) | Microsoft Learn)

​ Visual类是WPF框架中第三个父类，主要是为 WPF 中的呈现提供支持，其中包括命中测试、坐标转换和边界框计算. Button、TextBox、CheckBox、Gird、ListBox等所有控件都继承了Visual类，控件在绘制到界面的过程中，涉及到转换、裁剪、边框计算等功能，都是使用了Visual父类的功能

Dependency类(依赖属性概述 - WPF .NET | Microsoft Learn)

​ DependencyObject 类表示参与依赖属性系统的对象。属性系统的主要功能是计算属性的值，并提供有关已更改的值的系统通知。 参与属性系统的另一个类 DependencyProperty。 DependencyProperty 允许将依赖属性注册到属性系统，并提供有关每个依赖属性的标识和信息，而 DependencyObject 为基类，使对象能够使用此依赖属性。 ​ INotifyPropertyChanged 类用于通知UI刷新，注重的仅仅是数据更新后的通知。DependencyObject 类用于给UI添加依赖和附加属性，注重数据与UI的关联。如果简单的数据通知，两者都可以实现的。

​ 什么是数据驱动模式？控件的属性不再被直接赋值，而是绑定了另一个”变量“，当这个”变量“发生改变时，控件的属性也会跟着改变，这样的属性也被称为依赖属性

DispatcherObject类(DispatcherObject 类 (System.Windows.Threading) | Microsoft Learn)

​ 在 WPF 中， DispatcherObject 只能由 Dispatcher 它与之关联的访问。 例如，后台线程无法更新与 Dispatcher UI 线程上关联的内容Button。 为了使后台线程访问该 Content 属性 Button，后台线程必须将工作委托给 Dispatcher 与 UI 线程关联的工作。 这是通过使用 Invoke 或BeginInvoke。 Invoke 是同步的， BeginInvoke 是异步的。 操作将添加到指定DispatcherPriority位置的队列Dispatcher中。

​ DispatcherObject 类的主要方针路线到底是什么呢？主要有两个职责：

​ 1.提供对对象所关联的当前 Dispatcher 的访问权限，意思是说谁继承了它，谁就拥有了Dispatcher。 ​ 2.提供方法以检查 (CheckAccess) 和验证 (VerifyAccess) 某个线程是否有权访问对象（派生于 DispatcherObject）。CheckAccess 与 VerifyAccess 的区别在于 CheckAccess 返回一个布尔值，表示当前线程是否有可以使用的对象，而 VerifyAccess 则在线程无权访问对象的情况下引发异常。

Style绑定

DynamicResource 和 StaticResource 的区别

​ 这两个都是 XAML 标记扩展，作用都是从资源字典 (ResourceDictionary) 中查找并引用一个资源（比如一个颜色画刷、一个样式等）。它们最本质的区别在于查找资源的时机。

一个简单的比喻：查地址

• StaticResource (静态资源): 就像您在出发前，把朋友家的地址查好并抄写在纸上。在整个旅途中，您都看着这张纸条上的固定地址。如果中途您的朋友搬家了，您纸条上的地址就不会更新，您会找不到他。
• DynamicResource (动态资源): 就像您在手机地图上收藏了朋友家的位置。您不仅得到了当前地址，还得到了一个实时链接。如果中途您的朋友搬家并更新了位置，您的手机地图会自动刷新，导航到新的地址。

技术细节对比