首當(dāng)其沖的，自然是System.Object類了。這里主要想說的是，WPF的大部分代碼都是使用托管代碼編寫，原因是因?yàn)镃LR的許多不錯(cuò)的特性（如內(nèi)存管理、錯(cuò)誤處理、通用類型系統(tǒng)等。），可以讓開發(fā)的程序更有效、更健壯。但是，框架并不是所有代碼都是托管的，也有一部分是由非托管代碼編寫。原因主要是因?yàn)閃PF是展現(xiàn)層框架，它的顯示需要和DirectX很緊密的集成起來，進(jìn)行硬渲染和軟渲染，以得到性能上的提升。
??? 下面的結(jié)構(gòu)圖中，紅色部分是屬于WPF框架的。其中，只有milcore這個(gè)部分是采用非托管代碼編寫。所以，可以看出，我們在使用WPF的時(shí)候，是不會接觸到里面的非托管代碼的。

DispatcherObject（異步）
??? 命令空間：System.Threading。 ??? WPF Dispatcher使用User32的消息機(jī)制來實(shí)現(xiàn)跨線程調(diào)用。工作機(jī)制類似Win32的消息泵。 ??? WPF的線程模型和User32的線程模型保持一致，使用STA。主要原因是互可操作性，因?yàn)楝F(xiàn)在的很多系統(tǒng)都是需要STA的，如IE、OLE2.0、剪貼板等。 ??? 通過Dispatcher，我們可以實(shí)現(xiàn)線程間的通信。繼承自DispatcherObejct的類，都獲取了一個(gè)所在線程的Dispatcher引用，這樣，任何使用這個(gè)類的對象的線程，都可以使用它的Dispatcher來發(fā)送“消息”。 一般情況下，我們使用這個(gè)類的意圖主要是異步線程調(diào)用DispatcherObject的Dispather來讓DispatcherObject的創(chuàng)建線程做一些特定的事情，如設(shè)置界面上某個(gè)值。這樣大大方便了我們開發(fā)人員。想想我原來用WindowsForm開發(fā)的時(shí)候，為了異步調(diào)用顯示一下Label，寫出來的代碼真是夠繁瑣。
DependencyObject（屬性）
??? 命令空間：System.Windows。 ???? WPF框架中最主要的思想之一是：優(yōu)先使用屬性，而不是事件、方法。 ??? 繼承自DependencyObject的類，就擁有了WPF特別定制的“富”屬性系統(tǒng)。該屬性系統(tǒng)提供了以下好處： ??? 1. Dependency Property：“依賴”的屬性，自動(dòng)檢測依賴性的屬性表達(dá)式，當(dāng)被依賴的屬性變化時(shí)，自動(dòng)更新屬性值。 ??? 2. 使用盡量少的屬性值存儲空間。因?yàn)椴⒉皇敲恳粋€(gè)屬性都會存儲在內(nèi)存中。 ??? 3. Attached Property：任何一個(gè)類都允許使用其它的類定義的任何依賴屬性。（類似于javascript的expando特性。）
Visual（集成、繪制）
??? 命令空間：System.Windows.Media。 ??? Visual類才真正是WPF的入口點(diǎn)。就是在這里，整合了托管代碼API和非托管代碼milcore。 ??? WPF使用milcore中的一種叫Composition Nodes的數(shù)據(jù)結(jié)構(gòu)來進(jìn)行顯示。這種數(shù)據(jù)結(jié)構(gòu)類似一棵樹，樹的每個(gè)節(jié)點(diǎn)都帶有繪制的指令。Visual以及Visual的子類，可以通過消息協(xié)議來和Composition Nodes進(jìn)行通信。（每一個(gè)Visual，可能會建立零到多個(gè)不等的Composition Nodes。）重點(diǎn)是：Visual的整棵樹及其所附屬繪制指令，都會被緩存起來。這樣，整個(gè)系統(tǒng)可以進(jìn)行高速的重繪，也不會因?yàn)橛脩舫绦虻淖枞枞@示。 ??? 在User32和GDI中，系統(tǒng)是通過一種盒子方式來進(jìn)行繪制的：每一個(gè)成員都被放在一個(gè)指定的區(qū)域里面進(jìn)行繪制，然后再疊加再一起。這樣生成的圖象中的每一個(gè)象素，其實(shí)都只屬于唯一一個(gè)成員。但是是WPF系統(tǒng)中，使用的是"painter’s algorithm"繪制算法：從后到前，一個(gè)一個(gè)的畫出這些成員。這樣的話，后畫出來的成員就在已經(jīng)繪制好的圖案上繼續(xù)進(jìn)行繪制，就可以顯示出一些復(fù)雜的半透明的圖形。 ??? 而“屬性優(yōu)先”的思想，在Visual類中也有所體現(xiàn)。如，我們原來熟悉的DrawLine()/DrawLine()方式，現(xiàn)在變成了new Line()/new Line()。這種數(shù)據(jù)驅(qū)動(dòng)的編程方式，可以讓我們使用屬性來完成一些復(fù)雜的繪制操作。又如，動(dòng)畫的使用方式，也是完全的使用屬性聲明方式。
UIElement（界面基礎(chǔ)）
??? 命令空間：System.Windows。
??? UIElement提供了很多PresentationCore程序集中比較重要的特性：

布局： ??? 布局系統(tǒng)中，比較重要的是Measure和Arrage這兩個(gè)階段。 ??? Measure過程讓一個(gè)成員決定它到底需要多大的尺寸。很多情況下，父元素經(jīng)常會多次詢問子元素所需要的尺寸，然后再決定給它一個(gè)比較合適的最終尺寸。這就是WPF中另一個(gè)重要思想：Size To Content。這樣，WPF中所有的控件，都可以控制自己的顯示尺寸，使其大小和控件的內(nèi)容比較協(xié)調(diào)。

輸入、事件： ??? 在WPF中事件模型中最基本的、不同于以往應(yīng)用程序的變化是“事件路由模型”。操作系統(tǒng)收到從硬件發(fā)出的輸入信號后，導(dǎo)向相應(yīng)的進(jìn)程、線程。當(dāng)這些關(guān)于輸入信息的Win32消息被傳送到WPF中時(shí)，會被轉(zhuǎn)換成WPF最原始的輸入信號并發(fā)送到Dispatcher“發(fā)報(bào)機(jī)”中。WPF可能會把一個(gè)原始的信號轉(zhuǎn)換成多個(gè)與之相應(yīng)的事件。 ??? 這里需要說一下，這里事件路由的概念。每個(gè)輸入發(fā)生時(shí)，會被轉(zhuǎn)換成兩個(gè)具體的事件，一個(gè)preview event和一個(gè)一般事件。一個(gè)事件從控件樹上發(fā)生事件的目標(biāo)節(jié)點(diǎn)，依次傳到最上層的根節(jié)點(diǎn)的方式，叫作“bubble”。另一種相反的方式被叫作“tunnel”。preview event就是一個(gè)正在進(jìn)行tunnel的事件。這樣，可以先讓所有元素都有機(jī)會對事件進(jìn)行過濾，或者發(fā)生一些特定的行為。然后這個(gè)事件又被從目標(biāo)節(jié)點(diǎn)依次bubble回到根節(jié)點(diǎn)。 ??? 另外，不象Win32中的應(yīng)用程序只有一個(gè)"TranslateAccelerator"（用來控制如“Ctrl+N”這樣的組合鍵），因?yàn)閃PF系統(tǒng)是“組合”

總結(jié)

以上是生活随笔為你收集整理的了解WPF框架的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。