一、界面渲染流程

① 渲染流程分析

• 計算機中的顯示過程通常是通過 CPU、GPU、顯示器協(xié)同工作來將圖片顯示到屏幕上，如下圖所示：

• 蘋果為了解決圖片撕裂的問題使用了 VSync + 雙緩沖區(qū)的形式，就是顯示器顯示完成一幀的渲染的時候會向發(fā)送一個垂直信號 VSync，收到這個這個垂直信號之后顯示器開始讀取另外一個幀緩沖區(qū)中的數(shù)據(jù)而 App 接到垂直信號之后開始新一幀的渲染。
• • CPU 計算好顯示內(nèi)容，提交至 GPU；
• • GPU 經(jīng)過渲染完成后將渲染的結(jié)果放入 FrameBuffer（幀緩存區(qū)）；
• • 隨后視頻控制器會按照 VSync 信號逐行讀取 FrameBuffer 的數(shù)據(jù)；
• • 經(jīng)過可能的數(shù)模轉(zhuǎn)換傳遞給顯示器進(jìn)行顯示。
• 最開始時，FrameBuffer 只有一個，這種情況下 FrameBuffer 的讀取和刷新的效率問題會受到很大的影響，雙緩沖機制就可以很好的解決這個問題：GPU 會預(yù)先渲染好一幀放入 FrameBuffer，讓視頻控制器讀取，當(dāng)下一幀渲染好后，GPU 會直接將視頻控制器的指針指向第二個 FrameBuffer。
• 雙緩存機制雖然解決了效率問題，但是隨之而言的是新的問題，當(dāng)視頻控制器還未讀取完成時，例如屏幕內(nèi)容剛顯示一半，GPU 將新的一幀內(nèi)容提交到 FrameBuffer，并將兩個 FrameBuffer 而進(jìn)行交換后，視頻控制器就會將新的一幀數(shù)據(jù)的下半段顯示到屏幕上，造成屏幕撕裂現(xiàn)象。
• 為了解決這個問題，采用了垂直同步信號機制。當(dāng)開啟垂直同步后，GPU 會等待顯示器的 VSync 信號發(fā)出后，才進(jìn)行新的一幀渲染和 FrameBuffer 更新，而目前 iOS 設(shè)備中采用的正是雙緩存區(qū) + VSync。

② 屏幕卡頓原因

• 在 VSync 信號到來后，系統(tǒng)圖形服務(wù)會通過 CADisplayLink 等機制通知 App，App 主線程開始在 CPU 中計算顯示內(nèi)容。隨后 CPU 會將計算好的內(nèi)容提交到 GPU 去，由 GPU 進(jìn)行變換、合成、渲染。隨后 GPU 會把渲染結(jié)果提交到幀緩沖區(qū)去，等待下一次 VSync 信號到來時顯示到屏幕上。由于垂直同步的機制，如果在一個 VSync 時間內(nèi)，CPU 或者 GPU 沒有完成內(nèi)容提交，則那一幀就會被丟棄，等待下一次機會再顯示，而這時顯示屏?xí)Ａ糁暗膬?nèi)容不變，中間這個等待的過程就造成了掉幀，也就是會卡頓。
• 如下圖所示，是一個顯示過程，第 1 幀在 VSync 到來前，處理完成，正常顯示，第 2 幀在 VSync 到來后，仍在處理中，此時屏幕不刷新，依舊顯示第 1 幀，此時就出現(xiàn)了掉幀情況，渲染時就會出現(xiàn)明顯的卡頓現(xiàn)象：

二、卡頓檢測

① FPS 監(jiān)控

