最近一段時(shí)間經(jīng)常遇到關(guān)于iOS性能優(yōu)化、卡頓優(yōu)化的問題，今天在這里總結(jié)一下。
一般困擾我們的性能優(yōu)化的問題一般是
你在項(xiàng)目中是怎么優(yōu)化內(nèi)存的？
優(yōu)化你是從哪幾方面著手？
列表卡頓的原因可能有哪些？你平時(shí)是怎么優(yōu)化的？
遇到tableView卡頓嘛？會(huì)造成卡頓的原因大致有哪些？

具體分析：
1：CPU和GPU

2：卡頓優(yōu)化 - CPU

3：卡頓優(yōu)化 - GPU

3.1：離屏渲染

4：耗電的主要來源

4.1：耗電優(yōu)化

5：APP的啟動(dòng)

5.1：APP的啟動(dòng) - dyld

5.2：APP的啟動(dòng) - runtime

5.3：APP的啟動(dòng) - main

5.4：APP的啟動(dòng)優(yōu)化

6：安裝包瘦身

6.1：LinkMap

1：CPU和GPU
在屏幕成像的過程中，CPU和GPU起著至關(guān)重要的作用

CPU（Central Processing Unit，中央處理器）
對(duì)象的創(chuàng)建和銷毀、對(duì)象屬性的調(diào)整、布局計(jì)算、文本的計(jì)算和排版、圖片的格式轉(zhuǎn)換和解碼、圖像的繪制（Core Graphics）

GPU（Graphics Processing Unit，圖形處理器）
紋理的渲染

在iOS中是雙緩沖機(jī)制，有前幀緩存、后幀緩存
一幀畫面 一頁(yè)畫面 會(huì)發(fā)出垂直同步信號(hào)
屏幕成像原理

如果要顯示一幀畫面的話：首先會(huì)發(fā)出垂直同步信號(hào)，就表示 即將顯示一頁(yè)的數(shù)據(jù)、一幀的數(shù)據(jù)。首先會(huì)發(fā)出水平同步信號(hào)，就是一行一行的數(shù)據(jù)搞定，也就是一屏幕的一行的數(shù)據(jù)都顯示完了，也就是剛開始發(fā)出垂直同步信號(hào)，就意味著要顯示新的一幀數(shù)據(jù)，當(dāng)最后一行水平同步信號(hào)發(fā)完，就會(huì)又發(fā)出一個(gè)新的垂直同步信號(hào)，顯示下一幀數(shù)據(jù)，如果每一幀都連起來，就像動(dòng)畫一樣了。

有時(shí)候我們?cè)谕献crowview和tableview的時(shí)候，也會(huì)產(chǎn)生卡頓。

卡頓產(chǎn)生的原因
1：一開始由cpu先往右邊走，隨著時(shí)間推移，cpu做好之后交給gpu進(jìn)行渲染，接著來了一個(gè)垂直同步信號(hào)，就會(huì)將剛才cpu計(jì)算好，gpu渲染好的數(shù)據(jù)顯示到屏幕上，完成剛才這一幀的顯示，（一旦來了一個(gè)垂直同步信號(hào)，會(huì)立馬將gpu渲染的數(shù)據(jù)顯示到屏幕上，并且馬上開始下一幀的操作），

2：下一幀又要開始cpu的計(jì)算，和gpu的渲染，這次操作可能比上次快，時(shí)間也可能不一定，對(duì)應(yīng)上面第二塊，還留有一段時(shí)間來等待垂直同步信號(hào)的到來之后，就會(huì)將剛才的數(shù)據(jù)顯示出來，

3：接著走第三段，可能這端時(shí)間花費(fèi)太長(zhǎng)，gpu花費(fèi)時(shí)間比較長(zhǎng)，發(fā)現(xiàn)渲染到中間的時(shí)候，垂直同步信號(hào)來了，但是渲染還沒有結(jié)束，這個(gè)時(shí)候只能將上一次的數(shù)據(jù)也就是第二段，顯示出來，也就是當(dāng)前正在計(jì)算的這一幀數(shù)據(jù)丟失了，也就是掉幀，就會(huì)產(chǎn)生卡頓。

