iOS 界面渲染

嘗試和大家一起探討以下問題：

view繪制渲染機制和runloop什么關系？
所謂的列表卡頓，到底是什么原因引發的？
我們經常在drawrect方法里繪制代碼，但該方法是誰調用的何時調用的？
drawrect方法內為何第一行代碼往往要獲取圖形的上下文？
layer的代理必須是view嗎，可以是vc嗎，為何CALayerDelegate 不能主動遵循？
view繪制機制和CPU之間關系？
view渲染機制和GPU之間關系？
所有的切圓角都很浪費性能嗎？
離屏渲染很nb嗎?
那些繪制API都是哪個類提供的我如何系統的學習它？
如何優化CPU /GPU使用率？

view繪制渲染機制和runloop什么關系？

代碼示例

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    ZYYView *view = [[ZYYView alloc] init];
    view.backgroundColor = [UIColor whiteColor];
    view.bounds = CGRectMake(0, 0, 100, 100);
    view.center = CGPointMake(100, 100);
    [self.view addSubview:view];
}

@end

@implementation ZYYView

- (void)drawRect:(CGRect)rect {
    CGContextRef con = UIGraphicsGetCurrentContext();
    CGContextAddEllipseInRect(con, CGRectMake(0,0,100,200));
    CGContextSetRGBFillColor(con, 0, 0, 1, 1);
    CGContextFillPath(con);
}

@end

堆棧展示

這里寫圖片描述

底層原理

當在操作 UI 時，比如改變了 Frame、更新了 UIView/CALayer 的層次時，或者手動調用了 UIView/CALayer 的 setNeedsLayout/setNeedsDisplay方法后，這個 UIView/CALayer 就被標記為待處理，并被提交到一個全局的容器去。
蘋果注冊了一個 Observer 監聽 BeforeWaiting(即將進入休眠) 和 Exit (即將退出Loop) 事件，回調去執行一個很長的函數：
_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()。這個函數里會遍歷所有待處理的 UIView/CAlayer 以執行實際的繪制和調整，并更新 UI 界面。
這個函數內部的調用棧大概是這樣的：

_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()
QuartzCore:CA::Transaction::observer_callback:
CA::Transaction::commit();
CA::Context::commit_transaction();
CA::Layer::layout_and_display_if_needed();
CA::Layer::layout_if_needed();
[CALayer layoutSublayers];
[UIView layoutSubviews];
CA::Layer::display_if_needed();
[CALayer display];
[UIView drawRect];

我們上圖的堆棧信息截圖，看到巴拉巴拉一大堆調用堆棧信息，其實這就是個函數做的孽。如何不能理解，那直接看下面的流程圖吧。

流程圖

所謂的列表卡頓，到底是什么原因引發的？

iOS的mainRunloop是一個60fps的回調，也就是說每16.7ms會繪制一次屏幕，這個時間段內要完成view的緩沖區創建，view內容的繪制（如果重寫了drawRect），這些CPU的工作。然后將這個緩沖區交給GPU渲染，這個過程又包括多個view的拼接(compositing)，紋理的渲染（Texture）等，最終顯示在屏幕上。整個過程就是我們上面畫的流程圖。 因此，如果在16.7ms內完不成這些操作，比如，CPU做了太多的工作，或者view層次過于多，圖片過于大，導致GPU壓力太大，就會導致“卡”的現象，也就是丟幀

我們經常在drawrect方法里繪制代碼，但該方法是誰調用的何時調用的？

產品繪圖需求

首先我們假設有這樣一個需求：實現下面的橢圓效果：

這里寫圖片描述

代碼示例

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    ZYYView *view = [[ZYYView alloc] init];
    view.backgroundColor = [UIColor whiteColor];
    view.bounds = CGRectMake(0, 0, 100, 100);
    view.center = CGPointMake(100, 100);
    [self.view addSubview:view];
}

@end

@implementation ZYYView

- (void)drawRect:(CGRect)rect {
    CGContextRef con = UIGraphicsGetCurrentContext();
    CGContextAddEllipseInRect(con, CGRectMake(0,0,100,200));
    CGContextSetRGBFillColor(con, 0, 0, 1, 1);
    CGContextFillPath(con);
}

@end

堆棧展示

這里寫圖片描述

底層原理

1、在[ZYYView drawRect:] 方法之前，先調用了 [UIView(CALayerDelegate) drawLayer:inContext:] 和 [CALayer drawInContext:]
2、如果 [self.view addSubview:view]; 被注銷掉則 drawRect 不執行?？梢钥隙?drawRect
方法是由 addSubview 函數觸發的。

