IOS核心動(dòng)畫高級(jí)二:寄宿圖

寄宿圖

承接上文泞遗,我們?cè)凇緢D層樹】的文章中介紹了CALayer 并且創(chuàng)建了一個(gè)簡(jiǎn)單藍(lán)色背景的圖層進(jìn)行展示温兼,如果圖層只能展示單調(diào)的顏色未免太無聊了俱恶,事實(shí)上CALayer類能夠包含一張你喜歡的圖片究孕,本章我們一塊來探索CALayer的寄宿圖(即圖層中包含的圖)比搭。

contents屬性

CALayer有一個(gè)屬性叫做contents艾疟,這個(gè)屬性的類型被定義為id,意味著它可以是任意類型的對(duì)象。在這種情況下蔽莱,你可以給contents屬性賦任何值弟疆,你的APP仍然可以編譯通過。但是盗冷,在實(shí)踐中怠苔,如果你給contents賦的值不是CGImage類型,你所得到的圖層都是空白的仪糖。

contents的這種奇怪表現(xiàn)是由Mac OS的歷史原因造成的柑司。它之所以被定義為id類型,是因?yàn)樵贛ac OS系統(tǒng)上锅劝,這個(gè)屬性對(duì)CGImage 和 NSImage類型的值都起作用攒驰。如果你試圖在IOS系統(tǒng)上給它賦UIImage類型的值,那只能得到一塊空白的圖層故爵。一些初識(shí)Core Animation 的開發(fā)者可能會(huì)對(duì)這個(gè)感到困惑玻粪。

頭疼的不僅僅是上面我們提到的這個(gè)問題,事實(shí)上诬垂,你真正要賦值的類型應(yīng)該是CGImageRef劲室,CGImageRef是一個(gè)指向CGImage結(jié)構(gòu)的指針。UIImage有一個(gè)CGimage屬性结窘,它會(huì)返回一個(gè)‘CGImageRef’很洋,如果你想把它直接賦值給CALayer的contents屬性,那你將會(huì)得到一個(gè)編譯錯(cuò)誤隧枫。因?yàn)镃GImageRef并不是一個(gè)真正的Cocoa對(duì)象喉磁,而是一個(gè)Core Foundation類型。

盡管Cocoa對(duì)象和Core Foundation類型在運(yùn)行時(shí)貌似很像官脓,被稱作(toll-free bridging)协怒。他們并不是類型兼容的,不過你可以使用bridged關(guān)鍵字進(jìn)行轉(zhuǎn)換确买。如果要給圖層的寄宿圖賦值斤讥,代碼如下:

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

如果你沒有使用ARC (自動(dòng)引用計(jì)數(shù)),你就不需要使用__bridge 這個(gè)部分湾趾,但是芭商,你干嘛不用ARC呢?

那好搀缠,接下來我們以之前的代碼為基礎(chǔ)繼續(xù)進(jìn)行講解:我們要讓圖層不僅能夠設(shè)置背景色還能顯示圖片铛楣。我們已經(jīng)創(chuàng)建了圖層CALayer ,我們?cè)O(shè)置宿主圖層的contents屬性為圖片;
代碼如下

  UIView *layerView = [[UIView alloc] initWithFrame: CGRectMake(100, 100, 200, 200)];
layerView.backgroundColor = [UIColor whiteColor];
[self.view addSubview:layerView];

UIImage *image = [UIImage imageNamed:@"tesla.jpg"];
layerView.layer.contents = (__bridge id)image.CGImage;

看下圖層展示圖片的效果:

圖層展示圖片.png

我們用如此簡(jiǎn)單的代碼做了一件很有趣事:我們利用CALayer在一個(gè)普通的UIView上展示了一張圖片艺普。這不是一個(gè)UIImageView簸州,它不是我們通常用來展示圖片的方法鉴竭。通過直接操作圖層,我們使用了一個(gè)新的函數(shù)岸浑,使得UIView更加有趣了搏存。

contentGravity