• 蘋果的 iPhone 推薦的刷新率是60Hz，也就是每秒中刷新屏幕 60 次，也就是每秒中有 60 幀渲染完成，差不多每幀渲染的時間是 1000/60 = 16.67 毫秒整個界面會比較流暢，一般刷新率低于 45Hz ，在 16.67ms 內(nèi)沒有準(zhǔn)備好下一幀數(shù)據(jù)，就會出現(xiàn)明顯的卡頓現(xiàn)象。
• FPS 的監(jiān)控可以通過 YYFPSLabel 來實現(xiàn)，該原理主要是依靠 CADisplayLink 來實現(xiàn)的，通過 CADisplayLink 來監(jiān)聽每次屏幕刷新并獲取屏幕刷新的時間，借助 link 的時間差，來計算一次刷新刷新所需的時間，然后通過“刷新次數(shù) / 時間差”得到刷新頻次，然后使用次數(shù)（也就是1）除以每次刷新的時間間隔得到 FPS，并判斷是否其范圍，通過顯示不同的文字顏色來表示卡頓嚴(yán)重程度，具體源碼如下：

#import "YYFPSLabel.h"#import "YYKit.h"#define kSize CGSizeMake(55, 20)@implementation YYFPSLabel {CADisplayLink *_link;NSUInteger _count;NSTimeInterval _lastTime;UIFont *_font;UIFont *_subFont;NSTimeInterval _llll;}- (instancetype)initWithFrame:(CGRect)frame {if (frame.size.width == 0 && frame.size.height == 0) {frame.size = kSize;}self = [super initWithFrame:frame];self.layer.cornerRadius = 5;self.clipsToBounds = YES;self.textAlignment = NSTextAlignmentCenter;self.userInteractionEnabled = NO;self.backgroundColor = [UIColor colorWithWhite:0.000 alpha:0.700];_font = [UIFont fontWithName:@"Menlo" size:14];if (_font) {_subFont = [UIFont fontWithName:@"Menlo" size:4];} else {_font = [UIFont fontWithName:@"Courier" size:14];_subFont = [UIFont fontWithName:@"Courier" size:4];}// YYWeakProxy 這里使用了虛擬類來解決強引用問題_link = [CADisplayLink displayLinkWithTarget:[YYWeakProxy proxyWithTarget:self] selector:@selector(tick:)];[_link addToRunLoop:[NSRunLoop mainRunLoop] forMode:NSRunLoopCommonModes];return self;}- (void)dealloc {[_link invalidate];}- (CGSize)sizeThatFits:(CGSize)size {return kSize;}- (void)tick:(CADisplayLink *)link {if (_lastTime == 0) {_lastTime = link.timestamp;NSLog(@"sdf");return;}// 次數(shù)_count++;// 時間NSTimeInterval delta = link.timestamp - _lastTime;if (delta < 1) return;_lastTime = link.timestamp;float fps = _count / delta;_count = 0;CGFloat progress = fps / 60.0;UIColor *color = [UIColor colorWithHue:0.27 * (progress - 0.2) saturation:1 brightness:0.9 alpha:1];NSMutableAttributedString *text = [[NSMutableAttributedString alloc] initWithString:[NSString stringWithFormat:@"%d FPS",(int)round(fps)]];[text setColor:color range:NSMakeRange(0, text.length - 3)];[text setColor:[UIColor whiteColor] range:NSMakeRange(text.length - 3, 3)];text.font = _font;[text setFont:_subFont range:NSMakeRange(text.length - 4, 1)];self.attributedText = text;}@end

• FPS 只用在開發(fā)階段的輔助性的數(shù)值，因為它會頻繁喚醒 runloop，如果 runloop 在閑置的狀態(tài)被 CADisplayLink 喚醒則會消耗性能。
• FPS 的監(jiān)控，具體實現(xiàn)邏輯如下：

