iOS 動畫

圖層樹、寄宿圖以及圖層幾何學
（一）圖層的樹狀結構

技術交流新QQ羣：414971585

巨妖有圖層，洋蔥也有圖層，你有嗎？咱們都有圖層 -- 史萊克

Core Animation實際上是一個使人誤解的命名。你可能認爲它只是用來作動畫的，但實際上它是從一個叫作Layer Kit這麼一個不怎麼和動畫有關的名字演變而來，因此作動畫這只是Core Animation特性的冰山一角。

Core Animation是一個複合引擎，它的職責就是儘量快地組合屏幕上不一樣的可視內容，這個內容是被分解成獨立的圖層，存儲在一個叫作圖層樹的體系之中。因而這個樹造成了UIKit以及在iOS應用程序當中你所能在屏幕上看見的一切的基礎。

在咱們討論動畫以前，咱們將從圖層樹開始，涉及一下Core Animation的靜態組合以及佈局特性。

圖層和視圖

若是你曾經在iOS或者Mac OS平臺上寫過應用程序，你可能會對視圖的概念比較熟悉。一個視圖就是在屏幕上顯示的一個矩形塊（好比圖片，文字或者視頻），它可以攔截相似於鼠標點擊或者觸摸手勢等用戶輸入。視圖在層級關係中能夠互相嵌套，一個視圖能夠管理它的全部子視圖的位置。圖1.1顯示了一種典型的視圖層級關係

圖1.1 一種典型的iOS屏幕（左邊）和造成視圖的層級關係（右邊）

在iOS當中，全部的視圖都從一個叫作UIVIew的基類派生而來，UIView能夠處理觸摸事件，能夠支持基於Core Graphics繪圖，能夠作仿射變換（例如旋轉或者縮放），或者簡單的相似於滑動或者漸變的動畫。

CALayer

CALayer類在概念上和UIView相似，一樣也是一些被層級關係樹管理的矩形塊，一樣也能夠包含一些內容（像圖片，文本或者背景色），管理子圖層的位置。它們有一些方法和屬性用來作動畫和變換。和UIView最大的不一樣是CALayer不處理用戶的交互。

CALayer並不清楚具體的響應鏈（iOS經過視圖層級關係用來傳送觸摸事件的機制），因而它並不可以響應事件，即便它提供了一些方法來判斷是否一個觸點在圖層的範圍以內（具體見第三章，「圖層的幾何學」）

平行的層級關係

每個UIview都有一個CALayer實例的圖層屬性，也就是所謂的backing layer，視圖的職責就是建立並管理這個圖層，以確保當子視圖在層級關係中添加或者被移除的時候，他們關聯的圖層也一樣對應在層級關係樹當中有相同的操做（見圖1.2）。

圖1.2 圖層的樹狀結構（左邊）以及對應的視圖層級（右邊）

實際上這些背後關聯的圖層纔是真正用來在屏幕上顯示和作動畫，UIView僅僅是對它的一個封裝，提供了一些iOS相似於處理觸摸的具體功能，以及Core Animation底層方法的高級接口。

可是爲何iOS要基於UIView和CALayer提供兩個平行的層級關係呢？爲何不用一個簡單的層級來處理全部事情呢？緣由在於要作職責分離，這樣也能避免不少重複代碼。在iOS和Mac OS兩個平臺上，事件和用戶交互有不少地方的不一樣，基於多點觸控的用戶界面和基於鼠標鍵盤有着本質的區別，這就是爲何iOS有UIKit和UIView，可是Mac OS有AppKit和NSView的緣由。他們功能上很類似，可是在實現上有着顯著的區別。

繪圖，佈局和動畫，相比之下就是相似Mac筆記本和桌面系列同樣應用於iPhone和iPad觸屏的概念。把這種功能的邏輯分開並應用到獨立的Core Animation框架，蘋果就可以在iOS和Mac OS之間共享代碼，使得對蘋果本身的OS開發團隊和第三方開發者去開發兩個平臺的應用更加便捷。

實際上，這裏並非兩個層級關係，而是四個，每個都扮演不一樣的角色，除了視圖層級和圖層樹以外，還存在呈現樹和渲染樹，將在第七章「隱式動畫」和第十二章「性能調優」分別討論。

圖層的能力

若是說CALayer是UIView內部實現細節，那咱們爲何要全面地瞭解它呢？蘋果固然爲咱們提供了優美簡潔的UIView接口，那麼咱們是否就不必直接去處理Core Animation的細節了呢？

某種意義上說的確是這樣，對一些簡單的需求來講，咱們確實不必處理CALayer，由於蘋果已經經過UIView的高級API間接地使得動畫變得很簡單。

可是這種簡單會不可避免地帶來一些靈活上的缺陷。若是你略微想在底層作一些改變，或者使用一些蘋果沒有在UIView上實現的接口功能，這時除了介入Core Animation底層以外別無選擇。

咱們已經證明了圖層不能像視圖那樣處理觸摸事件，那麼他能作哪些視圖不能作的呢？這裏有一些UIView沒有暴露出來的CALayer的功能：

• 陰影，圓角，帶顏色的邊框

• 3D變換

• 非矩形範圍

• 透明遮罩

• 多級非線性動畫

咱們將會在後續章節中探索這些功能，首先咱們要關注一下在應用程序當中CALayer是怎樣被利用起來的。

使用圖層

首先咱們來建立一個簡單的項目，來操縱一些layer的屬性。打開Xcode，使用Single View Application模板建立一個工程。

在屏幕中央建立一個小視圖（大約200 X 200的尺寸），固然你能夠手工編碼，或者使用Interface Builder（隨你方便）。確保你的視圖控制器要添加一個視圖的屬性以即可以直接訪問它。咱們把它稱做layerView。

運行項目，應該能在淺灰色屏幕背景中看見一個白色方塊（圖1.3），若是沒看見，可能須要調整一下背景window或者view的顏色

圖1.3 灰色背景上的一個白色UIView

這並無什麼使人激動的地方，咱們來添加一個色塊，在白色方塊中間添加一個小的藍色塊。