4：等到下一次同步信號(hào)，也就是第四端的時(shí)候，會(huì)將上一段也就是第三段的數(shù)據(jù)顯示出來。這一幀就來的比較晚，導(dǎo)致中間掉幀，卡頓了。

掉幀原因：會(huì)卡 ：是因?yàn)閏pu和Gpu花的時(shí)間太長(zhǎng)了，垂直同步信號(hào)來的時(shí)候還沒有結(jié)束，就掉幀。

卡頓解決的主要思路：盡可能減少CPU、GPU資源消耗

（1秒鐘刷新60幀）按照60FPS的刷幀率，每隔16ms就會(huì)有一次VSync信號(hào) 1秒是1000毫秒

2：卡頓優(yōu)化 - CPU
a：盡量用輕量級(jí)的對(duì)象，比如用不到事件處理的地方，可以考慮使用CALayer取代UIView對(duì)象的創(chuàng)建和銷毀都是cpu來處理的，CALayer是UIView里面的一個(gè)成員，CALayer：專門用來顯示內(nèi)容的。UIView：監(jiān)聽點(diǎn)擊事件的，一個(gè)UIView之所以能顯示東西，是因?yàn)槔锩嬗幸粋€(gè)CALayer。

b：不要頻繁地調(diào)用UIView的相關(guān)屬性，比如frame、bounds、transform等屬性，盡量減少不必要的修改每次調(diào)整，都是重新計(jì)算啊、渲染啊，耗性能更多。

c：盡量提前計(jì)算好布局，在有需要時(shí)一次性調(diào)整對(duì)應(yīng)的屬性，不要多次修改屬性

d：Autolayout會(huì)比直接設(shè)置frame消耗更多的CPU資源

e：圖片的size最好剛好跟UIImageView的size保持一致

f：控制一下線程的最大并發(fā)數(shù)量

g：盡量把耗時(shí)的操作放到子線程 文本處理（尺寸計(jì)算、繪制）圖片處理（解碼、繪制）

 imageView.image = [UIImage imageNamed:@"timg"]; 

這個(gè)圖片通過imageNamed去加載，加載完畢后，不能直接顯示到屏幕上的，加載進(jìn)來是經(jīng)過壓縮的圖片的二進(jìn)制數(shù)據(jù)，如果想渲染到屏幕上，還需要一個(gè)解碼，解碼成屏幕所需要的格式，當(dāng)這個(gè)圖片真正需要顯示在屏幕上的時(shí)候，才會(huì)解碼，這個(gè)解碼會(huì)在主線程進(jìn)行操作。如果圖片比較多，比較大的話，也會(huì)產(chǎn)生卡頓。一般來說那就需要提前對(duì)圖片進(jìn)行解碼。

來看代碼

- (void)image
{
    UIImageView *imageView = [[UIImageView alloc] init];
    imageView.frame = CGRectMake(100, 100, 100, 56);
    [self.view addSubview:imageView];
    self.imageView = imageView;
 
    // 子線程做的
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        // 獲取CGImage
//        [UIImage imageWithData:[NSData dataWithContentsOfURL:@""]]; 通過網(wǎng)絡(luò)下載
        CGImageRef cgImage = [UIImage imageNamed:@"timg"].CGImage;
 
        // alphaInfo
        CGImageAlphaInfo alphaInfo = CGImageGetAlphaInfo(cgImage) & kCGBitmapAlphaInfoMask;
        BOOL hasAlpha = NO;
        if (alphaInfo == kCGImageAlphaPremultipliedLast ||
            alphaInfo == kCGImageAlphaPremultipliedFirst ||
            alphaInfo == kCGImageAlphaLast ||
            alphaInfo == kCGImageAlphaFirst) {
            hasAlpha = YES;
        }
 
        // bitmapInfo
        CGBitmapInfo bitmapInfo = kCGBitmapByteOrder32Host;
        bitmapInfo |= hasAlpha ? kCGImageAlphaPremultipliedFirst : kCGImageAlphaNoneSkipFirst;
 
        // size
        size_t width = CGImageGetWidth(cgImage);
        size_t height = CGImageGetHeight(cgImage);
 
        // context：創(chuàng)建圖形上下文
        CGContextRef context = CGBitmapContextCreate(NULL, width, height, 8, 0, CGColorSpaceCreateDeviceRGB(), bitmapInfo);
 
        // draw：將圖片畫到圖形上下文中
        CGContextDrawImage(context, CGRectMake(0, 0, width, height), cgImage);
 
        // get CGImage  ：得到畫出來的圖片
        cgImage = CGBitmapContextCreateImage(context);
 
        // into UIImage
        UIImage *newImage = [UIImage imageWithCGImage:cgImage];
 
        // release
        CGContextRelease(context);
        CGImageRelease(cgImage);
 
        // back to the main thread
        dispatch_async(dispatch_get_main_queue(), ^{
            self.imageView.image = newImage;
        });
    });
}

