iOS 界面渲染

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

view繪制渲染機制和runloop什么關(guān)系诺凡？
所謂的列表卡頓变屁，到底是什么原因引發(fā)的病瞳？
我們經(jīng)常在drawrect方法里繪制代碼揽咕，但該方法是誰調(diào)用的何時調(diào)用的？
drawrect方法內(nèi)為何第一行代碼往往要獲取圖形的上下文套菜？
layer的代理必須是view嗎亲善，可以是vc嗎，為何CALayerDelegate 不能主動遵循逗柴？
view繪制機制和CPU之間關(guān)系蛹头？
view渲染機制和GPU之間關(guān)系？
所有的切圓角都很浪費性能嗎戏溺？
離屏渲染很nb嗎?
那些繪制API都是哪個類提供的我如何系統(tǒng)的學(xué)習(xí)它掘而？
如何優(yōu)化CPU /GPU使用率？

view繪制渲染機制和runloop什么關(guān)系于购？

代碼示例

@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

堆棧展示

這里寫圖片描述

底層原理

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

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

我們上圖的堆棧信息截圖涧狮，看到巴拉巴拉一大堆調(diào)用堆棧信息炕矮，其實這就是個函數(shù)做的孽么夫。如何不能理解，那直接看下面的流程圖吧肤视。

流程圖

所謂的列表卡頓于毙，到底是什么原因引發(fā)的？

iOS的mainRunloop是一個60fps的回調(diào)庶喜，也就是說每16.7ms會繪制一次屏幕，這個時間段內(nèi)要完成view的緩沖區(qū)創(chuàng)建救鲤，view內(nèi)容的繪制（如果重寫了drawRect）久窟，這些CPU的工作。然后將這個緩沖區(qū)交給GPU渲染本缠，這個過程又包括多個view的拼接(compositing)斥扛，紋理的渲染（Texture）等，最終顯示在屏幕上丹锹。整個過程就是我們上面畫的流程圖稀颁。 因此，如果在16.7ms內(nèi)完不成這些操作楣黍，比如匾灶，CPU做了太多的工作，或者view層次過于多租漂，圖片過于大阶女，導(dǎo)致GPU壓力太大，就會導(dǎo)致“卡”的現(xiàn)象哩治，也就是丟幀

我們經(jīng)常在drawrect方法里繪制代碼秃踩，但該方法是誰調(diào)用的何時調(diào)用的？

產(chǎn)品繪圖需求

首先我們假設(shè)有這樣一個需求：實現(xiàn)下面的橢圓效果：

這里寫圖片描述

代碼示例

@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:] 方法之前憔杨，先調(diào)用了 [UIView(CALayerDelegate) drawLayer:inContext:] 和 [CALayer drawInContext:]
2、如果 [self.view addSubview:view]; 被注銷掉則 drawRect 不執(zhí)行蒜胖∠穑可以肯定 drawRect
方法是由 addSubview 函數(shù)觸發(fā)的抛蚤。

流程圖

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

代碼示例

CGContextRef con = UIGraphicsGetCurrentContext();

堆棧展示

這里寫圖片描述

底層原理
每一個UIView都有一個layer，每一個layer都有個content妖啥，這個content指向的是一塊緩存霉颠，叫做backing store
當(dāng)UIView被繪制時（從 CA::Transaction::commit:以后），CPU執(zhí)行drawRect荆虱，通過context將數(shù)據(jù)寫入backing store
當(dāng)backing store寫完后蒿偎，通過render server交給GPU去渲染，將backing store中的bitmap數(shù)據(jù)顯示在屏幕上
所以在 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

圖標(biāo)展示

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

編號	所在的類或類別	方法	出現(xiàn)范圍	可以使用的API	viewDidLoad	優(yōu)先級
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設(shè)置為CALayer的delegate岳瞭，因為UIView對象已經(jīng)是它內(nèi)部根層的delegate，再次設(shè)置為其他層的delegate就會出問題蚊锹。

這里寫圖片描述

在設(shè)置代理的時候瞳筏，它并不要求我們遵守協(xié)議，說明這個方法為非正式協(xié)議牡昆，就不需要再額外的顯示遵守協(xié)議了

view繪制機制和CPU之間關(guān)系

創(chuàng)建對象

性能瓶頸：

創(chuàng)建對象會分配內(nèi)存姚炕，對象過多，比較消耗 CPU 資源丢烘。

優(yōu)化方案：

