理解WPF中的视觉树和逻辑树（转载）

 

理解WPF中的视觉树和逻辑树

 

理解WPF中的视觉树和逻辑树  Understanding the Visual Tree and Logical Tree in WPF
这篇文章讨论WPF中视觉树和逻辑树的细微差别。同时提供了一个小程序供读者稍后分析。如果你已经对着两个概念完全不熟悉，我建议你先读SDK文档中的这篇文章“URL”。

背景

目前SDK文档中关于视觉树和逻辑树的介绍还不是很完全。从我一开始接触WPF，我就对这两个概念的区别很模糊。我认为这两个树都包含可视化元素和控件，对吧？错！我认为Window/Page/Control等有且仅有一棵逻辑树，对吧？还是错！我知道我在干嘛吗？完全不知道！
事实证明WPF中的元素树相当复杂而且要求WPF类库中很底层的知识来理解这些树。怎样用通用的方式遍历元素树；你觉得在什么地方无法得知元素成分；这些并不像看起来那么简单。不幸的是，WPF没有暴露接口来简化对元素树的遍历。
现在你可能会为什么遍历元素树会这么麻烦。答案分成几个部分，在下面讨论。

可视化树

可视化树代表你界面上所有的渲染在屏幕上的元素。可视化树用于渲染，事件路由，定位资源（如果该元素没有逻辑父元素）等等等等。向上或者乡下遍历可视化树可以简单的使用VisualTreeHelper和简单的递归方法。

然后，还是有个小别扭让它变得复杂。任何承继自ContentElement的东西都可以在UI上显示，但其实并不在可视化树中。WPF会假定这些元素也在可视化树中，来保持事件路由的一致性，但这只是个幻觉。VisualTreeHelper对ContentElement对象不起作用，因为ContentElement不是继承自Visual或者Visual3D. 下面是Framework中所有承继自ContentElement的类从Reflector中可以看到：

 

这个文档介绍了为什么ContentElement并不真正存在可视化树中。
内容元素(继承自ContentElement的类)不是可视化树的一部分；他们不是继承自Visual而且没有可视化表示。为了显示在UI上，ContentElement必须寄宿在一个Visual主体上，通常是一个FrameworkElement。你可以认为主体类似于一个可以选择如何展示该ContentElement的浏览器。一旦一个Content被显示主体捕获，这个Content就可以加入到一个特定的和可视化树相关的树处理过程中。一般说来，FrameworkElement类都会包含一段代码用来把ContentElement添加到事件路由中去，通过这个content逻辑树的某个子节点，尽管这个content并不是可视化树的一部分。这很必要，因为content也需要找到路由事件的源头。
这意味着你永远没办法仅仅使用VisualTreeHelper来遍历可视化树。如果你把一个ContentElement传递给VisualTreeHelper的GetParent或者GetChild方法，会抛出一个异常。因为ContentElement不是Visual或者Visual3D的子类，你只能沿着逻辑树查找ContentElement的父元素，直到找到一个Visual对象。这里有个例子遍历到可视化树的根元素。

 

DependencyObject FindVisualTreeRoot (DependencyObject initial)
{
	DependencyObject current = initial;
	DependencyObject result = initial;


	While(current !=null)
	{
		result = current;
		if(current is Visual || current is Visual3D)
		{
			current = VisualTreeHelper.GetParent(current);
		}
		else
		{
			current = LogicalTreeHelper.GetParent(current);
		}
	}
	return result;
}

 

 

这段代码在必要的时候沿着逻辑树上溯，如else子句所示。这很有用，假如说用户点击一个在TextBlock中的Run元素你需要从Run元素开始上溯可视化树。由于Run类继承自ContentElement, 所以它不真在可视化树中。所以我们需要走出逻辑树直到我们找到了那个包好Run元素的TextBlock。之后我们就可以回到可视化树上来了，因为TextBlock不是ContentElement的子类。

逻辑树