3：卡頓優(yōu)化 - GPU
a：盡量避免短時(shí)間內(nèi)大量圖片的顯示，盡可能將多張圖片合成一張進(jìn)行顯示
b：GPU能處理的最大紋理尺寸是4096x4096，一旦超過這個(gè)尺寸，就會(huì)占用CPU資源進(jìn)行處理，所以紋理盡量不要超過這個(gè)尺寸
c：盡量減少視圖數(shù)量和層次
d：減少透明的視圖（alpha<1），不透明的就設(shè)置opaque為YES
如果有透明的，就需要計(jì)算，（透明的混合的就需要計(jì)算）
e：盡量避免出現(xiàn)離屏渲染

3.1：離屏渲染
在OpenGL中，GPU有2種渲染方式
On-Screen Rendering：當(dāng)前屏幕渲染，在當(dāng)前用于顯示的屏幕緩沖區(qū)進(jìn)行渲染操作

Off-Screen Rendering：離屏渲染，在當(dāng)前屏幕緩沖區(qū)以外新開辟一個(gè)緩沖區(qū)進(jìn)行渲染操作

離屏渲染消耗性能的原因
需要?jiǎng)?chuàng)建新的緩沖區(qū)

離屏渲染的整個(gè)過程，需要多次切換上下文環(huán)境(重點(diǎn))，先是從當(dāng)前屏幕（On-Screen）切換到離屏（Off-Screen）；等到離屏渲染結(jié)束以后，將離屏緩沖區(qū)的渲染結(jié)果顯示到屏幕上，又需要將上下文環(huán)境從離屏切換到當(dāng)前屏幕

哪些操作會(huì)觸發(fā)離屏渲染？
光柵化，layer.shouldRasterize = YES
遮罩，layer.mask
圓角，同時(shí)設(shè)置layer.masksToBounds = YES、layer.cornerRadius大于0。考慮通過CoreGraphics繪制裁剪圓角，或者叫美工提供圓角圖片

陰影，layer.shadowXXX。如果設(shè)置了layer.shadowPath就不會(huì)產(chǎn)生離屏渲染

3.2：卡頓檢測(cè)
平時(shí)所說的“卡頓”主要是因?yàn)樵谥骶€程執(zhí)行了比較耗時(shí)的操作

可以添加Observer到主線程RunLoop中，通過監(jiān)聽RunLoop狀態(tài)切換的耗時(shí)，以達(dá)到監(jiān)控卡頓的目的

可以搜索LXDAppFluecyMonitor。

4：耗電的主要來源
CPU處理，Processing

網(wǎng)絡(luò)，Networking

定位，Location

圖像，Graphics

4.1：耗電優(yōu)化

盡可能降低CPU、GPU功耗
少用定時(shí)器
優(yōu)化I/O操作
盡量不要頻繁寫入小數(shù)據(jù)，最好批量一次性寫入

讀寫大量重要數(shù)據(jù)時(shí)，考慮用dispatch_io，其提供了基于GCD的異步操作文件I/O的API。用dispatch_io系統(tǒng)會(huì)優(yōu)化磁盤訪問