流程圖

drawrect方法內為何第一行代碼總要獲取圖形的上下文

代碼示例

CGContextRef con = UIGraphicsGetCurrentContext();

堆棧展示

這里寫圖片描述

底層原理
每一個UIView都有一個layer，每一個layer都有個content，這個content指向的是一塊緩存，叫做backing store
當UIView被繪制時（從 CA::Transaction::commit:以后），CPU執行drawRect，通過context將數據寫入backing store
當backing store寫完后，通過render server交給GPU去渲染，將backing store中的bitmap數據顯示在屏幕上
所以在 drawRect 方法中要首先獲取 context

layer的代理必須是view嗎，可以是vc嗎？為何CALayerDelegate 不能主動遵循？

代碼示例

代碼1

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    ZYYLayer *layer = [ZYYLayer layer];
    layer.bounds    = CGRectMake(0, 0, 100, 100);
    layer.position  = CGPointMake(100, 100);
    [layer setNeedsDisplay];
    [self.view.layer addSublayer:layer];
}

@end

@implementation ZYYLayer

- (void)drawInContext:(CGContextRef)ctx {
    CGContextAddEllipseInRect(ctx, CGRectMake(0,0,100,200));
    CGContextSetRGBFillColor(ctx, 0, 0, 1, 1);
    CGContextFillPath(ctx);
}

@end

代碼二

#import <UIKit/UIKit.h>

@interface ViewController : UIViewController

@end

#import "ViewController.h"

@interface ViewController ()

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    CALayer *layer  = [CALayer layer];
    layer.bounds    = CGRectMake(0, 0, 100, 100);
    layer.position  = CGPointMake(100, 100);
    layer.delegate  = self;
    [layer setNeedsDisplay];
    [self.view.layer addSublayer:layer];
}

- (void)drawLayer:(CALayer *)layer inContext:(CGContextRef)ctx {
    CGContextAddEllipseInRect(ctx, CGRectMake(0,0,100,200));
    CGContextSetRGBFillColor(ctx, 0, 0, 1, 1);
    CGContextFillPath(ctx);
}

@end

圖標展示

綜合以上2種不同的繪制函數加上uiview下的drawrect方法一起區別：

編號	所在的類或類別	方法	出現范圍	可以使用的API	viewDidLoad	優先級
1	UIView(UIViewRendering)	drawRect	自定義view類	UIkit 、CoreGraphics		3
2	CALayer	drawInContext	自定義layer類	CoreGraphics	[layer setNeedsDisplay]	1
3	NSObject (CALayerDelegate)	drawLayer:inContext	vc類、自定義layer、view類	UIkit、CoreGraphics	[layer setNeedsDisplay] layer.delegate = self	2

底層原理

這里寫圖片描述

不能再將某個UIView設置為CALayer的delegate，因為UIView對象已經是它內部根層的delegate，再次設置為其他層的delegate就會出問題。

這里寫圖片描述

在設置代理的時候，它并不要求我們遵守協議，說明這個方法為非正式協議，就不需要再額外的顯示遵守協議了

view繪制機制和CPU之間關系

創建對象

性能瓶頸：

創建對象會分配內存，對象過多，比較消耗 CPU 資源。

優化方案：

1、盡量用輕量的對象代替重量的對象，可以對性能有所優化。比如 CALayer 比 UIView 要輕量，如果不需要響應觸摸事件，用 CALayer 顯示會更加合適。如果對象不涉及 UI 操作，則盡量放到后臺線程去創建，但如果是包含了 CALayer 的控件，都只能在主線程創建和操作。
2、通過 Storyboard 創建視圖對象時，其資源消耗會比直接通過代碼創建對象要大非常多。
3、使用懶加載，盡量推遲對象創建的時間，并把對象的創建分散到多個任務中去。

調整對象

調整對象視圖層級

性能瓶頸：

對象的調整也經常是消耗 CPU 資源的地方。視圖層次調整時，UIView、CALayer 之間會出現很多方法調用與通知。

優化方案：

盡量的避免或者減少調整視圖層次、添加和移除視圖。

調整對象布局計算

性能瓶頸：視圖布局的計算是 App 中最為常見的消耗 CPU 資源的地方

優化方案：不論通過何種技術對視圖進行布局，其最終都會落到對 UIView.frame/bounds/center 等屬性的調整上。對這些屬性的調整非常消耗資源，所以盡量提前計算好布局，如果一次性可以調整好對應屬性，就不要多次、頻繁的計算和調整這些屬性。