咱們固然能夠簡單地在已經存在的UIView上添加一個子視圖（隨意用代碼或者IB），但這不能真正學到任何關於圖層的東西。

因而咱們來建立一個CALayer，而且把它做爲咱們視圖相關圖層的子圖層。儘管UIView類的接口中暴露了圖層屬性，可是標準的Xcode項目模板並無包含Core Animation相關頭文件。因此若是咱們不給項目添加合適的庫，是不可以使用任何圖層相關的方法或者訪問它的屬性。因此首先須要添加QuartzCore框架到Build Phases標籤（圖1.4），而後在vc的.m文件中引入庫。

圖1.4 把QuartzCore庫添加到項目

以後就能夠在代碼中直接引用CALayer的屬性和方法。在清單1.1中，咱們用建立了一個CALayer，設置了它的backgroundColor屬性，而後添加到layerView背後相關圖層的子圖層（這段代碼的前提是經過IB建立了layerView並作好了鏈接），圖1.5顯示告終果。

清單1.1 給視圖添加一個藍色子圖層

#import "ViewController.h"
#import
@interface ViewController ()
@property (nonatomic, weak) IBOutlet UIView *layerView;
?
@end
@implementation ViewController
- (void)viewDidLoad
{
    [super viewDidLoad];
    //create sublayer
    CALayer *blueLayer = [CALayer layer];
    blueLayer.frame = CGRectMake(50.0f, 50.0f, 100.0f, 100.0f);
    blueLayer.backgroundColor = [UIColor blueColor].CGColor;
    //add it to our view
    [self.layerView.layer addSublayer:blueLayer];
}
@end

圖1.5 白色UIView內部嵌套的藍色CALayer

一個視圖只有一個相關聯的圖層（自動建立），同時它也能夠支持添加無數多個子圖層，從清單1.1能夠看出，你能夠顯示建立一個單獨的圖層，而且把它直接添加到視圖關聯圖層的子圖層。儘管能夠這樣添加圖層，但每每咱們只是見簡單地處理視圖，他們關聯的圖層並不須要額外地手動添加子圖層。

在Mac OS平臺，10.8版本以前，一個顯著的性能缺陷就是因爲用了視圖層級而不是單獨在一個視圖內使用CALayer樹狀層級。可是在iOS平臺，使用輕量級的UIView類並無顯著的性能影響（固然在Mac OS 10.8以後，NSView的性能一樣也獲得很大程度的提升）。

使用圖層關聯的視圖而不是CALayer的好處在於，你能在使用全部CALayer底層特性的同時，也可使用UIView的高級API（好比自動排版，佈局和事件處理）。

然而，當知足如下條件的時候，你可能更須要使用CALayer而不是UIView

• 開發同時能夠在Mac OS上運行的跨平臺應用

• 使用多種CALayer的子類（見第六章，「特殊的圖層「），而且不想建立額外的UIView去包封裝它們全部

• 作一些對性能特別挑剔的工做，好比對UIView一些可忽略不計的操做都會引發顯著的不一樣（儘管如此，你可能會直接想使用OpenGL繪圖）

可是這些例子都不多見，總的來講，處理視圖會比單獨處理圖層更加方便。

總結

這一章闡述了圖層的樹狀結構，說明了如何在iOS中由UIView的層級關係造成的一種平行的CALayer層級關係，在後面的實驗中，咱們建立了本身的CALayer，並把它添加到圖層樹中。

在第二章，「圖層關聯的圖片」，咱們將要研究一下CALayer關聯的圖片，以及Core Animation提供的操做顯示的一些特性。
--------------------------------------------------------------------------------------------------------------------------------------------------------

（二）寄宿圖

圖片賽過千言萬語，界面抵得上千圖片 ——Ben Shneiderman

咱們在第一章『圖層樹』中介紹了CALayer類並建立了一個簡單的有藍色背景的圖層。背景顏色還好啦，可是若是它僅僅是展示了一個單調的顏色未免也太無聊了。事實上CALayer類可以包含一張你喜歡的圖片，這一章節咱們未來探索CALayer的寄宿圖（即圖層中包含的圖）。

contents屬性

CALyer 有一個屬性叫作contents，這個屬性的類型被定義爲id，意味着它能夠是任何類型的對象。在這種狀況下，你能夠給contents屬性賦任何值，你的app仍然可以編譯經過。可是，在實踐中，若是你給contents賦的不是CGImage，那麼你獲得的圖層將是空白的。

contents這個奇怪的表現是由Mac OS的歷史緣由形成的。它之因此被定義爲id類型，是由於在Mac OS系統上，這個屬性對CGImage和NSImage類型的值都起做用。若是你試圖在iOS平臺上將UIImage的值賦給它，只能獲得一個空白的圖層。一些初識Core Animation的iOS開發者可能會對這個感到困惑。

頭疼的不只僅是咱們剛纔提到的這個問題。事實上，你真正要賦值的類型應該是CGImageRef，它是一個指向CGImage結構的指針。UIImage有一個CGImage屬性，它返回一個"CGImageRef",若是你想把這個值直接賦值給CALayer的contents，那你將會獲得一個編譯錯誤。由於CGImageRef並非一個真正的Cocoa對象，而是一個Core Foundation類型。

儘管Core Foundation類型跟Cocoa對象在運行時貌似很像（被稱做toll-free bridging），他們並非類型兼容的，不過你能夠經過bridged關鍵字轉換。若是要給圖層的寄宿圖賦值，你能夠按照如下這個方法：

layer.contents = (__bridge id)image.CGImage;

若是你沒有使用ARC（自動引用計數），你就不須要__bridge這部分。可是，你幹嗎不用ARC？！

讓咱們來繼續修改咱們在第一章新建的工程，以便可以展現一張圖片而不只僅是一個背景色。咱們已經用代碼的方式創建一個圖層，那咱們就不須要額外的圖層了。那麼咱們就直接把layerView的宿主圖層的contents屬性設置成圖片。

清單2.1 更新後的代碼。