數(shù)據(jù)量比較大的，建議使用數(shù)據(jù)庫(kù)（比如SQLite、CoreData）

網(wǎng)絡(luò)優(yōu)化
減少、壓縮網(wǎng)絡(luò)數(shù)據(jù) （原來用xml 體積比較大; json體積比較小; 也有用：protocol buffer：服務(wù)器也是這個(gè)）

如果多次請(qǐng)求的結(jié)果是相同的，盡量使用緩存

使用斷點(diǎn)續(xù)傳，否則網(wǎng)絡(luò)不穩(wěn)定時(shí)可能多次傳輸相同的內(nèi)容

網(wǎng)絡(luò)不可用時(shí)，不要嘗試執(zhí)行網(wǎng)絡(luò)請(qǐng)求

讓用戶可以取消長(zhǎng)時(shí)間運(yùn)行或者速度很慢的網(wǎng)絡(luò)操作，設(shè)置合適的超時(shí)時(shí)間

批量傳輸，比如，下載視頻流時(shí)，不要傳輸很小的數(shù)據(jù)包，直接下載整個(gè)文件或者一大塊一大塊地下載。如果下載廣告，一次性多下載一些，然后再慢慢展示。如果下載電子郵件，一次下載多封，不要一封一封地下載

定位優(yōu)化
如果只是需要快速確定用戶位置，最好用CLLocationManager的requestLocation方法。定位完成后，會(huì)自動(dòng)讓定位硬件斷電

如果不是導(dǎo)航應(yīng)用，盡量不要實(shí)時(shí)更新位置，定位完畢就關(guān)掉定位服務(wù)
盡量降低定位精度，比如盡量不要使用精度最高的kCLLocationAccuracyBest

需要后臺(tái)定位時(shí)，盡量設(shè)置pausesLocationUpdatesAutomatically為YES，如果用戶不太可能移動(dòng)的時(shí)候系統(tǒng)會(huì)自動(dòng)暫停位置更新

盡量不要使用startMonitoringSignificantLocationChanges，優(yōu)先考慮startMonitoringForRegion:

硬件檢測(cè)優(yōu)化
用戶移動(dòng)、搖晃、傾斜設(shè)備時(shí)，會(huì)產(chǎn)生動(dòng)作(motion)事件，這些事件由加速度計(jì)、陀螺儀、磁力計(jì)等硬件檢測(cè)。在不需要檢測(cè)的場(chǎng)合，應(yīng)該及時(shí)關(guān)閉這些硬件

5：APP的啟動(dòng)
APP的啟動(dòng)可以分為2種
冷啟動(dòng)（Cold Launch）：從零開始啟動(dòng)APP

熱啟動(dòng)（Warm Launch）：APP已經(jīng)在內(nèi)存中，在后臺(tái)存活著，再次點(diǎn)擊圖標(biāo)啟動(dòng)APP（減少了冷啟動(dòng)過程）

APP啟動(dòng)時(shí)間的優(yōu)化，主要是針對(duì)冷啟動(dòng)進(jìn)行優(yōu)化
通過添加環(huán)境變量可以打印出APP的啟動(dòng)時(shí)間分析（Edit scheme -> Run -> Arguments）
DYLD_PRINT_STATISTICS設(shè)置為1

如果需要更詳細(xì)的信息，那就將DYLD_PRINT_STATISTICS_DETAILS設(shè)置為1

一般在400毫秒之內(nèi)都是比較正常的。

APP的冷啟動(dòng)可以概括為3大階段
dyld
runtime
main
5.1：APP的啟動(dòng) - dyld
在點(diǎn)擊icon的時(shí)候，一開始dyld裝載我們的可執(zhí)行文件。

dyld（dynamic link editor），Apple的動(dòng)態(tài)鏈接器，可以用來裝載Mach-O文件（可執(zhí)行文件、動(dòng)態(tài)庫(kù)等）
啟動(dòng)APP時(shí)，dyld所做的事情有
裝載APP的可執(zhí)行文件，同時(shí)會(huì)遞歸加載所有依賴的動(dòng)態(tài)庫(kù)（有一個(gè)exec的文件，這個(gè)里面包含了我們項(xiàng)目的所有代碼，真正的動(dòng)態(tài)庫(kù)文件不在這里面，而只是有依賴信息。）

