本文是對http://www.cocoachina.com/ios/20150104/10814.html文章的關鍵段落的摘抄,有需要的看原文
CALayer和UIView的關係:
CALayer類在概念上和UIView類似,同樣也是一些被層級關係樹管理的矩形塊,同樣也可以包含一些內容(像圖片,文字或者背景色),管理子圖層的位置。它們有一些方法和屬性用來做動畫和變換。和UIView最大的不同是CALayer不處理使用者的互動。
CALayer並不清楚具體的響應鏈(iOS通過檢視層級關係用來傳送觸控事件的機制),於是它並不能夠響應事件,即使它提供了一些方法來判斷是否一個觸點在圖層的範圍之內(具體見第三章,“圖層的幾何學”)
實際上這些背後關聯的圖層才是真正用來在螢幕上顯示和做動畫,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不能處理觸控事件,那麼能做哪些檢視不能做的呢?
-
陰影,圓角,帶顏色的邊框
-
3D變換
-
非矩形範圍
-
透明遮罩
-
多級非線性動畫
Contents屬性
這個屬性的型別被定義為id,意味著它可以是任何型別的物件。但是,在實踐中,如果你給contents賦的不是CGImage,那麼你得到的圖層將是空白的。
contents這個奇怪的表現是由Mac OS的歷史原因造成的。它之所以被定義為id型別,是因為在Mac OS系統上,這個屬性對CGImage和NSImage型別的值都起作用。如果你試圖在iOS平臺上將UIImage的值賦給它,只能得到一個空白的圖層。一些初識Core Animation的iOS開發者可能會對這個感到困惑。
contentsScale屬性
當用程式碼的方式來處理寄宿圖的時候,一定要記住要手動的設定圖層的contentsScale屬性,否則,你的圖片在Retina裝置上就顯示得不正確啦。程式碼如下:layer.contentsScale = [UIScreen mainScreen].scale;
contentGravity屬性
對其方式與縮放方式
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(左)和之前顯示的內容(右)
典型地,圖片拼合後可以打包整合到一張大圖上一次性載入。相比多次載入不同的圖片,這樣做能夠帶來很多方面的好處:記憶體使用,載入時間,渲染效能等等
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提供了一個整潔的載入方式,還有效地提高了載入效能(單張大圖比多張小圖載入地更快),但是如果有手動安排的話,他們還是有一些不方便的,如果你需要在一個已經建立好的品和圖上做一些尺寸上的修改或者其他變動,無疑是比較麻煩的。
contentsCenter屬性
contentsCenter其實是一個CGRect,它定義了一個固定的邊框和一個在圖層上可拉伸的區域。 改變contentsCenter的值並不會影響到寄宿圖的顯示,除非這個圖層的大小改變了,你才看得到效果。
預設情況下,contentsCenter是{0, 0, 1, 1},這意味著如果大小(由conttensGravity決定)改變了,那麼寄宿圖將會均勻地拉伸開。但是如果我們增加原點的值並減小尺寸。我們會在圖片的周圍創造一個邊框。圖2.9展示了contentsCenter設定為{0.25, 0.25, 0.5, 0.5}的效果。
IB中設定:
Custome Drawing
給contents賦CGImage的值不是唯一的設定寄宿圖的方法。我們也可以直接用Core Graphics直接繪製寄宿圖。能夠通過繼承UIView並實現-drawRect:方法來自定義繪製。
如果你不需要寄宿圖,那就不要建立這個方法了,這會造成CPU資源和記憶體的浪費,這也是為什麼蘋果建議:如果沒有自定義繪製的任務就不要在子類中寫一個空的-drawRect:方法。
當檢視在螢幕上出現的時候 -drawRect:方法就會被自動呼叫。-drawRect:方法裡面的程式碼利用Core Graphics去繪製一個寄宿圖,然後內容就會被快取起來直到它需要被更新(通常是因為開發者呼叫了-setNeedsDisplay方法,儘管影響到表現效果的屬性值被更改時,一些檢視型別會被自動重繪,如bounds屬性)。雖然-drawRect:方法是一個UIView方法,事實上都是底層的CALayer安排了重繪工作和儲存了因此產生的圖片。
當需要被重繪時,CALayer會請求它的代理給他一個寄宿圖來顯示。它通過呼叫下面這個方法做到的:
1
|
(void)displayLayer:(CALayerCALayer *)layer; |
趁著這個機會,如果代理想直接設定contents屬性的話,它就可以這麼做,不然沒有別的方法可以呼叫了。如果代理不實現-displayLayer:方法,CALayer就會轉而嘗試呼叫下面這個方法:
1
|
- (void)drawLayer:(CALayer *)layer inContext:(CGContextRef)ctx; |
在呼叫這個方法之前,CALayer建立了一個合適尺寸的空寄宿圖(尺寸由bounds和contentsScale決定)和一個Core Graphics的繪製上下文環境,為繪製寄宿圖做準備,他作為ctx引數傳入。
@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
-
我們在blueLayer上顯式地呼叫了-display。不同於UIView,當圖層顯示在螢幕上時,CALayer不會自動重繪它的內容。它把重繪的決定權交給了開發者。
現在你理解了CALayerDelegate,並知道怎麼使用它。但是除非你建立了一個單獨的圖層,你幾乎沒有機會用到CALayerDelegate協議。因為當UIView建立了它的宿主圖層時,它就會自動地把圖層的delegate設定為它自己,並提供了一個-displayLayer:的實現,那所有的問題就都沒了。
幾何相關
錨點
之前提到過,檢視的center屬性和圖層的position屬性都指定了相對於父圖層anchorPoint的位置。圖層的anchorPoint通過position來控制它的frame的位置,你可以認為anchorPoint是用來移動圖層的把柄。
預設來說,anchorPoint位於圖層的中點,所以圖層的將會以這個點為中心放置。anchorPoint屬性並沒有被UIView介面暴露出來,這也是檢視的position屬性被叫做“center”的原因。但是圖層的anchorPoint可以被移動,比如你可以把它置於圖層frame的左上角,於是圖層的內容將會向右下角的position方向移動(圖3.3),而不是居中了。
注意在圖3.3中,當改變了anchorPoint,position屬性保持固定的值並沒有發生改變,但是frame卻移動了。
那在什麼場合需要改變anchorPoint呢?既然我們可以隨意改變圖層位置,那改變anchorPoint不會造成困惑麼?為了舉例說明,我們來舉一個實用的例子,建立一個模擬鬧鐘的專案。
- (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 }
Hit Testing
注意當呼叫圖層的-hitTest:方法時,測算的順序嚴格依賴於圖層樹當中的圖層順序(和UIView處理事件類似)。之前提到的zPosition屬性可以明顯改變螢幕上圖層的順序,但不能改變事件傳遞的順序。
這意味著如果改變了圖層的z軸順序,你會發現將不能夠檢測到最前方的檢視點選事件,這是因為被另一個圖層遮蓋住了,雖然它的zPosition值較小,但是在圖層樹中的順序靠前。