視圖和窗口展示了應用的用戶界面，同時負責界面的交互。UIKit和其他系統框架提供了很多視圖，你可以就地使用而幾乎不需要修改。當你需要展示的內容與標準視圖允許的有很大的差別時，你也可以定義自己的視圖。
不管你是使用系統的視圖還是創建自己的視圖，你需要理解UIView和UIWindow類所提供的基本結構。這些類提供了複雜的方法來管理視圖的佈局和展示。理解這些方法的工作非常重要，使你在應用發生改變時可以確認視圖有合適的行爲。
視圖架構 fundamentals
大部分你想要可視化操作都是由視圖對象－即UIView類的實例－來進行的。一個視圖對象定義了一個屏幕上的一個矩形區域，同時處理該區域的繪製和觸屏事件。一個視圖也可以作爲其他視圖的父視圖，同時決定着這些子視圖的位置和大小。UIView類做了大量的工作去管理這些內部視圖的關係，但是需要的時候你也可以定製默認的行爲。
視圖與Core Animation層聯合起來處理着視圖內容的解釋和動畫過渡。每個UIKit框架裏的視圖都被一個層對象支持（通常是一個CALayer類的實例），它管理管理着後臺的視圖存儲和處理視圖相關的動畫。然而，當你需要對視圖的解釋和動畫行爲有更多的控制權時，你可以使用層。
爲了理解視圖和層之間的關係，我們可以藉助於一些例子。圖1－1顯示了ViewTransitions樣例程序的視圖層次及其對底層Core Animation層的關係。應用中的視圖包括了一個window(同時也是一個視圖)，一個通用的表現得像一個容器視圖的UIView對象，一個圖像視圖，一個控制顯示用的工具條，和一個工具條按鈕(它本身不是一個視圖但是在內部管理着一個視圖)。（注意這個應用包含了一個額外的圖像視圖，它是用來實現動畫的）。爲了簡化，同時因爲這個視圖通常是被隱藏的，所以沒把它包含在下面的圖中。每個視圖都有一個相應的層對象，它可以通過視圖礶r屬性被訪問。（因爲工具條按鈕不是一個視圖，你不能直接訪問它的層對象。）在它們的層對象之後是Core Animation的解釋對象，最後是用來管理屏幕上的位的硬件緩存。
Figure 1-1 View architecture
使用Core Animation的層對象有很重要的性能意義。一個視圖對象的繪製代碼需要儘量的少被調用，當它被調用時，其繪製結果會被Core Animation緩存起來並在往後可以被儘可能的重用。重用已經解釋過的內容消除了通常需要更新視圖的開銷昂貴的繪製週期。內容的重用在動畫中特別重要，我們可以使用已有的內容，這樣比創建新的內容開銷更小。
視圖層次和子視圖管理
除了提供自己的內容之外，一個視圖也可以表現得像一個容器。當一個視圖包含其他視圖時，就在兩個視圖之間創建了一個父子關係。在這個關係中孩子視圖被當作子視圖，父視圖被當作超視圖。創建這樣一個關係對應用的可視化和行爲都有重要的意義。
在視覺上，子視圖隱藏了父視圖的內容。如果子視圖是完全不透明的，那麼子視圖所佔據的區域就完全的隱藏了父視圖的相應區域。如果子視圖是部分透明的，那麼兩個視圖在顯示在屏幕上之前就混合在一起了。每個父視圖都用一個有序的數組存儲着它的子視圖，存儲的順序會影響到每個子視圖的顯示效果。如果兩個兄弟子視圖重疊在一起，後來被加入的那個（或者說是排在子視圖數組後面的那個）出現在另一個上面。
父子視圖關係也影響着一些視圖行爲。改變父視圖的尺寸會連帶着改變子視圖的尺寸和位置。在這種情況下，你可以通過合適的配置視圖來重定義子視圖的尺寸。其他會影響到子視圖的改變包括隱藏父視圖，改變父視圖的alpha值，或者轉換父視圖。
視圖層次的安排也會決定着應用如何去響應事件。在一個具體的視圖內部發生的觸摸事件通常會被直接發送到該視圖去處理。然而，如果該視圖沒有處理，它會將該事件傳遞給它的父視圖，在響應者鏈中以此類推。具體視圖可能也會傳遞事件給一個干預響應者對象，像視圖控制器。如果沒有對象處理這個事件，它最終會到達應用對象，此時通常就被丟棄了。
獲取更多關於如何創建視圖層次，查看 creating and managing a view hierarchy
視圖繪製週期
UIView類使用一個點播繪製模型來展示內容。當一個視圖第一次出現在屏幕前，系統會要求它繪製自己的內容。在該流程中，系統會創建一個快照，這個快照是出現在屏幕中的視圖內容的可見部分。如果你從來沒有改變視圖的內容，這個視圖的繪製代碼可能永遠不會再被調用。這個快照圖像在大部分涉及到視圖的操作中被重用。
如果你確實改變了視圖內容，也不會直接的重新繪製視圖內容。相反，使用setNeedsDisplay或者setNeedsDisplayInRect:方法廢止該視圖，同時讓系統在稍候重畫內容。系統等待當前運行循環結束，然後開始繪製操作。這個延遲給了你一個機會來廢止多個視圖，從你的層次中增加或者刪除視圖，隱藏，重設大小和重定位視圖。所有你做的改變會稍候在同一時間反應。
注意：改變一個視圖的幾何結構不會自動引起系統重畫內容。視圖的contentMode屬性決定了改變幾何結構應該如果解釋。大部分內容模式在視圖的邊界內拉伸或者重定位了已有快照，它不會重新創建一個新的快照。獲取更多關於內容模式如果影響視圖的繪製週期，查看 content modes
當繪製視圖內容的時候到了時，真正的繪製流程會根據視圖及其配置改變。系統視圖通常會實現私有的繪製方法來解釋它們的視圖，（那些相同的系統視圖經常開發接口，好讓你可以用來配置視圖的真正表現。）對於定製的UIView子類，你通常可以覆蓋drawRect:方法並使用該方法來繪製你的視圖內容。也有其他方法來提供視圖內容，像直接在底部的層設置內容，但是覆蓋drawRect:時最通用的技術
內容模式
視圖的內容模式控制着視圖如何回收內容來響應視圖幾何結構的變化，也控制着是否需要回收內容。當一個視圖第一次顯示時，它通常會解釋內容，其結果會被底層的層級樹捕獲爲一張位圖。在那之後，改變視圖的幾何結構不會導致重新創建位圖。相反，視圖中contentMode屬性的值決定着這張位圖是否該被拉伸，以適應新的邊界或者只是簡單的被放到角落或者視圖的邊界。
視圖的內容模式在你進行如下操作時被應用：
改變視圖frame或者bounds矩形的寬度或者高度時。
賦值給視圖的transform屬性，新的轉換包括一個放縮因子。
大部分視圖的contentMode值是UIViewContentModeScaleToFiill，它使視圖的內容被放縮到適合新框架的值。Figure 1-2展示了使用其他可用的內容模式的結果。正如你在圖中所看到的那樣，不是所有的內容模式都可以填充視圖的範圍，可以的模式可能會扭曲內容。
內容模式很好的支持了視圖的內容回收，但是當你想視圖在放縮和重設尺寸的操作中重繪你也可以用UIViewContentModeRedraw內容模式。設置這個值繪強制系統調用視圖的drawRect:方法來響應幾何結構的變化。通常來講，你應該儘可能的避免使用這個模式，同時你不應該在標準的系統視圖中使用這個模式。
獲取更多骨幹與可用的內容模式，查看UIView Class Reference
Figure 1-2
拉伸視圖
你可以指定視圖的某部分爲可拉伸的，以便當視圖的尺寸改變時只有可拉伸的部分被影響到。可拉伸的部分通常給按鈕或者其他的部分爲重複模式的視圖。由你指定的可拉伸區域允許沿着兩條或者其中一條軸拉伸。當然，當一個視圖沿着兩條軸拉伸的時候，視圖的邊界必須也定義了一個重複的模式來避免任何的扭曲。Figure1-3展示了這種扭曲在視圖裏是怎麼表現自己的。每個視圖裏的原始像素的顏色都自我複製，以便可以填充更大視圖的相應區域。
Figure 1-3 拉伸一個按鈕的背景
你可以用contentStretch屬性來定義一個視圖的可拉伸區域。這個屬性的值一個邊的值被標準化爲0.0到1.0之間的矩形。當拉伸這個視圖時，系統將視圖的當前邊界值和放縮因子乘以標準值，以便決定哪些像素需要被拉伸。使用標準值可以減輕每次改變視圖的邊界值都更新contentStretch屬性的需要。
視圖的內容模式也在決定如何視圖的可拉伸區域的使用中扮演着重要的角色。只有當內容模式可能繪引起視圖內容放縮的時候可拉伸區域纔會被使用。這意味這你的可拉伸視圖只被UIViewContentModeScaleToFill, UIViewContentModeScaleAspectFit和UIViewContentModeScaleAspectFill內容模式。如果你指定了一個將內容彈到邊界或者角落的內容模式（這樣就沒有真正的放縮內容），這個視圖會忽視可拉伸區域。
注意：當需要創建一個可拉伸UIImage對象作爲視圖的背景時，使用contentStretch屬性是推薦的。可拉伸視圖完全被Core Animation層處理，這樣性能通常更好。
嵌入式動畫支持
使用層對象來支持視圖的其中一個利益是你可以輕鬆的用動畫處理視圖相關的改變。動畫是與用戶進行信息交流的一個有用的方法，而且應該總是在進行應用設計的過程中考慮使用動畫。UIView類的很多屬性是動畫化的－也就是，可以半自動的從一個值動畫的變化到另一個值。爲了實現這樣一個動畫，你需要做的只是：
1 告訴UIKit你想要實現一個動畫
2 改變這個屬性的值
在一個UIView對象中有以下的動畫化屬性：
frame - 你可以使用這個來動畫的改變視圖的尺寸和位置
bounds - 使用這個可以動畫的改變視圖的尺寸
center － 使用這個可以動畫的改變視圖的位置
transform － 使用這個可以翻轉或者放縮視圖
alpha － 使用這個可以改變視圖的透明度
backgroundColor － 使用這個可以改變視圖的背景顏色
contentStretch - 使用這個可以改變視圖內容如何拉伸
動畫的一個很重要的地方是用於從一組視圖到另一組視圖的過渡。通常來說，會用一個視圖控制器來管理關係到用戶界面的主要變更的動畫。例如，涉及到從高層到底層信息的導航的界面，通常會使用一個導航控制器來管理視圖的過渡，這些視圖顯示了數據的每一個連續層面。然而，你也可以使用動畫來創建兩組視圖的過渡，而不是視圖控制器。當你想用一個系統提供的視圖控制器無法支持的導航方案時你可能會這樣做。
除了用UIKit類可以創建動畫外，你也可以用Core Animation層來創建動畫。在更低層你有更多的在時間或者動畫屬性上的控制權。
獲取更多關於如何創建一個基於視圖的動畫，查看 Animations
獲取更多關於使用Core Animation創建動畫的信息，查看Core Animation Programming Guide和Core Animation Cookbook.
視圖幾何結構和座標系統
UIKit的默認座標系統把原點設置在左上角，兩條軸往下和右擴展。做標誌被表示爲浮點數，這樣允許內容的精確佈局和定位而不管底層的屏幕。Figure1-4展示了相對於屏幕的座標系統。除了屏幕座標系統窗口和視圖也定義了它們自己的本地座標系統，這樣允許你指定相對於視圖或者窗口原點的座標而不是屏幕。
Figure 1-4 UIKit中的座標系統
因爲每個視圖和窗口都定義了它自己的本地座標系統，你需要留意在任何時間內是哪個座標系統在起作用。每次繪製或者改變一個視圖都是基於一個座標系統的。在某些繪製中會基於視圖本身的座標系統。在某些幾何結構變更中是基於父視圖的座標系統的。UIWindow和UIView類都包含了幫助你從一個座標系統轉換到另一個的方法。
重要：一些iOS技術定義了默認的座標系統，它們的原點和方向與UIKit的不同。；例如，Core Graphics和OpenGL ES的座標系統是原點在可視區域的左下角，而y軸往上遞增。當繪製或者創建內容時，你的代碼應該考慮到一些不同並且適應座標值。
frame, bounds和center屬性之間的關係
視圖對象使用frame, bounds和center屬性來跟蹤它的尺寸和位置：
frame屬性包含了frame矩形，指定了在父視圖座標系統中該視圖的尺寸和位置。
center屬性包含了在父視圖座標系統中的已知中心點。
bounds屬性包含了邊界矩形，指定了在視圖本地座標系統中視圖的尺寸。
主要使用center和frame屬性來控制當前視圖的幾何結構。例如，當在運行時構建你的視圖層次或者改變視圖的尺寸或者位置時你可以使用這些屬性。如果你只是要改變視圖的位置，那麼推薦使用center屬性。center屬性的值永遠是可用的，即使添加了放縮或者轉換因子到視圖的轉換矩陣當中。但是對於frame屬性卻不是，當視圖的轉換矩形不等於原始矩陣時它被當作時無效的。
在繪製的過程中主要使用bounds屬性。這個邊界矩陣在視圖的本地座標系統被解釋。這個矩形的默認原點是（0， 0），它的尺寸也適應frame矩形的尺寸。任何繪製在這個矩形當中的東西都是該視圖的可視內容的一部分。如果你改變了bounds矩形的原點，任何你繪製在新矩形的東西都會變成該視圖可視內容的一部分。
Figure1-5展示了一個圖像視圖的frame和bounds矩形之間的關係。圖中，圖像視圖的右上角被定位在父視圖座標系統的（40， 40），它的矩形尺寸爲240x380。對於bounds矩形，原點是（0， 0），矩形尺寸也是240x380。
Figure 1-5 視圖frame和bounds之間的關係
即使你可以獨立的改變frame，bounds和center屬性，其中一個改變還是會影響到另外兩個屬性：
當你設置了frame屬性，bounds屬性的尺寸值也改變來適應frame矩形的新尺寸。center屬性也會改變爲新frame矩形的中心值。
當你設置了center屬性，frame的原點也會相應的改變。
當你設置了bounds屬性，frame屬性會改變以適應bounds矩形的新尺寸。
視圖的框架默認不會被它的父視圖框架裁剪。這樣的化，任何放置在父視圖外的子視圖都會被完整的解釋。你可以改變這種行爲，改變父視圖的clipsToBounds屬性就可以。不管子視圖是否在視覺上被裁剪，觸屏事件總是發生在目標視圖父視圖的bounds矩形。換句話說，如果觸摸位於父視圖外的那部分視圖，那麼該事件不會被髮送到該視圖。
座標系統轉換矩陣
座標系統轉換矩陣給改變視圖（或者是它的視圖）提供了一個輕鬆和簡易的方法。一個仿射轉換是一個數學矩陣，它指定了在座標系統中的點是怎麼被映射到另一個座標系統中的點。你可以對整個視圖應用仿射轉換，以基於其父視圖來改變視圖的尺寸，位置或者朝向。你也可以在你的繪製代碼中應用仿射轉換，以對已解釋內容的獨立部分實現相同的操控。如何應用仿射轉換是基於這樣的上下文的：
爲了修改整個視圖，可以修改視圖transform屬性的仿射轉換值。
爲了在視圖中的drawRect:方法中修改內容的指定部分，可以修改與當前圖形上下文相關的仿射轉換。
當你想實現動畫時，通常可以修改視圖的transform屬性值。例如，你可以使用這個屬性來製作一個視圖圍繞中心點翻轉的動畫。你不應該在其父視圖的座標空間中用這個屬性來永久的改變你的視圖，像修改它的位置和尺寸。對於這種類型的改變，你可以修改視圖的frame矩形。
注意：當修改視圖的transform屬性值時，所有的轉換都是基於視圖的中心點來實現的。
在視圖的drawRect:方法中，你可以使用仿射轉換來定位或者翻轉你想要繪製的項目。相對於在視圖某些部位中修正對象的位置，我們更傾向於相對於一個固定點去創建對象，通常是（0， 0），同時在繪製之前使用轉換來定位對象。這樣的話，如果在視圖中對象的位置改變了，你要做的只是修改轉換矩陣，這樣比爲對象重新創建新的位置性能更好開銷更低。你可以通過使用CGContextGetCTM方法來獲取關於圖形上下文的仿射轉換，同時可以用Core Graphics的相關方法在繪製中來設置或者修改這個轉換矩陣。
當前轉換矩陣（CTM）是一個在任何時候都被使用的仿射矩陣。當操控整個視圖的幾何結構時，CTM就是視圖transform屬性的值。在drawRect:方法中，CTM是關於圖形上下文的仿射矩陣。
每個子視圖的座標系統都是構建在其祖先的座標系統之上的。所以當你修改一個視圖的transform屬性，這個改變會影響到視圖及其所有的子視圖。然而，這些改變只會影響到屏幕上視圖的最終解釋。因爲每個視圖都負責繪製自己的內容和對自己的子視圖進行佈局，所以在繪製和佈局的過程中它可以忽略父視圖的轉換。
Figure1- 6描述了在解釋的時候，兩個不同的轉換因子是如何在視覺上組合起來的。在視圖的drawRect:方法中，對一個形狀應用一個45度的轉換因子會使該形狀翻轉指定的角度。另外加上一個45度的轉換因子會導致整個形狀翻轉90度。這個形狀對於繪製它的視圖來講仍然只是翻轉了45度，但是視圖自己的轉換讓它看起來像使翻轉了90度。
Figure 1-6 翻轉一個視圖和它的內容
重要：如果一個視圖的transform屬性不是其定義時轉換矩陣，那麼視圖的frame屬性是未定義的而且必須被忽略。當對視圖應用轉換時，你必須使用視圖的bounds和center屬性來獲取視圖的位置和尺寸。子視圖的frame矩形仍然是有效的，因爲它們與視圖的bounds相關。
獲取更多關於在運行時修改視圖的transform屬性，查看 “Translating, Scaling, and Rotating Views.”獲取更多如何在繪製過程中使用轉換來定位內容，查看 Drawing and Printing Guide for iOS.
點與像素
在iOS中，所有的座標值和距離都被指定爲使用浮點數，其單元值稱爲點。點的數量隨着設備的不同而不同，而且彼此不相關。要明白關於點的最主要一點是它們提供了一個繪製用的固定框架。
Table 1-1 列出了不同iOS設備的分辨率（點度量）。前爲寬後爲長。只要你依照這些屏幕的尺寸來設計用戶界面，你的視圖就回被相應的設備正確顯示。
Table 1-1
Device Screen dimensions (in points)
iPhone and iPod touch 320 x 480
iPad 768 x 1024
每一種使用基於點度量系統的設備都定義了一個用戶座標空間。這是幾乎在你所有的代碼都會用到的標準座標空間。例如，當你要操控視圖的幾何結構或者調用Core Graphics方法來繪製內容時會用到點和用戶座標空間。即使有時用戶座標空間裏的座標時直接映射到設備屏幕的像素，你還是永遠不應該假設這是永遠不變的。相反，你應該記住：一個點並不一定對應着屏幕上的一個像素
在設備層面，所有由你指定的視圖上的座標在某些點上必須被轉化成像素。然而，從用戶座標空間上的點到設備座標空間上的像素通常由系統來處理。UIKit和Core Graphics都主要使用基於向量的繪製模型，所有的座標值都被指定爲使用點。這樣，如果你用Core Graphics畫了一條曲線，你會用一些值來指定這條曲線，而不管底層屏幕使用怎樣的解決方法。
當你需要處理圖像或者其他基於像素的技術，像OpenGL ES時，iOS會幫你管理這些像素。對於存儲爲應用程序的束中的資源的靜態圖像文件，iOS定義了一些約定，可以指定不同像素密度的圖像，也可以在加載圖像時最大限度的適應當前屏幕的解決方案。視圖也提供了關於當前放縮因子的信息，以便你可以適當的調整任何基於像素的繪製代碼來適應有更高級解決方案的屏幕。在不同屏幕的解決方案中處理基於像素內容的技術可以在"Supporting High-Resolution Screens"和"Drawing and Printing Guide for iOS"找到描述。
視圖的運行時交互模型
當用戶和界面進行交互時，或者由代碼程序性的改變一些東西時，一系列複雜的事件就會發生在UIKit的內部來處理這些交互。在這個系列中的某些點，UIKit喚出你的視圖類，同時給它們一個機會去響應程序的行爲。理解這些喚出點對於理解視圖在哪裏融入系統很重要。Figure 1-7 展示了這些事件的基本序列，從用戶觸屏開始到圖形系統更新屏幕內容來響應結束。同樣的事件序列也會發生在任何程序性啓動的動作。
Figure 1-7 UIKit 與視圖對象進行交互
以下的步驟分解了圖1－7中的事件序列，既解釋了在每一步發生了什麼，也解釋了應用如何響應
1 用戶觸屏
2 硬件報告觸摸事件給UIKit框架
3 UIKit框架將觸摸事件打包成UIEvent對象，同時分發給適合的視圖。（對於UIKit框架如何提交事件給視圖的詳細解釋，查看 Event Handing Guide for iOS）
4 視圖中的事件處理代碼可能進行以下的動作來響應：
改變視圖或者其子視圖的屬性（frame， bounds， alpha， 等等）
調用setNeedsLayout方法以標記該視圖（或者它的子視圖）爲需要進行佈局更新
調用setNeedsDisplay或者setNeedsDisplayInRect:方法以標記該視圖（或者它的子視圖）需要進行重畫
通知一個控制器關於一些數據的更新
當然，哪些事情要做，哪些方法要被調用是由視圖來決定的。
5 如果一個視圖的幾何結構改變了，UIKit會根據以下幾條規則來更新它的子視圖：
a 如果自動重設尺寸的規則在發生作用，UIKit會根據這些規則來調整視圖。獲取更多關於自動重設尺寸規則如何工作，查看"Handling Layout Changes Automatically Using Autoresizing Rules."
b 如果視圖實現了layoutSubviews方法，UIKit會調用它。你可以在你的定製視圖中覆蓋這個方法同時用它來調整任何子視圖的位置和大小。例如，一個提供了巨大滾動區域的視圖會需要使用幾個子視圖作爲“瓦塊”而不是創建一個不太可能放進內存的巨大視圖。在這個方法的實現中，視圖會隱藏任何屏幕外的子視圖，或者重定位它們然後用來繪製新的可視內容。作爲這個流程的一部分，視圖的佈局代碼也可以廢止任何需要被重畫的視圖。
6 如果任何視圖的任何部分被標記爲需要重畫，UIKit會要求視圖重畫自身。
對於顯式的定義了drawRect:方法的定製視圖，UIKit會調用這個方法。這方法的實現應該儘快重畫視圖的指定區域，並且不應該再做其他事。不要在這個點上做額外的佈局，也不要改變應用的數據模型。提供這個方法僅僅是爲了更新視圖的可視內容。
標準的系統視圖通常不會實現drawRect:方法，但是也會在這個時候管理它們的繪製。
7 任何已經更新的視圖會與應用餘下的可視內容組合在一起，同時被髮送到圖形硬件去顯示。
8 圖形硬件將已解釋內容轉化到屏幕上。
注意：上面的更新模型主要應用於使用標準系統視圖和繪製技術的應用。使用OpenGL ES來繪製的應用通常會配置一個單一的全屏視圖和直接繪製相關的OpenGL圖像上下文。你的視圖還是應該處理觸屏事件，但是它是全屏的，毋需給子視圖佈局或者實現drawRect:方法。獲取更多關於使用OpenGL ES的信息，查看 OpenGL ES Programming Guide for iOS.
給定之前的一系列步驟，將自己的定製視圖整合進去的方法包括：
事件處理方法：
touchesBegan:withEvent:
touchesMoved:withEvent:
touchesEnded:withEvent:
touchesCancelled:withEvent:
layoutSubviews方法
drawRect:方法
這些是視圖的最常用的覆蓋方法，但是你可能不需要覆蓋全部。如果你使用手勢識別來處理事件，你不需要覆蓋事件處理方法。相似的，如果你的視圖沒有包含子視圖或者它的尺寸不會改變，那就沒有理由去覆蓋layoutSubviews方法。最後，只有當視圖內容會在運行時改變，同時你要用UIKit或者Core Graphics等本地技術來繪製時才需要用到drawRect。
要記住這些是主要的整合點，但是不僅僅只有這些。UIView類中有些方法是專門設計來給子類覆蓋的。你應該到UIView Class Reference中查看這些方法的描述，以便在定製時清楚哪些方法適合給你覆蓋。
有效使用視圖的提示
當你需要繪製一些標準系統視圖不能提供的內容時，定製視圖是很有用的。但是你要負責保證視圖的性能要足夠的高。UIKit會盡可能的優化視圖相關的行爲，也會幫助你提高性能。然而，考慮一些提示可以幫助到UIKit。
重要：在調整繪製代碼之前，你應該一直收集與你視圖當前性能有關的數據。估量當前性能讓你可以確定是否真的有問題，同時如果真的有問題，它也提供一個基線，讓你在未來的優化中可以比較。
視圖不會總是有一個相應的視圖控制器
在應用中，視圖和視圖控制器之間的一對一關係是很少見的。視圖控制器的工作是管理一個視圖層次，而視圖層次經常是包含了多個視圖，它們都有自包含特性。對於iPhone應用，每個視圖層次通常都填滿了整個屏幕，儘管對於iPad應用來說不是。
當你設計用戶界面的時候，考慮到視圖控制器的所扮演的角色是很重要的。視圖控制器提供了很多重要的行爲，像協調視圖的展示，協調視圖的剔除，釋放內存以響應低內存警告，還有翻轉視圖以響應界面的方向變更。逃避這些行爲會導致應用發生錯誤。
獲取更多關於視圖控制器的信息，查看 View Controller Programming Guide for iOS
最小化定製的繪畫
儘管定製的繪畫有時是需要的，但是你也應該儘量避免它。真正需要定製繪畫的時候是已有的視圖類無法提供足夠的表現和能力時。任何時候你的內容都應該可以被組裝到其他視圖，最好結果時組合那些視圖對象到定製的視圖層次
利用內容模式
內容模式可以最小化重畫視圖要花費的時間。默認的，視圖使用UIViewContentModeScaleToFill 內容模式，這個模式會放縮視圖的已有內容來填充視圖的frame矩形。需要時你可以改變這個模式來調整你的內容，但是應該避免使用UIViewContentModeRedraw內容模式。不管哪個內容模式發生作用，你都可以調用setNeedsDisplay或者setNeedsDisplayInRect:方法來強制視圖重畫它的內容。
可能的話將視圖聲明爲不透明
UIKit使用opaque屬性來決定它是否可以優化組合操作。將一個定製視圖的這個屬性設置爲YES會告訴UIKit不需要解釋任何在該視圖後的內容。這樣可以爲你的繪製代碼提高性能並且是推薦的。當然，如果你將這個屬性設置爲YES，你的視圖一定要用不透明的內容完全填充它的bounds矩形。
滾動時調整視圖的繪製行爲
滾動會導致數個視圖在短時間內更新。如果視圖的繪製代碼沒有被適當的調整，滾動的性能會非常的緩慢。相對於總是保證視圖內容的平庸，我們更傾向於考慮滾動操作開始時改變視圖行爲。例如，你可以暫時減少已解釋的內容，或者在滾動的時候改變內容模式。當滾動停止時，你可以將視圖返回到前一狀態，同時需要時更新內容。
不要嵌入子視圖來定製控制
儘管在技術上增加子視圖到標準系統控制對象－繼承自UIControl的類－是可行的，你還是永遠不應該用這種方法來定製它們。控制對象支持定製，它們有顯式並且良好歸檔的接口。例如，UIButton類包含了設置標題和背景圖片的方法。使用已定義好的定製點意味着你的代碼總是會正確的工作。不用這些方法，而嵌入一個定製的圖像視圖或者標籤到按鈕中去會導致應用出現未預期的結果。