@implementation ViewController
- (void)viewDidLoad
{
  [super viewDidLoad]; //load an image
  UIImage *image = [UIImage imageNamed:@"Snowman.png"];
  //add it directly to our view's layer
  self.layerView.layer.contents = (__bridge id)image.CGImage;
}
@end

圖表2.1 在UIView的宿主圖層中顯示一張圖片

咱們用這些簡單的代碼作了一件頗有趣的事情：咱們利用CALayer在一個普通的UIView中顯示了一張圖片。這不是一個UIImageView，它不是咱們一般用來展現圖片的方法。經過直接操做圖層，咱們使用了一些新的函數，使得UIView更加有趣了。

contentGravity

你可能已經注意到了咱們的雪人看起來有點。。。胖 ＝＝！ 咱們加載的圖片並不恰好是一個方的，爲了適應這個視圖，它有一點點被拉伸了。在使用UIImageView的時候遇到過一樣的問題，解決方法就是把contentMode屬性設置成更合適的值，像這樣：

view.contentMode = UIViewContentModeScaleAspectFit;

這個方法基本和咱們遇到的狀況的解決方法已經接近了（你能夠試一下 :) ），不過UIView大多數視覺相關的屬性好比contentMode，對這些屬性的操做實際上是對對應圖層的操做。

CALayer與contentMode對應的屬性叫作contentsGravity，可是它是一個NSString類型，而不是像對應的UIKit部分，那裏面的值是枚舉。contentsGravity可選的常量值有如下一些：

kCAGravityCenter
kCAGravityTop
kCAGravityBottom
kCAGravityLeft
kCAGravityRight
kCAGravityTopLeft
kCAGravityTopRight
kCAGravityBottomLeft
kCAGravityBottomRight
kCAGravityResize
kCAGravityResizeAspect
kCAGravityResizeAspectFill

和cotentMode同樣，contentsGravity的目的是爲了決定內容在圖層的邊界中怎麼對齊，咱們將使用kCAGravityResizeAspect，它的效果等同於UIViewContentModeScaleAspectFit， 同時它還能在圖層中等比例拉伸以適應圖層的邊界。

self.layerView.layer.contentsGravity = kCAGravityResizeAspect;

圖2.2 能夠看到結果

圖2.2 正確地設置contentsGravity的值

contentsScale

contentsScale屬性定義了寄宿圖的像素尺寸和視圖大小的比例，默認狀況下它是一個值爲1.0的浮點數。

contentsScale的目的並非那麼明顯。它並非總會對屏幕上的寄宿圖有影響。若是你嘗試對咱們的例子設置不一樣的值，你就會發現根本沒任何影響。由於contents因爲設置了contentsGravity屬性，因此它已經被拉伸以適應圖層的邊界。

若是你只是單純地想放大圖層的contents圖片，你能夠經過使用圖層的transform和affineTransform屬性來達到這個目的（見第五章『Transforms』，裏面對此有解釋），這(指放大)也不是contengsScale的目的所在.

contentsScale屬性其實屬於支持高分辨率（又稱Hi-DPI或Retina）屏幕機制的一部分。它用來判斷在繪製圖層的時候應該爲寄宿圖建立的空間大小，和須要顯示的圖片的拉伸度（假設並無設置contentsGravity屬性）。UIView有一個相似功能可是很是少用到的contentScaleFactor屬性。

若是contentsScale設置爲1.0，將會以每一個點1個像素繪製圖片，若是設置爲2.0，則會以每一個點2個像素繪製圖片，這就是咱們熟知的Retina屏幕。（若是你對像素和點的概念不是很清楚的話，這個章節的後面部分將會對此作出解釋）。

這並不會對咱們在使用kCAGravityResizeAspect時產生任何影響，由於它就是拉伸圖片以適應圖層而已，根本不會考慮到分辨率問題。可是若是咱們把contentsGravity設置爲kCAGravityCenter（這個值並不會拉伸圖片），那將會有很明顯的變化（如圖2.3）

圖2.3 用錯誤的contentsScale屬性顯示Retina圖片

如你所見，咱們的雪人不只有點大還有點像素的顆粒感。那是由於和UIImage不一樣，CGImage沒有拉伸的概念。當咱們使用UIImage類去讀取咱們的雪人圖片的時候，他讀取了高質量的Retina版本的圖片。可是當咱們用CGImage來設置咱們的圖層的內容時，拉伸這個因素在轉換的時候就丟失了。不過咱們能夠經過手動設置contentsScale來修復這個問題（如2.2清單），圖2.4是結果

@implementation ViewController
- (void)viewDidLoad
{
  [super viewDidLoad]; //load an image
  UIImage *image = [UIImage imageNamed:@"Snowman.png"]; //add it directly to our view's layer
  self.layerView.layer.contents = (__bridge id)image.CGImage; //center the image
  self.layerView.layer.contentsGravity = kCAGravityCenter;
  //set the contentsScale to match image
  self.layerView.layer.contentsScale = image.scale;
}
@end

圖2.4 一樣的Retina圖片設置了正確的contentsScale以後

當用代碼的方式來處理寄宿圖的時候，必定要記住要手動的設置圖層的contentsScale屬性，不然，你的圖片在Retina設備上就顯示得不正確啦。代碼以下：

layer.contentsScale = [UIScreen mainScreen].scale;

maskToBounds

如今咱們的雪人總算是顯示了正確的大小，不過你也許已經發現了另一些事情：他超出了視圖的邊界。默認狀況下，UIView仍然會繪製超過邊界的內容或是子視圖，在CALayer下也是這樣的。

UIView有一個叫作clipsToBounds的屬性能夠用來決定是否顯示超出邊界的內容，CALayer對應的屬性叫作masksToBounds，把它設置爲YES，雪人就在邊界裏啦～（如圖2.5）

圖2.5 使用masksToBounds來修建圖層內容

contentsRect

CALayer的contentsRect屬性容許咱們在圖層邊框裏顯示寄宿圖的一個子域。這涉及到圖片是如何顯示和拉伸的，因此要比contentsGravity靈活多了

