IOS UIKit框架之窗口和視圖架構介紹

UIKit框架圖

窗口和視圖
窗口和視圖是爲iPhone應用程序構造用戶界面的可視組件。窗口爲內容顯示提供背景平臺，而視圖負責絕大部分的內容描畫，並負責響應用戶的交互。雖然本章討論的概念和窗口及視圖都相關聯，可是討論過程更加關注視圖，由於視圖對系統更爲重要。
什麼是窗口和視圖？

和Mac OS X同樣，iPhone OS經過窗口和視圖在屏幕上展示圖形內容。雖然窗口和視圖對象之間在兩個平臺上有不少類似性，可是具體到每一個平臺上，它們的做用都有輕微的差異。

UIWindow的做用

和Mac OS X的應用程序有所不一樣，iPhone應用程序一般只有一個窗口，表示爲一個UIWindow類的實例。您的應用程序在啓動時建立這個窗口（或者從nib文件進行裝載），並往窗口中加入一或多個視圖，而後將它顯示出來。窗口顯示出來以後，您不多須要再次引用它。

在iPhone OS中，窗口對象並無像關閉框或標題欄這樣的視覺裝飾，用戶不能直接對其進行關閉或其它操做。全部對窗口的操做都須要經過其編程接口來實現。應用程序能夠藉助窗口對象來進行事件傳遞。窗口對象會持續跟蹤當前的第一響應者對象，並在UIApplication對象提出請求時將事件傳遞它。

還有一件可能讓有經驗的Mac OS X開發者以爲奇怪的事是UIWindow類的繼承關係。在Mac OS X中，NSWindow的父類是NSResponder；而在iPhone OS中，UIWindow的父類是UIView。所以，窗口在iPhone OS中也是一個視圖對象。無論其起源如何，您一般能夠將iPhone OS上的窗口和Mac OS X的窗口一樣對待。也就是說，您一般沒必要直接操做UIWindow對象中與視圖有關的屬性變量。

在建立應用程序窗口時，您應該老是將其初始的邊框尺寸設置爲整個屏幕的大小。若是您的窗口是從nib文件裝載獲得，Interface Builder並不容許建立比屏幕尺寸小的窗口；然而，若是您的窗口是經過編程方式建立的，則必須在建立時傳入指望的邊框矩形。除了屏幕矩形以外，沒有理由傳入其它邊框矩形。屏幕矩形能夠經過UIScreen對象來取得，具體代碼以下所示：

UIWindow* aWindow = [[[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]] autorelease];

雖然iPhone OS支持將一個窗口疊放在其它窗口的上方，可是您的應用程序永遠不該建立多個窗口。系統自身使用額外的窗口來顯示系統狀態條、重要的警告、以及位於應用程序窗口上方的其它消息。若是您但願在本身的內容上方顯示警告，可使用UIKit提供的警告視圖，而不該建立額外的窗口。

UIView是做用視圖

是UIView類的實例，負責在屏幕上定義一個矩形區域。在iPhone的應用程序中，視圖在展現用戶界面及響應用戶界面交互方面發揮關鍵做用。每一個視圖對象都要負責渲染視圖矩形區域中的內容，並響應該區域中發生的觸碰事件。這一雙重行爲意味着視圖是應用程序與用戶交互的重要機制。在一個基於模型-視圖-控制器的應用程序中，視圖對象明顯屬於視圖部分。

