從 Auto Layout 的佈局演算法談效能

Draveness發表於2016-09-01
演算法

這是使用 ASDK 效能調優系列的第二篇文章，前一篇文章中講到了如何提升 iOS 應用的渲染效能，你可以點選 這裡 瞭解這部分的內容。

在上一篇文章中，我們提到了 iOS 介面的渲染過程以及如何對渲染過程進行優化。ASDK 的做法是將渲染繪製的工作拋到後臺執行緒進行，並在每次 Runloop 結束時，將繪製結果交給 CALayer 進行展示。

而這篇文章就要從 iOS 中影響效能的另一大殺手，也就是萬惡之源 Auto Layout（自動佈局）來分析如何對 iOS 應用的效能進行優化以及 Auto Layout 到底為什麼會影響效能？

box-layout

把 Auto Layout 批判一番

由於在 2012 年蘋果釋出了 4.0 寸的 iPhone5，在 iOS 平臺上出現了不同尺寸的移動裝置，使得原有的 frame 佈局方式無法很好地適配不同尺寸的螢幕，所以，為了解決這一問題 Auto Layout 就誕生了。

Auto Layout 的誕生並沒有如同蘋果的其它框架一樣收到開發者的好評，它自誕生的第一天起就飽受 iOS 開發者的批評，其蹩腳、冗長的語法使得它在剛剛面世就被無數開發者吐槽，寫了幾個螢幕的程式碼都不能完成一個簡單的佈局，哪怕是 VFL（Visual Format Language）也拯救不了它。

真正使 Auto Layout 大規模投入使用的應該還是 Masonry，它使用了鏈式的語法對 Auto Layout 進行了很好的封裝，使得 Auto Layout 更加簡單易用；時至今日，開發者也在日常使用中發現了 Masonry 的各種問題，於是出現了各種各樣的佈局框架，不過這都是後話了。

masonry

Auto Layout 的原理和 Cassowary

Auto Layout 的原理其實非常簡單，在這裡通過一個例子先簡單的解釋一下：

view-demonstrate

iOS 中檢視所需要的佈局資訊只有兩個，分別是 origin/center 和 size，在這裡我們以 origin & size 為例，也就是 frame 時代下佈局的需要的兩個資訊；這兩個資訊由四部分組成：

  • x & y

  • width & height

以左上角的 (0, 0) 為座標的原點，找到座標 (x, y)，然後繪製一個大小為 (width, height) 的矩形，這樣就完成了一個最簡單的佈局。而 Auto Layout 的佈局方式與上面所說的 frame 有些不同，frame 表示與父檢視之間的絕對距離，但是 Auto Layout 中大部分的約束都是描述性的，表示檢視間相對距離，以上圖為例：

A.left = Superview.left + 50
A.top  = Superview.top + 30
A.width  = 100
A.height = 100

B.left = (A.left + A.width)/(A.right) + 30
B.top  = A.top
B.width  = A.width
B.height = A.height

雖然上面的約束很好的表示了各個檢視之間的關係，但是 Auto Layout 實際上並沒有改變原有的 Hard-Coded 形式的佈局方式，只是將原有沒有太多意義的 (x, y) 值，變成了描述性的程式碼。

我們仍然需要知道佈局資訊所需要的四部分 x、y、width 以及 height。換句話說，我們要求解上述的八元一次方程組，將每個檢視所需要的資訊解出來；Cocoa 會在執行時求解上述的方程組，最終使用 frame 來繪製檢視。

layout-phase

Cassowary 演算法

在上世紀 90 年代，一個名叫 Cassowary) 的佈局演算法解決了使用者介面的佈局問題，它通過將佈局問題抽象成線性等式和不等式約束來進行求解。

Auto Layout 其實就是對 Cassowary 演算法的一種實現，但是這裡並不會對它展開介紹，有興趣的讀者可以在文章最後的 Reference 中瞭解一下 Cassowary 演算法相關的文章。

Auto Layout 的原理就是對線性方程組或者不等式的求解。

Auto Layout 的效能