和bounds，frame不一樣，contentsRect不是按點來計算的，它使用了單位座標，單位座標指定在0到1之間，是一個相對值（像素和點就是絕對值）。因此他們是相對與寄宿圖的尺寸的。iOS使用瞭如下的座標系統：

• 點 —— 在iOS和Mac OS中最多見的座標體系。點就像是虛擬的像素，也被稱做邏輯像素。在標準設備上，一個點就是一個像素，可是在Retina設備上，一個點等於2*2個像素。iOS用點做爲屏幕的座標測算體系就是爲了在Retina設備和普通設備上能有一致的視覺效果。

• 像素 —— 物理像素座標並不會用來屏幕布局，可是仍然與圖片有相對關係。UIImage是一個屏幕分辨率解決方案，因此指定點來度量大小。可是一些底層的圖片表示如CGImage就會使用像素，因此你要清楚在Retina設備和普通設備上，他們表現出來了不一樣的大小。

• 單位 —— 對於與圖片大小或是圖層邊界相關的顯示，單位座標是一個方便的度量方式， 當大小改變的時候，也不須要再次調整。單位座標在OpenGL這種紋理座標系統中用得不少，Core Animation中也用到了單位座標。

默認的contentsRect是{0, 0, 1, 1}，這意味着整個寄宿圖默認都是可見的，若是咱們指定一個小一點的矩形，圖片就會被裁剪（如圖2.6）

圖2.6 一個自定義的contentsRect（左）和以前顯示的內容（右）

事實上給contentsRect設置一個負數的原點或是大於{1, 1}的尺寸也是能夠的。這種狀況下，最外面的像素會被拉伸以填充剩下的區域。

contentsRect在app中最有趣的地方在於一個叫作image sprites（圖片拼合）的用法。若是你有遊戲編程的經驗，那麼你必定對圖片拼合的概念很熟悉，圖片可以在屏幕上獨立地變動位置。拋開遊戲編程不談，這個技術經常使用來指代載入拼合的圖片，跟移動圖片一點關係也沒有。

典型地，圖片拼合後能夠打包整合到一張大圖上一次性載入。相比屢次載入不一樣的圖片，這樣作可以帶來不少方面的好處：內存使用，載入時間，渲染性能等等

2D遊戲引擎入Cocos2D使用了拼合技術，它使用OpenGL來顯示圖片。不過咱們可使用拼合在一個普通的UIKit應用中，對！就是使用contentsRect

首先，咱們須要一個拼合後的圖表 —— 一個包含小一些的拼合圖的大圖片。如圖2.7所示：

接下來，咱們要在app中載入並顯示這些拼合圖。規則很簡單：像日常同樣載入咱們的大圖，而後把它賦值給四個獨立的圖層的contents，而後設置每一個圖層的contentsRect來去掉咱們不想顯示的部分。

咱們的工程中須要一些額外的視圖。（爲了不太多代碼。咱們將使用Interface Builder來拜訪他們的位置，若是你願意仍是能夠用代碼的方式來實現的）。清單2.3有須要的代碼，圖2.8展現告終果

@interface ViewController ()
@property (nonatomic, weak) IBOutlet UIView *coneView;
@property (nonatomic, weak) IBOutlet UIView *shipView;
@property (nonatomic, weak) IBOutlet UIView *iglooView;
@property (nonatomic, weak) IBOutlet UIView *anchorView;
@end
@implementation ViewController
- (void)addSpriteImage:(UIImage *)image withContentRect:(CGRect)rect ?toLayer:(CALayer *)layer //set image
{
  layer.contents = (__bridge id)image.CGImage;
  //scale contents to fit
  layer.contentsGravity = kCAGravityResizeAspect;
  //set contentsRect
  layer.contentsRect = rect;
}
- (void)viewDidLoad 
{
  [super viewDidLoad]; //load sprite sheet
  UIImage *image = [UIImage imageNamed:@"Sprites.png"];
  //set igloo sprite
  [self addSpriteImage:image withContentRect:CGRectMake(0, 0, 0.5, 0.5) toLayer:self.iglooView.layer];
  //set cone sprite
  [self addSpriteImage:image withContentRect:CGRectMake(0.5, 0, 0.5, 0.5) toLayer:self.coneView.layer];
  //set anchor sprite
  [self addSpriteImage:image withContentRect:CGRectMake(0, 0.5, 0.5, 0.5) toLayer:self.anchorView.layer];
  //set spaceship sprite
  [self addSpriteImage:image withContentRect:CGRectMake(0.5, 0.5, 0.5, 0.5) toLayer:self.shipView.layer];
}
@end

拼合不只給app提供了一個整潔的載入方式，還有效地提升了載入性能（單張大圖比多張小圖載入地更快），可是若是有手動安排的話，他們仍是有一些不方便的，若是你須要在一個已經建立好的品和圖上作一些尺寸上的修改或者其餘變更，無疑是比較麻煩的。

Mac上有一些商業軟件能夠爲你自動拼合圖片，這些工具自動生成一個包含拼合後的座標的XML或者plist文件，拼合圖片的使用大大簡化。這個文件能夠和圖片一同載入，並給每一個拼合的圖層設置contentsRect，這樣開發者就不用手動寫代碼來擺放位置了。

這些文件一般在OpenGL遊戲中使用，不過呢，你要是有興趣在一些常見的app中使用拼合技術，那麼一個叫作LayerSprites的開源庫（https://github.com/nicklockwood/LayerSprites)，它可以讀取Cocos2D格式中的拼合圖並在普通的Core Animation層中顯示出來。

contentsCenter

本章咱們介紹的最後一個和內容有關的屬性是contentsCenter，看名字你可能會覺得它可能跟圖片的位置有關，不過這名字着實誤導了你。contentsCenter實際上是一個CGRect，它定義了一個固定的邊框和一個在圖層上可拉伸的區域。 改變contentsCenter的值並不會影響到寄宿圖的顯示，除非這個圖層的大小改變了，你纔看獲得效果。