你可能也注意到了圖片有些擁擠。小車變胖了矢洲!因?yàn)槲覀兗虞d的圖片并不能剛好就是一個(gè)方形的璧眠,為了適應(yīng)這個(gè)視圖,它有一點(diǎn)點(diǎn)被拉伸了读虏。在使用UIImageView 的時(shí)候遇到過同樣的問題责静,解決辦法是設(shè)置contentMode的值為更合適的值,比如:

view.contentMode = UIViewContentModeScaleAspectFit;

這種方法已經(jīng)和我們遇到的問題的解決方法很接近了(可以先不看后面的內(nèi)容盖桥,自己試下)灾螃。不過UIView大多數(shù)和視覺相關(guān)的屬性(比如:contentsmode),對(duì)這些屬性的操作其實(shí)是對(duì)對(duì)應(yīng)圖層的操作揩徊。

CALayer中與contentMode對(duì)應(yīng)的屬性的屬性是contentsGravity腰鬼,但是它是一個(gè)NSString類型,而不是像對(duì)應(yīng)的UIKit 部分靴拱,那里面的值是枚舉類型垃喊。contentsGravity 可選的常量值有以下一些:

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

和contentMode一樣猾普,contentsGravity的目的是為了決定內(nèi)容在圖層的邊界中怎么對(duì)齊袜炕,我們將使用kCAGravityResizeAspect,它的效果等同于UIViewContentModeScaleAspectFit初家,同時(shí)它還能在圖層中等比例拉伸以適應(yīng)圖層的邊界偎窘。
代碼如下:

    layerView.layer.contentsGravity = kCAGravityResizeAspect;

效果如下:

等比例拉伸效果.png

contentsScale

contentsScale屬性定義了寄宿圖的像素尺寸和視圖大小的比例。默認(rèn)情況下它是一個(gè)值為1.0的浮點(diǎn)數(shù)溜在。

contentsScale的目的并不是那么明顯陌知,它并不是總會(huì)對(duì)屏幕上寄宿圖有影響。如果你嘗試在我們的例子上設(shè)置不同的值掖肋,你會(huì)發(fā)現(xiàn)根本沒有任何影響仆葡。因?yàn)閏ontents設(shè)置了contentsGravity屬性值,所以它已經(jīng)被拉伸以適應(yīng)圖層邊界志笼。

如果你只是想單純的放大圖層的content圖片沿盅,你可以使用圖層的transform 和 affineTransform屬性來達(dá)到這個(gè)目的,將content圖片放大也不是contentScale 的目的所在纫溃。

contentsScale屬性其實(shí)屬于支持高分辨率(Hi-DPI或者Retina)屏幕機(jī)制的一部分腰涧。它用來判斷在繪制圖層的時(shí)候應(yīng)該為寄宿圖創(chuàng)建的空間大小,和需要顯示的圖片的拉伸度(假設(shè)contents沒有設(shè)置contentsGravity屬性)紊浩。UIView有一個(gè)類似功能但是非常少用的屬性contentScaleFactor窖铡。

如果contentsScale設(shè)置為1.0疗锐,將會(huì)以每個(gè)點(diǎn)1個(gè)像素繪制圖片,如果設(shè)置為2.0费彼,將會(huì)以每個(gè)點(diǎn)2個(gè)像素繪制圖片滑臊,這就是我們熟知的Retina屏幕。(如果對(duì)點(diǎn)和像素的概念不太清楚箍铲,我們?cè)诒菊履┪矔?huì)給出解釋简珠,也可自行上網(wǎng)查看)。

這并不會(huì)對(duì)我們?cè)谑褂胟CAGravityResizeAspect時(shí)產(chǎn)生任何影響虹钮,因?yàn)樗褪抢靾D片以適應(yīng)圖層而已聋庵。根本不會(huì)考慮到分辨率的問題。但是如果我們把contentsGravity設(shè)置成kCAGravityCenter(這個(gè)值并不會(huì)拉伸圖片)芙粱,那將會(huì)有明顯的變化:
代碼如下:

  layerView.layer.contentsGravity = kCAGravityCenter;