除了顯示內容和處理事件以外，視圖還能夠用於管理一或多個子視圖。子視圖是指嵌入到另外一視圖對象邊框內部的視圖對象，而被嵌入的視圖則被稱爲父視圖或超視圖。視圖的這種佈局方式被稱爲視圖層次，一個視圖能夠包含任意數量的子視圖，經過爲子視圖添加子視圖的方式，視圖能夠實現任意深度的嵌套。視圖在視圖層次中的組織方式決定了在屏幕上顯示的內容，緣由是子視圖老是被顯示在其父視圖的上方；這個組織方法還決定了視圖如何響應事件和變化。每一個父視圖都負責管理其直接的子視圖，即根據須要調整它們的位置和尺寸，以及響應它們沒有處理的事件。
因爲視圖對象是應用程序和用戶交互的主要途徑，因此須要在不少方面發揮做用，下面是其中的一小部分：
描畫和動畫
視圖負責對其所屬的矩形區域進行描畫。
某些視圖屬性變量能夠以動畫的形式過渡到新的值。
佈局和子視圖管理
視圖管理着一個子視圖列表。
視圖定義了自身相對於其父視圖的尺寸調整行爲。
必要時，視圖能夠經過代碼調整其子視圖的尺寸和位置。
視圖能夠將其座標系統下的點轉換爲其它視圖或窗口座標系統下的點。
事件處理
視圖能夠接收觸摸事件。
視圖是響應者鏈的參與者。
在iPhone應用程序中，視圖和視圖控制器緊密協做，管理若干方面的視圖行爲。視圖控制器的做用是處理視圖的裝載與卸載、處理因爲設備旋轉致使的界面旋轉，以及和用於構建複雜用戶界面的高級導航對象進行交互。更多這方面的信息請參見「視圖控制器的做用」部分。
本章的大部份內容都着眼於解釋視圖的這些做用，以及說明如何將您本身的定製代碼關聯到現有的UIView行爲中。

UIKit的視圖類

UIView類定義了視圖的基本行爲，但並不定義其視覺表示。相反，UIKit經過其子類來爲像文本框、按鍵、及工具條這樣的標準界面元素定義具體的外觀和行爲。顯示了全部UIKit視圖類的層次框圖。除了UIView和UIControl類是例外，這個框圖中的大多數視圖都設計爲可直接使用，或者和委託對象結合使用。
視圖的類層次
View class hierarchy

這個視圖層次能夠分爲以下幾個大類：

容器
容器視圖用於加強其它視圖的功能，或者爲視圖內容提供額外的視覺分隔。好比，UIScrollView類能夠用於顯示因內容太大而沒法顯示在一個屏幕上的視圖。UITableView類是UIScrollView類的子類，用於管理數據列表。表格的行能夠支持選擇，因此一般也用於層次數據的導航—好比用於挖掘一組有層次結構的對象。
UIToolbar對象則是一個特殊類型的容器，用於爲一或多個相似於按鍵的項提供視覺分組。工具條一般出如今屏幕的底部。Safari、Mail、和Photos程序都使用工具條來顯示一些按鍵，這些按鍵表明常用的命令。工具條能夠一直顯示，也能夠根據應用程序的須要進行顯示。

控件
控件用於建立大多數應用程序的用戶界面。控件是一種特殊類型的視圖，繼承自UIControl超類，一般用於顯示一個具體的值，並處理修改這個值所須要的全部用戶交互。控件一般使用標準的系統範式（好比目標-動做模式和委託模式）來通知應用程序發生了用戶交互。控件包括按鍵、文本框、滑塊、和切換開關。
顯示視圖
控件和不少其它類型的視圖都提供了交互行爲，而另一些視圖則只是用於簡單地顯示信息。具備這種行爲的UIKit類包括UIImageView、 UILabel（標籤）、UIProgressView、UIActivityIndicatorView(界面活動指示器視圖)。
文本和web視圖
文本和web視圖爲應用程序提供更爲高級的顯示多行文本的方法。UITextView類支持在滾動區域內顯示和編輯多行文本；而UIWebView類則提供了顯示HTML內容的方法，經過這個類，您能夠將圖形和高級的文本格式選項集成到應用程序中，並以定製的方式對內容進行佈局。
警告視圖和動做表單
警告視圖和動做表單用於即刻取得用戶的注意。它們向用戶顯示一條消息，同時還有一或多個可選的按鍵，用戶經過這些按鍵來響應消息。警告視圖和動做表單的功能相似，可是外觀和行爲不一樣。舉例來講，UIAlertView類在屏幕上彈出一個藍色的警告框，而UIActionSheet類則從屏幕的底部滑出動做框。
導航視圖
標籤欄和導航條和視圖控制器結合使用，爲用戶提供從一個屏幕到另外一個屏幕的導航工具。在使用時，您一般沒必要直接建立UITabBar和UINavigationBar的項，而是經過恰當的控制器接口或Interface Builder來對其進行配置。
窗口
窗口提供一個描畫內容的表面，是全部其它視圖的根容器。每一個應用程序一般都只有一個窗口。更多信息請參見「UIWindow的做用」部分。除了視圖以外，UIKit還提供了視圖控制器，用於管理這些對象。更多信息請參見「視圖控制器的做用」部分。

