深入理解 Autolayout 與列表性能 -- 背鍋的 Cassowary 和偷懶的 CPU

這篇文章會(huì)通過對(duì) autolayout 內(nèi)部實(shí)現(xiàn)的探索和數(shù)據(jù)分析和對(duì) autolayout 的性能問題做一個(gè)詳細(xì)的分析，并在最后給出一個(gè)高性能 autolayout 的解決方案。開始看文章之前，可以先試試這個(gè) demo ,使用 YYKit demo 數(shù)據(jù)做的微博 Feed 列表。使用我自己寫的異步繪制組件 Panda 和和 ‘a(chǎn)utolayout’ 框架 Layoutable 寫的 ,cell 代碼只有 五百多行,但是流暢度很高。

Cassowary 算法性能

Autolayout 會(huì)將約束條件轉(zhuǎn)換成線性規(guī)劃問題，通過 Cassowary 算法求解線性規(guī)劃問題得到 frame。因此分析 autolayout 性能都繞不開 Cassowary 算法。大部分分析最后都會(huì)給出結(jié)論 “autolayout 性能差是 cassowary 算法的多項(xiàng)式的時(shí)間復(fù)雜度造成的”。也有一些會(huì)給出 autolayout 的 benchmark 來證明 cassowary 算法的問題。但是

1. Cassowary 是 1997 年就被發(fā)表并被稱作高效的線性方程求解算法，為什么 ‘8012’ 年了反而成了性能殺手？
2. 如果是 Cassowary 算法的問題，跑著 iOS 8 的 iPhone 6 應(yīng)該比實(shí)際表現(xiàn)更卡頓才合理，畢竟算法時(shí)間復(fù)雜度不會(huì)隨著設(shè)備和系統(tǒng)升級(jí)下降。由于系統(tǒng)開銷造成的性能下降在 ios 設(shè)備升級(jí)的和過程中似乎額外的大了。

想到自己實(shí)現(xiàn) cassowary 算法和 autolayout 也是由對(duì)這兩個(gè)問題的不解引出的。

Cassowary is an incremental constraint solving toolkit that efficiently solves systems of linear equalities and inequalities.

線性規(guī)劃問題的求解很早就有通用解法--單純型法，有興趣的同學(xué)可以看看這篇文章 AutoLayout 中的線性規(guī)劃 - Simplex 算法
?！端惴▽?dǎo)論》也有一章專門介紹單純型法的（所以誰說算法對(duì) iOS 開發(fā)沒用??）。Cassowary 則是單純型法在用戶界面實(shí)踐中的應(yīng)用和改進(jìn)算法，解決一些實(shí)際使用的問題，最重要的增加了增量的概念(Autolayout 實(shí)現(xiàn)中 Cassowary 相關(guān)的代碼是以 NSIS 作為前綴的，IS 就是 incremental Simplex 增量單純型的縮寫 )，單純型法通過建立單純型表，在對(duì)單純形表進(jìn)行 pivot 和 optimize 操作得到最優(yōu)解；Cassowary 則是可以在已經(jīng)建立單純型表上，高效的進(jìn)行添加修改更新操作。因?yàn)橛脩艚缑鎽?yīng)用中，大部分約束已經(jīng)固定，界面變化只需要對(duì)其中的部分約束進(jìn)行更新或者進(jìn)行少量的增減操作。Cassowary 的高效是建立在增量跟新的基礎(chǔ)上的。

完整介紹 Cassowary 需要很長篇幅，有時(shí)間單獨(dú)介紹，這里用數(shù)據(jù)說話

一組 benchmark: （MacBook Pro 2016 i5,iPhone6S 模擬器）

image

• Autolayout: 是相對(duì)布局的耗時(shí)
• Autolayout Nestlayout: 嵌套布局的耗時(shí)
• update constant: 更新約束的耗時(shí),即更新 NSLayoutConstraint 的 constant 常量。