效果如下

不拉伸圖片.png

如圖所示祭玉,我們圖片不僅變大而且仔細(xì)看會(huì)有一種像素的顆粒感。那是因?yàn)镃GImage和UIImage不同春畔,CGImage沒有拉伸的概念脱货。當(dāng)我們使用UIImage類去讀取我們的特斯拉圖片時(shí), 它讀取到的是高質(zhì)量的Retina版本的圖片律姨。但是當(dāng)我們使用CGImage來設(shè)置我們的圖層內(nèi)容時(shí)振峻,拉伸這個(gè)因素在轉(zhuǎn)換的時(shí)候就丟失了。此時(shí)我們就可以使用contentsScale來修復(fù)這個(gè)問題择份。

當(dāng)用代碼的方式來處理寄宿圖的時(shí)候扣孟,一定要記住手動(dòng)設(shè)置圖層的contentsScale屬性,否則荣赶,你的圖片在Retina屏幕上就顯示不正確了凤价。
代碼如下:
layerView.layer.contentsGravity = kCAGravityCenter;
layerView.layer.contentsScale = [UIScreen mainScreen].scale;

效果如下


通過contentsScale.png

maskToBounds

截止到此我們特斯拉已經(jīng)顯示正確的大小,不過你可能也已經(jīng)發(fā)現(xiàn)另外一件事情拔创,他超出了視圖的邊界利诺,默認(rèn)情況下,UIView 仍然會(huì)繪制超出邊界的內(nèi)容或者子視圖剩燥,在CALayer上也是這樣的慢逾。

UIView中有一個(gè)clipsToBounds屬性來決定是否顯示超出邊界的內(nèi)容。CALayer對(duì)應(yīng)的屬性是masksToBounds灭红,把他設(shè)置成YES侣滩,就是只顯示在視圖邊界內(nèi)的內(nèi)容。
代碼如下:

  layerView.layer.masksToBounds = YES;

效果如下:

邊界內(nèi)顯示.png

contentsRect

CALayer的contentsRect屬性允許我們?cè)趫D層邊框里顯示寄宿圖的一個(gè)子域比伏,這涉及到圖片是如何顯示和拉伸胜卤,所以要比contentsGravity靈活多了

和bounds赁项,frame不同葛躏,contentsRect不是按點(diǎn)來計(jì)算的澈段,它使用了單位坐標(biāo)單位坐標(biāo)指定在0到1之間舰攒,是個(gè)相對(duì)值(像素和點(diǎn)都是絕對(duì)值)败富。所以單位坐標(biāo)是相對(duì)與寄宿圖的尺寸的

在此我們總結(jié)一些ios系統(tǒng)是用到了一些坐標(biāo)系統(tǒng):

點(diǎn)——在Ios和MacOS系統(tǒng)中最常見的坐標(biāo)體系摩窃。點(diǎn)就像是虛擬的像素兽叮,也被稱作邏輯像素。在標(biāo)準(zhǔn)設(shè)備上猾愿,一個(gè)點(diǎn)就是一個(gè)像素鹦聪,但是在Retina設(shè)備上,一個(gè)點(diǎn)等于2 * 2個(gè)像素蒂秘。ios用點(diǎn)作為屏幕的坐標(biāo)測(cè)算體系就是為了讓應(yīng)用在Retina設(shè)備和標(biāo)準(zhǔn)設(shè)備上有一致的視覺效果泽本。

像素——物理像素坐標(biāo)并不會(huì)用來做屏幕布局,但是仍然和圖片有相對(duì)關(guān)系姻僧。UIImage是一個(gè)屏幕分辨率解決方案规丽,所以指定點(diǎn)來度量大小但是一些底層的圖片表示比如CGImage就會(huì)使用像素撇贺,所以你要清楚在Retina設(shè)備和普通設(shè)備上赌莺,他們表現(xiàn)出來了不同大小

