作者: hi_xgb
地址: http://www.reibang.com/p/1b5cbf155b31
前言
在軟件開(kāi)發(fā)領(lǐng)域里經(jīng)常能聽(tīng)到這樣一句話(huà)沾凄，“過(guò)早的優(yōu)化是萬(wàn)惡之源”壮韭，不要過(guò)早優(yōu)化或者過(guò)度優(yōu)化拘荡。我認(rèn)為在編碼過(guò)程中時(shí)刻注意性能影響是有必要的胳徽，但凡事都有個(gè)度伍派，不能為了性能耽誤了開(kāi)發(fā)進(jìn)度鸭你。在時(shí)間緊急的情況下我們往往采用“quick and dirty”的方案來(lái)快速出成果屈张，后面再迭代優(yōu)化擒权，即所謂的敏捷開(kāi)發(fā)。與之相對(duì)應(yīng)的是傳統(tǒng)軟件開(kāi)發(fā)中的瀑布流開(kāi)發(fā)流程阁谆。
卡頓產(chǎn)生的原因
在 iOS 系統(tǒng)中碳抄，圖像內(nèi)容展示到屏幕的過(guò)程需要 CPU 和 GPU 共同參與。CPU 負(fù)責(zé)計(jì)算顯示內(nèi)容场绿，比如視圖的創(chuàng)建剖效、布局計(jì)算、圖片解碼焰盗、文本繪制等璧尸。隨后 CPU 會(huì)將計(jì)算好的內(nèi)容提交到 GPU 去，由 GPU 進(jìn)行變換姨谷、合成逗宁、渲染。之后 GPU 會(huì)把渲染結(jié)果提交到幀緩沖區(qū)去梦湘，等待下一次 VSync 信號(hào)到來(lái)時(shí)顯示到屏幕上瞎颗。由于垂直同步的機(jī)制，如果在一個(gè) VSync 時(shí)間內(nèi)捌议，CPU 或者 GPU 沒(méi)有完成內(nèi)容提交哼拔，則那一幀就會(huì)被丟棄，等待下一次機(jī)會(huì)再顯示瓣颅，而這時(shí)顯示屏?xí)Ａ糁暗膬?nèi)容不變倦逐。這就是界面卡頓的原因。
因此宫补，我們需要平衡 CPU 和 GPU 的負(fù)荷避免一方超負(fù)荷運(yùn)算檬姥。為了做到這一點(diǎn)，我們首先得了解 CPU 和 GPU 各自負(fù)責(zé)哪些內(nèi)容粉怕。
上面的圖展示了 iOS 系統(tǒng)下各個(gè)模塊所處的位置健民，下面我們?cè)倬唧w看一下 CPU 和 GPU 對(duì)應(yīng)了哪些操作。
CPU 消耗型任務(wù)
布局計(jì)算
布局計(jì)算是 iOS 中最為常見(jiàn)的消耗 CPU 資源的地方贫贝，如果視圖層級(jí)關(guān)系比較復(fù)雜秉犹，計(jì)算出所有圖層的布局信息就會(huì)消耗一部分時(shí)間。因此我們應(yīng)該盡量提前計(jì)算好布局信息稚晚，然后在合適的時(shí)機(jī)調(diào)整對(duì)應(yīng)的屬性崇堵。還要避免不必要的更新，只在真正發(fā)生了布局改變時(shí)再更新客燕。
對(duì)象創(chuàng)建
對(duì)象創(chuàng)建過(guò)程伴隨著內(nèi)存分配鸳劳、屬性設(shè)置、甚至還有讀取文件等操作幸逆，比較消耗 CPU 資源棍辕。盡量用輕量的對(duì)象代替重量的對(duì)象暮现，可以對(duì)性能有所優(yōu)化。比如 CALayer 比 UIView 要輕量許多楚昭，如果視圖元素不需要響應(yīng)觸摸事件栖袋，用 CALayer 會(huì)更加合適。
通過(guò) Storyboard 創(chuàng)建視圖對(duì)象還會(huì)涉及到文件反序列化操作抚太，其資源消耗會(huì)比直接通過(guò)代碼創(chuàng)建對(duì)象要大非常多塘幅，在性能敏感的界面里，Storyboard 并不是一個(gè)好的技術(shù)選擇尿贫。
對(duì)于列表類(lèi)型的頁(yè)面电媳，還可以參考 UITableView 的復(fù)用機(jī)制。每次要初始化 View 對(duì)象時(shí)先根據(jù) identifier 從緩存池里取庆亡，能取到就復(fù)用這個(gè) View 對(duì)象匾乓，取不到再真正執(zhí)行初始化過(guò)程∮帜保滑動(dòng)屏幕時(shí)拼缝，會(huì)將滑出屏幕外的 View 對(duì)象根據(jù) identifier 放入緩存池，新進(jìn)入屏幕可見(jiàn)范圍內(nèi)的 View 又根據(jù)前面的規(guī)則來(lái)決定是否要真正初始化彰亥。
Autolayout
Autolayout 是蘋(píng)果在 iOS6 之后新引入的布局技術(shù)咧七，在大多數(shù)情況下這一技術(shù)都能大大提升開(kāi)發(fā)速度，特別是在需要處理多語(yǔ)言時(shí)任斋。比如阿拉伯語(yǔ)下布局是從右往左继阻，通過(guò) Autolayout 設(shè)置 leading 和 trailing 即可。
但是 Autolayout 對(duì)于復(fù)雜視圖來(lái)說(shuō)常常會(huì)產(chǎn)生嚴(yán)重的性能問(wèn)題废酷，對(duì)于性能敏感的頁(yè)面建議還是使用手動(dòng)布局的方式瘟檩，并控制好刷新頻率，做到真正需要調(diào)整布局時(shí)再重新布局澈蟆。
文本計(jì)算
如果一個(gè)界面中包含大量文本（比如微博芒帕、微信朋友圈等），文本的寬高計(jì)算會(huì)占用很大一部分資源丰介，并且不可避免。
一個(gè)比較常見(jiàn)的場(chǎng)景是在 UITableView 中鉴分，heightForRowAtIndexPath
這個(gè)方法會(huì)被頻繁調(diào)用哮幢，即使不是耗時(shí)的計(jì)算在調(diào)用次數(shù)多了之后也會(huì)帶來(lái)性能損耗。這里的優(yōu)化就是盡量避免每次都重新進(jìn)行文本的行高計(jì)算志珍，可以在獲取到 Model 數(shù)據(jù)后就根據(jù)文本內(nèi)容計(jì)算好布局信息橙垢，然后將這份布局信息作為一個(gè)屬性保存到對(duì)應(yīng)的 Model 中，這樣在 UITableView 的回調(diào)中就可以直接使用 Model 中的屬性伦糯，減少了文本的計(jì)算柜某。
文本渲染
屏幕上能看到的所有文本內(nèi)容控件嗽元，包括 UIWebView，在底層都是通過(guò) CoreText 排版喂击、繪制為 Bitmap 顯示的剂癌。常見(jiàn)的文本控件 （UILabel、UITextView 等）翰绊，其排版和繪制都是在主線(xiàn)程進(jìn)行的佩谷，當(dāng)顯示大量文本時(shí)，CPU 的壓力會(huì)非常大监嗜。
這一部分的性能優(yōu)化就需要我們放棄使用系統(tǒng)提供的上層控件轉(zhuǎn)而直接使用 CoreText 進(jìn)行排版控制谐檀。
Wherever possible, try to avoid making changes to the frame of a view that contains text, because it will cause the text to be redrawn. For example, if you need to display a static block of text in the corner of a layer that frequently changes size, put the text in a sublayer instead.
上面這段話(huà)引用自 iOS Core Animation: Advanced Techniques，翻譯過(guò)來(lái)的意思就是說(shuō)包含文本的視圖在改變布局時(shí)會(huì)觸發(fā)文本的重新渲染裁奇，對(duì)于靜態(tài)文本我們應(yīng)該盡量減少它所在視圖的布局修改桐猬。
圖像的繪制
圖像的繪制通常是指用那些以 CG 開(kāi)頭的方法把圖像繪制到畫(huà)布中，然后從畫(huà)布創(chuàng)建圖片并顯示的過(guò)程刽肠。前面的模塊圖里介紹了 CoreGraphic 是作用在 CPU 之上的溃肪，因此調(diào)用 CG 開(kāi)頭的方法消耗的是 CPU 資源。我們可以將繪制過(guò)程放到后臺(tái)線(xiàn)程五垮，然后在主線(xiàn)程里將結(jié)果設(shè)置到 layer 的 contents 中乍惊。代碼如下：
- (void)display {
dispatch_async(backgroundQueue, ^{
CGContextRef ctx = CGBitmapContextCreate(...);
// draw in context...
CGImageRef img = CGBitmapContextCreateImage(ctx);
CFRelease(ctx);
dispatch_async(mainQueue, ^{
layer.contents = img;
});
});
}
圖片的解碼
Once an image file has been loaded, it must then be decompressed. This decompression can be a computationally complex task and take considerable time. The decompressed image will also use substantially more memory than the original.
圖片被加載后需要解碼，圖片的解碼是一個(gè)復(fù)雜耗時(shí)的過(guò)程放仗，并且需要占用比原始圖片還多的內(nèi)存資源润绎。
為了節(jié)省內(nèi)存，iOS 系統(tǒng)會(huì)延遲解碼過(guò)程诞挨， 在圖片被設(shè)置到 layer 的 contents 屬性或者設(shè)置成 UIImageView 的 image 屬性后才會(huì)執(zhí)行解碼過(guò)程莉撇，但是這兩個(gè)操作都是在主線(xiàn)程進(jìn)行，還是會(huì)帶來(lái)性能問(wèn)題惶傻。
如果想要提前解碼棍郎，可以使用 ImageIO 或者提前將圖片繪制到 CGContext 中，這部分實(shí)踐可以參考 iOS Core Animation: Advanced Techniques( http://apprize.info/apple/ios_5/15.html )
這里多提一點(diǎn)银室，常用的 UIImage 加載方法有 imageNamed和 imageWithContentsOfFile涂佃。其中 imageNamed加載圖片后會(huì)馬上解碼，并且系統(tǒng)會(huì)將解碼后的圖片緩存起來(lái)蜈敢，但是這個(gè)緩存策略是不公開(kāi)的辜荠，我們無(wú)法知道圖片什么時(shí)候會(huì)被釋放。因此在一些性能敏感的頁(yè)面抓狭，我們還可以用 static 變量 hold 住 imageNamed加載到的圖片避免被釋放掉伯病，以空間換時(shí)間的方式來(lái)提高性能。
GPU消耗型任務(wù)
相對(duì)于 CPU 來(lái)說(shuō)否过，GPU 能干的事情比較單一：接收提交的紋理（Texture）和頂點(diǎn)描述（三角形）午笛，應(yīng)用變換（transform）惭蟋、混合并渲染，然后輸出到屏幕上药磺。寬泛的說(shuō)告组，大多數(shù) CALayer 的屬性都是用 GPU 來(lái)繪制。
以下一些操作會(huì)降低 GPU 繪制的性能与涡，
大量幾何結(jié)構(gòu)
所有的 Bitmap惹谐，包括圖片、文本驼卖、柵格化的內(nèi)容氨肌，最終都要由內(nèi)存提交到顯存，綁定為 GPU Texture酌畜。不論是提交到顯存的過(guò)程怎囚，還是 GPU 調(diào)整和渲染 Texture 的過(guò)程，都要消耗不少 GPU 資源桥胞。當(dāng)在較短時(shí)間顯示大量圖片時(shí)（比如 TableView 存在非常多的圖片并且快速滑動(dòng)時(shí)）恳守，CPU 占用率很低，GPU 占用非常高贩虾，界面仍然會(huì)掉幀催烘。避免這種情況的方法只能是盡量減少在短時(shí)間內(nèi)大量圖片的顯示，盡可能將多張圖片合成為一張進(jìn)行顯示缎罢。
另外當(dāng)圖片過(guò)大伊群，超過(guò) GPU 的最大紋理尺寸時(shí)，圖片需要先由 CPU 進(jìn)行預(yù)處理策精，這對(duì) CPU 和 GPU 都會(huì)帶來(lái)額外的資源消耗舰始。
視圖的混合
當(dāng)多個(gè)視圖（或者說(shuō) CALayer）重疊在一起顯示時(shí)，GPU 會(huì)首先把他們混合到一起咽袜。如果視圖結(jié)構(gòu)過(guò)于復(fù)雜丸卷，混合的過(guò)程也會(huì)消耗很多 GPU 資源。為了減輕這種情況的 GPU 消耗询刹，應(yīng)用應(yīng)當(dāng)盡量減少視圖數(shù)量和層次谜嫉，并且減少不必要的透明視圖。
離屏渲染
離屏渲染是指圖層在被顯示之前是在當(dāng)前屏幕緩沖區(qū)以外開(kāi)辟的一個(gè)緩沖區(qū)進(jìn)行渲染操作凹联。
離屏渲染需要多次切換上下文環(huán)境：先是從當(dāng)前屏幕（On-Screen）切換到離屏（Off-Screen）骄恶；等到離屏渲染結(jié)束以后，將離屏緩沖區(qū)的渲染結(jié)果顯示到屏幕上又需要將上下文環(huán)境從離屏切換到當(dāng)前屏幕匕垫，而上下文環(huán)境的切換是一項(xiàng)高開(kāi)銷(xiāo)的動(dòng)作。
會(huì)造成 offscreen rendering 的原因有：
1.陰影（UIView.layer.shadowOffset/shadowRadius/…）
2.圓角（當(dāng) UIView.layer.cornerRadius 和 UIView.layer.maskToBounds 一起使用時(shí)）
3.圖層蒙板
4.開(kāi)啟光柵化（shouldRasterize = true）
使用陰影時(shí)同時(shí)設(shè)置 shadowPath 就能避免離屏渲染大大提升性能虐呻，后面會(huì)有一個(gè) Demo 來(lái)演示象泵；圓角觸發(fā)的離屏渲染可以用 CoreGraphics 將圖片處理成圓角來(lái)避免寞秃。
CALayer 有一個(gè) shouldRasterize 屬性，將這個(gè)屬性設(shè)置成 true 后就開(kāi)啟了光柵化偶惠。開(kāi)啟光柵化后會(huì)將圖層繪制到一個(gè)屏幕外的圖像春寿，然后這個(gè)圖像將會(huì)被緩存起來(lái)并繪制到實(shí)際圖層的 contents 和子圖層，對(duì)于有很多的子圖層或者有復(fù)雜的效果應(yīng)用忽孽，這樣做就會(huì)比重繪所有事務(wù)的所有幀來(lái)更加高效绑改。但是光柵化原始圖像需要時(shí)間，而且會(huì)消耗額外的內(nèi)存兄一。
光柵化也會(huì)帶來(lái)一定的性能損耗厘线，是否要開(kāi)啟就要根據(jù)實(shí)際的使用場(chǎng)景了，圖層內(nèi)容頻繁變化時(shí)不建議使用出革。最好還是用 Instruments 比對(duì)開(kāi)啟前后的 FPS 來(lái)看是否起到了優(yōu)化效果造壮。
注意：shouldRasterize = true 時(shí)記得同時(shí)設(shè)置 rasterizationScale
Instruments 使用
Instruments 是一系列工具集，我們這里只演示 Core Animation 的使用骂束。在 Core Animation 選項(xiàng)右下方會(huì)看到如下選項(xiàng)耳璧，
Color Blended Layers
這個(gè)選項(xiàng)選項(xiàng)基于渲染程度對(duì)屏幕中的混合區(qū)域進(jìn)行綠到紅的高亮顯示，越紅表示性能越差展箱，會(huì)對(duì)幀率等指標(biāo)造成較大的影響旨枯。紅色通常是由于多個(gè)半透明圖層疊加引起。
Color Hits Green and Misses Red
當(dāng) UIView.layer.shouldRasterize = YES 時(shí)混驰，耗時(shí)的圖片繪制會(huì)被緩存攀隔，并當(dāng)做一個(gè)簡(jiǎn)單的扁平圖片來(lái)呈現(xiàn)。這時(shí)候账胧，如果頁(yè)面的其他區(qū)塊(比如 UITableViewCell 的復(fù)用)使用緩存直接命中竞慢，就顯示綠色，反之治泥，如果不命中筹煮，這時(shí)就顯示紅色。紅色越多居夹，性能越差败潦。因?yàn)闁鸥窕删彺娴倪^(guò)程是有開(kāi)銷(xiāo)的，如果緩存能被大量命中和有效使用准脂，則總體上會(huì)降低開(kāi)銷(xiāo)劫扒，反之則意味著要頻繁生成新的緩存，這會(huì)讓性能問(wèn)題雪上加霜狸膏。
Color Copied Images
對(duì)于 GPU 不支持的色彩格式的圖片只能由 CPU 來(lái)處理沟饥，把這樣的圖片標(biāo)為藍(lán)色。藍(lán)色越多，性能越差贤旷。
Color Immediately
通常 Core Animation Instruments 以每毫秒 10 次的頻率更新圖層調(diào)試顏色广料。對(duì)某些效果來(lái)說(shuō)，這顯然太慢了幼驶。這個(gè)選項(xiàng)就可以用來(lái)設(shè)置每幀都更新（可能會(huì)影響到渲染性能艾杏，而且會(huì)導(dǎo)致幀率測(cè)量不準(zhǔn)，所以不要一直都設(shè)置它）盅藻。
Color Misaligned Images
這個(gè)選項(xiàng)檢查了圖片是否被縮放购桑，以及像素是否對(duì)齊。被放縮的圖片會(huì)被標(biāo)記為黃色氏淑，像素不對(duì)齊則會(huì)標(biāo)注為紫色勃蜘。黃色、紫色越多夸政，性能越差元旬。
Color Offscreen-Rendered Yellow
這個(gè)選項(xiàng)會(huì)把那些離屏渲染的圖層顯示為黃色。黃色越多守问，性能越差匀归。這些顯示為黃色的圖層很可能需要用 shadowPath 或者 shouldRasterize 來(lái)優(yōu)化。
Color OpenGL Fast Path Blue
這個(gè)選項(xiàng)會(huì)把任何直接使用 OpenGL 繪制的圖層顯示為藍(lán)色耗帕。藍(lán)色越多穆端，性能越好。如果僅僅使用 UIKit 或者 Core Animation 的 API仿便，那么不會(huì)有任何效果体啰。
Flash Updated Regions
這個(gè)選項(xiàng)會(huì)把重繪的內(nèi)容顯示為黃色。不該出現(xiàn)的黃色越多嗽仪，性能越差荒勇。通常我們希望只是更新的部分被標(biāo)記完黃色。
演示
上述幾個(gè)選項(xiàng)中常用來(lái)檢測(cè)性能的是 Color Blended Layers闻坚、Offscreen-Rendered Yellow 和 Color Hits Green and Misses Red沽翔。下面我重點(diǎn)演示一下離屏渲染和光柵化的檢測(cè)，寫(xiě)了一個(gè)簡(jiǎn)單的 Demo 設(shè)置了陰影效果窿凤，代碼如下：
view.layer.shadowOffset = CGSizeMake(1, 1);
view.layer.shadowOpacity = 1.0;
view.layer.shadowRadius = 2.0;
view.layer.shadowColor = [UIColor blackColor].CGColor;
// view.layer.shadowPath = CGPathCreateWithRect(CGRectMake(0, 0, 50, 50), NULL);
shadowPath
沒(méi)有設(shè)置時(shí)用 Instruments 檢測(cè) FPS 基本在 20 以下（iPhone6設(shè)備）仅偎，設(shè)置了 shadowPath
后基本維持在 55 左右，性能提升十分明顯雳殊。
下面來(lái)看一下光柵化的檢測(cè)橘沥，代碼如下，
view.layer.shouldRasterize = YES;
view.layer.rasterizationScale = [UIScreen mainScreen].scale;
勾選 Color Hits Green and Misses Red 選項(xiàng)后顯示如下：
我們可以看到在靜止時(shí)緩存都生效了夯秃，在快速滑動(dòng)時(shí)緩存基本不起作用座咆，因此是否要開(kāi)啟光柵化還是得根據(jù)具體場(chǎng)景痢艺，用 Instruments 檢測(cè)開(kāi)啟前后的性能來(lái)決定。
總結(jié)
本文主要總結(jié)了性能調(diào)優(yōu)的一些理論知識(shí)介陶，后面還介紹了 Instruments 中 Core Animation 的一些性能檢測(cè)指標(biāo)用法腹备。性能優(yōu)化最重要的是要使用工具來(lái)檢測(cè)而不是猜測(cè)，先查看是否有離屏渲染等問(wèn)題斤蔓，再用 Time Profiler 分析一下耗時(shí)的函數(shù)調(diào)用。修改后再用工具分析是否有改善镀岛，一步一步執(zhí)行弦牡，小心仔細(xì)。
建議大家也實(shí)際動(dòng)手分析一下自己的應(yīng)用漂羊，加深一下印象驾锰，enjoy~
參考資料
http://blog.ibireme.com/2015/11/12/smooth_user_interfaces_for_ios/