調整對象文本計算

性能瓶頸：如果一個界面中包含大量文本（比如微博微信朋友圈等），文本的寬高計算會占用很大一部分資源。

優化方案：用 [NSAttributedString boundingRectWithSize:options:context:] 來計算文本寬高，用 -[NSAttributedString drawWithRect:options:context:] 來繪制文本，記住放到后臺線程進行以避免阻塞主線程。

圖像的繪制

流程圖

底層原理

我們回過頭思考圖形的上下文 CGContextRef的創建歷程。

? addsubview 的時候觸發的
? CPU會為layer分配一塊內存用來繪制bitmap，叫做backing store
? layer創建指向這塊bitmap緩沖區的指針，叫做CGContextRef
? 通過CoreGraphic的api，也叫Quartz2D，繪制bitmap
? 將layer的content指向生成的bitmap

其實 CGContextRef 的創建過程就是CPU的工作過程
CPU 將view變成了bitmap 完成自己工作，剩下就是GPU的工作了。

view渲染機制和GPU之間關系

GPU功能

GPU處理的單位是Texture
基本上我們控制GPU都是通過OpenGL來完成的，但是從bitmap到Texture之間需要一座橋梁，Core Animation正好充當了這個角色：
Core Animation對OpenGL的api有一層封裝，當我們的要渲染的layer已經有了bitmap content的時候，這個content一般來說是一個CGImageRef，CoreAnimation會創建一個OpenGL的Texture并將CGImageRef（bitmap）和這個Texture綁定，通過TextureID來標識。
這個對應關系建立起來之后，剩下的任務就是GPU如何將Texture渲染到屏幕上了。

GPU工作模式：

整個過程也就是一件事：CPU將準備好的bitmap放到RAM里，GPU去搬這快內存到VRAM中處理。
而這個過程GPU所能承受的極限大概在16.7ms完成一幀的處理，所以最開始提到的60fps其實就是GPU能處理的最高頻率。

GPU性能瓶頸

因此，GPU的挑戰有兩個：
? 將數據從RAM搬到VRAM中
? 將Texture渲染到屏幕上
這兩個中瓶頸基本在第二點上。渲染Texture基本要處理這么幾個問題：

Compositing：

Compositing是指將多個紋理拼到一起的過程，對應UIKit，是指處理多個view合到一起的情況，如

[self.view addsubview : subview]

如果view之間沒有疊加，那么GPU只需要做普通渲染即可。如果多個view之間有疊加部分，GPU需要做blending。
加入兩個view大小相同，一個疊加在另一個上面，那么計算公式如下：

R = S+D*(1-Sa)