在使用 Auto Layout 進行佈局時，可以指定一系列的約束，比如檢視的高度、寬度等等。而每一個約束其實都是一個簡單的線性等式或不等式，整個介面上的所有約束在一起就明確地（沒有衝突）定義了整個系統的佈局。

在涉及衝突發生時，Auto Layout 會嘗試 break 一些優先順序低的約束，儘量滿足最多並且優先順序最高的約束。

因為佈局系統在最後仍然需要通過 frame 來進行，所以 Auto Layout 雖然為開發者在描述佈局時帶來了一些好處，不過它相比原有的佈局系統加入了從約束計算 frame 的過程，而在這裡，我們需要了解 Auto Layout 的佈局效能如何。

performance-loss

因為使用 Cassowary 演算法解決約束問題就是對線性等式或不等式求解，所以其時間複雜度就是多項式時間的，不難推測出，在處理極其複雜的 UI 介面時，會造成效能上的巨大損失。

在這裡我們會對 Auto Layout 的效能進行測試，為了更明顯的展示 Auto Layout 的效能，我們通過 frame 的效能建立一條基準線以消除物件的建立和銷燬、檢視的渲染、檢視層級的改變帶來的影響。

你可以在 這裡 找到這次對 Layout 效能測量使用的程式碼。

程式碼分別使用 Auto Layout 和 frame 對 N 個檢視進行佈局，測算其執行時間。

使用 AutoLayout 時，每個檢視會隨機選擇兩個檢視對它的 top 和 left 進行約束，隨機生成一個數字作為 offset；同時，還會用幾個優先順序高的約束保證檢視的佈局不會超出整個 keyWindow。

而下圖就是對 100~1000 個檢視佈局所需要的時間的折線圖。