單位——對(duì)于與圖片大小或者圖層邊界相關(guān)的顯示松嘶,單位坐標(biāo)是一個(gè)方便的度量方式艘狭,當(dāng)大小改變時(shí),也不需要再次調(diào)整喘蟆。單位坐標(biāo)在OpenGL這種紋理坐標(biāo)系統(tǒng)中用的比較多缓升。Core Animation中也用到了這種坐標(biāo)鼓鲁。

默認(rèn)的contentsRect是{0,0,1贾漏,1}岩睁,這意味著整個(gè)寄宿圖默認(rèn)都是可見的。如果我們指定一個(gè)小點(diǎn)的矩形燥狰,圖片就會(huì)被裁剪棘脐。
例如:

圖片裁剪

接上我們的例子
代碼如下

   layerView.layer.contentsGravity = kCAGravityResizeAspect;
  //    layerView.layer.contentsScale = image.scale;
  layerView.layer.masksToBounds = YES;
  layerView.layer.contentsScale = [UIScreen mainScreen].scale;
  layerView.layer.contentsRect = CGRectMake(0, 0, 0.5, 0.5);

效果如下:

裁剪后的效果.png

以上描述的這種情況,我們的截圖空間是[0,0]坐標(biāo)到[1,1]之間龙致,如果我們的起始坐標(biāo)為負(fù)數(shù)蛀缝,結(jié)束坐標(biāo)超過一會(huì)會(huì)如何呢?
代碼如下:

layerView.layer.contentsRect = CGRectMake(-0.3, 0.3, 1, 1);

效果

原點(diǎn)為負(fù)數(shù).png

代碼如下:

 layerView.layer.contentsRect = CGRectMake(0, 0, 1.3, 1.3);

效果如下:

截止坐標(biāo)超過1.png

事實(shí)上給contentsRect設(shè)置一個(gè)為負(fù)數(shù)的原點(diǎn)或者設(shè)置一個(gè)大于{1目代,1}的尺寸也是可以的屈梁。在這種情況下嗤练,最外面的一層像素會(huì)被拉伸以填充剩下的區(qū)域。

contentsRect在app中最有趣的地方在于一個(gè)叫image sprites(圖片拼合)的用法在讶。如果你有游戲編程的經(jīng)驗(yàn)煞抬,那你一定對(duì)圖片拼合的概念很熟悉,圖片能夠在屏幕上獨(dú)立的變更位置构哺。拋開游戲編程不談革答,這個(gè)技術(shù)常用來指代載入拼合的圖片,跟移動(dòng)圖片一點(diǎn)關(guān)系也沒有曙强。

典型的残拐,圖片拼合后可以打包整合到一張大圖上一次性載入。相比多次載入不同的圖片碟嘴,這樣能夠帶來很多方面的好處:內(nèi)存使用蹦骑,載入時(shí)間,渲染性能等等臀防。

2D游戲引擎Cocoa2D使用了拼合技術(shù)眠菇,它使用OpenGL來顯示圖片。不過我們可以在一個(gè)普通的UIKit應(yīng)用中使用拼合袱衷,那就是contentsRect捎废。

首先我們需要一個(gè)拼合后的圖表——一個(gè)包含了小一些拼合圖的大圖片。舉例:

拼合后的圖表

接下來致燥,我們要在app中載入并顯示這些拼合圖(在此我們以之前的特斯拉圖片為例登疗,以3 * 2 的網(wǎng)格分割為6張拼合圖)。規(guī)則很簡(jiǎn)單:像平常一樣載入我們的大圖嫌蚤,然后把它賦值給6個(gè)獨(dú)立的圖層的contents辐益。然后設(shè)置圖層的contentsRect來去掉我們不想顯示的部分。

代碼如下:

- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view.
self.view.backgroundColor = [UIColor whiteColor];
//載入圖片
UIImage *tesleImg = [UIImage imageNamed:@"tesla.jpg"];///600 × 450