逻辑树表示UI的核心结构。和XAML文件中定义的元素近乎相等，排除掉内部生成的那些用来帮助渲染的可视化元素。WPF用逻辑树来决定依赖属性，值继承，资源解决方案等。
逻辑树用起来不像可视化树那么简单。对于新手来说，逻辑树可以包含类型对象，这一点和可视化树不同，可视化树只包含Dependancy子类的实例。遍历逻辑树时，要记住逻辑树的叶子可以是任何类型。由于LogicTreeHelper只对DependencyObject有效，遍历逻辑树时需要非常小心，最好做类型检查。看个例子：

void WalkDownLogicalTree(object current)
{
	DoSomethingWithObjectInLogicalTree(current);


	DependencyObject depObj = current as DependencyObject;


	if(depObj != null)
	{
		foreach(object logicalChild in LogicalTreeHelper.GetChildren(depObj))
			WalkDownLogicalTree(logicalChild);
	}
}

 

 

一个给定的Window/Page/Control会有一棵视觉树，但是可以有几个逻辑树。这些逻辑树互相不相连。可以仅仅使用LogicalTreeHelper来在几棵逻辑树之间遍历。在这篇文章中，我会把顶层控件的逻辑树称作主逻辑树，在他里面的其他逻辑树称作逻辑岛。逻辑岛实际上就是普通的逻辑树但是“岛”可以帮助说明它们和主逻辑树并不相连。
这种无关性可以归结于一个概念：模板。
控件和数据对象本身并没有可见的外观。相反，它们依赖模板来决定怎样进行渲染。一个模板就像一个“拼图块”可以扩展开来以便展示正真的用来渲染的可视元素。这些元素是可扩展模板的一部分，称之为“模板元素”。这些元素有自己的逻辑树，和生成这些元素的对象所拥有的逻辑树不相连。这些小的逻辑树就是我说的逻辑岛。
你只能写额外的代码来在不同的逻辑树或者逻辑岛之间进行切换。遍历逻辑树时，为了连接这些岛，需要使用类似FrameworkElement.TemplateParent,FrameworkContentElement.TemplateParent这些属性来返回持有这些模板的元素，这样就把逻辑岛包含进来了。以下是找到任意元素
的TemplateParent的一个方法：

DependencyObject GetTemplatedParen(DependencyObject depObj)
{
	FrameworkElement fe = depObj as FrameworkElement;
	FrameworkElementElement fce = depObj as FrameworkContentElement;


	DependencyObject result;


	if(fe != null)
		result = fe.TemplatedParent;


	else if(fce != null)
		result = fce.TemplateParent;
	
	else
		return null;


	return result;
}

 

 

下溯逻辑树并且在逻辑树之间切换更难因为TemplatedChild属性并不存在。你得检查逻辑树叶子元素的可视化子元素，然后看看这些子元素是不是别的逻辑树的成员。代码留给大家自己练习。

研究工具

这篇文章提供一个小的控制台程序来帮助你体验各种元素树。它会打开一个WPF窗口，然后在控制台输出任何你点击的元素的逻辑树和可视化树。怎样用它在WPF窗口中有说明，先来看看它都提供了些什么功能。

打开工具：

 

然后最大化控制台，把WPF窗体移动到控制台上面，在窗口中间的按钮上按Ctrl+鼠标左键(不要按到字母上)，工具会导出点击到的ButtonChrome元素的逻辑树，如下：

 

逻辑树现在变的非常不一样。它比之前的那棵树要小很多，根是ButtonChrome而不是Button, 叶子是一个ContentPresenter而不是一个string.之所以不同，是因为我们在看的是一个逻辑岛。这个逻辑岛是Button内容的模板元素所用的逻辑树。

 

如果我们按住Ctrl+Left，点击ButtonChrome，控制台窗口就会显示整棵可视化树，如下：

 

很明显可视化树比之前的逻辑树大很多。值得注意的是，可视化树包括了所有的可视化元素，包括刚刚测试过的按钮，它不关心这些元素是否来自于模板。所有显示的元素都可以在可视化树中找到。这样就更好理解了。

结论

第一次了解元素树的时候，可能会觉得很好理解。深入研究会发现其实它们也没那么简单。对于大多数WPF编程，知道这些细节都没有什么害处，而对于一些高级场景，这些知识就变得很必须。希望这篇文章对于理解这些晦涩的细节能有所裨益。