iOS-Core-Animation之三----圖層幾何學(xué)

>*不熟悉幾何學(xué)的人就不要來這里了* --柏拉圖學(xué)院入口的簽名

在第二章里面,我們介紹了圖層背后的圖片,和一些控制圖層坐標和旋轉(zhuǎn)的屬性。在這一章中,我們將要看一看圖層內(nèi)部是如何根據(jù)父圖層和兄弟圖層來控制位置和尺寸的。另外我們也會涉及如何管理圖層的幾何結(jié)構(gòu),以及它是如何被自動調(diào)整和自動布局影響的。

##布局

`UIView`有三個比較重要的布局屬性:`frame`,`bounds`和`center`,`CALayer`對應(yīng)地叫做`frame`,`bounds`和`position`。為了能清楚區(qū)分,圖層用了“position”,視圖用了“center”,但是他們都代表同樣的值。

`frame`代表了圖層的外部坐標(也就是在父圖層上占據(jù)的空間),`bounds`是內(nèi)部坐標({0, 0}通常是圖層的左上角),`center`和`position`都代表了相對于父圖層`anchorPoint`所在的位置。`anchorPoint`的屬性將會在后續(xù)介紹到,現(xiàn)在把它想成圖層的中心點就好了。圖3.1顯示了這些屬性是如何相互依賴的。

圖3.1`UIView`和`CALayer`的坐標系

視圖的`frame`,`bounds`和`center`屬性僅僅是*存取方法*,當(dāng)操縱視圖的`frame`,實際上是在改變位于視圖下方`CALayer`的`frame`,不能夠獨立于圖層之外改變視圖的`frame`。

對于視圖或者圖層來說,`frame`并不是一個非常清晰的屬性,它其實是一個虛擬屬性,是根據(jù)`bounds`,`position`和`transform`計算而來,所以當(dāng)其中任何一個值發(fā)生改變,frame都會變化。相反,改變frame的值同樣會影響到他們當(dāng)中的值

記住當(dāng)對圖層做變換的時候,比如旋轉(zhuǎn)或者縮放,`frame`實際上代表了覆蓋在圖層旋轉(zhuǎn)之后的整個軸對齊的矩形區(qū)域,也就是說`frame`的寬高可能和`bounds`的寬高不再一致了(圖3.2)

圖3.2旋轉(zhuǎn)一個視圖或者圖層之后的`frame`屬性

##錨點

之前提到過,視圖的`center`屬性和圖層的`position`屬性都指定了相對于父圖層`anchorPoint`的位置。圖層的`anchorPoint`通過`position`來控制它的`frame`的位置,你可以認為`anchorPoint`是用來移動圖層的*把柄*。

默認來說,`anchorPoint`位于圖層的中點,所以圖層的將會以這個點為中心放置。`anchorPoint`屬性并沒有被`UIView`接口暴露出來,這也是視圖的position屬性被叫做“center”的原因。但是圖層的`anchorPoint`可以被移動,比如你可以把它置于圖層`frame`的左上角,于是圖層的內(nèi)容將會向右下角的`position`方向移動(圖3.3),而不是居中了。

圖3.3改變`anchorPoint`的效果

和第二章提到的`contentsRect`和`contentsCenter`屬性類似,`anchorPoint`用*單位坐標*來描述,也就是圖層的相對坐標,圖層左上角是{0, 0},右下角是{1, 1},因此默認坐標是{0.5, 0.5}。`anchorPoint`可以通過指定x和y值小于0或者大于1,使它放置在圖層范圍之外。

注意在圖3.3中,當(dāng)改變了`anchorPoint`,`position`屬性保持固定的值并沒有發(fā)生改變,但是`frame`卻移動了。

那在什么場合需要改變`anchorPoint`呢?既然我們可以隨意改變圖層位置,那改變`anchorPoint`不會造成困惑么?為了舉例說明,我們來舉一個實用的例子,創(chuàng)建一個模擬鬧鐘的項目。

鐘面和鐘表由四張圖片組成(圖3.4),為了簡單說明,我們還是用傳統(tǒng)的方式來裝載和加載圖片,使用四個`UIImageView`實例(當(dāng)然你也可以用正常的視圖,設(shè)置他們圖層的`contents`圖片)。

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

鬧鐘的組件通過IB來排列(圖3.5),這些圖片視圖嵌套在一個容器視圖之內(nèi),并且自動調(diào)整和自動布局都被禁用了。這是因為自動調(diào)整會影響到視圖的`frame`,而根據(jù)圖3.2的演示,當(dāng)視圖旋轉(zhuǎn)的時候,`frame`是會發(fā)生改變的,這將會導(dǎo)致一些布局上的失靈。

我們用`NSTimer`來更新鬧鐘,使用視圖的`transform`屬性來旋轉(zhuǎn)鐘表(如果你對這個屬性不太熟悉,不要著急,我們將會在第5章“變換”當(dāng)中詳細說明),具體代碼見清單3.1

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

清單3.1 **Clock**

```objective-c

@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),因為鐘表的圖片在圍繞著中心旋轉(zhuǎn),這并不是我們期待的一個支點。

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

你也許會認為可以在Interface Builder當(dāng)中調(diào)整指針圖片的位置來解決,但其實并不能達到目的,因為如果不放在鐘面中間的話,同樣不能正確的旋轉(zhuǎn)。

也許在圖片末尾添加一個透明空間也是個解決方案,但這樣會讓圖片變大,也會消耗更多的內(nèi)存,這樣并不優(yōu)雅。

更好的方案是使用`anchorPoint`屬性,我們來在`-viewDidLoad`方法中添加幾行代碼來給每個鐘指針的`anchorPoint`做一些平移(清單3.2),圖3.7顯示了正確的結(jié)果。

清單3.2

```objective-c

- (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鐘面,和正確對齊的鐘指針

##坐標系

和視圖一樣,圖層在圖層樹當(dāng)中也是相對于父圖層按層級關(guān)系放置,一個圖層的`position`依賴于它父圖層的`bounds`,如果父圖層發(fā)生了移動,它的所有子圖層也會跟著移動。

這樣對于放置圖層會更加方便,因為你可以通過移動根圖層來將它的子圖層作為一個整體來移動,但是有時候你需要知道一個圖層的*絕對*位置,或者是相對于另一個圖層的位置,而不是它當(dāng)前父圖層的位置。

`CALayer`給不同坐標系之間的圖層轉(zhuǎn)換提供了一些工具類方法:

- (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;

這些方法可以把定義在一個圖層坐標系下的點或者矩形轉(zhuǎn)換成另一個圖層坐標系下的點或者矩形

###翻轉(zhuǎn)的幾何結(jié)構(gòu)

常規(guī)說來,在iOS上,一個圖層的`position`位于父圖層的左上角,但是在Mac OS上,通常是位于左下角。Core Animation可以通過`geometryFlipped`屬性來適配這兩種情況,它決定了一個圖層的坐標是否相對于父圖層垂直翻轉(zhuǎn),是一個`BOOL`類型。在iOS上通過設(shè)置它為`YES`意味著它的子圖層將會被垂直翻轉(zhuǎn),也就是將會沿著底部排版而不是通常的頂部(它的所有子圖層也同理,除非把它們的`geometryFlipped`屬性也設(shè)為`YES`)。

###Z坐標軸

和`UIView`嚴格的二維坐標系不同,`CALayer`存在于一個三維空間當(dāng)中。除了我們已經(jīng)討論過的`position`和`anchorPoint`屬性之外,`CALayer`還有另外兩個屬性,`zPosition`和`anchorPointZ`,二者都是在Z軸上描述圖層位置的浮點類型。

注意這里并沒有更*深*的屬性來描述由寬和高做成的`bounds`了,圖層是一個完全扁平的對象,你可以把它們想象成類似于一頁二維的堅硬的紙片,用膠水粘成一個空洞,就像三維結(jié)構(gòu)的折紙一樣。

`zPosition`屬性在大多數(shù)情況下其實并不常用。在第五章,我們將會涉及`CATransform3D`,你會知道如何在三維空間移動和旋轉(zhuǎn)圖層,除了做變換之外,`zPosition`最實用的功能就是改變圖層的*顯示順序*了。

通常,圖層是根據(jù)它們子圖層的`sublayers`出現(xiàn)的順序來類繪制的,這就是所謂的*畫家的算法*--就像一個畫家在墻上作畫--后被繪制上的圖層將會遮蓋住之前的圖層,但是通過增加圖層的`zPosition`,就可以把圖層向相機方向*前置*,于是它就在所有其他圖層的*前面*了(或者至少是小于它的`zPosition`值的圖層的前面)。

這里所謂的“相機”實際上是相對于用戶是視角,這里和iPhone背后的內(nèi)置相機沒任何關(guān)系。

圖3.8顯示了在Interface Builder內(nèi)的一對視圖,正如你所見,首先出現(xiàn)在視圖層級綠色的視圖被繪制在紅色視圖的后面。

圖3.8在視圖層級中綠色視圖被繪制在紅色視圖的后面

我們希望在真實的應(yīng)用中也能顯示出繪圖的順序,同樣地,如果我們提高綠色視圖的`zPosition`(清單3.3),我們會發(fā)現(xiàn)順序就反了(圖3.9)。其實并不需要增加太多,視圖都非常地薄,所以給`zPosition`提高一個像素就可以讓綠色視圖前置,當(dāng)然0.1或者0.0001也能夠做到,但是最好不要這樣,因為浮點類型四舍五入的計算可能會造成一些不便的麻煩。

清單3.3

```objective-c

@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

第一章“圖層樹”證實了最好使用圖層相關(guān)視圖,而不是創(chuàng)建獨立的圖層關(guān)系。其中一個原因就是要處理額外復(fù)雜的觸摸事件。

`CALayer`并不關(guān)心任何響應(yīng)鏈事件,所以不能直接處理觸摸事件或者手勢。但是它有一系列的方法幫你處理事件:`-containsPoint:`和`-hitTest:`。

`-containsPoint:`接受一個在本圖層坐標系下的`CGPoint`,如果這個點在圖層`frame`范圍內(nèi)就返回`YES`。如清單3.4所示第一章的項目的另一個合適的版本,也就是使用`-containsPoint:`方法來判斷到底是白色還是藍色的圖層被觸摸了

(圖3.10)。這需要把觸摸坐標轉(zhuǎn)換成每個圖層坐標系下的坐標,結(jié)果很不方便。

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

```objective-c

@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`類型參數(shù),而不是`BOOL`類型,它返回圖層本身,或者包含這個坐標點的葉子節(jié)點圖層。這意味著不再需要像使用`-containsPoint:`那樣,人工地在每個子圖層變換或者測試點擊的坐標。如果這個點在最外面圖層的范圍之外,則返回nil。具體使用`-hitTest:`方法被點擊圖層的代碼如清單3.5所示。

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

```objective-c

- (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];

}

}

```

注意當(dāng)調(diào)用圖層的`-hitTest:`方法時,測算的順序嚴格依賴于圖層樹當(dāng)中的圖層順序(和UIView處理事件類似)。之前提到的`zPosition`屬性可以明顯改變屏幕上圖層的順序,但不能改變事件傳遞的順序。

這意味著如果改變了圖層的z軸順序,你會發(fā)現(xiàn)將不能夠檢測到最前方的視圖點擊事件,這是因為被另一個圖層遮蓋住了,雖然它的`zPosition`值較小,但是在圖層樹中的順序靠前。我們將在第五章詳細討論這個問題。

##自動布局

你可能用過`UIViewAutoresizingMask`類型的一些常量,應(yīng)用于當(dāng)父視圖改變尺寸的時候,相應(yīng)`UIView`的`frame`也跟著更新的場景(通常用于橫豎屏切換)。

在iOS6中,蘋果介紹了*自動排版*機制,它和自動調(diào)整不同,并且更加復(fù)雜。

在Mac OS平臺,`CALayer`有一個叫做`layoutManager`的屬性可以通過`CALayoutManager`協(xié)議和`CAConstraintLayoutManager`類來實現(xiàn)自動排版的機制。但由于某些原因,這在iOS上并不適用。

當(dāng)使用視圖的時候,可以充分利用`UIView`類接口暴露出來的`UIViewAutoresizingMask`和`NSLayoutConstraint`API,但如果想隨意控制`CALayer`的布局,就需要手工操作。最簡單的方法就是使用`CALayerDelegate`如下函數(shù):

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

當(dāng)圖層的`bounds`發(fā)生改變,或者圖層的`-setNeedsLayout`方法被調(diào)用的時候,這個函數(shù)將會被執(zhí)行。這使得你可以手動地重新擺放或者重新調(diào)整子圖層的大小,但是不能像`UIView`的`autoresizingMask`和`constraints`屬性做到自適應(yīng)屏幕旋轉(zhuǎn)。

這也是為什么最好使用視圖而不是單獨的圖層來構(gòu)建應(yīng)用程序的另一個重要原因之一。

##總結(jié)

本章涉及了`CALayer`的集合結(jié)構(gòu),包括它的`frame`,`position`和`bounds`,介紹了三維空間內(nèi)圖層的概念,以及如何在獨立的圖層內(nèi)響應(yīng)事件,最后簡單說明了在iOS平臺,Core Animation對自動調(diào)整和自動布局支持的缺乏。

在第四章“視覺效果”當(dāng)中,我們接著介紹一些圖層外表的特性。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,501評論 6 544
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 99,673評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,610評論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,939評論 1 318
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 72,668評論 6 412
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 56,004評論 1 329
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 44,001評論 3 449
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 43,173評論 0 290
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 49,705評論 1 336
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 41,426評論 3 359
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,656評論 1 374
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,139評論 5 364
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 44,833評論 3 350
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,247評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,580評論 1 295
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,371評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 48,621評論 2 380

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