//存放6個(gè)圖片的圖層
UIView *view1 = [[UIView alloc] initWithFrame:CGRectMake(0, 0, 200, 200)];
[self imageSpriteOnLayer:view1.layer withRect:CGRectMake(0, 0, 0.5, 0.5) withImage:tesleImg];

UIView *view2 = [[UIView alloc] initWithFrame:CGRectMake(120, 150, 200, 200)];
[self imageSpriteOnLayer:view2.layer withRect:CGRectMake(0.5, 0, 0.5, 0.5) withImage:tesleImg];

UIView *view3 = [[UIView alloc] initWithFrame:CGRectMake(0, 300, 200, 200)];
[self imageSpriteOnLayer:view3.layer withRect:CGRectMake(0, 0.5, 0.5, 0.5) withImage:tesleImg];

UIView *view4 = [[UIView alloc] initWithFrame:CGRectMake(120, 500, 200, 200)];
[self imageSpriteOnLayer:view4.layer withRect:CGRectMake(0.5, 0.5, 0.5 , 0.5) withImage:tesleImg];



[self.view addSubview:view1];
[self.view addSubview:view2];
[self.view addSubview:view3];
[self.view addSubview:view4];

}

- (void)imageSpriteOnLayer:(CALayer *)layer withRect:(CGRect) rect withImage:(UIImage *)image
{
layer.contents = (__bridge id) image.CGImage;
layer.contentsRect = rect;
layer.contentsGravity = kCAGravityResizeAspect;
}

效果如下:

分割后的圖片.png

拼合不僅給app提供了一個(gè)整潔的載入方式脱吱,還有效的提高了載入性能(單張大圖要比多張小圖載入地更快)智政。但是如果有手動(dòng)安排的話,他們還是有一些不方便的箱蝠,如果你需要在已經(jīng)創(chuàng)建好的拼合圖上做一些尺寸上的修改或者其他變動(dòng)续捂,無疑是比較麻煩的。

Mac上有一些商業(yè)軟件可以為你自動(dòng)拼合圖片宦搬,這些工具自動(dòng)生成一個(gè)包含拼合后的坐標(biāo)的xml或者plist文件牙瓢,拼合圖片的使用大大簡(jiǎn)化。這個(gè)文件可以和圖片一同載入间校,并給每個(gè)拼合的圖層設(shè)置contentsRect矾克,這樣開發(fā)人員就不用手動(dòng)寫代碼來擺放位置了。

這些文件通常在OpenGL游戲中使用憔足,不過胁附,你要是有興趣在一些常見的app中使用拼合技術(shù)差购,那么有一個(gè)叫做LayerSprites的開源庫。他能夠讀取Cocos2D格式中的拼合圖并在普通的Core Animation層中顯示出來汉嗽。

contentsCenter

本章我們介紹的最后一個(gè)和內(nèi)容相關(guān)的屬性是contentsCenter欲逃。看名字你感覺可能會(huì)跟圖片的位置有關(guān)饼暑,不過這名字著實(shí)誤導(dǎo)了你稳析。contentsCenter其實(shí)是一個(gè)CGRect類型,它定義了一個(gè)固定的邊框和一個(gè)在圖層上可拉伸的區(qū)域弓叛。改變contentsRect的值并不會(huì)影響寄宿圖的顯示彰居。除非這個(gè)圖層的大小改變了。你才看得到效果撰筷。

默認(rèn)情況下陈惰,contentsCenter的值為{0,0毕籽,1抬闯,1}(這里要特別注意contentsCenter用的是單位坐標(biāo)),這意味著如果大泄赝病(由contentsGravity決定)改變了溶握,那么寄宿圖就會(huì)均勻的拉伸開**。但是如果我們?cè)黾釉c(diǎn)的值并減小尺寸蒸播。我們就會(huì)在圖片的周圍創(chuàng)建出一個(gè)邊框睡榆。如下圖所示:我們將contentsCenter的值設(shè)置成{0.25,0.25袍榆,0.5胀屿,0.5}

contentsCenter例子