1柱宦、盡量用輕量的對象代替重量的對象，可以對性能有所優(yōu)化播瞳。比如 CALayer 比 UIView 要輕量掸刊，如果不需要響應(yīng)觸摸事件，用 CALayer 顯示會更加合適赢乓。如果對象不涉及 UI 操作忧侧，則盡量放到后臺線程去創(chuàng)建，但如果是包含了 CALayer 的控件骏全，都只能在主線程創(chuàng)建和操作。
2尼斧、通過 Storyboard 創(chuàng)建視圖對象時姜贡，其資源消耗會比直接通過代碼創(chuàng)建對象要大非常多。
3棺棵、使用懶加載楼咳，盡量推遲對象創(chuàng)建的時間熄捍，并把對象的創(chuàng)建分散到多個任務(wù)中去。

調(diào)整對象

調(diào)整對象視圖層級

性能瓶頸：

對象的調(diào)整也經(jīng)常是消耗 CPU 資源的地方母怜。視圖層次調(diào)整時余耽，UIView、CALayer 之間會出現(xiàn)很多方法調(diào)用與通知苹熏。

優(yōu)化方案：

盡量的避免或者減少調(diào)整視圖層次碟贾、添加和移除視圖。

調(diào)整對象布局計算

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

優(yōu)化方案：不論通過何種技術(shù)對視圖進行布局轨域，其最終都會落到對 UIView.frame/bounds/center 等屬性的調(diào)整上袱耽。對這些屬性的調(diào)整非常消耗資源，所以盡量提前計算好布局干发，如果一次性可以調(diào)整好對應(yīng)屬性朱巨，就不要多次、頻繁的計算和調(diào)整這些屬性枉长。

調(diào)整對象文本計算

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

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

圖像的繪制

流程圖

底層原理

我們回過頭思考圖形的上下文 CGContextRef的創(chuàng)建歷程。

? addsubview 的時候觸發(fā)的
? CPU會為layer分配一塊內(nèi)存用來繪制bitmap粗仓，叫做backing store
? layer創(chuàng)建指向這塊bitmap緩沖區(qū)的指針嫁怀，叫做CGContextRef
? 通過CoreGraphic的api，也叫Quartz2D借浊，繪制bitmap
? 將layer的content指向生成的bitmap

其實 CGContextRef 的創(chuàng)建過程就是CPU的工作過程
CPU 將view變成了bitmap 完成自己工作塘淑，剩下就是GPU的工作了。

view渲染機制和GPU之間關(guān)系

GPU功能

GPU處理的單位是Texture
基本上我們控制GPU都是通過OpenGL來完成的蚂斤，但是從bitmap到Texture之間需要一座橋梁存捺，Core Animation正好充當(dāng)了這個角色：
Core Animation對OpenGL的api有一層封裝，當(dāng)我們的要渲染的layer已經(jīng)有了bitmap content的時候，這個content一般來說是一個CGImageRef捌治，CoreAnimation會創(chuàng)建一個OpenGL的Texture并將CGImageRef（bitmap）和這個Texture綁定岗钩，通過TextureID來標(biāo)識。
這個對應(yīng)關(guān)系建立起來之后肖油，剩下的任務(wù)就是GPU如何將Texture渲染到屏幕上了兼吓。

GPU工作模式：

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

GPU性能瓶頸

因此疲恢，GPU的挑戰(zhàn)有兩個：
? 將數(shù)據(jù)從RAM搬到VRAM中
? 將Texture渲染到屏幕上
這兩個中瓶頸基本在第二點上凶朗。渲染Texture基本要處理這么幾個問題：

Compositing：

Compositing是指將多個紋理拼到一起的過程，對應(yīng)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都已經(jīng)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的層級很復(fù)雜，或者view都是半透明的（alpha值不為1）都會帶來GPU額外的計算工作。
應(yīng)用應(yīng)當(dāng)盡量減少視圖數(shù)量和層次虽填，并在不透明的視圖里標(biāo)明 opaque 屬性以避免無用的 Alpha 通道合成。

Size

這個問題曹动，主要是處理image帶來的斋日，假如內(nèi)存里有一張400x400的圖片，要放到100x100的imageview里墓陈，如果不做任何處理恶守，直接丟進去，問題就大了贡必，這意味著兔港，GPU需要對大圖進行縮放到小的區(qū)域顯示，需要做像素點的sampling仔拟，這種smapling的代價很高衫樊，又需要兼顧pixel alignment。計算量會飆升利花。

shouldRasterize

