【笔记】【WPF编程宝典】第01章 WPF概述

最新推荐文章于 2024-08-08 18:21:34 发布

zhy29563

最新推荐文章于 2024-08-08 18:21:34 发布

阅读量1.2k

点赞数 1

分类专栏： # WPF 读书笔记

本文链接：https://blog.csdn.net/zhy29563/article/details/89061085

版权

读书笔记同时被 2 个专栏收录

37 篇文章 5 订阅

订阅专栏

WPF

18 篇文章 19 订阅

订阅专栏

WPF(Windows Presentation Foundation)是用于Windows的现代图形显示系统。与之前出现的其他技术相比，WPF发生了根本性的变化，引入了“内置硬件加速”和“分辨率无关”等创新功能；

如要构建运行在Windows Vista、Windows 7 和 Windows 8 桌面模式（以及对应的Windows Server 版本）下的富桌面应用程序，WPF无疑是最适用的工具包。事实上，WPF是针对这些Windows版本的唯一通用的工具包。比较起来，Mircrosoft新推出的Metro工具包虽然令人感到激动，但Metro的使用范围仅限于Windows 8 系统。WPF的应用范围却广泛很多，它甚至可运行在仍在很多企业中使用的已经过时的Windows XP计算机上；唯一的局限性在于您必须对Visual Studio进行配置，使其将较为陈旧的.NET 4.0 Framework作为目标。

1.1 Windows图形演化

在WPF问世之前的近15个念头，Windows开发人员一直在使用本质上相同的显示技术。究其原因，是由于此前的每个传统Windows应用程序都一开Windows操作系统的如下两个由来已久的部分来创建用户界面：

User32：该部分为许多元素（如窗口、按钮和文本框等）提供了熟悉的Windows外观。
GDI/GDI+：该部分为渲染简单形状、文本以及图像提供了绘图支持。但增加了复杂程序（而且通常性较差）。

历经多年的发展，这两种技术都得到了改进，而且开发人员使用的与其交互的API也已发生了巨大变化。但在构建应用程序时，不管使用.NET和Windows窗体，还是使用过去Visual Basic 6或基于MFC的C++代码，底层都是使用Windows操作系统的相同部分来工作的。不同框架工具只是为与User32和GDI/GDI+进行交互提供了不同的封装器而已。这些框架工具能提高效率较低复杂性，并提供了更多预置特性，从而使开发人员不比在自行编写底层代码，但这些框架工具不可能消除在10多前设计的系统组件的基本限制。

1.1.1 DirectX：新的图形引擎

Microsoft曾针对User32和GDI/GDI+库提供了一个解决方案：DirectX。DirectX起初使一个易于出错的组合性质的工具包，用于在Windows平台上开发游戏。DirectX在设计上关注的重点使速度，谓词，Microsoft和显卡供应商密切合作，以便为DirectX提供复杂的纹理映射、特殊效果(如半透明)以及三维图形所需的硬件加速功能。

在首次发布DirectX后，历经数年的发展，DirectX已趋于乘数。现在DirectX已称为Windows的基本组成部分，可支持所有现带显卡。然而，DirectX编程API一直未背离其设计初衷，仍主要作为游戏开发人员的工具包。因为DirectX固有的复杂性。它几乎从未用于开发传统类型的Windows应用程序。

WPF彻底扭转了这种据面。在WPF中，底层的图形技术不在是GDI/GDI+，而是DirectX。事实上，不管创建哪种用户界面，WPF应用程序在底层都使用DirectX。这意味着，无论设计复杂的三维图形，还是仅绘制几个按钮和纯文本，所有绘图工作都是通过DirectX管线完成的。因此，即使是最普通的商业应用程序也能使用丰富的效果，如半透明和反锯齿。在硬件加速方面也带来了好处，DirectX在渲染图形时会将尽可能多的工作递交给图形处理单元去处理。

注意

因为DirectX能理解可由显卡直接渲染的高层元素，如纹理和渐变，所以DirectX效率更高。而GDI/GDI+不理解这些搞曾元素，因此必须将它们转换成像素指令，而通过现带显卡渲染这些指令更慢。