因?yàn)檫@里沒有不含 UILabel，UIView 等有 intrincContentSize 的 UIView,update constant 基本就是 Cassowary 更新約束的耗時(shí)。Applelayout 和 Apple NestLayout 則也包含 UIView 創(chuàng)建，約束創(chuàng)建和求解的時(shí)間。

可以看到 update 約束是非常高效的， 80 個(gè) view，160 條約束更新約束也只需要 2.5 個(gè)毫秒，這個(gè)數(shù)量在實(shí)際使用中基本上是用不到的。實(shí)際使用中，同時(shí)更新 40 個(gè) view 80 條約束已經(jīng)算是很多的了，也只耗時(shí) 1.25 ms。

列表滾動(dòng)中，一般情況下頁面加載的時(shí)候 cell 和 約束已經(jīng)創(chuàng)建，性能應(yīng)該主要和更新約束相關(guān)（更新約束包括 UILabel。UIView 更改 text ,image 造成的 size 變化，更新系統(tǒng)默認(rèn)的約束；也包括手動(dòng)調(diào)整 NSLayoutConstraint 的 constant 屬性等）。為什么實(shí)際表現(xiàn)卻差很多呢？

Autolayout 設(shè)計(jì)問題

Autolayout 構(gòu)建在 Cassowary 之上，但是 autolayout 的一些機(jī)制沒有充分利用 Cassowary 更新高效的特點(diǎn)。我們可以通過私有類和方法來研究系統(tǒng)內(nèi)部的實(shí)現(xiàn)。這里有一個(gè)網(wǎng)站 iOS SDK Header Dump 可以查看 iOS 的私有頭文件。其中 NSIS 開頭的類都是 Autolayout 相關(guān)的頭文件。我把 iOS 11 Autolayout 相關(guān)的頭文件下載下來并做成了一個(gè)可以運(yùn)行的工程?？梢?hook 內(nèi)部實(shí)現(xiàn)或者打印變量來觀察系統(tǒng)的調(diào)用，可以這里下載 ExplorAutolayout 。后面一些測試代碼會(huì)基于這個(gè)工程。

1. NSContentSizeLayoutConstraint

   這是 FDTemplateLayoutCell profile 的一段結(jié)果，展開部分是 cellForRowAIndex 里運(yùn)行的代碼。

   image

   理論上 cellForRowAIndex 是不需要?jiǎng)?chuàng)建 NSLayoutConstraint 的，畢竟 cell 已經(jīng)創(chuàng)建過了, 更新數(shù)據(jù)的時(shí)候代碼中并沒有新加約束。但這里創(chuàng)建了 UIContentSizeLayoutConstraint 對(duì)象，UIContentSizeLayoutConstraint 繼承自 NSLayoutConstraint,是專門用來約束 contentSize 的約束。

   來一段測試代碼，我們在 NSLayoutConstraint 對(duì)象創(chuàng)建的時(shí)候輸出創(chuàng)建的約束類型:

   // 子類化 UIlabel，每次調(diào)用 intrinsicContentSize 輸出大小
   @implementation TestLabel
   
   - (CGSize)intrinsicContentSize{  
       NSLog(@"width: %f, height: %f",size.width,size.height);
       return [super intrinsicContentSize];
   }
   
   @end
   
   // 替換 NSLayoutConstraint init 方法，每次輸出創(chuàng)建的類型
   @implementation NSLayoutConstraint (methodSwizze)
   
   + (void)load{
      [self replace:@selector(init) byNew:@selector(new_init)];
   }
   
   - (instancetype)new_init{
       NSLog(@"New %@",[self class]);
       return [self new_init];
   }
   
   @end  
   
   

   一個(gè)多行文字的 label 給一個(gè)寬度約束,然后設(shè)置 text, layoutIfNeeded 強(qiáng)制布局 輸出結(jié)果：

   width: 1073741824.000000, height: 20.500000
   New NSContentSizeLayoutConstraint
   New NSContentSizeLayoutConstraint
   width: 296.500000, height: 41.000000
   New NSContentSizeLayoutConstraint
   New NSContentSizeLayoutConstraint
   

   創(chuàng)建的兩個(gè)約束是根據(jù) intrinsicContentSize 值給的寬度和高度約束。也就是每次 intrinsicContentSize 變化的時(shí)候，Autolayout 都會(huì)創(chuàng)建兩個(gè)新的 NSContentSizeLayoutConstraint 約束分別約束寬和高，添加到 NSISEnginer 中求解, 而不是直接更新已經(jīng)創(chuàng)建好的約束。

   水果公司一邊告訴我們重新添加約束比更新約束低效，一邊在頻繁調(diào)用的地方用著低效的方法??。