這意味著我們可以隨便調(diào)整尺寸,邊框仍是會(huì)是連續(xù)的包雀。他工作起來的效果和UIImage中的-resizeableImageWithCapInsets:方法效果非常類似宿崭,只是它可以用到任何寄宿圖上,甚至包括用Core Graphics運(yùn)行時(shí)繪制的圖形上馏艾。
代碼如下:

self.view.backgroundColor = [UIColor whiteColor];
UIImage *image = [UIImage imageNamed:@"geren_.png"];

CGRect contentsCenterRect = CGRectMake(0.25, 0.25, 0.5, 0.5); //會(huì)拉伸的區(qū)域

//橫向拉伸
CALayer *layerH = [CALayer layer];
layerH.contents =  (__bridge id) image.CGImage;
layerH.frame = CGRectMake(0, 60, 320, 72);
layerH.backgroundColor = [UIColor grayColor].CGColor;
layerH.contentsCenter = contentsCenterRect;
//    layerH.contentsGravity = kCAGravityResizeAspect;
[self.view.layer addSublayer:layerH];


//縱向拉伸
CALayer *layerV = [CALayer layer];
layerV.contents =  (__bridge id) image.CGImage;
layerV.frame = CGRectMake(100, 150, 72, 320);
layerV.backgroundColor = [UIColor redColor].CGColor;
layerV.contentsCenter = contentsCenterRect;
//    layerV.contentsGravity = kCAGravityResizeAspect;
[self.view.layer addSublayer:layerV];

效果如下:

拉伸效果.png

contentsCenter另外一個(gè)很酷的特性就是可以直接在interface builder里面進(jìn)行配置劳曹,根本不用寫代碼。
如圖:

Interface Builder設(shè)置contentsCenter屬性

custom Drawing

給contents賦CGImage值不是唯一的設(shè)置寄宿圖的方法琅摩。我們也可以直接使用Core Graphics直接繪制寄宿圖能夠通過集成UIView來重新實(shí)現(xiàn)-drawRect:方法來自定義繪制锭硼。

-drawRect:方法沒有默認(rèn)的實(shí)現(xiàn)房资,因?yàn)閷?duì)UIView來說,寄宿圖并不是必須的檀头,它不在意那到底是一個(gè)單調(diào)的顏色還是一張圖片的實(shí)例轰异。如果UIView檢測(cè)到-drawRect:方法被調(diào)用了岖沛,它就會(huì)為視圖分配一個(gè)寄宿圖。這個(gè)寄宿圖的像素尺寸等于視圖大小乘以contentsScale的值搭独。

如果你不需要寄宿圖婴削,那就不要?jiǎng)?chuàng)建這個(gè)方法了,這會(huì)造成CPU和內(nèi)存資源的浪費(fèi)牙肝,這也就是為什么蘋果建議:如果沒有自定義繪制的任務(wù)就不要在子類中寫一個(gè)空的-drawRect方法唉俗。

當(dāng)視圖在屏幕上出現(xiàn)的時(shí)候-drawRect:方法會(huì)被自動(dòng)調(diào)用,-drawRect:里面的代碼會(huì)利用Core Graphics 去繪制一個(gè)寄宿圖配椭。然后內(nèi)容就會(huì)被緩存起來直到他需要被更新(通常是因?yàn)殚_發(fā)者調(diào)用了-setNeedsToDisplay方法虫溜,盡管影響到表現(xiàn)效果的屬性值被更改時(shí),一些視圖類型會(huì)被自動(dòng)重繪股缸,如bounds屬性)衡楞。雖然-drawRect:方法是一個(gè)UIView的方法。事實(shí)上都是底層的CALayer安排了重繪工作和保存了因此產(chǎn)生的圖片敦姻。