其中shouldRasterize（光柵化）是比較特別的一種：
光柵化概念：將圖轉(zhuǎn)化為一個個柵格組成的圖象科侈。
光柵化特點：每個元素對應(yīng)幀緩沖區(qū)中的一像素。

shouldRasterize = YES在其他屬性觸發(fā)離屏渲染的同時炒事，會將光柵化后的內(nèi)容緩存起來臀栈，如果對應(yīng)的layer及其sublayers沒有發(fā)生改變，在下一幀的時候可以直接復(fù)用挠乳。shouldRasterize = YES权薯，這將隱式的創(chuàng)建一個位圖，各種陰影遮罩等效果也會保存到位圖中并緩存起來睡扬，從而減少渲染的頻度（不是矢量圖）盟蚣。

相當(dāng)于光柵化是把GPU的操作轉(zhuǎn)到CPU上了，生成位圖緩存威蕉，直接讀取復(fù)用刁俭。

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

如果光柵化的層變紅得太頻繁那么光柵化對優(yōu)化可能沒有多少用處虑粥。位圖緩存從內(nèi)存中刪除又重新創(chuàng)建得太過頻繁如孝，紅色表明緩存重建得太遲∶浯可以針對性的選擇某個較小而較深的層結(jié)構(gòu)進行光柵化第晰，來嘗試減少渲染時間。

注意：
對于經(jīng)常變動的內(nèi)容,這個時候不要開啟,否則會造成性能的浪費

例如我們?nèi)粘探?jīng)常打交道的TableViewCell,因為TableViewCell的重繪是很頻繁的（因為Cell的復(fù)用）,如果Cell的內(nèi)容不斷變化,則Cell需要不斷重繪,如果此時設(shè)置了cell.layer可光柵化。則會造成大量的離屏渲染,降低圖形性能茁瘦。

Offscreen Rendering And Mask（離屏渲染）

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

On-Screen Rendering
意為當(dāng)前屏幕渲染品抽，指的是GPU的渲染操作是在當(dāng)前用于顯示的屏幕緩沖區(qū)中進行。

Off-Screen Rendering
意為離屏渲染甜熔，指的是GPU在當(dāng)前屏幕緩沖區(qū)以外新開辟一個緩沖區(qū)進行渲染操作圆恤。

設(shè)置了以下屬性時，都會觸發(fā)離屏繪制：

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

為什么會使用離屏渲染

當(dāng)使用圓角腔稀，陰影盆昙，遮罩的時候，圖層屬性的混合體被指定為在未預(yù)合成之前不能直接在屏幕中繪制焊虏，所以就需要屏幕外渲染被喚起淡喜。

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

性能瓶頸：

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

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

會產(chǎn)生offscreen rendering,它帶來的最大的問題是炼团，當(dāng)渲染這樣的layer的時候，需要額外開辟內(nèi)存疏尿，繪制好radius们镜，mask，然后再將繪制好的bitmap重新賦值給layer润歉。所以當(dāng)使用離屏渲染的時候會很容易造成性能消耗模狭，屏幕外緩沖區(qū)跟當(dāng)前屏幕緩沖區(qū)上下文切換是很耗性能的。

優(yōu)化方案：

1踩衩、因此繼續(xù)性能的考慮嚼鹉，Quartz提供了優(yōu)化的api：

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

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

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

這里寫圖片描述

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

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者