2. systemLayoutSizeFittingSize

   NSContentSizeLayoutConstraint 只是蘋果浪費(fèi) Cassowary 算法優(yōu)點(diǎn)的一個(gè)地方，

   • 看另一組不包含 intrinsicContentSize 的 UIView 的數(shù)據(jù)，都是單純的更新約束,區(qū)別只在于有沒有添加到 window 上，以及強(qiáng)制布局的方法：

     image
     • Apple constant 是 view 沒有并添加到 window 上，更新約束后調(diào)用 layoutIfNeeded 的數(shù)據(jù)。
     • Apple In Window constant是把 view 添加到當(dāng)前 window 上，更新約束后調(diào)用 layoutIfNeeded 的數(shù)據(jù)
     • SystemFitSize constant 是調(diào)用 systemlayoutFitSize 獲取高度的數(shù)據(jù)。

     同樣是更新約束，耗時(shí)差距卻非常大，添加到 window 上再調(diào)用 layoutIfNeeded 的耗時(shí)遠(yuǎn)小于沒有加到 window 上。同樣沒有加到 window 上，systemlayoutFitSize 耗時(shí)又要小于 layoutIfNeeded.

   • 再以 FDTemplateLayoutCell 為例，我們在同一方法中同事調(diào)用 systemLayoutSizeFittingSize 和 layoutIfNeeded

     - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
     
         [self measure:^{
           [self configureCell:self.cell atIndexPath:indexPath];
           [self.cell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
         } log:@"heightForRow"];
     
         FDFeedCell *cell = [tableView dequeueReusableCellWithIdentifier:@"FDFeedCell"];
         [self measure:^{
             [self configureCell:cell atIndexPath:indexPath];
             [cell.contentView layoutIfNeeded];
         } log:@"cellForRowAtIndexPath"];
     
         return cell;
     }
     

     profile 下

     image

     systemLayoutSizeFittingSize 總耗時(shí) 276 ms, layoutIfNeeded 總耗時(shí) 161 ms 多了 70% 的耗時(shí)

   • 看一下 autolayout 調(diào)用的過程：

     替換 NSISEnginer （NSISEnginer 就是 autolayout 的 線性規(guī)劃求解器）的 init 方法，每次創(chuàng)建 NSISEnginer 打印 New NSISEnginer

     + (void)load{
         [self replace:@selector(init) byNew:@selector(new_init)];
     }
     
     - (id)new_init{
         NSLog(@"New NSISEnginer");
         return [self new_init];
     }
     
     ...
     
     @implementation NSObject(methodExchange)
     
     + (void)replace:(SEL)old byNew:(SEL)new{
         Method oldMethod = class_getInstanceMethod([self class], old);
         Method newMethod = class_getInstanceMethod([self class], new);
     
         method_exchangeImplementations(oldMethod, newMethod);
     }
     

     調(diào)用方法觀察輸出:

       UIView * view3 = [[UIView alloc] init];
     
       view3.translatesAutoresizingMaskIntoConstraints = false;
       NSLayoutConstraint *c3 =  [view3.widthAnchor constraintEqualToConstant:10];
       c3.priority = UILayoutPriorityDefaultHigh;
       c3.active = true;
     
       for(NSUInteger i = 0; i < 3; i++){
          [view3 setNeedsLayout];
          [view3 layoutIfNeeded];
          NSLog(@"View3LayoutIfNeeded");
        }
     
       for(NSUInteger i = 0; i < 3; i++){
         [view3 setNeedsLayout];
         [view3 systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
         NSLog(@"No superview systemLayoutSizeFittingSize");
       }
     
       [self.view addSubview:view3];
     
       for(NSUInteger i = 0; i < 3; i++){
         c3.constant = rand()%20;
         [view3 setNeedsLayout];
         [view3 layoutIfNeeded];
         NSLog(@"View3LayoutIfNeededSecondPass");
       }
     
       for(NSUInteger i = 0; i < 3; i++){
         c3.constant = rand()%20;
         CGSize size = [view3 systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
         NSLog(@"w :%f",size.width);
         NSLog(@"systemLayoutSizeFittingSize");
       }
     

     打印結(jié)果是

      View3LayoutIfNeeded
      New NSISEnginer
      View3LayoutIfNeeded
      New NSISEnginer 
      View3LayoutIfNeeded
      New NSISEnginer
     
      No superview systemLayoutSizeFittingSize
      New NSISEnginer
      No superview systemLayoutSizeFittingSize
      New NSISEnginer
      No superview systemLayoutSizeFittingSize
      New NSISEnginer
     
      View3LayoutIfNeededSecondPass
      View3LayoutIfNeededSecondPass
      View3LayoutIfNeededSecondPass
     
      systemLayoutSizeFittingSize
      New NSISEnginer
      systemLayoutSizeFittingSize
      New NSISEnginer
      systemLayoutSizeFittingSize
      New NSISEnginer
     

     可以看到，沒有添加到 window 之前, 調(diào)用 layoutIfNeeded 和 systemLayoutSizeFittingSize 每次都會(huì)創(chuàng)建 NSISEnginer；添加到 window 上以后，layoutIfNeeded 并不會(huì)創(chuàng)建 NSISEnginer, 而systemLayoutSizeFittingSize 還是每次都會(huì)創(chuàng)建 NSISEnginer。創(chuàng)建新的 NSISEnginer 則意味著對(duì)應(yīng)的所有約束，也會(huì)重新添加到 NSISEnginer,重新進(jìn)行優(yōu)化求解，這時(shí)候的耗時(shí)就變成了初次添加約束的時(shí)間。在列表的使用中，我們一般會(huì)在 heightForRowAtIndexPath 中創(chuàng)建一個(gè)不會(huì)添加到 window 上的 cell 調(diào)用 systemLayoutSizeFittingSize 來計(jì)算高度。這個(gè)的計(jì)算耗時(shí)就要比 cellForRowAtIndexPath 中的耗時(shí)大很多。

     image

   systemLayoutSizeFittingSize 會(huì)重新創(chuàng)建 NSISEnginer和 WWDC 《High performance Autolayout》 所講也是一致的。使用 systemLayoutSizeFittingSize 時(shí)，Autolayout 會(huì)創(chuàng)建新的 NSISEnginer 對(duì)象,重新添加約束求解，然后釋放掉 NSISEnginer 對(duì)象。而對(duì)于 layoutIfNeeded 也很好理解，Autolayout 中，一個(gè) window 層級(jí)下的 view 會(huì)共用 window 節(jié)點(diǎn)的 NSISEnginer 對(duì)象，沒有添加到 window 上的 view 沒有父 window 也就沒辦法共用，只能重新創(chuàng)建.

   image

   在 WWDC 介紹中 systemLayoutSizeFitting 是提供給 autolayout 和 frame 混合使用的，也不建議常用，似乎不是給計(jì)算高度來用的。

   那么能不能在算高度時(shí)候把 cell 添加到 window 上，隱藏，然后用 layoutIfNeeded 來提高效率?

   ??：呵呵 ??

   systemLayoutSizeFittingSize 對(duì)計(jì)算做了優(yōu)化，計(jì)算好以后不會(huì)對(duì) view 的 frame 進(jìn)行操作，也就避免 layer 調(diào)整的相關(guān)耗時(shí)。所以同樣是創(chuàng)建 NSISEnginer 重新添加約束， systemLayoutSizeFittingSize 比 layoutIfNeeded 要高效；添加到 window 上以后，layoutIfNeeded 計(jì)算的效率高于 systemLayoutSizeFittingSize,但是 setFrame 和觸發(fā)的 layer 相關(guān)操作又會(huì)有額外的耗時(shí)，不一定會(huì)比直接使用 systemLayoutSizeFittingSize 耗時(shí)少 。

   image

The Enginer is a layout cache and dependency tracker

Cassowary 的增量更新機(jī)制其實(shí)也算是某種程度上的緩存機(jī)制，重新創(chuàng)建 Enginer 的設(shè)計(jì)也就丟掉了 cache 的能力，降低了性能。

Text layout 對(duì)性能的影響

雖然由于上述種種問題， 但如上圖所示 heightForRowAtIndexPath 里調(diào)用 systemLayoutSizeFittingSize 再加上 cellForRowAtIndexPath 里調(diào)用 layoutIfNeeded 總耗時(shí)看起來也并不是很多，40 個(gè) view 左右耗時(shí)也不到 4 ms，看起來還可以，為什么實(shí)際使用起來表現(xiàn)卻差很多呢。

1. text layout 才是性能殺手

   1. 以 FDTemplateLayoutCell demo，為例，我們對(duì)同一個(gè) cell 連續(xù)執(zhí)行三次一樣的代碼，

      [self measure:^{
          [self configureCell:self.cell atIndexPath:indexPath];
          [self.cell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
       } log:@"heightForRow"];
      
      [self measure:^{
          [self configureCell:self.cell atIndexPath:indexPath];
          [self.cell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
      } log:@"heightForRow"];
      
      [self measure:^{
          [self configureCell:self.cell atIndexPath:indexPath];
          [self.cell.contentView systemLayoutSizeFittingSize:UILayoutFittingCompressedSize];
      } log:@"heightForRow"];
      
      

      結(jié)果差距很大

      image

      第一遍耗時(shí) 231 ms,后面兩遍只有 98,87 毫秒

      如果把第一遍展開的話，就會(huì)發(fā)現(xiàn)大部分時(shí)間都是在文字上：

      image

      后面兩遍因?yàn)楹偷谝槐榈臄?shù)據(jù)一樣，不會(huì)觸發(fā)文字相關(guān)的操作。計(jì)算的時(shí)間只占了 30%-40%

   2. 以我們的微博 demo layout 做一個(gè) benchmak

      for status in self.statusViewModels{
        measureTime(desc: "without text layout cache", action: {
          self.statusNode.update(status)
          self.statusNode.layoutIfNeeded()
          status.layoutValues = self.statusNode.layoutValues
          status.height = self.statusNode.frame.height
        })
      }
      
      for status in self.statusViewModels{
        measureTime(desc: "without text layout cache", action: {
          self.statusNode.update(status)
          self.statusNode.layoutIfNeeded()
          status.layoutValues = self.statusNode.layoutValues
          status.height = self.statusNode.frame.height
        })
      }
      

      兩個(gè) for 循環(huán)中，除了輸出的描述文案，代碼是一樣的，Panda 的實(shí)現(xiàn)中，會(huì)把已經(jīng)創(chuàng)建的 TextKit 組成的 TextRender 對(duì)象緩存起來，并且是不可變。再次出現(xiàn)相同的文字會(huì)從緩存取。

      第一次 for 循環(huán)中，不存在相應(yīng)的 TextRender 對(duì)象，每次都需要?jiǎng)?chuàng)建新的 TextRender 對(duì)象并進(jìn)行 layout

      第二次 for 循環(huán)中，因?yàn)榈谝淮斡?jì)算過程中已經(jīng)緩存了 TextRender，基本上只是單純?nèi)≈岛?Cassowary 更新約束計(jì)算。

      結(jié)果：（iPhone6 , iOS 12）

   image
   
   

   - Panda FirstPass 是第一個(gè) for 循環(huán)數(shù)據(jù)
   - Panda SecondPass 是第二個(gè) for 循環(huán)數(shù)據(jù)
   - YYKit 則是 YYKit 手算 frame 的數(shù)據(jù)
   - 縱坐標(biāo)是耗時(shí)

   同樣更新數(shù)據(jù)，同樣的 update 約束，同樣的 Panda Layout 數(shù)據(jù)相差卻非常大。而且第二次數(shù)據(jù)更加平穩(wěn)

   對(duì)于 Panda Layou，相差的數(shù)據(jù)基本就是 text layout 的時(shí)間。第一次 Layout 平均數(shù)據(jù) 5.94，第二次平均數(shù)據(jù) 1.44. text layout 占了總耗時(shí)的 70%-80%。