CALayer有一個(gè)可選的delegate屬性瘾境,實(shí)現(xiàn)了CALayerDelegate協(xié)議,當(dāng)CALayer需要一個(gè)內(nèi)容特定的信息時(shí)镰惦,就會(huì)從協(xié)議中請(qǐng)求寄雀。CALayerDelegate是一個(gè)非正式協(xié)議,其實(shí)就是說沒有CALayerDelegate @protocol可以讓你在類里面應(yīng)用了陨献。你只需要調(diào)用你想調(diào)用的方法盒犹,CALayer會(huì)幫你做剩下的。(delegate 屬性被聲明為id類型眨业,所有的代理方法都是可選的)急膀。

當(dāng)需要被重繪時(shí),CALayer會(huì)請(qǐng)求他的代理給他一個(gè)寄宿圖用來顯示龄捡。它通過下面這個(gè)方法調(diào)用的:

  -(void)displayLayer:(CALayerCALayer *)layer;

趁著這個(gè)機(jī)會(huì)卓嫂,如果代理想直接設(shè)置contents屬性的話,它就可以這么做聘殖,不然沒有別的方法可以調(diào)用了晨雳。如果代理不實(shí)現(xiàn)-displayLayer:方法,CALayer就會(huì)轉(zhuǎn)而嘗試下面的方法:

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

在調(diào)用這個(gè)方法之前奸腺,CALayer創(chuàng)建了一個(gè)合適尺寸的空寄宿圖(尺寸由bounds和contentsScale決定)和一個(gè)Core Graphics的繪制上下文環(huán)境餐禁,為繪制寄宿圖做準(zhǔn)備,他作為ctx參數(shù)傳入突照。

讓我們繼續(xù)在項(xiàng)目學(xué)習(xí)帮非,讓他實(shí)現(xiàn)CALayerDelegate并做一些繪圖操作:

代碼如下:

- (void)viewDidLoad {
[super viewDidLoad];
self.view.backgroundColor = [UIColor whiteColor];

//創(chuàng)建一個(gè)layer
CALayer *layer = [CALayer layer];
layer.frame = CGRectMake(100, 100, 200, 200);
layer.backgroundColor = [UIColor blueColor].CGColor;

//ensure that layer backing image uses correct scale
layer.contentsScale = [UIScreen mainScreen].scale;
[self.view.layer addSublayer:layer];

layer.delegate = self;

//重新繪制
[layer display];

 }


- (void)drawLayer:(CALayer *)layer inContext:(CGContextRef)ctx
{
CGContextSetLineWidth(ctx, 10.f);
CGContextSetStrokeColorWithColor(ctx,[UIColor redColor].CGColor);
CGContextStrokeEllipseInRect(ctx, layer.bounds);

 }

效果如下:

實(shí)現(xiàn)CALayerDelegate實(shí)現(xiàn)重繪.png

這里我們要注意一些有趣的事情:
1:我們?cè)趌ayer上顯示調(diào)用了-display。不同于UIView,當(dāng)圖層顯示在屏幕上時(shí)末盔,CALayer不會(huì)自動(dòng)重繪它的內(nèi)容筑舅。它把重新繪制的決定權(quán)交給了開發(fā)者。
2:盡管我們沒有用maskToBounds屬性陨舱。繪制的這個(gè)圓仍然沿著邊界被裁剪了翠拣。這是因?yàn)楫?dāng)你使用CALayerDelegate繪制寄宿圖的時(shí)候,并沒有對(duì)超出邊界外的內(nèi)容提供繪制支持游盲。

現(xiàn)在你理解了CALayerDelegate误墓,并知道怎么使用它。但是除非你創(chuàng)建了一個(gè)單獨(dú)的圖層背桐。你幾乎沒有機(jī)會(huì)用到CALayerDelegate協(xié)議优烧,因?yàn)楫?dāng)UIView創(chuàng)建它的宿主圖層時(shí),它就會(huì)自動(dòng)把圖層的delegate設(shè)置為它自己链峭。并提供一個(gè)-displaylayer:來實(shí)現(xiàn)畦娄,那所有的問題都沒了、