這裡的資料是在 OS X EL Captain，Macbook Air (13-inch Mid 2013）上的 iPhone 6s Plus 模擬器上採集的， Xcode 版本為 7.3.1。在其他裝置上可能不會獲得一致的資訊，由於筆者的 iPhone 升級到了 iOS 10，所以沒有辦法真機測試，最後的結果可能會有一定的偏差。

performance-chart-100-1000

從圖中可以看到，使用 Auto Layout 進行佈局的時間會是隻使用 frame 的 16 倍左右，雖然這裡的測試結果可能受外界條件影響差異比較大，不過 Auto Layout 的效能相比 frame 確實差很多，如果去掉設定 frame 的過程消耗的時間，Auto Layout 過程進行的計算量也是非常巨大的。

在上一篇文章中，我們曾經提到，想要讓 iOS 應用的檢視保持 60 FPS 的重新整理頻率，我們必須在 1/60 = 16.67 ms 之內完成包括佈局、繪製以及渲染等操作。

也就是說如果當前介面上的檢視大於 100 的話，使用 Auto Layout 是很難達到絕對流暢的要求的；而在使用 frame 時，同一個介面下哪怕有 500 個檢視，也是可以在 16.67 ms 之內完成佈局的。不過在一般情況下，在 iOS 的整個 UIWindow 中也不會一次性出現如此多的檢視。

我們更關心的是，在日常開發中難免會使用 Auto Layout 進行佈局，既然有 16.67 ms 這個限制，那麼在介面上出現了多少個檢視時，我才需要考慮其它的佈局方式呢？在這裡，我們將需要佈局的檢視數量減少一個量級，重新繪製一個圖表：

performance-layout-10-90

從圖中可以看出，當對 30 個左右檢視使用 Auto Layout 進行佈局時，所需要的時間就會在 16.67 ms 左右，當然這裡不排除一些其它因素的影響；到目前為止，會得出一個大致的結論，使用 Auto Layout 對複雜的 UI 介面進行佈局時（大於 30 個檢視）就會對效能有嚴重的影響（同時與裝置有關，文章中不會考慮裝置效能的差異性）。

上述對 Auto Layout 的使用還是比較簡單的，而在日常使用中，使用巢狀的檢視層級又非常正常。

在筆者對巢狀檢視層級中使用 Auto Layout 進行佈局時，當檢視的數量超過了 500 時，模擬器直接就 crash 了，所以這裡沒有超過 500 個檢視的資料。

我們對巢狀檢視數量在 100~500 之間佈局時間進行測量，並與 Auto Layout 進行比較：

performance-nested-autolayout-frame

在檢視數量大於 200 之後，隨著檢視數量的增加，使用 Auto Layout 對巢狀檢視進行佈局的時間相比非巢狀的佈局成倍增長。

雖然說 Auto Layout 為開發者在多尺寸佈局上提供了遍歷，而且支援跨越檢視層級的約束，但是由於其實現原理導致其時間複雜度為多項式時間，其效能損耗是僅使用 frame 的十幾倍，所以在處理龐大的 UI 介面時表現差強人意。

在三年以前，有一篇關於 Auto Layout 效能分析的文章，可以點選這裡瞭解這篇文章的內容 Auto Layout Performance on iOS。

ASDK 的佈局引擎

Auto Layout 不止在複雜 UI 介面佈局的表現不佳，它還會強制檢視在主執行緒上佈局；所以在 ASDK 中提供了另一種可以在後臺執行緒中執行的佈局引擎，它的結構大致是這樣的：

layout-hierarchy

ASLayoutSpec 與下面的所有的 Spec 類都是繼承關係，在檢視需要佈局時，會呼叫 ASLayoutSpec 或者它的子類的 - measureWithSizeRange: 方法返回一個用於佈局的物件 ASLayout。

ASLayoutable 是 ASDK 中一個協議，遵循該協議的類實現了一系列的佈局方法。

當我們使用 ASDK 佈局時，需要做下面四件事情中的一件：

  • 提供 layoutSpecBlock

  • 覆寫 - layoutSpecThatFits: 方法

  • 覆寫 - calculateSizeThatFits: 方法

  • 覆寫 - calculateLayoutThatFits: 方法

只有做上面四件事情中的其中一件才能對 ASDK 中的檢視或者說結點進行佈局。

方法 - calculateSizeThatFits: 提供了手動佈局的方式，通過在該方法內對 frame 進行計算，返回一個當前檢視的 CGSize。

而 - layoutSpecThatFits: 與 layoutSpecBlock 其實沒什麼不同，只是前者通過覆寫方法返回 ASLayoutSpec；後者通過 block 的形式提供一種不需要子類化就可以完成佈局的方法，兩者可以看做是完全等價的。

- calculateLayoutThatFits: 方法有一些不同，它把上面的兩種佈局方式：手動佈局和 Spec 佈局封裝成了一個介面，這樣，無論是 CGSize 還是 ASLayoutSpec 最後都會以 ASLayout 的形式返回給方法呼叫者。

手動佈局

這裡簡單介紹一下手動佈局使用的 -[ASDisplayNode calculatedSizeThatFits:] 方法，這個方法與 UIView 中的 -[UIView sizeThatFits:] 非常相似，其區別只是在 ASDK 中，所有的計算出的大小都會通過快取來提升效能。

- (CGSize)calculateSizeThatFits:(CGSize)constrainedSize {
  return _preferredFrameSize;
}

子類可以在這個方法中進行計算，通過覆寫這個方法返回一個合適的大小，不過一般情況下都不會使用手動佈局的方式。

使用 ASLayoutSpec 佈局

在 ASDK 中，更加常用的是使用 ASLayoutSpec 佈局，在上面提到的 ASLayout 是一個儲存佈局資訊的媒介，而真正計算檢視佈局的程式碼都在 ASLayoutSpec 中；所有 ASDK 中的佈局（手動 / Spec）都是由 -[ASLayoutable measureWithSizeRange:] 方法觸發的，在這裡我們以 ASDisplayNode 的呼叫棧為例看一下方法的執行過程：

-[ASDisplayNode measureWithSizeRange:]
    -[ASDisplayNode shouldMeasureWithSizeRange:]
    -[ASDisplayNode calculateLayoutThatFits:]
        -[ASDisplayNode layoutSpecThatFits:]
        -[ASLayoutSpec measureWithSizeRange:]
        +[ASLayout layoutWithLayoutableObject:constrainedSizeRange:size:sublayouts:]
        -[ASLayout filteredNodeLayoutTree]

ASDK 的文件中推薦在子類中覆寫 - layoutSpecThatFits: 方法，返回一個用於佈局的 ASLayoutSpec 物件，然後使用 ASLayoutSpec 中的 - measureWithSizeRange: 方法對它指定的檢視進行佈局，不過通過覆寫 ASDK 的佈局引擎 一節中的其它方法也都是可以的。

如果我們使用 ASStackLayoutSpec 對檢視進行佈局的話，方法呼叫棧大概是這樣的：

-[ASDisplayNode measureWithSizeRange:]
    -[ASDisplayNode shouldMeasureWithSizeRange:]
    -[ASDisplayNode calculateLayoutThatFits:]
        -[ASDisplayNode layoutSpecThatFits:]
        -[ASStackLayoutSpec measureWithSizeRange:]
            ASStackUnpositionedLayout::compute
            ASStackPositionedLayout::compute            ASStackBaselinePositionedLayout::compute        +[ASLayout layoutWithLayoutableObject:constrainedSizeRange:size:sublayouts:]
        -[ASLayout filteredNodeLayoutTree]

這裡只是執行了 ASStackLayoutSpec 對應的 - measureWithSizeRange: 方法，對其中的檢視進行佈局。在 - measureWithSizeRange: 中呼叫了一些 C++ 方法 ASStackUnpositionedLayout、ASStackPositionedLayout 以及 ASStackBaselinePositionedLayout 的 compute 方法，這些方法完成了對 ASStackLayoutSpec 中檢視的佈局。

相比於 Auto Layout，ASDK 實現了一種完全不同的佈局方式；比較類似與前端開發中的 Flexbox 模型，而 ASDK 其實就實現了 Flexbox 的一個子集。

在 ASDK 1.0 時代，很多開發者都表示希望 ASDK 中加入 ComponentKit 的佈局引擎；而現在，ASDK 佈局引擎的大部分程式碼都是從 ComponentKit 中移植過來的（ComponentKit 是另一個 Facebook 團隊開發的用於佈局的框架）。

ASLayout

ASLayout 表示當前的結點在佈局樹中的大小和位置；當然，它還有一些其它的奇怪的屬性：

@interface ASLayout : NSObject

@property (nonatomic, weak, readonly) id<ASLayoutable> layoutableObject;
@property (nonatomic, readonly) CGSize size;
@property (nonatomic, readwrite) CGPoint position;
@property (nonatomic, readonly) NSArray<ASLayout *> *sublayouts;
@property (nonatomic, readonly) CGRect frame;

...

@end

程式碼中的 layoutableObject 表示當前的物件，sublayouts 表示當前檢視的子佈局 ASLayout 陣列。

整個類的實現都沒有什麼值得多說的，除了大量的構造方法，唯一一個做了一些事情的就是 -[ASLayout filteredNodeLayoutTree] 方法了：

- (ASLayout *)filteredNodeLayoutTree {
  NSMutableArray *flattenedSublayouts = [NSMutableArray array];
  struct Context {
    ASLayout *layout;
    CGPoint absolutePosition;
  };
  std::queue<Context> queue;
  queue.push({self, CGPointMake(0, 0)});
  while (!queue.empty()) {
    Context context = queue.front();
    queue.pop();

    if (self != context.layout && context.layout.type == ASLayoutableTypeDisplayNode) {
      ASLayout *layout = [ASLayout layoutWithLayout:context.layout position:context.absolutePosition];
      layout.flattened = YES;
      [flattenedSublayouts addObject:layout];
    }
    
    for (ASLayout *sublayout in context.layout.sublayouts) {
      if (sublayout.isFlattened == NO) queue.push({sublayout, context.absolutePosition + sublayout.position});
  }

  return [ASLayout layoutWithLayoutableObject:_layoutableObject
                         constrainedSizeRange:_constrainedSizeRange
                                         size:_size
                                   sublayouts:flattenedSublayouts];
}

而這個方法也只是將 sublayouts 中的內容展平，然後例項化一個新的 ASLayout 物件。

ASLayoutSpec

ASLayoutSpec 的作用更像是一個抽象類，在真正使用 ASDK 的佈局引擎時，都不會直接使用這個類，而是會用類似 ASStackLayoutSpec、ASRelativeLayoutSpec、ASOverlayLayoutSpec 以及 ASRatioLayoutSpec 等子類。

筆者不打算一行一行程式碼深入講解其內容，簡單介紹一下最重要的 ASStackLayoutSpec。

stack

ASStackLayoutSpec 從 Flexbox 中獲得了非常多的靈感，比如說 justifyContent、alignItems 等屬性，它和蘋果的 UIStackView 比較類似，不過底層並沒有使用 Auto Layout 進行計算。如果沒有接觸過 ASStackLayoutSpec 的開發者，可以通過這個小遊戲 Foggy-ASDK-Layout 快速學習 ASStackLayoutSpec 的使用。

關於快取以及非同步併發

因為計算檢視的 CGRect 進行佈局是一種非常昂貴的操作，所以 ASDK 在這裡面加入了快取機制，在每次執行 - measureWithSizeRange: 方法時，都會通過 -shouldMeasureWithSizeRange: 判斷是否需要重新計算佈局：

- (BOOL)shouldMeasureWithSizeRange:(ASSizeRange)constrainedSize {
  return [self _hasDirtyLayout] || !ASSizeRangeEqualToSizeRange(constrainedSize, _calculatedLayout.constrainedSizeRange);
}

- (BOOL)_hasDirtyLayout {
  return _calculatedLayout == nil || _calculatedLayout.isDirty;
}

在一般情況下，只有當前結點被標記為 dirty 或者這一次佈局傳入的 constrainedSize 不同時，才需要進行重新計算。在不需要重新計算佈局的情況下，只需要直接返回 _calculatedLayout 佈局物件就可以了。

因為 ASDK 實現的佈局引擎其實只是對 frame 的計算，所以無論是在主執行緒還是後臺的非同步併發程式中都是可以執行的，也就是說，你可以在任意執行緒中呼叫 - measureWithSizeRange: 方法，ASDK 中的一些 ViewController 比如：ASDataViewController 就會在後臺併發程式中執行該方法：

- (NSArray<ASCellNode *> *)_layoutNodesFromContexts:(NSArray<ASIndexedNodeContext *> *)contexts {
  ...

  dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
  dispatch_apply(nodeCount, queue, ^(size_t i) {
    ASIndexedNodeContext *context = contexts[i];
    ASCellNode *node = [context allocateNode];
    if (node == nil) node = [[ASCellNode alloc] init];

    CGRect frame = CGRectZero;
    frame.size = [node measureWithSizeRange:context.constrainedSize].size;
    node.frame = frame;

    [ASDataController _didLayoutNode];
  });

  ...

  return nodes;
}

上述程式碼做了比較大的修改，將原有一些方法呼叫放到了當前方法中，並省略了大量的程式碼。

關於效能的對比

由於 ASDK 的佈局引擎的問題，其效能比較難以測試，在這裡只對 ASDK 使用 ASStackLayoutSpec 的佈局計算時間進行了測試，不包括檢視的渲染以及其它時間：

async-node-calculate

測試結果表明 ASStackLayoutSpec 花費的佈局時間與結點的數量成正比，哪怕計算 100 個檢視的佈局也只需要 8.89 ms，雖然這裡沒有包括檢視的渲染時間，不過與 Auto Layout 相比效能還是有比較大的提升。

總結

其實 ASDK 的佈局引擎大部分都是對 ComponentKit 的封裝，不過由於擺脫了 Auto Layout 這一套低效但是通用的佈局方式，ASDK 的佈局計算不僅在後臺併發執行緒中進行、而且通過引入 Flexbox 提升了佈局的效能，但是 ASDK 的使用相對比較複雜，如果只想對佈局效能進行優化，更推薦單獨使用 ComponentKit 框架。

References

Github Repo：iOS-Source-Code-Analyze

Follow: Draveness · GitHub

Source: http://draveness.me/layout-pe…

相關文章