2. Autolayout 要比手算多一些 Text layout過程

   text layout 耗時(shí)最多， 使用 autolayout 會(huì)比 手算 frame 多一部分 text layout 過程

   其實(shí)上一個(gè) NSContentSizeLayoutConstraint 的輸出結(jié)果中已經(jīng)給出部分答案，只設(shè)置一次 text,卻輸出了兩次 intrinsicContentSize，而且結(jié)果也不一樣。 檢查一下 UIView 的私有方法，會(huì)發(fā)現(xiàn)一個(gè)_needsDoubleUpdateConstraintsPass 的方法，返回值為 true 的話，會(huì)調(diào)用兩次 intrinsicContentSize 方法。

   • 手撕的 frame 時(shí)候開發(fā)人員需要額外注意計(jì)算順序。比如計(jì)算一個(gè)多行的 UILabel，可能會(huì)先把左右兩邊相關(guān)的寬度計(jì)算好，這樣可以知道 UILabel 最大寬度，或者直接指定 UILabel 的最大寬度，使用 size(withAttributes:) 進(jìn)行一次 text layout 就可以把文字大小算出來。
   • Autolayout 使開發(fā)者免去了操心布局順序的負(fù)擔(dān)（這也是 Autolayout 一個(gè)比較核心的優(yōu)點(diǎn)）， 導(dǎo)致更新 UILabel 的約束時(shí)不能直接確定 UILabel 的最大寬度，怎么解決換行的問題？（iOS 6 的時(shí)候需要手動(dòng)設(shè)置 preferrdMaxLayoutWidth，很多時(shí)候會(huì)造成很大困擾，因?yàn)椴⒉皇悄敲慈菀状_定）。 對(duì)于多行文字的 UILabel,Autolayout 會(huì)進(jìn)行兩邊 layout. 第一次 layout 會(huì)先假設(shè)文本可以一行展示完，進(jìn)行一次 text layout ，計(jì)算一行文字的大小，更新 UILabel 的 size 約束。size 的寬高約束都不是 required 的，外部如果有對(duì)寬度相關(guān)的約束的話，也不會(huì)沖突。整個(gè) view 層級(jí)一次布局結(jié)束之后，所有 view 的寬度就確定了，第二遍 layout 再以當(dāng)前寬度再做一次 text layout ,更新文本寬高。這樣 autolayout 文本的多行文字 textLayout 過程就要比手算 frame 多一倍。多行文本 layout 一般耗時(shí)更長。多出來一次的 text layout 的耗時(shí)就很多了了。
   image

   textlayout 耗時(shí)占比很大，這也是為什么蘋果推薦重寫 UIlable 的 intrinsicContentSize 方法，然后約束寬高的方式來避免 text layout。但是實(shí)際使用中能這樣優(yōu)化的場景并不多。