不过，仍有一个User32组件得以保留，该组件只用于有限的范围。因为对于特定的服务，WPF仍以利于User32，如处理和路由输入信息以及区分哪个应用程序实际拥有屏幕的那一部分。但所有绘图操作都是由DirectX完成的。

1.1.2 硬件加速与WPF

显卡在支持特定渲染特性和优化方面是有区别的。令人感到庆幸的是，这并不是什么问题，原因有两点。首先，当今大多数计算机配备的显卡硬件都足以支持3D绘图和动画等WPF功能。即使是使用继承图形处理器的便携式电脑和坐标计算机也同样如此。其次，WPF未要完成的所有工作都预备了软件处理方式。这意味着，WPF的只能成都足够搞，会尽量采用硬件优化方式，但如有必要，它也可采用软件计算方式来完成同样工作。因此，如果在配备旧式显卡的计算机上运行WPF应用程序，界面仍将按其设计方式显示。防染，采用软件计算方式时，速度自然就慢很多，而且配备旧式显卡的计算机不能十分顺畅地运行富WPF应用程序。

1.2 WPF：高级API

如果WPF仅通过DirectX提供硬件加速功能，那么它只能算是一项重要改进，而不是革命性的变化。实际上，WPF包含了一整套面向应用程序编程人员的高级服务。

下面列出WPF引入到Windows编程领域中的一些最重要变化：

类似Web的布局模型

与通过特定的坐标将控件固定在固定在具体位置不同，WPF十分注重灵活的流式布局。根据控件的内容灵活地排列控件，从而使用户界面能适应变化幅度大的内容以及不同的语言。

丰富的绘图模型

与逐像素进行绘制不同，在WPF中可直接处理图元——基本形状、文本块以及其它图形元素。也可使用其他新特性，如真正的透明控件、防止多层并具有不同透明度内容的功能以及本地3D支持。

丰富的文本模型

WPF为Windows应用程序提供了在用户界面的任何位置显示丰富的样式化文本的功能。甚至可将文本和列表、浮动的图形已经其他用户界面元素结合起来。并且如果需要显示大量文本，还可以使用高级的文档显示特性，例如换行、分类和对其，以提高可读性。

作为首要编程概念的动画

在WPF中，不必再用计时器来强制窗体绘制自身。与此相反，动画成为WPF框架的固有部分。在WPF中可使用声明式画，WPF会自动让他们运动起来标签定义动。

支持音频和视频媒体

以前的用户界面开发工具包对多媒体的处理有很大的显示。但WPF支持播放任何Windows媒体播放器所支持的音频和视频文件，并允许同时播放多个媒体文件。更引人注目的是，WPF提供了允许再用户界面的其他部分继承视频内容的工具还允许添加特效技巧，比如再一个旋转的3D立方体上放置视频窗口。

样式和模板

通过样式可实现显示格式的标准化，并可再整个应用程序中反复使用。通过模板可改变元素的渲染方式，甚至改变核心控件的渲染方式。再创建现代的具有皮肤的用户界面，从来都不像现在这样方便。

命令

大多数用户已认识到，通过菜单或工具栏触发Open命令并没有什么区别最终结果是相同的。现在通过代码抽象，可再特定位置定义应用程序命令并将其连接倒多个控件上。

声明式用户界面

尽管可编写代码量创建WPF窗口，但Visual Studio提供了另一种方式。它将每个窗口的内容串行化到XAML文件中的一组XML标签中。其优点是用户界面和代码完全分离，并且图形设计人员可使用专业工具标记XAML文件，并最终润色应用程序的前端界面。

基于页面的应用程序

可使用WPF创建类似于浏览器的应用程序，此类应用程序可通过“前进”和“后退”导航按钮再一组页面中移动。由WPF来处理那些纷繁的细节，如页面历史。甚至可将项目部署为运行于IE中的基于浏览器的应用程序。

1.3 分辨率无关性

传统的Windows应用程序都会受特定的假定屏幕分辨率的限制。在设计窗口时，开发人员通常鉴定标准的显示器分辨率（如1366*768像素），并针对更小或更大的分辨率尽量保证窗口能够合理地改变尺寸。