視圖控制器的做用
運行在iPhone OS上的應用程序在如何組織內容和如何將內容呈現給用戶方面有不少選擇。含有不少內容的應用程序能夠將內容分爲多個屏幕。在運行時，每一個屏幕的背後都是一組視圖對象，負責顯示該屏幕的數據。一個屏幕的視圖後面是一個視圖控制器其做用是管理那些視圖上顯示的數據，並協調它們和應用程序其它部分的關係。

UIViewController類負責建立其管理的視圖及在低內存時將它們從內容中移出。視圖控制器還爲某些標準的系統行爲提供自動響應。好比，在響應設備方向變化時，若是應用程序支持該方向，視圖控制器能夠對其管理的視圖進行尺寸調整，使其適應新的方向。您也能夠經過視圖控制器來將新的視圖以模式框的方式顯示在當前視圖的上方。

除了基礎的UIViewController類以外，UIKit還包含不少高級子類，用於處理平臺共有的某些高級接口。特別須要提到的是，導航控制器用於顯示多屏具備必定層次結構的內容；而標籤欄控制器則支持用戶在一組不一樣的屏幕之間切換，每一個屏幕都表明應用程序的一種不一樣的操做模式。

視圖架構和幾何屬性
因爲視圖是iPhone應用程序的焦點對象，因此對視圖與系統其它部分的交互機制有所瞭解是很重要的。UIKit中的標準視圖類爲應用程序免費提供至關數量的行爲，還提供了一些定義良好的集成點，您能夠經過這些集成點來對標準行爲進行定製，完成應用程序須要作的工做。

本文的下面部分將解釋視圖的標準行爲，並說明哪些地方能夠集成您的定製代碼。若是須要特定類的集成點信息，請參見該類的參考文檔。您能夠從UIKit框架參考中取得全部類參考文檔的列表。

視圖交互模型
任什麼時候候，當用戶和您的程序界面進行交互、或者您的代碼以編碼的方式進行某些修改時，UIKit內部都會發生一個複雜的事件序列。在事件序列的一些特定的點上，UIKit會調用您的視圖類，使它們有機會表明應用程序進行事件響應。理解這些調用點是很重要的，有助於理解您的視圖對象和系統在哪裏進行結合。圖2-2顯示了從用戶觸擊屏幕到圖形系統更新屏幕內容這一過程的基本事件序列。以編程方式觸發事件的基本步驟與此相同，只是沒有最初的用戶交互。
UIKit和您的視圖對象之間的交互

UIKit interactions with your view objects

下面的步驟說明進一步刨析了圖2-2中的事件序列，解釋了序列的每一個階段都發生了什麼，以及應用程序可能如何進行響應。