3. 主線程運(yùn)行的影響

   關(guān)于列表性能優(yōu)化，大家比較喜歡說的就是 frame 比 autolayout 快，其實(shí)更重要的是 frame 相對(duì) autolayout 可以減少一些重復(fù)計(jì)算，以及把耗時(shí)操作丟到后臺(tái)線程。

   1. 手算 frame 可以放到后臺(tái)線程，從而避免了主線程的 text layout。
   2. 手算 frame 只會(huì) layout 一遍，autolayout heightForRowAtIndexPath 和 cellForRowAtIndexPath 都需要計(jì)算，這個(gè)多出來的的計(jì)算和 text layout 就更多了。

Textlayout 在計(jì)算和渲染過程占的比重很大，也是很多 app 即使 cell 高度用 frame 算，沒有做 text layout 相關(guān)緩存或者異步 Label 也會(huì)不流暢的原因。單純做計(jì)算的優(yōu)化，不做 text layout 緩存的布局框架一般實(shí)際表現(xiàn)都不會(huì)太好。

CPU 調(diào)度對(duì)列表性能的影響

上面的 benchmark 是針對(duì) iPhone 6 的, 數(shù)據(jù)其實(shí)已經(jīng)很不錯(cuò)了，更好的設(shè)備豈不是要逆天？

