[iOS Animation]-CALayer 顯示方式

寄宿圖

圖片賽過千言萬語,界面抵得上千圖片 ——Ben Shneidermangit

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

contents屬性

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

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關鍵字轉換。若是要給圖層的寄宿圖賦值,你能夠按照如下這個方法:app

//設置圖層的內容顯示爲一張圖片
layer.contents = (__bridge id)image.CGImage;

若是你沒有使用ARC(自動引用計數),你就不須要__bridge這部分。可是,你幹嗎不用ARC?!ide

讓咱們來繼續修改咱們在第一章新建的工程,以便可以展現一張圖片而不只僅是一個背景色。咱們已經用代碼的方式創建一個圖層,那咱們就不須要額外的圖層了。那麼咱們就直接把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的宿主圖層中顯示一張圖片佈局

圖2.1

咱們用這些簡單的代碼作了一件頗有趣的事情:咱們利用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 能夠看到結果

image

圖2.2 正確地設置contentsGravity的值

contentsScale

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

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

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

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

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

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

圖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

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

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

layer.contentsScale = [UIScreen mainScreen].scale;

maskToBounds

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

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

圖2.5

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

contentsRect

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

boundsframe不一樣,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

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

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

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

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

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

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

圖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

圖2.8

拼合不只給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

圖2.9 contentsCenter的例子

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

圖2.10

圖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

圖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建立了一個合適尺寸的空寄宿圖(尺寸由boundscontentsScale決定)和一個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

圖2.12 實現CALayerDelegate來繪製圖層

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

  • 咱們在blueLayer上顯式地調用了-display。不一樣於UIView,當圖層顯示在屏幕上時,CALayer不會自動重繪它的內容。它把重繪的決定權交給了開發者。
  • 儘管咱們沒有用masksToBounds屬性,繪製的那個圓仍然沿邊界被裁剪了。這是由於當你使用CALayerDelegate繪製寄宿圖的時候,並無對超出邊界外的內容提供繪製支持。

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

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

總結

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

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

相關文章
相關標籤/搜索