當(dāng)使用寄宿了視圖的圖層的時(shí)候弊仪,你也不必再實(shí)現(xiàn) -displayLayer:和 -drawLayer:inContext:方法來繪制你的寄宿圖熙卡。通常的做法就是實(shí)現(xiàn)UIView中的-drawRect方法,UIView會(huì)幫你做完剩下的工作励饵,包括在需要重繪時(shí)調(diào)用-display方法驳癌。

總結(jié)

本章介紹了寄宿圖和一些相關(guān)的屬性,如何顯示和放置圖片役听。使用拼合技術(shù)來顯示颓鲜。使用CALayerDelegate和CoreGraphics來繪制圖層內(nèi)容。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末典予,一起剝皮案震驚了整個(gè)濱河市甜滨,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌瘤袖,老刑警劉巖衣摩,帶你破解...
    沈念sama閱讀 221,548評(píng)論 6 515
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異捂敌,居然都是意外死亡艾扮,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 94,497評(píng)論 3 399
  • 文/潘曉璐 我一進(jìn)店門占婉,熙熙樓的掌柜王于貴愁眉苦臉地迎上來泡嘴,“玉大人,你說我怎么就攤上這事锐涯】恼铮” “怎么了?”我有些...
    開封第一講書人閱讀 167,990評(píng)論 0 360
  • 文/不壞的土叔 我叫張陵纹腌,是天一觀的道長(zhǎng)霎终。 經(jīng)常有香客問我,道長(zhǎng)升薯,這世上最難降的妖魔是什么莱褒? 我笑而不...
    開封第一講書人閱讀 59,618評(píng)論 1 296
  • 正文 為了忘掉前任,我火速辦了婚禮涎劈,結(jié)果婚禮上广凸,老公的妹妹穿的比我還像新娘。我一直安慰自己蛛枚,他們只是感情好谅海,可當(dāng)我...
    茶點(diǎn)故事閱讀 68,618評(píng)論 6 397
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著蹦浦,像睡著了一般扭吁。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上盲镶,一...
    開封第一講書人閱讀 52,246評(píng)論 1 308
  • 那天侥袜,我揣著相機(jī)與錄音,去河邊找鬼溉贿。 笑死枫吧,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的宇色。 我是一名探鬼主播九杂,決...
    沈念sama閱讀 40,819評(píng)論 3 421
  • 文/蒼蘭香墨 我猛地睜開眼,長(zhǎng)吁一口氣:“原來是場(chǎng)噩夢(mèng)啊……” “哼宣蠕!你這毒婦竟也來了例隆?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 39,725評(píng)論 0 276
  • 序言:老撾萬榮一對(duì)情侶失蹤植影,失蹤者是張志新(化名)和其女友劉穎裳擎,沒想到半個(gè)月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體思币,經(jīng)...
    沈念sama閱讀 46,268評(píng)論 1 320
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡鹿响,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 38,356評(píng)論 3 340
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了谷饿。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片惶我。...
    茶點(diǎn)故事閱讀 40,488評(píng)論 1 352
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖博投,靈堂內(nèi)的尸體忽然破棺而出绸贡,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 36,181評(píng)論 5 350
  • 正文 年R本政府宣布听怕,位于F島的核電站捧挺,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏尿瞭。R本人自食惡果不足惜闽烙,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,862評(píng)論 3 333
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望声搁。 院中可真熱鬧黑竞,春花似錦、人聲如沸疏旨。這莊子的主人今日做“春日...
    開封第一講書人閱讀 32,331評(píng)論 0 24
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽檐涝。三九已至遏匆,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間骤铃,已是汗流浹背拉岁。 一陣腳步聲響...
    開封第一講書人閱讀 33,445評(píng)論 1 272
  • 我被黑心中介騙來泰國(guó)打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留惰爬,地道東北人喊暖。 一個(gè)月前我還...
    沈念sama閱讀 48,897評(píng)論 3 376
  • 正文 我出身青樓,卻偏偏與公主長(zhǎng)得像撕瞧,于是被迫代替她去往敵國(guó)和親陵叽。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 45,500評(píng)論 2 359

推薦閱讀更多精彩內(nèi)容