问题是传统的Windows应用程序的用户界面是不可伸缩的。因此，如果使用更高的显示器分辨率，将会更紧密的排列像素，应用程序窗口将变得更小更难以阅读。特别时对于使用像素排列更加紧密的新式显示器，当以较高分辨率运行时，问题更趋严重。例如，通常可发现用户使用的某些显示器（特别时便携式电脑的显示器）的像素排列密度时120DPI（dot per inch）或144DPI，超过更常见的96DPI。当这些显示器使用它们默认的分辨率时，像素会以更紧密的方式显示，使控件和文本边的更小。

理想情况下，应用程序应用使用更高的像素密度显示更过细节。例如，高分辨率显示器可显示相同大小的工具栏图标，但使用高多像素像是更清晰的图像。这样可保持图相同的基本布局，但增加了清晰度和细节。出于多种原因，这种解决方法再过去时无法实现的。尽管可改变用GDI/GDI+绘制的图像内容的大小，但User32不支持真正的缩放。

这个问题再WPF中不复存在，因为WPF自行渲染所有用户界面元素，从简单的形状到通用控件。所以，如果再计算机显示器上创建一个1英寸宽的按钮，在更高分辨率的显示器上仍能保持1英寸的宽度——WPF只是使用更多像素更详细地渲染这个按钮罢了。

1.3.1 WPF单位

WPF窗口以及其中的所有元素都使用与设备无关的单位进行度量。一个与设备无关的单位被定义为1/96英寸。为了理解其实际含义，下面将分析一个例子。

设想用WPF创建一个尺寸为96*96单位的小按钮。如果使用标准的Windows DPI（96DPI）设置，每个设备无关单位实际上对应一个物理像素。因为对于这种情况，WPF用以下公式进行计算：

【物理单位尺寸】=【设备无关单位尺寸】*【系统DPI】
= 1/96英寸 * 96DPI
= 1像素

本质上，WPF假定使用96个像素构成1英寸，因为这是Windows操作系统通过系统DPI设置告诉WPF的。但实际上依赖于显示设备。例如，考虑一个最大分辨率为1600*1200像素的19英寸显示器。改显示器的像素密度【屏幕DPI】=SQRT(1600*1600 + 1200*1200)/19 像素/英寸 = 100DPI

在这种情况下，像素密度达到100DPI，稍高于Windows假定的数值。因此在该显示器上，一个96*96像素的按钮将略小于1英寸。另一方面，考虑分辨率为1024*768像素的15寸显示器，对于这种情况，像素密度降至约85DPI，因此96*96像素的按钮看起来比1英寸稍大。在这种两情况下，如果减小屏幕尺寸，那么按钮将相应方法。这时因为i系统DPI仍使用96DPI。换句话说，Windows仍然假定96像素代表1英寸，尽管在更低的分辨率下像素更少。

1.4 WPF体系结构

WPF使用多层体系结构。在顶层，应用程序与完全由托管C#代码编写的一组高层服务进行交互。至于将.NET对象转换为Direct3D纹理和三角形的实际工作，是在后台由一个名为milcore.dll的低级非托管组件完成的。milcore.dll使用非托管代码实现的，因为它需要和Direct3D紧密集成，并且它对性能极其敏感。

PresentationFramework.dll

包含WPF顶层的类型，包括那些表示窗口、面板以及其他类型控件的类型。它还实现了高层编程抽象，如样式。

PresentationCore.dll

包含了基础类型，如 UIElement 类和 Visual 类，所有形状类和控件类都继承自这两个类。如果不需要窗口和控件抽象层的全部特征，可使用这一层，而且仍能利用WPF的渲染引擎。

WindowsBase.dll

包含了更多的基本要素，这些要素具有在WPF之外的重要潜能，如 DispatcherObject 类和 DependencyObject 类，这两个类引入了依赖项属性。

milcore.dll

是WPF渲染系统的核心，也是媒体集成层（Media Integration Layer，MIL）的基础。其合成引擎将可视化元素转换未Direct3D所期望的三角形和纹理。尽管milcore.dll视为WPF的一部分，但它也是Windows Vista和Windows 7的核心系统组建之一。实际上，桌面窗口管理器使用milcore.dll渲染桌面。