當(dāng)dyld把可執(zhí)行文件、動(dòng)態(tài)庫(kù)都裝載完畢后，會(huì)通知Runtime進(jìn)行下一步的處理

5.2：APP的啟動(dòng) - runtime
啟動(dòng)APP時(shí)，runtime所做的事情有
調(diào)用map_images進(jìn)行可執(zhí)行文件內(nèi)容的解析和處理
在load_images中調(diào)用call_load_methods，調(diào)用所有Class和Category的+load方法

進(jìn)行各種objc結(jié)構(gòu)的初始化（注冊(cè)O(shè)bjc類 、初始化類對(duì)象等等）

調(diào)用C++靜態(tài)初始化器和attribute((constructor))修飾的函數(shù)

到此為止，可執(zhí)行文件和動(dòng)態(tài)庫(kù)中所有的符號(hào)(Class，Protocol，Selector，IMP，…)都已經(jīng)按格式成功加載到內(nèi)存中，被runtime 所管理
5.3：APP的啟動(dòng) - main
總結(jié)一下

APP的啟動(dòng)由dyld主導(dǎo)，將可執(zhí)行文件加載到內(nèi)存，順便加載所有依賴的動(dòng)態(tài)庫(kù)

并由runtime負(fù)責(zé)加載成objc定義的結(jié)構(gòu)

所有初始化工作結(jié)束后，dyld就會(huì)調(diào)用main函數(shù)

接下來就是UIApplicationMain函數(shù)，AppDelegate的application:didFinishLaunchingWithOptions:方法

5.4：APP的啟動(dòng)優(yōu)化
按照不同的階段

dyld
減少動(dòng)態(tài)庫(kù)、合并一些動(dòng)態(tài)庫(kù)（定期清理不必要的動(dòng)態(tài)庫(kù)）

減少Objc類、分類的數(shù)量、減少Selector數(shù)量（定期清理不必要的類、分類）

減少C++虛函數(shù)數(shù)量

Swift盡量使用struct

runtime
用+initialize方法和dispatch_once取代所有的attribute((constructor))、C++靜態(tài)構(gòu)造器、ObjC的+load

main
在不影響用戶體驗(yàn)的前提下，盡可能將一些操作延遲，不要全部都放在finishLaunching方法中
按需加載：需要用到什么就加載什么

6：安裝包瘦身
我們開發(fā)的項(xiàng)目，編譯-》打包-》上傳appstore，打包，最終生成的是ipa文件，里面有一個(gè).app的包，整個(gè)項(xiàng)目的所有的代碼和資源都在這個(gè).app包中。將來會(huì)把這個(gè)包壓縮成一個(gè)ipa文件，傳到appstore，提供給用戶下載。項(xiàng)目變大，下載變大，上傳變慢。so：瘦身

安裝包（IPA）主要由可執(zhí)行文件（源代碼文件最終編譯變成的文件）、資源組成（加的視頻、圖片、音頻、sb等）
資源（圖片、音頻、視頻等）
采取無損壓縮

去除沒有用到的資源： https://github.com/tinymind/LSUnusedResources

可執(zhí)行文件瘦身：對(duì)源代碼
編譯器優(yōu)化：

Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default設(shè)置為YES

去掉異常支持，Enable C++ Exceptions、Enable Objective-C Exceptions設(shè)置為NO， Other C Flags添加-fno-exceptions

利用AppCode（https://www.jetbrains.com/objc/）檢測(cè)未使用的代碼：菜單欄 -> Code -> Inspect Code
編寫LLVM插件檢測(cè)出重復(fù)代碼、未被調(diào)用的代碼

6.1：LinkMap
生成LinkMap文件，可以查看可執(zhí)行文件的具體組成

可借助第三方工具解析LinkMap文件： （https://github.com/huanxsd/LinkMap）