默認狀況下，contentsCenter是{0, 0, 1, 1}，這意味着若是大小（由conttensGravity決定）改變了,那麼寄宿圖將會均勻地拉伸開。可是若是咱們增長原點的值並減少尺寸。咱們會在圖片的周圍創造一個邊框。圖2.9展現了contentsCenter設置爲{0.25, 0.25, 0.5, 0.5}的效果。

圖2.9 contentsCenter的例子

這意味着咱們能夠隨意重設尺寸，邊框仍然會是連續的。他工做起來的效果和UIImage裏的-resizableImageWithCapInsets: 方法效果很是相似，只是它能夠運用到任何寄宿圖，甚至包括在Core Graphics運行時繪製的圖形（本章稍後會講到）。

圖2.10 同一圖片使用不一樣的contentsCenter

清單2.4 演示瞭如何編寫這些可拉伸視圖。不過，contentsCenter的另外一個很酷的特性就是，它能夠在Interface Builder裏面配置，根本不用寫代碼。如圖2.11

清單2.4 用contentsCenter設置可拉伸視圖

@interface ViewController ()
@property (nonatomic, weak) IBOutlet UIView *button1;
@property (nonatomic, weak) IBOutlet UIView *button2;
@end
@implementation ViewController
- (void)addStretchableImage:(UIImage *)image withContentCenter:(CGRect)rect toLayer:(CALayer *)layer
{  
  //set image
  layer.contents = (__bridge id)image.CGImage;
  //set contentsCenter
  layer.contentsCenter = rect;
}
- (void)viewDidLoad
{
  [super viewDidLoad]; //load button image
  UIImage *image = [UIImage imageNamed:@"Button.png"];
  //set button 1
  [self addStretchableImage:image withContentCenter:CGRectMake(0.25, 0.25, 0.5, 0.5) toLayer:self.button1.layer];
  //set button 2
  [self addStretchableImage:image withContentCenter:CGRectMake(0.25, 0.25, 0.5, 0.5) toLayer:self.button2.layer];
}
@end

圖2.11 用Interface Builder 探測窗口控制contentsCenter屬性

Custome Drawing

給contents賦CGImage的值不是惟一的設置寄宿圖的方法。咱們也能夠直接用Core Graphics直接繪製寄宿圖。可以經過繼承UIView並實現-drawRect:方法來自定義繪製。

-drawRect: 方法沒有默認的實現，由於對UIView來講，寄宿圖並非必須的，它不在乎那究竟是單調的顏色仍是有一個圖片的實例。若是UIView檢測到-drawRect: 方法被調用了，它就會爲視圖分配一個寄宿圖，這個寄宿圖的像素尺寸等於視圖大小乘以 contentsScale的值。

若是你不須要寄宿圖，那就不要建立這個方法了，這會形成CPU資源和內存的浪費，這也是爲何蘋果建議：若是沒有自定義繪製的任務就不要在子類中寫一個空的-drawRect:方法。

當視圖在屏幕上出現的時候 -drawRect:方法就會被自動調用。-drawRect:方法裏面的代碼利用Core Graphics去繪製一個寄宿圖，而後內容就會被緩存起來直到它須要被更新（一般是由於開發者調用了-setNeedsDisplay方法，儘管影響到表現效果的屬性值被更改時，一些視圖類型會被自動重繪，如bounds屬性）。雖然-drawRect:方法是一個UIView方法，事實上都是底層的CALayer安排了重繪工做和保存了所以產生的圖片。

CALayer有一個可選的delegate屬性，實現了CALayerDelegate協議，當CALayer須要一個內容特定的信息時，就會從協議中請求。CALayerDelegate是一個非正式協議，其實就是說沒有CALayerDelegate @protocol可讓你在類裏面引用啦。你只須要調用你想調用的方法，CALayer會幫你作剩下的。（delegate屬性被聲明爲id類型，全部的代理方法都是可選的）。

當須要被重繪時，CALayer會請求它的代理給他一個寄宿圖來顯示。它經過調用下面這個方法作到的:

(void)displayLayer:(CALayerCALayer *)layer;

趁着這個機會，若是代理想直接設置contents屬性的話，它就能夠這麼作，否則沒有別的方法能夠調用了。若是代理不實現-displayLayer:方法，CALayer就會轉而嘗試調用下面這個方法：

- (void)drawLayer:(CALayer *)layer inContext:(CGContextRef)ctx;

在調用這個方法以前，CALayer建立了一個合適尺寸的空寄宿圖（尺寸由bounds和contentsScale決定）和一個Core Graphics的繪製上下文環境，爲繪製寄宿圖作準備，他做爲ctx參數傳入。

讓咱們來繼續第一章的項目讓它實現CALayerDelegate並作一些繪圖工做吧（見清單2.5）.圖2.12是他的結果

清單2.5 實現CALayerDelegate

@implementation ViewController
- (void)viewDidLoad
{
  [super viewDidLoad];
  ?
  //create sublayer
  CALayer *blueLayer = [CALayer layer];
  blueLayer.frame = CGRectMake(50.0f, 50.0f, 100.0f, 100.0f);
  blueLayer.backgroundColor = [UIColor blueColor].CGColor;
  //set controller as layer delegate
  blueLayer.delegate = self;
  //ensure that layer backing image uses correct scale
  blueLayer.contentsScale = [UIScreen mainScreen].scale; //add layer to our view
  [self.layerView.layer addSublayer:blueLayer];
  //force layer to redraw
  [blueLayer display];
}
- (void)drawLayer:(CALayer *)layer inContext:(CGContextRef)ctx
{
  //draw a thick red circle
  CGContextSetLineWidth(ctx, 10.0f); 
  CGContextSetStrokeColorWithColor(ctx, [UIColor redColor].CGColor);
  CGContextStrokeEllipseInRect(ctx, layer.bounds);
}
@end

圖2.12 實現CALayerDelegate來繪製圖層

注意一下一些有趣的事情：

• 咱們在blueLayer上顯式地調用了-display。不一樣於UIView，當圖層顯示在屏幕上時，CALayer不會自動重繪它的內容。它把重繪的決定權交給了開發者。

