圖片勝過千言萬語,界面抵得上千圖片 ——Ben Shneiderman
我們在第一章『圖層樹』中介紹了CALayer類并創(chuàng)建了一個簡單的有藍(lán)色背景的圖層。背景顏色還好啦,但是如果它僅僅是展現(xiàn)了一個單調(diào)的顏色未免也太無聊了。事實上CALayer類能夠包含一張你喜歡的圖片,這一章節(jié)我們將來探索CALayer的寄宿圖(即圖層中包含的圖)。
CALayer 有一個屬性叫做contents
,這個屬性的類型被定義為id,意味著它可以是任何類型的對象。在這種情況下,你可以給contents
屬性賦任何值,你的app仍然能夠編譯通過。但是,在實踐中,如果你給contents
賦的不是CGImage,那么你得到的圖層將是空白的。
contents
這個奇怪的表現(xiàn)是由Mac OS的歷史原因造成的。它之所以被定義為id類型,是因為在Mac OS系統(tǒng)上,這個屬性對CGImage和NSImage類型的值都起作用。如果你試圖在iOS平臺上將UIImage的值賦給它,只能得到一個空白的圖層。一些初識Core Animation的iOS開發(fā)者可能會對這個感到困惑。
頭疼的不僅僅是我們剛才提到的這個問題。事實上,你真正要賦值的類型應(yīng)該是CGImageRef,它是一個指向CGImage結(jié)構(gòu)的指針。UIImage有一個CGImage屬性,它返回一個"CGImageRef",如果你想把這個值直接賦值給CALayer的contents
,那你將會得到一個編譯錯誤。因為CGImageRef并不是一個真正的Cocoa對象,而是一個Core Foundation類型。
盡管Core Foundation類型跟Cocoa對象在運(yùn)行時貌似很像(被稱作toll-free bridging),他們并不是類型兼容的,不過你可以通過bridged關(guān)鍵字轉(zhuǎn)換。如果要給圖層的寄宿圖賦值,你可以按照以下這個方法:
layer.contents = (__bridge id)image.CGImage;
如果你沒有使用ARC(自動引用計數(shù)),你就不需要__bridge這部分。但是,你干嘛不用ARC?!
讓我們來繼續(xù)修改我們在第一章新建的工程,以便能夠展示一張圖片而不僅僅是一個背景色。我們已經(jīng)用代碼的方式建立一個圖層,那我們就不需要額外的圖層了。那么我們就直接把layerView的宿主圖層的contents
屬性設(shè)置成圖片。
清單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,它不是我們通常用來展示圖片的方法。通過直接操作圖層,我們使用了一些新的函數(shù),使得UIView更加有趣了。
contentGravity
你可能已經(jīng)注意到了我們的雪人看起來有點(diǎn)。。。胖 ==! 我們加載的圖片并不剛好是一個方的,為了適應(yīng)這個視圖,它有一點(diǎn)點(diǎn)被拉伸了。在使用UIImageView的時候遇到過同樣的問題,解決方法就是把contentMode
屬性設(shè)置成更合適的值,像這樣:
view.contentMode = UIViewContentModeScaleAspectFit;
這個方法基本和我們遇到的情況的解決方法已經(jīng)接近了(你可以試一下 :) ),不過UIView大多數(shù)視覺相關(guān)的屬性比如contentMode
,對這些屬性的操作其實是對對應(yīng)圖層的操作。
CALayer與contentMode
對應(yīng)的屬性叫做contentsGravity
,但是它是一個NSString類型,而不是像對應(yīng)的UIKit部分,那里面的值是枚舉。contentsGravity
可選的常量值有以下一些:
和cotentMode
一樣,contentsGravity
的目的是為了決定內(nèi)容在圖層的邊界中怎么對齊,我們將使用kCAGravityResizeAspect,它的效果等同于UIViewContentModeScaleAspectFit, 同時它還能在圖層中等比例拉伸以適應(yīng)圖層的邊界。
self.layerView.layer.contentsGravity = kCAGravityResizeAspect;
圖2.2 可以看到結(jié)果
圖2.2 正確地設(shè)置contentsGravity
的值
contentsScale
屬性定義了寄宿圖的像素尺寸和視圖大小的比例,默認(rèn)情況下它是一個值為1.0的浮點(diǎn)數(shù)。
contentsScale
的目的并不是那么明顯。它并不是總會對屏幕上的寄宿圖有影響。如果你嘗試對我們的例子設(shè)置不同的值,你就會發(fā)現(xiàn)根本沒任何影響。因為contents
由于設(shè)置了contentsGravity
屬性,所以它已經(jīng)被拉伸以適應(yīng)圖層的邊界。
如果你只是單純地想放大圖層的contents
圖片,你可以通過使用圖層的transform
和affineTransform
屬性來達(dá)到這個目的(見第五章『Transforms』,里面對此有解釋),這(指放大)也不是contentsScale
的目的所在.
contentsScale
屬性其實屬于支持高分辨率(又稱Hi-DPI或Retina)屏幕機(jī)制的一部分。它用來判斷在繪制圖層的時候應(yīng)該為寄宿圖創(chuàng)建的空間大小,和需要顯示的圖片的拉伸度(假設(shè)并沒有設(shè)置contentsGravity
屬性)。UIView有一個類似功能但是非常少用到的contentScaleFactor
屬性。
如果contentsScale
設(shè)置為1.0,將會以每個點(diǎn)1個像素繪制圖片,如果設(shè)置為2.0,則會以每個點(diǎn)2個像素繪制圖片,這就是我們熟知的Retina屏幕。(如果你對像素和點(diǎn)的概念不是很清楚的話,這個章節(jié)的后面部分將會對此做出解釋)。
這并不會對我們在使用kCAGravityResizeAspect時產(chǎn)生任何影響,因為它就是拉伸圖片以適應(yīng)圖層而已,根本不會考慮到分辨率問題。但是如果我們把contentsGravity
設(shè)置為kCAGravityCenter(這個值并不會拉伸圖片),那將會有很明顯的變化(如圖2.3)
圖2.3 用錯誤的contentsScale
屬性顯示Retina圖片
如你所見,我們的雪人不僅有點(diǎn)大還有點(diǎn)像素的顆粒感。那是因為和UIImage不同,CGImage沒有拉伸的概念。當(dāng)我們使用UIImage類去讀取我們的雪人圖片的時候,他讀取了高質(zhì)量的Retina版本的圖片。但是當(dāng)我們用CGImage來設(shè)置我們的圖層的內(nèi)容時,拉伸這個因素在轉(zhuǎn)換的時候就丟失了。不過我們可以通過手動設(shè)置contentsScale
來修復(fù)這個問題(如2.2清單),圖2.4是結(jié)果
@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圖片設(shè)置了正確的contentsScale
之后
當(dāng)用代碼的方式來處理寄宿圖的時候,一定要記住要手動的設(shè)置圖層的contentsScale
屬性,否則,你的圖片在Retina設(shè)備上就顯示得不正確啦。代碼如下:
layer.contentsScale = [UIScreen mainScreen].scale;
現(xiàn)在我們的雪人總算是顯示了正確的大小,不過你也許已經(jīng)發(fā)現(xiàn)了另外一些事情:他超出了視圖的邊界。默認(rèn)情況下,UIView仍然會繪制超過邊界的內(nèi)容或是子視圖,在CALayer下也是這樣的。
UIView有一個叫做clipsToBounds
的屬性可以用來決定是否顯示超出邊界的內(nèi)容,CALayer對應(yīng)的屬性叫做masksToBounds
,把它設(shè)置為YES,雪人就在邊界里啦~(如圖2.5)
圖2.5 使用masksToBounds
來修建圖層內(nèi)容
CALayer的contentsRect
屬性允許我們在圖層邊框里顯示寄宿圖的一個子域。這涉及到圖片是如何顯示和拉伸的,所以要比contentsGravity
靈活多了
和bounds
,frame
不同,contentsRect
不是按點(diǎn)來計算的,它使用了單位坐標(biāo),單位坐標(biāo)指定在0到1之間,是一個相對值(像素和點(diǎn)就是絕對值)。所以他們是相對與寄宿圖的尺寸的。iOS使用了以下的坐標(biāo)系統(tǒng):
默認(rèn)的contentsRect
是{0, 0, 1, 1},這意味著整個寄宿圖默認(rèn)都是可見的,如果我們指定一個小一點(diǎn)的矩形,圖片就會被裁剪(如圖2.6)
圖2.6 一個自定義的contentsRect
(左)和之前顯示的內(nèi)容(右)
事實上給contentsRect
設(shè)置一個負(fù)數(shù)的原點(diǎn)或是大于{1, 1}的尺寸也是可以的。這種情況下,最外面的像素會被拉伸以填充剩下的區(qū)域。
contentsRect
在app中最有趣的地方在于一個叫做image sprites(圖片拼合)的用法。如果你有游戲編程的經(jīng)驗,那么你一定對圖片拼合的概念很熟悉,圖片能夠在屏幕上獨(dú)立地變更位置。拋開游戲編程不談,這個技術(shù)常用來指代載入拼合的圖片,跟移動圖片一點(diǎn)關(guān)系也沒有。
典型地,圖片拼合后可以打包整合到一張大圖上一次性載入。相比多次載入不同的圖片,這樣做能夠帶來很多方面的好處:內(nèi)存使用,載入時間,渲染性能等等
2D游戲引擎入Cocos2D使用了拼合技術(shù),它使用OpenGL來顯示圖片。不過我們可以使用拼合在一個普通的UIKit應(yīng)用中,對!就是使用contentsRect
首先,我們需要一個拼合后的圖表 —— 一個包含小一些的拼合圖的大圖片。如圖2.7所示:
接下來,我們要在app中載入并顯示這些拼合圖。規(guī)則很簡單:像平常一樣載入我們的大圖,然后把它賦值給四個獨(dú)立的圖層的contents
,然后設(shè)置每個圖層的contentsRect
來去掉我們不想顯示的部分。
我們的工程中需要一些額外的視圖。(為了避免太多代碼。我們將使用Interface Builder來拜訪他們的位置,如果你愿意還是可以用代碼的方式來實現(xiàn)的)。清單2.3有需要的代碼,圖2.8展示了結(jié)果
@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提供了一個整潔的載入方式,還有效地提高了載入性能(單張大圖比多張小圖載入地更快),但是如果有手動安排的話,他們還是有一些不方便的,如果你需要在一個已經(jīng)創(chuàng)建好的品和圖上做一些尺寸上的修改或者其他變動,無疑是比較麻煩的。
Mac上有一些商業(yè)軟件可以為你自動拼合圖片,這些工具自動生成一個包含拼合后的坐標(biāo)的XML或者plist文件,拼合圖片的使用大大簡化。這個文件可以和圖片一同載入,并給每個拼合的圖層設(shè)置contentsRect
,這樣開發(fā)者就不用手動寫代碼來擺放位置了。
這些文件通常在OpenGL游戲中使用,不過呢,你要是有興趣在一些常見的app中使用拼合技術(shù),那么一個叫做LayerSprites的開源庫(https://github.com/nicklockwood/LayerSprites),它能夠讀取Cocos2D格式中的拼合圖并在普通的Core Animation層中顯示出來。
本章我們介紹的最后一個和內(nèi)容有關(guān)的屬性是contentsCenter
,看名字你可能會以為它可能跟圖片的位置有關(guān),不過這名字著實誤導(dǎo)了你。contentsCenter
其實是一個CGRect,它定義了一個固定的邊框和一個在圖層上可拉伸的區(qū)域。 改變contentsCenter
的值并不會影響到寄宿圖的顯示,除非這個圖層的大小改變了,你才看得到效果。
默認(rèn)情況下,contentsCenter
是{0, 0, 1, 1},這意味著如果大?。ㄓ?code>conttensGravity決定)改變了,那么寄宿圖將會均勻地拉伸開。但是如果我們增加原點(diǎn)的值并減小尺寸。我們會在圖片的周圍創(chuàng)造一個邊框。圖2.9展示了contentsCenter
設(shè)置為{0.25, 0.25, 0.5, 0.5}的效果。
圖2.9 contentsCenter
的例子
這意味著我們可以隨意重設(shè)尺寸,邊框仍然會是連續(xù)的。他工作起來的效果和UIImage里的-resizableImageWithCapInsets: 方法效果非常類似,只是它可以運(yùn)用到任何寄宿圖,甚至包括在Core Graphics運(yùn)行時繪制的圖形(本章稍后會講到)。
圖2.10 同一圖片使用不同的contentsCenter
清單2.4 演示了如何編寫這些可拉伸視圖。不過,contentsCenter的另一個很酷的特性就是,它可以在Interface Builder里面配置,根本不用寫代碼。如圖2.11
清單2.4 用contentsCenter
設(shè)置可拉伸視圖
@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
屬性
給contents
賦CGImage的值不是唯一的設(shè)置寄宿圖的方法。我們也可以直接用Core Graphics直接繪制寄宿圖。能夠通過繼承UIView并實現(xiàn)-drawRect:
方法來自定義繪制。
-drawRect:
方法沒有默認(rèn)的實現(xiàn),因為對UIView來說,寄宿圖并不是必須的,它不在意那到底是單調(diào)的顏色還是有一個圖片的實例。如果UIView檢測到-drawRect:
方法被調(diào)用了,它就會為視圖分配一個寄宿圖,這個寄宿圖的像素尺寸等于視圖大小乘以 contentsScale
的值。
如果你不需要寄宿圖,那就不要創(chuàng)建這個方法了,這會造成CPU資源和內(nèi)存的浪費(fèi),這也是為什么蘋果建議:如果沒有自定義繪制的任務(wù)就不要在子類中寫一個空的-drawRect:方法。
當(dāng)視圖在屏幕上出現(xiàn)的時候 -drawRect:
方法就會被自動調(diào)用。-drawRect:
方法里面的代碼利用Core Graphics去繪制一個寄宿圖,然后內(nèi)容就會被緩存起來直到它需要被更新(通常是因為開發(fā)者調(diào)用了-setNeedsDisplay
方法,盡管影響到表現(xiàn)效果的屬性值被更改時,一些視圖類型會被自動重繪,如bounds
屬性)。雖然-drawRect:
方法是一個UIView方法,事實上都是底層的CALayer安排了重繪工作和保存了因此產(chǎn)生的圖片。
CALayer有一個可選的delegate
屬性,實現(xiàn)了CALayerDelegate
協(xié)議,當(dāng)CALayer需要一個內(nèi)容特定的信息時,就會從協(xié)議中請求。CALayerDelegate是一個非正式協(xié)議,其實就是說沒有CALayerDelegate @protocol可以讓你在類里面引用啦。你只需要調(diào)用你想調(diào)用的方法,CALayer會幫你做剩下的。(delegate
屬性被聲明為id類型,所有的代理方法都是可選的)。
當(dāng)需要被重繪時,CALayer會請求它的代理給他一個寄宿圖來顯示。它通過調(diào)用下面這個方法做到的:
(void)displayLayer:(CALayerCALayer *)layer;
趁著這個機(jī)會,如果代理想直接設(shè)置contents
屬性的話,它就可以這么做,不然沒有別的方法可以調(diào)用了。如果代理不實現(xiàn)-displayLayer:
方法,CALayer就會轉(zhuǎn)而嘗試調(diào)用下面這個方法:
- (void)drawLayer:(CALayer *)layer inContext:(CGContextRef)ctx;
在調(diào)用這個方法之前,CALayer創(chuàng)建了一個合適尺寸的空寄宿圖(尺寸由bounds
和contentsScale
決定)和一個Core Graphics的繪制上下文環(huán)境,為繪制寄宿圖做準(zhǔn)備,他作為ctx參數(shù)傳入。
讓我們來繼續(xù)第一章的項目讓它實現(xiàn)CALayerDelegate并做一些繪圖工作吧(見清單2.5).圖2.12是他的結(jié)果
清單2.5 實現(xiàn)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 實現(xiàn)CALayerDelegate來繪制圖層
注意一下一些有趣的事情:
-display
。不同于UIView,當(dāng)圖層顯示在屏幕上時,CALayer不會自動重繪它的內(nèi)容。它把重繪的決定權(quán)交給了開發(fā)者。masksToBounds
屬性,繪制的那個圓仍然沿邊界被裁剪了。這是因為當(dāng)你使用CALayerDelegate繪制寄宿圖的時候,并沒有對超出邊界外的內(nèi)容提供繪制支持。現(xiàn)在你理解了CALayerDelegate,并知道怎么使用它。但是除非你創(chuàng)建了一個單獨(dú)的圖層,你幾乎沒有機(jī)會用到CALayerDelegate協(xié)議。因為當(dāng)UIView創(chuàng)建了它的宿主圖層時,它就會自動地把圖層的delegate設(shè)置為它自己,并提供了一個-displayLayer:
的實現(xiàn),那所有的問題就都沒了。
當(dāng)使用寄宿了視圖的圖層的時候,你也不必實現(xiàn)-displayLayer:
和-drawLayer:inContext:
方法來繪制你的寄宿圖。通常做法是實現(xiàn)UIView的-drawRect:
方法,UIView就會幫你做完剩下的工作,包括在需要重繪的時候調(diào)用-display
方法。
本章介紹了寄宿圖和一些相關(guān)的屬性。你學(xué)到了如何顯示和放置圖片, 使用拼合技術(shù)來顯示, 以及用CALayerDelegate和Core Graphics來繪制圖層內(nèi)容。
在第三章,"圖層幾何學(xué)"中,我們將會探討一下圖層的幾何,觀察他們是如何放置和改變相互的尺寸的。
更多建議: