iOS 中 UIView 和 CALayer 的關係

時間  2021-08-14
標籤 html git github 編程 swift markdown app 框架 iview async 欄目 iOS 简体版
原文   原文鏈接

UIView 有一個名叫 layer ，類型爲 CALayer 的對象屬性，它們的行爲很類似，主要區別在於：CALayer 繼承自 NSObject ，不可以響應事件。html

這是由於 UIView 除了負責響應事件 ( 繼承自 UIReponder ) 外，它仍是一個對 CALayer 的底層封裝。能夠說，它們的類似行爲都依賴於 CALayer 的實現，UIView 只不過是封裝了它的高級接口而已。git

那 CALayer 是什麼呢？github

CALayer（圖層）

文檔對它定義是：管理基於圖像內容的對象，容許您對該內容執行動畫。編程

概念

圖層一般用於爲 view 提供後備存儲，但也能夠在沒有 view 的狀況下使用以顯示內容。圖層的主要工做是管理您提供的可視內容，但圖層自己能夠設置可視屬性（例如背景顏色、邊框和陰影）。除了管理可視內容外，該圖層還維護有關內容幾何的信息（例如位置、大小和變換），用於在屏幕上顯示該內容。swift

和 UIView 之間的關係

示例1 - layer 影響視圖的變化：markdown

let view = UIView(frame: CGRect(x: 44, y: 44, width: UIScreen.width - 88, height: 300))
view.backgroundColor = .red
view.layer.backgroundColor = UIColor.orange.cgColor

print("view: \(view.backgroundColor!)")
print("layer: \(view.layer.backgroundColor!)")

// Prints "view: 1 0.5 0 1"
// Prints "layer: 1 0.5 0 1"

view.layer.frame.origin.y = 100

print("view: \(view.frame.origin.y)")
print("layer: \(view.layer.frame.origin.y)")

// Prints "view: 100"
// Prints "layer: 100"
複製代碼

能夠看到，不管是修改了 layer 的可視內容或是幾何信息，view 都會跟着變化，反之也是如此。這就證實：UIView 依賴於 CALayer 得以顯示。app

既然他們的行爲如此類似，爲何不直接用一個 UIView 或 CALayer 處理全部事件呢？主要是基於兩點考慮：框架

  1. 職責不一樣iview

    UIVIew 的主要職責是負責接收並響應事件；而 CALayer 的主要職責是負責顯示 UI。async

  2. 須要複用

    在 macOS 和 App 系統上，NSView 和 UIView 雖然行爲類似，在實現上卻有着顯著的區別，卻又都依賴於 CALayer 。在這種狀況下，只能封裝一個 CALayer 出來。

CALayerDelegate

你可使用 delegate (CALayerDelegate) 對象來提供圖層的內容，處理任何子圖層的佈局，並提供自定義操做以響應與圖層相關的更改。若是圖層是由 UIView 建立的，則該 UIView 對象一般會自動指定爲圖層的委託。

注意：

  1. 在 iOS 中，若是圖層與 UIView 對象關聯，則必須將此屬性設置爲擁有該圖層的 UIView 對象。
  2. delegate 只是另外一種爲圖層提供處理內容的方式，並非惟一的。UIView 的顯示跟它圖層委託沒有太大關係。

  1. func display(_ layer: CALayer)

    當圖層標記其內容爲須要更新 ( setNeedsDisplay() ) 時，調用此方法。例如，爲圖層設置 contents 屬性：

    let delegate = LayerDelegate()
     
lazy var sublayer: CALayer = {
    let layer = CALayer()
    layer.delegate = self.delegate
    return layer
}()
     
// 調用 `sublayer.setNeedsDisplay()` 時，會調用 `sublayer.display(_:)`。
class LayerDelegate: NSObject, CALayerDelegate {
    func display(_ layer: CALayer) {
        layer.contents = UIImage(named: "rabbit.png")?.cgImage
    }
}
複製代碼

    那什麼是 contents 呢？contents 被定義爲是一個 Any 類型，但實際上它只做用於 CGImage 。形成這種奇怪的緣由是，在 macOS 系統上，它能接受 CGImage 和 NSImage 兩種類型的對象。

    你能夠把它想象中 UIImageView 中的 image 屬性，其實是，UIImageView 在內部經過轉換，將 image.cgImage 賦值給了 contents 。

    注意：

    若是是 view 的圖層，應避免直接設置此屬性的內容。視圖和圖層之間的相互做用一般會致使視圖在後續更新期間替換此屬性的內容。

  2. func draw(_ layer: CALayer, in ctx: CGContext)

    和 display(_:) 同樣，可是可使用圖層的 CGContext 來實現顯示的過程（官方示例）：

    // sublayer.setNeedsDisplay()
class LayerDelegate: NSObject, CALayerDelegate {
    func draw(_ layer: CALayer, in ctx: CGContext) {
        ctx.addEllipse(in: ctx.boundingBoxOfClipPath)
        ctx.strokePath()
    }
}
複製代碼

    • 和 view 中 draw(_ rect: CGRect) 的關係

      文檔對其的解釋大概是：

      此方法默認不執行任何操做。使用 Core Graphics 和 UIKit 等技術繪製視圖內容的子類應重寫此方法，並在其中實現其繪圖代碼。 若是視圖以其餘方式設置其內容，則無需覆蓋此方法。 例如，若是視圖僅顯示背景顏色，或是使用基礎圖層對象直接設置其內容等。

      調用此方法時，在調用此方法的時候，UIKit 已經配置好了繪圖環境。具體來講，UIKit 建立並配置用於繪製的圖形上下文，並調整該上下文的變換，使其原點與視圖邊界矩形的原點匹配。可使用 UIGraphicsGetCurrentContext() 函數獲取對圖形上下文的引用（非強引用）。

      那它是如何建立並配置繪圖環境的？我在調查它們的關係時發現：

      /// 注：此方法默認不執行任何操做，調用 super.draw(_:) 與否並沒有影響。
override func draw(_ rect: CGRect) {
    print(#function)
}

override func draw(_ layer: CALayer, in ctx: CGContext) {
    print(#function)
}

// Prints "draw(_:in:)"
複製代碼

      這種狀況下，只輸出圖層的委託方法，而屏幕上沒有任何 view 的畫面顯示。而若是調用圖層的 super.draw(_:in:) 方法：

      /// 注：此方法默認不執行任何操做，調用 super.draw(_:) 與否並沒有影響。
override func draw(_ rect: CGRect) {
    print(#function)
}

override func draw(_ layer: CALayer, in ctx: CGContext) {
    print(#function)
    super.draw(layer, in: ctx)
}

// Prints "draw(_:in:)"
// Prints "draw"
複製代碼

      屏幕上有 view 的畫面顯示，爲何呢？首先咱們要知道，在調用 view 的 draw(_:in:) 時，它須要一個載體/畫板/圖形上下文 ( UIGraphicsGetCurrentContext ) 來進行繪製操做。因此我猜想是，這個 UIGraphicsGetCurrentContext 是在圖層的 super.draw(_:in:) 方法裏面建立和配置的。

      具體的調用順序是：

      1. 首先調用圖層的 draw(_:in:) 方法；
      2. 隨後在 super.draw(_:in:) 方法裏面建立並配置好繪圖環境；
      3. 經過圖層的 super.draw(_:in:) 調用 view 的 draw(_:) 方法。

      此外，還有另外一種狀況是：

      override func draw(_ layer: CALayer, in ctx: CGContext) {
    print(#function)
}
複製代碼

      只實現一個圖層的 draw(_:in:) 方法，而且沒有繼續調用它的 super.draw(_:in:) 來建立繪圖環境。那在沒有繪圖環境的時候，view 能顯示嗎？答案是能夠的！這是由於：view 的顯示不依賴於 UIGraphicsGetCurrentContext ，只有在繪製的時候才須要。

    • 和 contents 之間的關係

      通過測試發現，調用 view 中 draw(_ rect: CGRect) 方法的全部繪製操做，都被保存在其圖層的 contents 屬性中：

      // ------ LayerView.swift ------
override func draw(_ rect: CGRect) {
    UIColor.brown.setFill()	// 填充
    UIRectFill(rect)

    UIColor.white.setStroke()	// 描邊
    let frame = CGRect(x: 20, y: 20, width: 80, height: 80)
    UIRectFrame(frame)
}

// ------ ViewController.swift ------
DispatchQueue.main.asyncAfter(deadline: .now() + 2) {
    print("contents: \(self.layerView.layer.contents)")
}

// Prints "Optional(<CABackingStore 0x7faf91f06e20 (buffer [480 256] BGRX8888)>)"
複製代碼

      這也是爲何要 CALayer 提供繪圖環境、以及在上面介紹 contents 這個屬性時須要注意的地方。

      重要：

      若是委託實現了 display(_ :) ，將不會調用此方法。

    • 和 display(_ layer: CALayer) 之間的關係

      前面說過，view 的 draw(_:) 方法是由它圖層的 draw(_:in:) 方法調用的。可是若是咱們實現的是 display(_:) 而不是 draw(_:in:) 呢？這意味着 draw(_:in:) 失去了它的做用，在沒有上下文的支持下，屏幕上將不會有任何關於 view 的畫面顯示，而 display(_:) 也不會自動調用 view 的 draw(_:) ，view 的 draw(_:) 方法也失去了意義，那 display(_ layer: CALayer) 的做用是什麼？例如：

      override func draw(_ rect: CGRect) {
    print(#function)
}

override func display(_ layer: CALayer) {
    print(#function)
}

// Prints "display"
複製代碼

      這裏 draw(_:) 沒有被調用，屏幕上也沒有相關 view 的顯示。也就是說，此時除了在 display(_:) 上進行操做外，已經沒有任何相關的地方能夠設置圖層的可視內容了（參考 "1. func display(_ layer: CALayer)"，這裏再也不贅述，固然也能夠設置背景顏色等）。固然，你可能永遠都不會這麼作，除非你建立了一個單獨的圖層。

      至於爲何不在 display(_ layer: CALayer) 方法裏面調用它的父類實現，這是由於若是調用了會崩潰：

      // unrecognized selector sent to instance 0x7fbcdad03ba0
複製代碼

      至於爲何？根據個人參考資料，他們都沒有在此繼續調用 super ( UIView ) 的方法。我隨意猜想一下是這樣的：

      首先錯誤提示的意思翻譯過來就是：沒法識別的選擇器（方法）發送到實例。那咱們來分析一下，是哪個實例中？是什麼方法？

      1. 是 super 實例；
      2. 是 display(_ layer: CALayer) 。

      也就是說，在調用 super.display(_ layer: CALayer) 方法的時候，super 中找不到該方法。爲何呢？請注意 UIView 默認已經遵循了 CALayerDelegate 協議（右鍵點擊 UIView 查看頭文件），可是應該沒有實現它的 display(_:) 方法，而是選擇交給了子類去實現。相似的實現應該是：

      // 示意 `CALayerDelegate`
@objc protocol LayerDelegate: NSObjectProtocol {
    @objc optional func display()
    @objc optional func draw()
}

// 示意 `CALayer`
class Layer: NSObject {
    var delegate: LayerDelegate?
}

// 示意 `UIView`
class BaseView: NSObject, LayerDelegate {
    let layer = Layer()
    override init() {
        super.init()
        layer.delegate = self
    }
}
// 注意：並無實現委託的 `display()` 方法。
extension BaseView: LayerDelegate {
    func draw() {}
}

// 示意 `UIView` 的子類
class LayerView: BaseView {
    func display() {
        // 一樣的代碼在OC上實現沒有問題。
        // 因爲Swift是靜態編譯的關係，它會檢測在 `BaseView` 類中有沒有這個方法，
        // 若是沒有就會提示編譯錯誤。
        super.display()
    }
}

// ------ ViewController.swift ------
let layerView = LayerView()
// 若是在方法裏面調用了 `super.display()` 將引起崩潰。
layerView.display()
// 正常執行
layerView.darw()
複製代碼

    注意：

    只有當系統在檢測到 view 的 draw(_:) 方法被實現時，纔會自動調用圖層的 display(_:) 或 draw(_ rect: CGRect) 方法。不然就必須經過手動調用圖層的 setNeedsDisplay() 方法來調用。

  3. func layerWillDraw(_ layer: CALayer)

    在 draw(_ layer: CALayer, in ctx: CGContext) 調用以前調用，可使用此方法配置影響內容的任何圖層狀態（例如 contentsFormat 和 isOpaque ）。

  4. func layoutSublayers(of layer: CALayer)

    和 UIView 的 layoutSubviews() 相似。當發現邊界發生變化而且其 sublayers 可能須要從新排列時（例如經過 frame 改變大小），將調用此方法。

  5. func action(for layer: CALayer, forKey event: String) -> CAAction?

    CALayer 之因此可以執行動畫，是由於它被定義在 Core Animation 框架中，是 Core Animation 執行操做的核心。也就是說，CALayer 除了負責顯示內容外，還能執行動畫（實際上是 Core Animation 與硬件之間的操做在執行，CALayer 負責存儲操做須要的數據，至關於 Model）。所以，使用 CALayer 的大部分屬性都附帶動畫效果。可是在 UIView 中，默認將這個效果給關掉了，能夠經過它圖層的委託方法從新開啓 ( 在 view animation block 中也會自動開啓 )，返回決定它動畫特效的對象，若是返回的是 nil ，將使用默認隱含的動畫特效。

    示例 - 使用圖層的委託方法返回一個從左到右移動對象的基本動畫：

    final class CustomView: UIView {
    override func action(for layer: CALayer, forKey event: String) -> CAAction? {
        guard event == "moveRight" else {
            return super.action(for: layer, forKey: event)
        }
        let animation = CABasicAnimation()
        animation.valueFunction = CAValueFunction(name: .translateX)
        animation.fromValue = 1
        animation.toValue = 300
        animation.duration = 2
        return animation
    }
}

let view = CustomView(frame: CGRect(x: 44, y: 44, width: UIScreen.width - 88, height: 300))
view.backgroundColor = .orange
self.view.addSubview(view)

let action = view.layer.action(forKey: "moveRight")
action?.run(forKey: "transform", object: view.layer, arguments: nil)
複製代碼

    那怎麼知道它的哪些屬性是能夠附帶動畫的呢？核心動畫編程指南列出了你可能須要考慮設置動畫的 CALayer 屬性：

CALayer 座標系

CALayer 具備除了 frame 、bounds 以外區別於 UIView 的其餘位置屬性。UIView 使用的所謂 frame 、bounds 、center 等屬性，其實都是從 CALayer 中返回的，而 frame 只是 CALayer 中的一個計算型屬性而已。

這裏主要說一下 CALayer 中的 anchorPoint 和 position 這兩個屬性，也是 CALayer 座標系中的主要依賴：

  • var anchorPoint: CGPoint ( 錨點 )

    圖層錨點示意圖

    看 iOS 部分便可。能夠看出，錨點是基於圖層的內部座標，它取值範圍是 (0-1, 0-1) ，你能夠把它想象成是 bounds 的縮放因子。中間的 (0.5, 0.5) 是每一個圖層的 anchorPoint 默認值；而左上角的 (0.0, 0.0) 被視爲是 anchorPoint 的起始點。

    任何基於圖層的幾何操做都發生在指定點附近。例如，將旋轉變換應用於具備默認錨點的圖層會致使圍繞其中心旋轉，錨點更改成其餘位置將致使圖層圍繞該新點旋轉。

    錨點影響圖層變換示意圖

  • var position: CGPoint ( 錨點所處的位置 )

    錨點影響圖層的位置示意圖

    看 iOS 部分便可。圖1中的 position 被標記爲了 (100, 100) ，怎麼來的？

    對於錨點來講，它在父圖層中有着更詳細的座標。對 position 通俗來解釋一下，就是錨點在父圖層中的位置。

    一個圖層它的默認錨點是 (0.5, 0.5) ，既然如此，那就先看下錨點 x 在父圖層中的位置，能夠看到，從父圖層 x 到錨點 x 的位置是 100，那麼此時的 position.x 就是 100；而 y 也是相似的，從父圖層 y 到錨點 y 的位置也是 100；則能夠得出，此時錨點在父圖層中的座標是 (100, 100) ，也就是此時圖層中 position 的值。

    對圖2也是如此，此時的錨點處於起始點位置 (0.0, 0.0) ，從父圖層 x 到錨點 x 的位置是 40；而從父圖層 y 到錨點 y 的位置是 60 ，由此得出，此時圖層中 position 的值是 (40, 60) 。

    這裏其實計算 position 是有公式的，根據圖1能夠套用以下公式：

    1. position.x = frame.origin.x + 0.5 * bounds.size.width ；
    2. position.y = frame.origin.y + 0.5 * bounds.size.height 。

    由於裏面的 0.5 是 anchorPoint 的默認值，更通用的公式應該是：

    1. position.x = frame.origin.x + anchorPoint.x * bounds.size.width ；
    2. position.y = frame.origin.y + anchorPoint.y * bounds.size.height 。

    注意：

    實際上，position 就是 UIView 中的 center 。若是咱們修改了圖層的 position ，那麼 view 的 center 會隨之改變，反之也是如此。

anchorPoint 和 position 之間的關係

前面說過，position 處於錨點中的位置（相對於父圖層）。這裏就有一個問題，那就是，既然 position 相對於 anchorPoint ，那若是修改了 anchorPoint 會不會致使 position 的變化？結論是不會：

let redView = UIView(frame: CGRect(x: 40, y: 60, width: 120, height: 80))
print(self.redView.layer.position)	// Prints "(100.0, 100.0)"
redView.layer.anchorPoint = CGPoint(x: 0, y: 1)
print(self.redView.layer.position)	// Prints "(100.0, 100.0)"
複製代碼

那修改了 position 會致使 anchorPoint 的變化嗎？結論是也不會：

let redView = UIView(frame: CGRect(x: 40, y: 60, width: 120, height: 80))
print(redView.layer.anchorPoint)	// Prints "(0.5, 0.5)"
redView.layer.anchorPoint = CGPoint(x: 0, y: 1)
print(redView.layer.anchorPoint)	// Prints "(0.5, 0.5)"
複製代碼

通過測試，不管修改了誰另外一方都不會受到影響，受到影響的只會是 frame.origin 。至於爲何二者互不影響，我暫時還沒想到。我隨意猜想一下是這樣的：

其實 anchorPoint 就是 anchorPoint ；position 就是 position 。他們自己實際上是沒有關聯的，由於它們默認處在的位置正好重疊了，因此就給咱們形成了一種誤區，認爲 position 就必定是 anchorPoint 所在的那個點。

和 frame 之間的關係

CALayer 的 frame 在文檔中被描述爲是一個計算型屬性，它是從 bounds 、anchorPoint 和 position 的值中派生出來的。爲此屬性指定新值時，圖層會更改其 position 和 bounds 屬性以匹配您指定的矩形。

那它們是如何決定 frame 的？根據圖片能夠套用以下公式：

  1. frame.x = position.x - anchorPoint.x * bounds.size.width ；
  2. frame.y = position.y - anchorPoint.y * bounds.size.height 。

這就解釋了爲何修改 position 和 anchorPoint 會致使 frame 發生變化，咱們能夠測試一下，假設把錨點改成處在左下角 (0.0, 1.0) ：

let redView = UIView(frame: CGRect(x: 40, y: 60, width: 120, height: 80))
redView.layer.anchorPoint = CGPoint(x: 0, y: 1)
print(redView.frame.origin)	// Prints "(100.0, 20.0)"
複製代碼

用公式來計算就是：frame.x (100) = 100 - 0 * 120 、frame.y (20) = 100 - 1 * 80 ；正好和打印的結果相符。反之，修改 position 屬性也會致使 frame.origin 發生如公式般的變化，這裏就再也不贅述了。

注意：

若是修改了 frame 的值是會致使 position 發生變化的，由於 position 是基於父圖層定義的；frame 的改變意味着它自身的位置在父圖層中有所改變，position 也會所以改變。

可是修改了 frame 並不會致使 anchorPoint 發生變化，由於 anchorPoint 是基於自身圖層定義的，不管外部怎麼變，anchorPoint 都不會跟着變化。

修改 anchorPoint 所帶來的困惑

對於修改 position 來講其實就是修改它的 "center" ，這裏很容易理解。可是對於修改 anchorPoint ，相信不少人都有過一樣的困惑，爲何修改了 anchorPoint 所帶來的變化每每和本身想象中的不太同樣呢？來看一個修改錨點 x 的例子 ( 0.5 → 0.2 )：

仔細觀察一下 "圖2" 就會發現，無論是新錨點仍是舊錨點，它們在自身圖層中的位置中都沒有變化。既然錨點自己不會變化，那變化的就只能是 x 了。x 是如何變化的？從圖片中能夠很清楚地看到，是把新錨點移動到舊錨點的所在位置。這也是大部分人的誤區，覺得修改 0.5 -> 0.2 就是把舊的錨點移動到新錨點的所在位置，結果偏偏相反，這就是形成修改 anchorPoint 每每和本身想象中不太同樣的緣由。

還有一種比較好理解的方式就是，想象一下，假設 "圖1" 中的底部紅色圖層是一張紙，而中間的白點至關於一枚大頭釘固定在它中間，移動的時候，你就按住中間的大頭釘讓其保持不動。這時候假設你要開始移動到任意點了，那你會怎麼作呢？惟一的一種方式就是，移動整個圖層，讓新的錨點順着舊錨點中的位置靠攏，最終徹底重合，就算移動完成了。

參考

完全理解position與anchorPoint

核心動畫編程指南

iOS 核心動畫：高級技巧

蘋果 UIView 文檔

蘋果 CALayer 文檔

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程