• 儘管咱們沒有用masksToBounds屬性，繪製的那個圓仍然沿邊界被裁剪了。這是由於當你使用CALayerDelegate繪製寄宿圖的時候，並無對超出邊界外的內容提供繪製支持。

如今你理解了CALayerDelegate，並知道怎麼使用它。可是除非你建立了一個單獨的圖層，你幾乎沒有機會用到CALayerDelegate協議。由於當UIView建立了它的宿主圖層時，它就會自動地把圖層的delegate設置爲它本身，並提供了一個-displayLayer:的實現，那全部的問題就都沒了。

當使用寄宿了視圖的圖層的時候，你也沒必要實現-displayLayer:和-drawLayer:inContext:方法咦繪製你的寄宿圖。一般作法是實現UIView的-drawRect:方法，UIView就會幫你作完剩下的工做，包括在須要重繪的時候調用-display方法。

總結

本章介紹了寄宿圖和一些相關的屬性。你學到了如何顯示和放置圖片， 使用拼合技術來顯示， 以及用CALayerDelegate和Core Graphics來繪製圖層內容。

在第三章，"圖層幾何學"中，咱們將會探討一下圖層的幾何，觀察他們是如何放置和改變相互的尺寸的。
--------------------------------------------------------------------------------------------------------------------------------------------------------

（三）圖層幾何學

不熟悉幾何學的人就不要來這裏了 --柏拉圖學院入口的簽名

在第二章裏面，咱們介紹了圖層背後的圖片，和一些控制圖層座標和旋轉的屬性。在這一章中，咱們將要看一看圖層內部是如何根據父圖層和兄弟圖層來控制位置和尺寸的。另外咱們也會涉及如何管理圖層的幾何結構，以及它是如何被自動調整和自動佈局影響的。

佈局

UIView有三個比較重要的佈局屬性：frame，bounds和center，CALayer對應地叫作frame，bounds和position。爲了能清楚區分，圖層用了「position」，視圖用了「center」，可是他們都表明一樣的值。

frame表明了圖層的外部座標（也就是在父圖層上佔據的空間），bounds是內部座標（{0, 0}一般是圖層的左上角），center和position都表明了相對於父圖層anchorPoint所在的位置。anchorPoint的屬性將會在後續介紹到，如今把它想成圖層的中心點就行了。圖3.1顯示了這些屬性是如何相互依賴的。

圖3.1 UIView和CALayer的座標系

視圖的frame，bounds和center屬性僅僅是存取方法，當操縱視圖的frame，其實是在改變位於視圖下方CALayer的frame，不可以獨立於圖層以外改變視圖的frame。

對於視圖或者圖層來講，frame並非一個很是清晰的屬性，它實際上是一個虛擬屬性，是根據bounds，position和transform計算而來，因此當其中任何一個值發生改變，frame都會變化。相反，改變frame的值一樣會影響到他們當中的值

記住當對圖層作變換的時候，好比旋轉或者縮放，frame實際上表明瞭覆蓋在圖層旋轉以後的整個軸對齊的矩形區域，也就是說frame的寬高可能和bounds的寬高再也不一致了（圖3.2）

圖3.2 旋轉一個視圖或者圖層以後的frame屬性

錨點

以前提到過，視圖的center屬性和圖層的position屬性都指定了相對於父圖層anchorPoint的位置。圖層的anchorPoint經過position來控制它的frame的位置，你能夠認爲anchorPoint是用來移動圖層的把柄。

默認來講，anchorPoint位於圖層的中點，因此圖層的將會以這個點爲中心放置。anchorPoint屬性並無被UIView接口暴露出來，這也是視圖的position屬性被叫作「center」的緣由。可是圖層的anchorPoint能夠被移動，好比你能夠把它置於圖層frame的左上角，因而圖層的內容將會向右下角的position方向移動（圖3.3），而不是居中了。

圖3.3 改變anchorPoint的效果

和第二章提到的contentsRect和contentsCenter屬性相似，anchorPoint用單位座標來描述，也就是圖層的相對座標，圖層左上角是{0, 0}，右下角是{1, 1}，所以默認座標是{0.5, 0.5}。anchorPoint能夠經過指定x和y值小於0或者大於1，使它放置在圖層範圍以外。

注意在圖3.3中，當改變了anchorPoint，position屬性保持固定的值並無發生改變，可是frame卻移動了。

那在什麼場合須要改變anchorPoint呢？既然咱們能夠隨意改變圖層位置，那改變anchorPoint不會形成困惑麼？爲了舉例說明，咱們來舉一個實用的例子，建立一個模擬鬧鐘的項目。

鐘面和鐘錶由四張圖片組成（圖3.4），爲了簡單說明，咱們仍是用傳統的方式來裝載和加載圖片，使用四個UIImageView實例（固然你也能夠用正常的視圖，設置他們圖層的contents圖片）。

圖3.4 組成鐘面和鐘錶的四張圖片

鬧鐘的組件經過IB來排列（圖3.5），這些圖片視圖嵌套在一個容器視圖以內，而且自動調整和自動佈局都被禁用了。這是由於自動調整會影響到視圖的frame，而根據圖3.2的演示，當視圖旋轉的時候，frame是會發生改變的，這將會致使一些佈局上的失靈。

咱們用NSTimer來更新鬧鐘，使用視圖的transform屬性來旋轉鐘錶（若是你對這個屬性不太熟悉，不要着急，咱們將會在第5章「變換」當中詳細說明），具體代碼見清單3.1

圖3.5 在Interface Builder中佈局鬧鐘視圖

清單3.1 Clock