人面猴
序言：七十年代末，一起剝皮案震驚了整個濱河市荞下，隨后出現(xiàn)的幾起案子伶选，更是在濱河造成了極大的恐慌史飞，老刑警劉巖，帶你破解...
沈念sama閱讀 218,858評論 6贊 508
死咒
序言：濱河連續(xù)發(fā)生了三起死亡事件仰税，死亡現(xiàn)場離奇詭異构资，居然都是意外死亡，警方通過查閱死者的電腦和手機陨簇，發(fā)現(xiàn)死者居然都...
沈念sama閱讀 93,372評論 3贊 395
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進店門蚯窥，熙熙樓的掌柜王于貴愁眉苦臉地迎上來，“玉大人塞帐，你說我怎么就攤上這事∥∩常” “怎么了葵姥？”我有些...
開封第一講書人閱讀 165,282評論 0贊 356
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵，是天一觀的道長句携。經(jīng)常有香客問我榔幸，道長，這世上最難降的妖魔是什么矮嫉？我笑而不...
開封第一講書人閱讀 58,842評論 1贊 295
?港島之戀（遺憾婚禮）
正文為了忘掉前任削咆，我火速辦了婚禮，結(jié)果婚禮上蠢笋，老公的妹妹穿的比我還像新娘拨齐。我一直安慰自己，他們只是感情好昨寞，可當(dāng)我...
茶點故事閱讀 67,857評論 6贊 392
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布瞻惋。她就那樣靜靜地躺著，像睡著了一般援岩。火紅的嫁衣襯著肌膚如雪歼狼。梳的紋絲不亂的頭發(fā)上，一...
開封第一講書人閱讀 51,679評論 1贊 305
城市分裂傳說
那天享怀，我揣著相機與錄音羽峰，去河邊找鬼。笑死添瓷，一個胖子當(dāng)著我的面吹牛梅屉，可吹牛的內(nèi)容都是我干的。我是一名探鬼主播鳞贷，決...
沈念sama閱讀 40,406評論 3贊 418
雙鴛鴦連環(huán)套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼履植，長吁一口氣：“原來是場噩夢啊……” “哼！你這毒婦竟也來了悄晃？” 一聲冷哼從身側(cè)響起玫霎，我...
開封第一講書人閱讀 39,311評論 0贊 276
萬榮殺人案實錄
序言：老撾萬榮一對情侶失蹤凿滤，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后庶近，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體翁脆，經(jīng)...
沈念sama閱讀 45,767評論 1贊 315
?護林員之死
正文獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內(nèi)容為張勛視角年9月15日...
茶點故事閱讀 37,945評論 3贊 336
?白月光啟示錄
正文我和宋清朗相戀三年鼻种，在試婚紗的時候發(fā)現(xiàn)自己被綠了反番。大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
茶點故事閱讀 40,090評論 1贊 350
活死人
序言：一個原本活蹦亂跳的男人離奇死亡叉钥，死狀恐怖罢缸，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情投队，我是刑警寧澤枫疆，帶...
沈念sama閱讀 35,785評論 5贊 346
?日本核電站爆炸內(nèi)幕
正文年R本政府宣布，位于F島的核電站敷鸦，受9級特大地震影響息楔，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜扒披，卻給世界環(huán)境...
茶點故事閱讀 41,420評論 3贊 331
男人毒藥：我在死后第九天來索命
文/蒙蒙一值依、第九天我趴在偏房一處隱蔽的房頂上張望。院中可真熱鬧碟案，春花似錦愿险、人聲如沸。這莊子的主人今日做“春日...
開封第一講書人閱讀 31,988評論 0贊 22
一樁弒父案拯啦，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽。三九已至熔任，卻和暖如春褒链，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背疑苔。一陣腳步聲響...
開封第一講書人閱讀 33,101評論 1贊 271
情欲美人皮
我被黑心中介騙來泰國打工甫匹，沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留，地道東北人惦费。一個月前我還...
沈念sama閱讀 48,298評論 3贊 372
代替公主和親
正文我出身青樓兵迅，卻偏偏與公主長得像，于是被迫代替她去往敵國和親薪贫。傳聞我的和親對象是個殘疾皇子恍箭，可洞房花燭夜當(dāng)晚...
茶點故事閱讀 45,033評論 2贊 355

iOS 界面渲染

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

view繪制渲染機制和runloop什么關(guān)系于购？

代碼示例

堆棧展示

底層原理

流程圖

所謂的列表卡頓于毙，到底是什么原因引發(fā)的？

我們經(jīng)常在drawrect方法里繪制代碼秃踩，但該方法是誰調(diào)用的 何時調(diào)用的？

產(chǎn)品繪圖需求

代碼示例

堆棧展示

底層原理

流程圖

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

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

代碼示例

圖標(biāo)展示

底層原理

view繪制機制和CPU之間關(guān)系

創(chuàng)建對象

性能瓶頸：

優(yōu)化方案：

調(diào)整對象

調(diào)整對象視圖層級

性能瓶頸：

優(yōu)化方案：

調(diào)整對象布局計算

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

調(diào)整對象文本計算

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

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

圖像的繪制

流程圖

底層原理

view渲染機制和GPU之間關(guān)系

GPU功能

GPU工作模式：

GPU性能瓶頸

Compositing：

Size

shouldRasterize

Offscreen Rendering And Mask（離屏渲染）

性能瓶頸：

優(yōu)化方案：

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

我們經(jīng)常在drawrect方法里繪制代碼秃踩，但該方法是誰調(diào)用的何時調(diào)用的？