看一組 iPhneX 的數(shù)據(jù) （iPhoneX , iOS 12）

image

即使第一次 layout,Panda 和 YYKit 平均耗時(shí)只有 1.34 毫秒，只更新約束更是只需要 0.287 毫秒。（這個(gè)數(shù)據(jù)遠(yuǎn)好于 2016 MacBook Pro 的表現(xiàn)）。時(shí)間寬裕度很大，看起來即使 autolayout 的耗時(shí)多個(gè)一兩倍問題也不大。

Apple: 呵呵??

benchmark 出來的耗時(shí)其實(shí)一般和實(shí)際運(yùn)行是不一樣。同樣 iOS 12 iPhoneX ,如果對(duì)列表進(jìn)行快速滑動(dòng)的話，是可以到達(dá) benchmark 的數(shù)據(jù)；如果滑動(dòng)的不是很快的，上面 0.x,1.x ms 的耗時(shí)，很多就變成了 6 - 9 ms 左右。

image

image

CPU 達(dá)到最好性能是需要時(shí)間的，benchmark 過程計(jì)算比較集中， CPU 一直處于高性能狀態(tài)。但是滑的慢一點(diǎn)的話，可能 CPU 性能還沒起來計(jì)算就結(jié)束了。然后 CPU 開始偷懶。剛好性能下去以后另一計(jì)算過程又開始了。而且 iOS 12 這個(gè)已經(jīng)優(yōu)化過了，iOS11 和 iOS 10 表現(xiàn)更差。做 benchmark 的有時(shí)候也會(huì)有一個(gè)有趣的現(xiàn)象，如果有幾組數(shù)據(jù)需要測試，在同一段代碼里調(diào)用這些方法進(jìn)行測試，方法的調(diào)用順序?qū)?benchmark 出來的數(shù)據(jù)影響特別大。放在第一個(gè)的方法耗時(shí)會(huì)被大大增加。