class YDWFPSLabel: UILabel {fileprivate var link: CADisplayLink = {let link = CADisplayLink.init()return link}()fileprivate var count: Int = 0fileprivate var lastTime: TimeInterval = 0.0fileprivate var fpsColor: UIColor = {return UIColor.green}()fileprivate var fps: Double = 0.0override init(frame: CGRect) {var f = frameif f.size == CGSize.zero {f.size = CGSize(width: 80.0, height: 22.0)}super.init(frame: f)self.textColor = UIColor.whiteself.textAlignment = .centerself.font = UIFont.init(name: "Menlo", size: 12)self.backgroundColor = UIColor.lightGray// 通過虛擬類link = CADisplayLink.init(target: YDWWeakProxy(target:self), selector: #selector(tick(_:)))link.add(to: RunLoop.current, forMode: RunLoop.Mode.common)}required init?(coder: NSCoder) {fatalError("init(coder:) has not been implemented")}deinit {link.invalidate()}@objc func tick(_ link: CADisplayLink){guard lastTime != 0 else {lastTime = link.timestampreturn}count += 1// 時間差let detla = link.timestamp - lastTimeguard detla >= 1.0 else {return}lastTime = link.timestamp// 刷新次數(shù) / 時間差 = 刷新頻次fps = Double(count) / detlalet fpsText = "\(String.init(format: "%.2f", fps)) FPS"count = 0let attrMStr = NSMutableAttributedString(attributedString: NSAttributedString(string: fpsText))if fps > 55.0 {// 流暢fpsColor = UIColor.green}else if (fps >= 50.0 && fps <= 55.0){// 一般fpsColor = UIColor.yellow}else{// 卡頓fpsColor = UIColor.red}attrMStr.setAttributes([NSAttributedString.Key.foregroundColor: fpsColor], range: NSMakeRange(0, attrMStr.length - 3))attrMStr.setAttributes([NSAttributedString.Key.foregroundColor: UIColor.white], range: NSMakeRange(attrMStr.length - 3, 3))DispatchQueue.main.async {self.attributedText = attrMStr}}}

② 通過 RunLoop 檢測卡頓

• 通過監(jiān)聽主線程 Runloop 一次循環(huán)的時間來判斷是否卡頓，這里需要配合使用 GCD 的信號量來實現(xiàn)，設(shè)置初始化信號量為 0，然后開一個子線程等待信號量的觸發(fā)，也是就是在子線程的方法里面調(diào)用 dispatch_semaphore_wait 方法設(shè)置等待時間是 1 秒，然后主線程的 Runloop 的 Observer 回調(diào)方法中發(fā)送信號也就是調(diào)用 dispatch_semaphore_signal 方法，此時時間可以置為 0 了，如果是等待時間超時則看此時的 Runloop 的狀態(tài)是否是 kCFRunLoopBeforeSources 或者是 kCFRunLoopAfterWaiting，如果在這兩個狀態(tài)下兩秒則說明有卡頓，詳細(xì)代碼如下：

#import "YDWBlockMonitor.h"@interface YDWYDWlockMonitor (){CFRunLoopActivity activity;}@property (nonatomic, strong) dispatch_semaphore_t semaphore;@property (nonatomic, assign) NSUInteger timeoutCount;@end@implementation YDWBlockMonitor+ (instancetype)sharedInstance {static id instance = nil;static dispatch_once_t onceToken;dispatch_once(&onceToken, ^{instance = [[self alloc] init];});return instance;}- (void)start{[self registerObserver];[self startMonitor];}static void CallBack(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void *info){YDWBlockMonitor *monitor = (__bridge YDWBlockMonitor *)info;monitor->activity = activity;// 發(fā)送信號dispatch_semaphore_t semaphore = monitor->_semaphore;dispatch_semaphore_signal(semaphore);}- (void)registerObserver{CFRunLoopObserverContext context = {0,(__bridge void*)self,NULL,NULL};// NSIntegerMax : 優(yōu)先級最小CFRunLoopObserverRef observer = CFRunLoopObserverCreate(kCFAllocatorDefault,kCFRunLoopAllActivities,YES,NSIntegerMax,&CallBack,&context);CFRunLoopAddObserver(CFRunLoopGetMain(), observer, kCFRunLoopCommonModes);}- (void)startMonitor{// 創(chuàng)建信號c_semaphore = dispatch_semaphore_create(0);// 在子線程監(jiān)控時長dispatch_async(dispatch_get_global_queue(0, 0), ^{while (YES){// 超時時間是 1 秒，沒有等到信號量，st 就不等于 0， RunLoop 所有的任務(wù)// 沒有接收到信號底層會先對信號量進(jìn)行減減操作，此時信號量就變成負(fù)數(shù)// 所以開始進(jìn)入等到，等達(dá)到了等待時間還沒有收到信號則進(jìn)行加加操作復(fù)原信號量// 執(zhí)行進(jìn)入等待的方法dispatch_semaphore_wait會返回非0的數(shù)// 收到信號的時候此時信號量是1 底層是減減操作，此時剛好等于0 所以直接返回0long st = dispatch_semaphore_wait(self->_semaphore, dispatch_time(DISPATCH_TIME_NOW, 1 * NSEC_PER_SEC));if (st != 0){if (self->activity == kCFRunLoopBeforeSources || self->activity == kCFRunLoopAfterWaiting){//如果一直處于處理source0或者接受mach_port的狀態(tài)則說明runloop的這次循環(huán)還沒有完成if (++self->_timeoutCount < 2){NSLog(@"timeoutCount==%lu",(unsigned long)self->_timeoutCount);continue;}// 如果超過兩秒則說明卡頓了// 一秒左右的衡量尺度 很大可能性連續(xù)來 避免大規(guī)模打印!NSLog(@"檢測到超過兩次連續(xù)卡頓");}}self->_timeoutCount = 0;}});}@end

③ 微信 matrix

• 此方案也是借助 runloop 實現(xiàn)的大體流程和方案三相同，不過微信加入了堆棧分析，能夠定位到耗時的方法調(diào)用堆棧，所以需要準(zhǔn)確的分析卡頓原因可以借助微信 matrix 來分析卡頓。當(dāng)然也可以在方案2中使用 PLCrashReporter 這個開源的第三方庫來獲取堆棧信息。
• 微信 matrix 的下載鏈接：微信 matrix

④ 滴滴 DoraemonKit

• 實現(xiàn)方案大概就是在子線程中一直 ping 主線程，在主線程卡頓的情況下，會出現(xiàn)斷在的無響應(yīng)的表現(xiàn)，進(jìn)而檢測卡頓。
• 滴滴 DoraemonKit 的下載鏈接：滴滴 DoraemonKit

三、 CPU 資源消耗優(yōu)化

① 預(yù)排版

• 預(yù)排版主要是對 CPU 進(jìn)行減負(fù)。
• 假設(shè)現(xiàn)在又個 TableView 其中需要根據(jù)每個 cell 的內(nèi)容來定 cell 的高度。知道 TableView 有重用機制，如果復(fù)用池中有數(shù)據(jù)，即將滑入屏內(nèi)的 cell 就會使用復(fù)用池內(nèi)的 cell，做到節(jié)省資源，但是還是要根據(jù)新數(shù)據(jù)的內(nèi)容來計算 cell 的高度,重新布局新 cell 中內(nèi)容的布局，這樣反復(fù)滑動 TableView 相同的 cell 就會反復(fù)計算其 frame，這樣也給 CPU 帶來了負(fù)擔(dān)。如果在得到數(shù)據(jù)創(chuàng)建模型的時候就把 cell frame 算出，TableView 返回模型中的 frame 這樣的話同樣的一條 cell 就算來回反復(fù)滑動 TableView，計算 frame 這個操作也就僅僅只會執(zhí)行一次，所以也就做到了減負(fù)的功能，如下圖：一個 cell 的組成需要 modal 找到數(shù)據(jù)，也需要 layout 找到這個 cell 如何布局：

② 預(yù)解碼 & 預(yù)渲染

• 圖片的渲染流程，在 CPU 階段拿到圖片的頂點數(shù)據(jù)和紋理之后會進(jìn)行解碼生產(chǎn)位圖，然后傳遞到 GPU 進(jìn)行渲染，主要流程圖如下：

• 如果圖片很多很大的情況下解碼工作就會占用主線程 RunLoop 導(dǎo)致其他工作無法執(zhí)行比如滑動，這樣就會造成卡頓現(xiàn)象，所以這里就可以將解碼的工作放到異步線程中不占用主線程，可能有人會想只要將圖片加載放到異步線程中在異步線程中生成一個 UIImage 或者是 CGImage，然后再主線程中設(shè)置給 UIImageView，此時可以寫段代碼使用 instruments 的 Time Profiler，查看一下堆棧信息：

• 發(fā)現(xiàn)圖片的編解碼還是在主線程，針對這種問題常見的做法是在子線程中先將圖片繪制到 CGBitmapContext，然后從 Bitmap 直接創(chuàng)建圖片，例如 SDWebImage 三方框架中對圖片編解碼的處理，這就是 Image 的預(yù)解碼，代碼如下：

dispatch_async(queue, ^{CGImageRef cgImage = [UIImage imageWithData:[NSData dataWithContentsOfURL:[NSURL URLWithString:self]]].CGImage;CGImageAlphaInfo alphaInfo = CGImageGetAlphaInfo(cgImage) & kCGBitmapAlphaInfoMask;BOOL hasAlpha = NO;if (alphaInfo == kCGImageAlphaPremultipliedLast ||alphaInfo == kCGImageAlphaPremultipliedFirst ||alphaInfo == kCGImageAlphaLast ||alphaInfo == kCGImageAlphaFirst) {hasAlpha = YES;}CGBitmapInfo bitmapInfo = kCGBitmapByteOrder32Host;bitmapInfo |= hasAlpha ? kCGImageAlphaPremultipliedFirst : kCGImageAlphaNoneSkipFirst;size_t width = CGImageGetWidth(cgImage);size_t height = CGImageGetHeight(cgImage);CGContextRef context = CGBitmapContextCreate(NULL, width, height, 8, 0, CGColorSpaceCreateDeviceRGB(), bitmapInfo);CGContextDrawImage(context, CGRectMake(0, 0, width, height), cgImage);cgImage = CGBitmapContextCreateImage(context);UIImage * image = [[UIImage imageWithCGImage:cgImage] cornerRadius:width * 0.5];CGContextRelease(context);CGImageRelease(cgImage);completion(image);});

③ 按需加載

• 顧名思義需要顯示的加載出來，不需要顯示的加載，例如 TableView 中的圖片滑動的時候不加載，在滑動停止的時候加載（可以使用 Runloop，圖片繪制設(shè)置 defaultModal 就行）。

④ 異步渲染

• UIView 和 CALayer 的關(guān)系：
• • UIView 是基于 UIKit 框架的，能夠接受點擊事件，處理用戶的觸摸事件，并管理子視圖；
• • CALayer 是基于 CoreAnimation，而 CoreAnimation 是基于 QuartzCode 的，所以 CALayer 只負(fù)責(zé)顯示，不能處理用戶的觸摸事件；
• • UIView 是直接繼承 UIResponder 的，CALayer 是繼承 NSObject 的；
• • UIView 的主要職責(zé)是負(fù)責(zé)接收并響應(yīng)事件；而 CALayer 的主要職責(zé)是負(fù)責(zé)顯示 UI，UIView 依賴于 CALayer 得以顯示。
• UIView 主要負(fù)責(zé)時間處理，CALayer 主要是視圖顯示，異步渲染的原理其實也就是在子線程將所有的視圖繪制成一張位圖，然后回到主線程賦值給 layer 的 contents。例如 Graver 框架的異步渲染流程如下：

• 核心源碼如下：

if (drawingFinished && targetDrawingCount == layer.drawingCount){CGImageRef CGImage = context ? CGBitmapContextCreateImage(context) : NULL;{// 讓 UIImage 進(jìn)行內(nèi)存管理// 最終生成的位圖 UIImage *image = CGImage ? [UIImage imageWithCGImage:CGImage] : nil;void (^finishBlock)(void) = ^{// 由于block可能在下一runloop執(zhí)行，再進(jìn)行一次檢查if (targetDrawingCount != layer.drawingCount){failedBlock();return;}//主線程中賦值完成顯示layer.contents = (id)image.CGImage;// ...}if (drawInBackground) dispatch_async(dispatch_get_main_queue(), finishBlock);else finishBlock();}// 一些清理工作: release CGImageRef, Image context ending}

• 當(dāng)視圖層次調(diào)整時，UIView、CALayer 之間會出現(xiàn)很多方法調(diào)用與通知，所以在優(yōu)化性能時，應(yīng)該盡量避免調(diào)整視圖層次、添加和移除視圖。

⑤ 對象創(chuàng)建

• 對象的創(chuàng)建會分配內(nèi)存、調(diào)整屬性、甚至還有讀取文件等操作，比較消耗 CPU 資源。盡量用輕量的對象代替重量的對象，可以對性能有所優(yōu)化。比如 CALayer 比 UIView 要輕量許多，那么不需要響應(yīng)觸摸事件的控件，用 CALayer 顯示會更加合適。如果對象不涉及 UI 操作，則盡量放到后臺線程去創(chuàng)建，但可惜的是包含有 CALayer 的控件，都只能在主線程創(chuàng)建和操作。通過 Storyboard 創(chuàng)建視圖對象時，其資源消耗會比直接通過代碼創(chuàng)建對象要大非常多，在性能敏感的界面里，Storyboard 并不是一個好的技術(shù)選擇。
• 盡量推遲對象創(chuàng)建的時間，并把對象的創(chuàng)建分散到多個任務(wù)中去，懶加載是個不錯的選擇。盡管這實現(xiàn)起來比較麻煩，并且?guī)淼膬?yōu)勢并不多，但如果有能力做，還是要盡量嘗試一下。如果對象可以復(fù)用，并且復(fù)用的代價比釋放、創(chuàng)建新對象要小，那么這類對象應(yīng)當(dāng)盡量放到一個緩存池里復(fù)用。

⑥ 對象銷毀

• 對象的銷毀雖然消耗資源不多，但累積起來也是不容忽視的。通常當(dāng)容器類持有大量對象時，其銷毀時的資源消耗就非常明顯。同樣的，如果對象可以放到后臺線程去釋放，那就挪到后臺線程去。例如：把對象捕獲到 block 中，然后扔到后臺隊列去隨便發(fā)送個消息以避免編譯器警告，就可以讓對象在后臺線程銷毀了。

NSArray *tmp = self.array;self.array = nil;dispatch_async(queue, ^{[tmp class];});

⑦ 文本計算

• 如果一個界面中包含大量文本（比如微博微信朋友圈等），文本的寬高計算會占用很大一部分資源，并且不可避免。
• 如果對文本顯示沒有特殊要求，可以參考下 UILabel 內(nèi)部的實現(xiàn)方式：用 [NSAttributedString boundingRectWithSize:options:context:] 來計算文本寬高，用 -[NSAttributedString drawWithRect:options:context:] 來繪制文本。盡管這兩個方法性能不錯，但仍舊需要放到后臺線程進(jìn)行以避免阻塞主線程。

⑧ 文本渲染

• 屏幕上能看到的所有文本內(nèi)容控件，包括 UIWebView，在底層都是通過 CoreText 排版、繪制為 Bitmap 顯示的。
• 常見的文本控件 （UILabel、UITextView 等），其排版和繪制都是在主線程進(jìn)行的，當(dāng)顯示大量文本時，CPU 的壓力會非常大。對此解決方案只有一個，那就是自定義文本控件，用 TextKit 或最底層的 CoreText 對文本異步繪制。盡管這實現(xiàn)起來非常麻煩，但其帶來的優(yōu)勢也非常大，CoreText 對象創(chuàng)建好后，能直接獲取文本的寬高等信息，避免了多次計算（調(diào)整 UILabel 大小時算一遍、UILabel 繪制時內(nèi)部再算一遍）；CoreText 對象占用內(nèi)存較少，可以緩存下來以備稍后多次渲染。

⑨ 圖片的解碼

• 用 UIImage 或 CGImageSource 的那幾個方法創(chuàng)建圖片時，圖片數(shù)據(jù)并不會立刻解碼。圖片設(shè)置到 UIImageView 或者 CALayer.contents 中去，并且 CALayer 被提交到 GPU 前，CGImage 中的數(shù)據(jù)才會得到解碼。這一步是發(fā)生在主線程的，并且不可避免。
• 如果想要繞開這個機制，常見的做法是在后臺線程先把圖片繪制到 CGBitmapContext 中，然后從 Bitmap 直接創(chuàng)建圖片。目前常見的網(wǎng)絡(luò)圖片庫都自帶這個功能。

⑩ 圖像的繪制

• 圖像的繪制通常是指用那些以 CG 開頭的方法把圖像繪制到畫布中，然后從畫布創(chuàng)建圖片并顯示這樣一個過程，這個最常見的地方就是[UIView drawRect:]里面了。
• 由于 CoreGraphic 方法通常都是線程安全的，所以圖像的繪制就可以很容易的放到后臺線程進(jìn)行。一個簡單的異步繪制的過程大致如下（實際情況會比這個復(fù)雜得多，但原理基本一致）：

- (void)display {dispatch_async(backgroundQueue, ^{CGContextRef ctx = CGBitmapContextCreate(...);// draw in context...CGImageRef img = CGBitmapContextCreateImage(ctx);CFRelease(ctx);dispatch_async(mainQueue, ^{layer.contents = img;});});}

四、GPU 資源消耗優(yōu)化

① 紋理渲染

• 所有的 Bitmap，包括圖片、文本、柵格化的內(nèi)容，最終都要由內(nèi)存提交到顯存，綁定為 GPU Texture。不論是提交到顯存的過程，還是GPU調(diào)整和渲染Texture的過程，都要消耗不少GPU資源。當(dāng)在較短時間顯示大量圖片時（比如 TableView 存在非常多的圖片并且快速滑動時），CPU占用率很低，GPU占用非常高，界面仍然會掉幀。避免這種情況的方法只能是盡量減少在短時間內(nèi)大量圖片的顯示，盡可能將多張圖片合成為一張進(jìn)行顯示。
• 當(dāng)圖片過大，超過 GPU 的最大紋理尺寸時，圖片需要先由 CPU 進(jìn)行預(yù)處理，這對 CPU 和 GPU 都會帶來額外的資源消耗。目前來說，iPhone 4S 以上機型，紋理尺寸上限都是 4096×4096，所以盡量不要讓圖片和視圖的大小超過這個值。

② 視圖混合（Composing）

• 當(dāng)多個視圖（或者說 CALayer）重疊在一起顯示時，GPU 會首先把他們混合到一起。如果視圖結(jié)構(gòu)過于復(fù)雜，混合的過程也會消耗很多 GPU 資源。
• 為了減輕這種情況的 GPU 消耗，應(yīng)用應(yīng)當(dāng)盡量減少視圖數(shù)量和層次，并在不透明的視圖里標(biāo)明 opaque 屬性以避免無用的 Alpha 通道合成。當(dāng)然，這也可以用上面的方法，把多個視圖預(yù)先渲染為一張圖片來顯示。

③ 圖形生成

• CALayer 的 border、圓角、陰影、遮罩（mask），CASharpLayer 的矢量圖形顯示，通常會觸發(fā)離屏渲染（offscreen rendering），而離屏渲染通常發(fā)生在 GPU 中。
• 當(dāng)一個列表視圖中出現(xiàn)大量圓角的 CALayer，并且快速滑動時，可以觀察到 GPU 資源已經(jīng)占滿，而 CPU 資源消耗很少。這時界面仍然能正常滑動，但平均幀數(shù)會降到很低。
• 為了避免這種情況，可以嘗試開啟CALayer.shouldRasterize（指示在合成之前圖層是否呈現(xiàn)為位圖） 屬性，但這會把原本離屏渲染的操作轉(zhuǎn)嫁到CPU上去。對于只需要圓角的某些場合，也可以用一張已經(jīng)繪制好的圓角圖片覆蓋到原本視圖上面來模擬相同的視覺效果。
• 最徹底的解決辦法，就是把需要顯示的圖形在后臺線程繪制為圖片，避免使用圓角、陰影、遮罩等屬性。

④ 預(yù)渲染

• 對于 TableView 來說，Cell 內(nèi)容的離屏渲染會帶來較大的 GPU 消耗，為了圖省事兒用到了不少 layer 的圓角屬性，在低性能的設(shè)備（比如 iPad 3）上快速滑動一下這個列表，能感受到雖然列表并沒有較大的卡頓，但是整體的平均幀數(shù)降了下來。用 Instument 查看時能夠看到 GPU 已經(jīng)滿負(fù)荷運轉(zhuǎn)，而 CPU 卻比較清閑。
• 為了避免離屏渲染，應(yīng)當(dāng)盡量避免使用 layer 的 border、corner、shadow、mask 等技術(shù)，而盡量在后臺線程預(yù)先繪制好對應(yīng)內(nèi)容。

• 二進(jìn)制流 decode 屬于 UI 的 prepare，依賴于圖形編解碼插件。SDWebImage 關(guān)于解碼的處理：

// decode the image in coder queuedispatch_async(self.coderQueue, ^{@autoreleasepool {UIImage *image = SDImageLoaderDecodeImageData(imageData, self.request.URL, [[self class] imageOptionsFromDownloaderOptions:self.options], self.context);CGSize imageSize = image.size;if (imageSize.width == 0 || imageSize.height == 0) {[self callCompletionBlocksWithError:[NSError errorWithDomain:SDWebImageErrorDomain code:SDWebImageErrorBadImageData userInfo:@{NSLocalizedDescriptionKey : @"Downloaded image has 0 pixels"}]];} else {[self callCompletionBlocksWithImage:image imageData:imageData error:nil finished:YES];}[self done];}});

⑤ 預(yù)排版

• 當(dāng)獲取到 API JSON 數(shù)據(jù)后，把每條 Cell 需要的數(shù)據(jù)都在后臺線程計算并封裝為一個布局對象 CellLayout。CellLayout 包含所有文本的CoreText排版結(jié)果、Cell 內(nèi)部每個控件的高度、Cell 的整體高度。每個 CellLayout 的內(nèi)存占用并不多，所以當(dāng)生成后，可以全部緩存到內(nèi)存，以供稍后使用。這樣，TableView 在請求各個高度函數(shù)時，不會消耗任何多余計算量；當(dāng)把 CellLayout 設(shè)置到 Cell 內(nèi)部時，Cell 內(nèi)部也不用再計算布局了。
• 對于通常的 TableView 來說，提前在后臺計算好布局結(jié)果是非常重要的一個性能優(yōu)化點。為了達(dá)到最高性能，你可能需要犧牲一些開發(fā)速度，盡量不要用 Autolayout 等技術(shù)，少用 UILabel 等文本控件。但如果你對性能的要求并不那么高，可以嘗試用 TableView 的預(yù)估高度的功能，并把每個 Cell 高度緩存下來。這里有個來自百度知道團(tuán)隊的開源項目可以很方便的實現(xiàn)這一點：FDTemplateLayoutCell。

⑥ 異步繪制

• 當(dāng) TableView 快速滑動時，會有大量異步繪制任務(wù)提交到后臺線程去執(zhí)行。但是有時滑動速度過快時，繪制任務(wù)還沒有完成就可能已經(jīng)被取消了。如果這時仍然繼續(xù)繪制，就會造成大量的 CPU 資源浪費，甚至阻塞線程并造成后續(xù)的繪制任務(wù)遲遲無法完成。
• 如果這時仍然繼續(xù)繪制，就會造成大量的 CPU 資源浪費，甚至阻塞線程并造成后續(xù)的繪制任務(wù)遲遲無法完成。我的做法是盡量快速、提前判斷當(dāng)前繪制任務(wù)是否已經(jīng)被取消；在繪制每一行文本前，都會調(diào)用 isCancelled() 來進(jìn)行判斷，保證被取消的任務(wù)能及時退出，不至于影響后續(xù)操作。

總結(jié)

以上是生活随笔為你收集整理的iOS之性能优化·优化App界面的渲染与流畅度的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。