WindowsCodecs.dll

是一套提供图像支持的低级API（例如处理、显示以及缩放位图和JEPG图像）

Direct3D

是一套低级API，WPF应用程序中的所有图形都由它进行渲染。

User32

用于决定哪些程序实际占有坐标的哪一部分。所以它仍被包含在WPF中，但不在负责渲染通用控件。

1.4.1 类层次结构

System.Threading.DispatcherObject类

WPF应用程序使用单线程亲和（Single-Thread Affinity, STA）模型，这意味着整个用户界面由单个线程拥有。从另一个线程与用户界面元素进行交互是不安全的。为方便使用此模型，每个WPF应用程序由协调消息的调度程序管理。通过继承自 DispatcherObject 类，用户界面中的每个元素都可以检查代码是否在正确的线程上运行，并能通过访问调度程序为用户界面线程封送代码。

System.Windows.DependencyObject类

在WPF中，主要通过属性与屏幕上的元素进行交互。在早期设计阶段，WPF的设计者决定创建一个更加强大的属性模型，该模型支持许多特性，例如更改通知、默认值继承以及减少属性存储控件。最终结果就是依赖项属性特性。

System.Windows.Media.Visual类

在WPF窗口中显示的每个元素本质上都是 Visual 对象。可将Visual对象视为绘图对象，其中封装了绘图指令、如何执行绘图的附加细节以及基本功能。Visual类还在托管的WPF库和渲染桌面的milcore.dll程序集之间提供了链接。任何继承自Visual的类都能在窗口上显示出来。如果更愿意使用轻量级的API创建用户界面，而不想使用WPF的高级框架特征，可以直接对 Visual 进行编程。

System.Windows.UIElement类

UIElement类增加了对WPF本质特征的支持，如布局、输入、焦点和事件。例如，这里定义两个步骤的测量和排列布局过程。在该类中，原始的鼠标单击和按键操作被转换为更有用的事件，如MouseEnter事件。与属性类似，WPF实现了增强的称为路由事件的事件路由系统

System.Windows.FrameworkElement类

FrameworkElement类是WPF核心继承树中的最后一站。该类实现了一些全部由UIElement类定义的成员。例如，UIElement为WPF布局系统设置了基础，但Framework类提供了支持它的重要属性（如HorizontalAlignment和Margin属性）。UIElement类还添加了对数据绑定、动画以及样式等核心特性的支持。

Systeml.Windows.Shapes.Shape类

基本形状类（Rectangle、Polygon、Ellipse、Line、Path）都继承自该类。

System.Windows.Controls.Control类

控件（Control）是可与用户进行交互的元素。控件显然包括TextBox、Button、ListBox等。Control类为设置字体以及前景色与背景色提供了附加属性。但最令人感兴趣的细节是模板支持，通过模板支持，可使用自定义风格的绘图替换控件的标准外观。

注意：

在Windows窗体编程中，窗体中的每个可视化项都称为控件。在WPF中，情况不再如此。可视化内容被称为元素（element），只有部分元素是控件（控件是那些能够接受焦点并能够与用户进行交互的元素）。更令人费解之处在于，许多元素实在System.Windows.Controls名称控件中定义的，但它们不是继承自System.Windows.Controls.Control类。并且不被认为是控件。Panel类便是其中一例。

System.Windows.Controls.ContentControl类

ContentControl类是所有具有单一内容的控件的基类，包括简单的标签乃至窗口的所有内容。该模型给人印象深刻的部分是控件中的单一内容可以是普通字符串乃至具有其他形状和控件组合的布局面板。

System.Windows.Controls.ItemsControl类

ItemControl类是所有显示选项集合的控件的基类，如ListBox和TreeView控件。列表控件十分灵活——例如，使用ItemsControl类的内置特征，可将简单的ListBox控件变为单选按钮列表、复选按钮控件列表、平铺的图像或是您所选择的完全不同的元素组合。实际上，WPF中的菜单、工具栏以及状态栏都是特定的列表，并且实现它们的类都继承自ItemsControl类。