用戶觸擊屏幕。硬件將觸擊事件報告給UIKit框架。
UIKit框架將觸擊信息封裝爲一個UIEvent對象，並派發給恰當的視圖（有關UIKit如何將事件遞送給您的視圖的詳細解釋，請參見「事件的傳遞」部分）。
視圖的事件處理方法能夠經過下面的方式來響應事件：
調整視圖或其子視圖的屬性變量（邊框、邊界、透明度等）。
將視圖（或其子視圖）標識爲須要修改佈局。
將視圖（或其子視圖）標識爲佈局須要重畫。
將數據發生的變化通報給控制器。
固然，上述的哪些事情須要作及調用什麼方法來完成是由視圖來決定的。
若是視圖被標識爲須要從新佈局，UIKit就調用視圖的layoutSubviews方法。
您能夠在本身的定製視圖中重載這個方法，以便調整子視圖的尺寸和位置。舉例來講，若是一個視圖具備很大的滾動區域，就須要使用幾個子視圖來「平鋪」，而不是建立一個內存極可能裝不下的大視圖。在這個方法的實現中，視圖能夠隱藏全部不需顯示在屏幕上的子視圖，或者在從新定位以後將它們用於顯示新的內容。做爲這個過程的一部分，視圖也能夠將用於「平鋪」的子視圖標識爲須要重畫。
若是視圖的任何部分被標識爲須要重畫，UIKit就調用該視圖的drawRect:方法。
UIKit只對那些須要重畫的視圖調用這個方法。在這個方法的實現中，全部視圖都應該儘量快地重畫指定的區域，且都應該只重畫本身的內容，不該該描畫子視圖的內容。在這個調用點上，視圖不該該嘗試進一步改變其屬性或佈局。
全部更新過的視圖都和其它可視內容進行合成，而後發送給圖形硬件進行顯示。
圖形硬件將渲染完成的內容轉移到屏幕。

請注意：上述的更新模型主要適用於採納內置視圖和描畫技術的應用程序。若是您的應用程序使用OpenGL ES來描畫內容，則一般要配置一個全屏的視圖，而後直接在OpenGL的圖形上下文中進行描畫。您的視圖仍然須要處理觸碰事件，但不須要對子視圖進行佈局或者實現drawRect:方法。有關OpenGL ES的更多信息，請參見「用OpenGL ES進行描畫」部分。

基於上述的步驟說明能夠看出，UIKit爲您本身定製的視圖提供以下主要的結合點：

下面這些事件處理方法：
touchesBegan:withEvent:
touchesMoved:withEvent:
touchesEnded:withEvent:
touchesCancelled:withEvent:
layoutSubviews方法
drawRect:方法

大多數定製視圖經過實現這些方法來獲得本身指望的行爲。您可能不須要重載全部方法，舉例來講，若是您實現的視圖是固定尺寸的，則可能不須要重載layoutSubviews方法。相似地，若是您實現的視圖只是顯示簡單的內容，好比文本或圖像，則一般能夠經過簡單地嵌入UIImageView和UILabel對象做爲子視圖來避免描畫。

重要的是要記住，這些是主要的結合點，但不是所有。UIView類中有幾個方法的設計目的就是讓子類重載的。您能夠經過查閱UIView類參考中的描述來了解哪些方法能夠被重載。

視圖渲染架構
雖然您經過視圖來表示屏幕上的內容，可是UIView類自身的不少基礎行爲卻嚴重依賴於另外一個對象。UIKit中每一個視圖對象的背後都有一個Core Animation層對象，它是一個CALayer類的實例，該類爲視圖內容的佈局和渲染、以及合成和動畫提供基礎性的支持。

和Mac OS X（在這個平臺上Core Animation支持是可選的）不一樣的是，iPhone OS將Core Animation集成到視圖渲染實現的核心。雖然Core Animation發揮核心做用，可是UIKit在Core Animation上面提供一個透明的接口層，使編程體驗更爲流暢。這個透明的接口使開發者在大多數狀況下沒必要直接訪問Core Animation的層，而是經過UIView的方法和屬性聲明取得相似的行爲。然而，當UIView類沒有提供您須要的接口時，Core Animation就變得重要了，在那種狀況下，您能夠深刻到Core Animation層，在應用程序中實現一些複雜的渲染。

文章來源：http://www.cnblogs.com/CHONGCHONG2008/archive/2012/08/02/2619366.html    此文本ID有部分修改