@interface ViewController ()
@property (nonatomic, weak) IBOutlet UIImageView *hourHand;
@property (nonatomic, weak) IBOutlet UIImageView *minuteHand;
@property (nonatomic, weak) IBOutlet UIImageView *secondHand;
@property (nonatomic, weak) NSTimer *timer;
@end
@implementation ViewController
- (void)viewDidLoad
{
    [super viewDidLoad];
    //start timer
    self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(tick) userInfo:nil repeats:YES];
                  ?
    //set initial hand positions
    [self tick];
}
- (void)tick
{
    //convert time to hours, minutes and seconds
    NSCalendar *calendar = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar];
    NSUInteger units = NSHourCalendarUnit | NSMinuteCalendarUnit | NSSecondCalendarUnit;
    NSDateComponents *components = [calendar components:units fromDate:[NSDate date]];
    CGFloat hoursAngle = (components.hour / 12.0) * M_PI * 2.0;
    //calculate hour hand angle //calculate minute hand angle
    CGFloat minsAngle = (components.minute / 60.0) * M_PI * 2.0;
    //calculate second hand angle
    CGFloat secsAngle = (components.second / 60.0) * M_PI * 2.0;
    //rotate hands
    self.hourHand.transform = CGAffineTransformMakeRotation(hoursAngle);
    self.minuteHand.transform = CGAffineTransformMakeRotation(minsAngle);
    self.secondHand.transform = CGAffineTransformMakeRotation(secsAngle);
}
@end

運行項目，看起來有點奇怪（圖3.6），由於鐘錶的圖片在圍繞着中心旋轉，這並非咱們期待的一個支點。

圖3.6 鐘面，和不對齊的鐘指針

你也許會認爲能夠在Interface Builder當中調整指針圖片的位置來解決，但其實並不能達到目的，由於若是不放在鐘面中間的話，一樣不能正確的旋轉。

也許在圖片末尾添加一個透明空間也是個解決方案，但這樣會讓圖片變大，也會消耗更多的內存，這樣並不優雅。

更好的方案是使用anchorPoint屬性，咱們來在-viewDidLoad方法中添加幾行代碼來給每一個鐘指針的anchorPoint作一些平移（清單3.2），圖3.7顯示了正確的結果。

清單3.2

- (void)viewDidLoad 
{
    [super viewDidLoad];
    // adjust anchor points
    self.secondHand.layer.anchorPoint = CGPointMake(0.5f, 0.9f); 
    self.minuteHand.layer.anchorPoint = CGPointMake(0.5f, 0.9f); 
    self.hourHand.layer.anchorPoint = CGPointMake(0.5f, 0.9f);
    // start timer
}

圖3.7 鐘面，和正確對齊的鐘指針

座標系

和視圖同樣，圖層在圖層樹當中也是相對於父圖層按層級關係放置，一個圖層的position依賴於它父圖層的bounds，若是父圖層發生了移動，它的全部子圖層也會跟着移動。

這樣對於放置圖層會更加方便，由於你能夠經過移動根圖層來將它的子圖層做爲一個總體來移動，可是有時候你須要知道一個圖層的絕對位置，或者是相對於另外一個圖層的位置，而不是它當前父圖層的位置。

CALayer給不一樣座標系之間的圖層轉換提供了一些工具類方法：

- (CGPoint)convertPoint:(CGPoint)point fromLayer:(CALayer *)layer; 
- (CGPoint)convertPoint:(CGPoint)point toLayer:(CALayer *)layer; 
- (CGRect)convertRect:(CGRect)rect fromLayer:(CALayer *)layer;
- (CGRect)convertRect:(CGRect)rect toLayer:(CALayer *)layer;

這些方法能夠把定義在一個圖層座標系下的點或者矩形轉換成另外一個圖層座標系下的點或者矩形

翻轉的幾何結構

常規說來，在iOS上，一個圖層的position位於父圖層的左上角，可是在Mac OS上，一般是位於左下角。Core Animation能夠經過geometryFlipped屬性來適配這兩種狀況，它決定了一個圖層的座標是否相對於父圖層垂直翻轉，是一個BOOL類型。在iOS上經過設置它爲YES意味着它的子圖層將會被垂直翻轉，也就是將會沿着底部排版而不是一般的頂部（它的全部子圖層也同理，除非把它們的geometryFlipped屬性也設爲YES）。

Z座標軸

和UIView嚴格的二維座標系不一樣，CALayer存在於一個三維空間當中。除了咱們已經討論過的position和anchorPoint屬性以外，CALayer還有另外兩個屬性，zPosition和anchorPointZ，兩者都是在Z軸上描述圖層位置的浮點類型。

注意這裏並無更深的屬性來描述由寬和高作成的bounds了，圖層是一個徹底扁平的對象，你能夠把它們想象成相似於一頁二維的堅硬的紙片，用膠水粘成一個空洞，就像三維結構的摺紙同樣。

zPosition屬性在大多數狀況下其實並不經常使用。在第五章，咱們將會涉及CATransform3D，你會知道如何在三維空間移動和旋轉圖層，除了作變換以外，zPosition最實用的功能就是改變圖層的顯示順序了。

一般，圖層是根據它們子圖層的sublayers出現的順序來類繪製的，這就是所謂的畫家的算法--就像一個畫家在牆上做畫--後被繪製上的圖層將會遮蓋住以前的圖層，可是經過增長圖層的zPosition，就能夠把圖層向相機方向前置，因而它就在全部其餘圖層的前面了（或者至少是小於它的zPosition值的圖層的前面）。

這裏所謂的「相機」其實是相對於用戶是視角，這裏和iPhone背後的內置相機沒任何關係。

圖3.8顯示了在Interface Builder內的一對視圖，正如你所見，首先出如今視圖層級綠色的視圖被繪製在紅色視圖的後面。

圖3.8 在視圖層級中綠色視圖被繪製在紅色視圖的後面

咱們但願在真實的應用中也能顯示出繪圖的順序，一樣地，若是咱們提升綠色視圖的zPosition（清單3.3），咱們會發現順序就反了（圖3.9）。其實並不須要增長太多，視圖都很是地薄，因此給zPosition提升一個像素就可讓綠色視圖前置，固然0.1或者0.0001也可以作到，可是最好不要這樣，由於浮點類型四捨五入的計算可能會形成一些不便的麻煩。

清單3.3