Autolayout 一些結(jié)論

總結(jié)一下，autolayout 性能不好并不是以前經(jīng)?？吹降氖且?yàn)?cassowary 算法差導(dǎo)致的

1. cassowary 算法性能并沒有太大問題，update 很高效，計(jì)算耗時(shí)并不多。
2. autolayout 的實(shí)現(xiàn)沒有充分發(fā)揮 cassowary 的優(yōu)點(diǎn)，沒有父 window 的 view 重新創(chuàng)建 NSISEnginer 以及更新 intrincContentSize 需要重新創(chuàng)建和添加 NSLayoutConstraint 的設(shè)計(jì)加重了計(jì)算的負(fù)擔(dān)
3. cassowary 算法占整體耗時(shí)并不多,text layout 對(duì)性能的影響大于 cassowary，autolayout 只能把 textlayout 放主線，使得 text layout 的耗時(shí)對(duì)流暢度的影響不可避免。
4. autolayout 重復(fù)的計(jì)算，重復(fù)的 text layout 使得整體耗時(shí)增加很多。
5. CPU 調(diào)度使得計(jì)算可用時(shí)間很少。

Panda

為了解決上述問題，我用 swift 實(shí)現(xiàn)了一套異步繪制和 layout 組件 Panda。

Panda 包含第三個(gè)部分：