R: 為最終的像素值
S: 代表上面的Texture（Top Texture）
D: 代表下面的Texture(lower Texture)
Sa代表Texture的alpha值。
其中S,D都已經pre-multiplied各自的alpha值。
假如Top Texture（上層view）的alpha值為1，即不透明。那么它會遮住下層的Texture。即,R = S。是合理的。假如Top Texture（上層view）的alpha值為0.5，S 為 (1,0,0)，乘以alpha后為(0.5,0,0）。D為(0，0，1)。得到的R為（0.5，0，0.5）。
基本上每個像素點都需要這么計算一次。
因此，view的層級很復雜，或者view都是半透明的（alpha值不為1）都會帶來GPU額外的計算工作。
應用應當盡量減少視圖數量和層次，并在不透明的視圖里標明 opaque 屬性以避免無用的 Alpha 通道合成。

Size

這個問題，主要是處理image帶來的，假如內存里有一張400x400的圖片，要放到100x100的imageview里，如果不做任何處理，直接丟進去，問題就大了，這意味著，GPU需要對大圖進行縮放到小的區域顯示，需要做像素點的sampling，這種smapling的代價很高，又需要兼顧pixel alignment。計算量會飆升。

shouldRasterize

其中shouldRasterize（光柵化）是比較特別的一種：
光柵化概念：將圖轉化為一個個柵格組成的圖象。
光柵化特點：每個元素對應幀緩沖區中的一像素。

shouldRasterize = YES在其他屬性觸發離屏渲染的同時，會將光柵化后的內容緩存起來，如果對應的layer及其sublayers沒有發生改變，在下一幀的時候可以直接復用。shouldRasterize = YES，這將隱式的創建一個位圖，各種陰影遮罩等效果也會保存到位圖中并緩存起來，從而減少渲染的頻度（不是矢量圖）。

相當于光柵化是把GPU的操作轉到CPU上了，生成位圖緩存，直接讀取復用。

當你使用光柵化時，你可以開啟“Color Hits Green and Misses Red”來檢查該場景下光柵化操作是否是一個好的選擇。綠色表示緩存被復用，紅色表示緩存在被重復創建。

如果光柵化的層變紅得太頻繁那么光柵化對優化可能沒有多少用處。位圖緩存從內存中刪除又重新創建得太過頻繁，紅色表明緩存重建得太遲?？梢葬槍π缘倪x擇某個較小而較深的層結構進行光柵化，來嘗試減少渲染時間。

注意：
對于經常變動的內容,這個時候不要開啟,否則會造成性能的浪費

例如我們日程經常打交道的TableViewCell,因為TableViewCell的重繪是很頻繁的（因為Cell的復用）,如果Cell的內容不斷變化,則Cell需要不斷重繪,如果此時設置了cell.layer可光柵化。則會造成大量的離屏渲染,降低圖形性能。

Offscreen Rendering And Mask（離屏渲染）

GPU屏幕渲染有以下兩種方式：

On-Screen Rendering
意為當前屏幕渲染，指的是GPU的渲染操作是在當前用于顯示的屏幕緩沖區中進行。

Off-Screen Rendering
意為離屏渲染，指的是GPU在當前屏幕緩沖區以外新開辟一個緩沖區進行渲染操作。

設置了以下屬性時，都會觸發離屏繪制：

shouldRasterize（光柵化）
masks（遮罩）
shadows（陰影）
edge antialiasing（抗鋸齒）
group opacity（不透明）
復雜形狀設置圓角等
漸變

為什么會使用離屏渲染

當使用圓角，陰影，遮罩的時候，圖層屬性的混合體被指定為在未預合成之前不能直接在屏幕中繪制，所以就需要屏幕外渲染被喚起。

屏幕外渲染并不意味著軟件繪制，但是它意味著圖層必須在被顯示之前在一個屏幕外上下文中被渲染（不論CPU還是GPU）。

性能瓶頸：

如果我們對layer做這樣的操作：

label.layer.cornerRadius  = 5.0f;
label.layer.masksToBounds = YES;

會產生offscreen rendering,它帶來的最大的問題是，當渲染這樣的layer的時候，需要額外開辟內存，繪制好radius，mask，然后再將繪制好的bitmap重新賦值給layer。所以當使用離屏渲染的時候會很容易造成性能消耗，屏幕外緩沖區跟當前屏幕緩沖區上下文切換是很耗性能的。

優化方案：

1、因此繼續性能的考慮，Quartz提供了優化的api：

  label.layer.cornerRadius       = 5.0f;
  label.layer.masksToBounds      = YES;
  label.layer.shouldRasterize    = YES;
  label.layer.rasterizationScale = label.layer.contentsScale;

簡單的說，這是一種cache機制。
2、只需要圓角的某些場合，也可以用一張已經繪制好的圓角圖片覆蓋到原本視圖上面來模擬相同的視覺效果。
3、最徹底的解決辦法，就是把需要顯示的圖形在后臺線程繪制為圖片，避免使用圓角、陰影、遮罩等屬性.

同樣GPU的性能也可以通過instrument去衡量：

這里寫圖片描述

紅色代表GPU需要做額外的工作來渲染View，綠色代表GPU無需做額外的工作來處理bitmap。

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發布，文章內容僅代表作者本人觀點，簡書系信息發布平臺，僅提供信息存儲服務。

人面猴
序言：七十年代末，一起剝皮案震驚了整個濱河市，隨后出現的幾起案子，更是在濱河造成了極大的恐慌，老刑警劉巖，帶你破解...
沈念sama閱讀 230,527評論 6贊 544
死咒
序言：濱河連續發生了三起死亡事件，死亡現場離奇詭異，居然都是意外死亡，警方通過查閱死者的電腦和手機，發現死者居然都...
沈念sama閱讀 99,687評論 3贊 429
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人，你說我怎么就攤上這事?！?“怎么了？”我有些...
開封第一講書人閱讀 178,640評論 0贊 383
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵，是天一觀的道長。經常有香客問我，道長，這世上最難降的妖魔是什么？我笑而不...
開封第一講書人閱讀 63,957評論 1贊 318
?港島之戀（遺憾婚禮）
正文為了忘掉前任，我火速辦了婚禮，結果婚禮上，老公的妹妹穿的比我還像新娘。我一直安慰自己，他們只是感情好，可當我...
茶點故事閱讀 72,682評論 6贊 413
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布。她就那樣靜靜地躺著，像睡著了一般。火紅的嫁衣襯著肌膚如雪。梳的紋絲不亂的頭發上，一...
開封第一講書人閱讀 56,011評論 1贊 329
城市分裂傳說
那天，我揣著相機與錄音，去河邊找鬼。笑死，一個胖子當著我的面吹牛，可吹牛的內容都是我干的。我是一名探鬼主播，決...
沈念sama閱讀 44,009評論 3贊 449
雙鴛鴦連環套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了？” 一聲冷哼從身側響起，我...
開封第一講書人閱讀 43,183評論 0贊 290
萬榮殺人案實錄
序言：老撾萬榮一對情侶失蹤，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后，有當地人在樹林里發現了一具尸體，經...
沈念sama閱讀 49,714評論 1贊 336
?護林員之死
正文獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內容為張勛視角年9月15日...
茶點故事閱讀 41,435評論 3贊 359
?白月光啟示錄
正文我和宋清朗相戀三年，在試婚紗的時候發現自己被綠了。大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
茶點故事閱讀 43,665評論 1贊 374
活死人
序言：一個原本活蹦亂跳的男人離奇死亡，死狀恐怖，靈堂內的尸體忽然破棺而出，到底是詐尸還是另有隱情，我是刑警寧澤，帶...
沈念sama閱讀 39,148評論 5贊 365
?日本核電站爆炸內幕
正文年R本政府宣布，位于F島的核電站，受9級特大地震影響，放射性物質發生泄漏。R本人自食惡果不足惜，卻給世界環境...
茶點故事閱讀 44,838評論 3贊 350
男人毒藥：我在死后第九天來索命
文/蒙蒙一、第九天我趴在偏房一處隱蔽的房頂上張望。院中可真熱鬧，春花似錦、人聲如沸。這莊子的主人今日做“春日...
開封第一講書人閱讀 35,251評論 0贊 28
一樁弒父案，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽。三九已至，卻和暖如春，著一層夾襖步出監牢的瞬間，已是汗流浹背。一陣腳步聲響...
開封第一講書人閱讀 36,588評論 1贊 295
情欲美人皮
我被黑心中介騙來泰國打工，沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人。一個月前我還...
沈念sama閱讀 52,379評論 3贊 400
代替公主和親
正文我出身青樓，卻偏偏與公主長得像，于是被迫代替她去往敵國和親。傳聞我的和親對象是個殘疾皇子，可洞房花燭夜當晚...
茶點故事閱讀 48,627評論 2贊 380

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

iOS 界面渲染

嘗試和大家一起探討以下問題：

view繪制渲染機制和runloop什么關系？

代碼示例

堆棧展示

底層原理

流程圖

所謂的列表卡頓，到底是什么原因引發的？

我們經常在drawrect方法里繪制代碼，但該方法是誰調用的 何時調用的？

產品繪圖需求

代碼示例

堆棧展示

底層原理

流程圖

drawrect方法內為何第一行代碼總要獲取圖形的上下文

layer的代理必須是view嗎，可以是vc嗎？為何CALayerDelegate 不能主動遵循？

代碼示例

圖標展示

底層原理

view繪制機制和CPU之間關系

創建對象

性能瓶頸：

優化方案：

調整對象

調整對象視圖層級

性能瓶頸：

優化方案：

調整對象布局計算

性能瓶頸：視圖布局的計算是 App 中最為常見的消耗 CPU 資源的地方

調整對象文本計算

性能瓶頸：如果一個界面中包含大量文本（比如微博微信朋友圈等），文本的寬高計算會占用很大一部分資源。

優化方案：用 [NSAttributedString boundingRectWithSize:options:context:] 來計算文本寬高，用 -[NSAttributedString drawWithRect:options:context:] 來繪制文本，記住放到后臺線程進行以避免阻塞主線程。

圖像的繪制

流程圖

底層原理

view渲染機制和GPU之間關系

GPU功能

GPU工作模式：

GPU性能瓶頸

Compositing：

Size

shouldRasterize

Offscreen Rendering And Mask（離屏渲染）

性能瓶頸：

優化方案：

推薦閱讀更多精彩內容

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

所謂的列表卡頓，到底是什么原因引發的？

我們經常在drawrect方法里繪制代碼，但該方法是誰調用的何時調用的？

layer的代理必須是view嗎，可以是vc嗎？為何CALayerDelegate 不能主動遵循？

性能瓶頸：如果一個界面中包含大量文本（比如微博微信朋友圈等），文本的寬高計算會占用很大一部分資源。