@interface ViewController ()
@property (nonatomic, weak) IBOutlet UIView *greenView;
@property (nonatomic, weak) IBOutlet UIView *redView;
@end
@implementation ViewController
- (void)viewDidLoad
{
    [super viewDidLoad];
    ?
    //move the green view zPosition nearer to the camera
    self.greenView.layer.zPosition = 1.0f;
}
@end

圖3.9 綠色視圖被繪製在紅色視圖的前面

Hit Testing

第一章「圖層樹」證明了最好使用圖層相關視圖，而不是建立獨立的圖層關係。其中一個緣由就是要處理額外複雜的觸摸事件。

CALayer並不關心任何響應鏈事件，因此不能直接處理觸摸事件或者手勢。可是它有一系列的方法幫你處理事件：-containsPoint:和-hitTest:。

-containsPoint:接受一個在本圖層座標系下的CGPoint，若是這個點在圖層frame範圍內就返回YES。如清單3.4所示第一章的項目的另外一個合適的版本，也就是使用-containsPoint:方法來判斷究竟是白色仍是藍色的圖層被觸摸了 （圖3.10）。這須要把觸摸座標轉換成每一個圖層座標系下的座標，結果很不方便。

清單3.4 使用containsPoint判斷被點擊的圖層

@interface ViewController ()
@property (nonatomic, weak) IBOutlet UIView *layerView;
@property (nonatomic, weak) CALayer *blueLayer;
@end
@implementation ViewController
- (void)viewDidLoad
{
    [super viewDidLoad];
    //create sublayer
    self.blueLayer = [CALayer layer];
    self.blueLayer.frame = CGRectMake(50.0f, 50.0f, 100.0f, 100.0f);
    self.blueLayer.backgroundColor = [UIColor blueColor].CGColor;
    //add it to our view
    [self.layerView.layer addSublayer:self.blueLayer];
}
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
    //get touch position relative to main view
    CGPoint point = [[touches anyObject] locationInView:self.view];
    //convert point to the white layer's coordinates
    point = [self.layerView.layer convertPoint:point fromLayer:self.view.layer];
    //get layer using containsPoint:
    if ([self.layerView.layer containsPoint:point]) {
        //convert point to blueLayer’s coordinates
        point = [self.blueLayer convertPoint:point fromLayer:self.layerView.layer];
        if ([self.blueLayer containsPoint:point]) {
            [[[UIAlertView alloc] initWithTitle:@"Inside Blue Layer" 
                                        message:nil
                                       delegate:nil 
                              cancelButtonTitle:@"OK"
                              otherButtonTitles:nil] show];
        } else {
            [[[UIAlertView alloc] initWithTitle:@"Inside White Layer"
                                        message:nil 
                                       delegate:nil
                              cancelButtonTitle:@"OK"
                              otherButtonTitles:nil] show];
        }
    }
}
@end

圖3.10 點擊圖層被正確標識

-hitTest:方法一樣接受一個CGPoint類型參數，而不是BOOL類型，它返回圖層自己，或者包含這個座標點的葉子節點圖層。這意味着再也不須要像使用-containsPoint:那樣，人工地在每一個子圖層變換或者測試點擊的座標。若是這個點在最外面圖層的範圍以外，則返回nil。具體使用-hitTest:方法被點擊圖層的代碼如清單3.5所示。

清單3.5 使用hitTest判斷被點擊的圖層

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
    //get touch position
    CGPoint point = [[touches anyObject] locationInView:self.view];
    //get touched layer
    CALayer *layer = [self.layerView.layer hitTest:point];
    //get layer using hitTest
    if (layer == self.blueLayer) {
        [[[UIAlertView alloc] initWithTitle:@"Inside Blue Layer"
                                    message:nil
                                   delegate:nil
                          cancelButtonTitle:@"OK"
                          otherButtonTitles:nil] show];
    } else if (layer == self.layerView.layer) {
        [[[UIAlertView alloc] initWithTitle:@"Inside White Layer"
                                    message:nil
                                   delegate:nil
                          cancelButtonTitle:@"OK"
                          otherButtonTitles:nil] show];
    }
}

注意當調用圖層的-hitTest:方法時，測算的順序嚴格依賴於圖層樹當中的圖層順序（和UIView處理事件相似）。以前提到的zPosition屬性能夠明顯改變屏幕上圖層的順序，但不能改變事件傳遞的順序。

這意味着若是改變了圖層的z軸順序，你會發現將不可以檢測到最前方的視圖點擊事件，這是由於被另外一個圖層遮蓋住了，雖然它的zPosition值較小，可是在圖層樹中的順序靠前。咱們將在第五章詳細討論這個問題。

自動佈局

你可能用過UIViewAutoresizingMask類型的一些常量，應用於當父視圖改變尺寸的時候，相應UIView的frame也跟着更新的場景（一般用於橫豎屏切換）。

在iOS6中，蘋果介紹了自動排版機制，它和自動調整不一樣，而且更加複雜。

在Mac OS平臺，CALayer有一個叫作layoutManager的屬性能夠經過CALayoutManager協議和CAConstraintLayoutManager類來實現自動排版的機制。但因爲某些緣由，這在iOS上並不適用。

當使用視圖的時候，能夠充分利用UIView類接口暴露出來的UIViewAutoresizingMask和NSLayoutConstraintAPI，但若是想隨意控制CALayer的佈局，就須要手工操做。最簡單的方法就是使用CALayerDelegate以下函數：

- (void)layoutSublayersOfLayer:(CALayer *)layer;

當圖層的bounds發生改變，或者圖層的-setNeedsLayout方法被調用的時候，這個函數將會被執行。這使得你能夠手動地從新擺放或者從新調整子圖層的大小，可是不能像UIView的autoresizingMask和constraints屬性作到自適應屏幕旋轉。

這也是爲何最好使用視圖而不是單獨的圖層來構建應用程序的另外一個重要緣由之一。

總結

本章涉及了CALayer的集合結構，包括它的frame，position和bounds，介紹了三維空間內圖層的概念，以及如何在獨立的圖層內響應事件，最後簡單說明了在iOS平臺，Core Animation對自動調整和自動佈局支持的缺少。