1. Cassowary Cassowary 算法
2. Layoutable Autolayout API
3. Panda 異步繪制組件

Cassowary 是單純的線性規(guī)劃求解器；Layoutable 是在 Cassowary 之上構(gòu)建的 'autolayout' ，底層上實(shí)現(xiàn)了類似 NSLayoutConstraint ，NSLayoutAnchor 類似的 LayoutConstraint 和 Anchor,也封裝了更高級(jí)的 API 方便使用。Layoutable 提供 Layoutable 協(xié)議，任何實(shí)現(xiàn)了 Layoutable 的對(duì)象都可以使用 autolayout，比如 UIView,CALayer，或者其他自定義對(duì)象; Panda 則是實(shí)現(xiàn)了 Layoutable 協(xié)議的異步繪制組件，提供異步繪制，文本 layout 緩存,和通用的 FlowLayout,StackLayout 復(fù)合布局控件。

Panda 基本上解決了上面提到的問題

1. Panda 里的 ViewNode 對(duì)象不繼承自 UIView,計(jì)算高度的時(shí)候 不需要?jiǎng)?chuàng)建 view,也不操作 layer，開銷更??；可以繁重把 text layout 計(jì)算從主線程剝離出去
2. 默認(rèn)會(huì)緩存住 text layout 對(duì)象和結(jié)果，減少 text layout 計(jì)算過程，即使再次 layout 也不需要再 text layout 上耗時(shí)
3. 不會(huì)重新創(chuàng)建線性方程求解器和添加約束；更新 intrincContentSize 不會(huì)重新創(chuàng)建約束，只會(huì)更新約束常量。重復(fù)利用 Cassowary 的優(yōu)勢。
4. 對(duì)于多行文本，提供 fixedWidth 優(yōu)化屬性，大部分情況下可以避免一部分 text layout
5. 支持異步繪制，利用多線程提高效率。
6. 算高度的時(shí)候也可以緩存住所有子 view 的 frame，然后在 cellForRowAIndexPath 中可以禁止自動(dòng)布局，直接使用緩存數(shù)據(jù)，防止重復(fù)計(jì)算。

Panda 使用也很簡單, ViewNode，TextNode,ImageNode 分別代替 UIView,UILabel 和 UIImage,然后就可以像 autolayout 一樣布局

let node = ViewNode()
let node1 = ViewNode()
let node2 = TextNode()

textNode.text = "hehe"

node.addSubnode(node1)
node.addSubnode(node2)

node1.size == (30,30)
node2.size == (40,40)
  
[node,node1].equal(.centerY,.left)  
/// 等價(jià)于
/// node.left == node1.left
/// node.centerY == node2.centerY
/// 或者 
/// node.left.equalTo(node1.left)
/// node.centerY.equalTo(node1.centerY)

[node2,node].equal(.top,.bottom,.centerY,.right)
[node1,node2].space(10, axis: .horizontal)

/// 支持約束優(yōu)先級(jí)
node.width == 100 ~.strong 
node.height == 200 ~ 760.0
update constant

/// 更新約束
let c =  node.left ==  10
c.constant = 100
  

在上面提到的微博 Feed demo 中，只用 500 行代碼就可以實(shí)現(xiàn)非常流程的列表。開發(fā)效率和運(yùn)行效率都遠(yuǎn)超手算 frame。代碼更少，維護(hù)起來更方便。

對(duì)比 Texture(或者說 AsyncDisplayKit), Panda

1. 集成成本更低。Panda 代碼更少；使用上也不需要替換 UITabelView 或者 cell ,只需要實(shí)現(xiàn) contentView 內(nèi)容即可。
2. 學(xué)習(xí)成本更低，API 和 思想上和 autolayout 都是一致的，對(duì)于 autolayout 使用者基本零門檻
3. 完全 Swift 實(shí)現(xiàn)，對(duì)于使用 swift 的項(xiàng)目更友好。
4. 開發(fā)效率和運(yùn)行效率不輸 Texture