1卧蜓、CPU和GPU
在屏幕成像的過程中烦秩，CPU和GPU起著至關(guān)重要的作用
- CPU（Central Processing Unit，中央處理器）
對象的創(chuàng)建和銷毀、對象屬性的調(diào)整伐厌、布局計算、文本的計算和排版裸影、圖片的格式轉(zhuǎn)換和解碼挣轨、圖像的繪制（Core Graphics） -
GPU（Graphics Processing Unit，圖形處理器）
紋理的渲染
在iOS中是雙緩沖機制轩猩，有前幀緩存卷扮、后幀緩存
CPU和GPU渲染過程圖
2、屏幕成像原理
3均践、卡頓產(chǎn)生的原因
如上圖所示画饥，CPU計算耗時為紅色部分，GPU為藍色部分浊猾，當cpu計算結(jié)束時由GPU來渲染抖甘，如第一個所示，渲染結(jié)束時葫慎，垂直同步信號到來衔彻，渲染一幀畫面到屏幕上，第二個區(qū)間偷办，耗時比較短艰额，在等待VSync信號到來在渲染，第三個區(qū)間椒涯，GPU耗時比較長柄沮，等到VSync信號到達時尚未渲染結(jié)束，此時還是展示的上一幀畫面废岂，一直等到下一次vsync信號到達時在渲染祖搓，這就造成了卡頓。
卡頓解決的主要思路:
- 盡可能減少CPU湖苞、GPU資源消耗
- 按照60FPS的刷幀率拯欧，每隔16ms就會有一次VSync信號
4. CPU 優(yōu)化：
- 盡量用輕量級的對象，比如用不到事件處理的地方财骨，可以考慮使用CALayer取代UIView
- 不要頻繁地調(diào)用UIView的相關(guān)屬性镐作，比如frame、bounds隆箩、transform等屬性该贾，盡量減少不必要的修改
- 盡量提前計算好布局，在有需要時一次性調(diào)整對應的屬性捌臊，不要多次修改屬性
- Autolayout會比直接設置frame消耗更多的CPU資源
- 圖片的size最好剛好跟UIImageView的size保持一致
- 控制一下線程的最大并發(fā)數(shù)量
- 盡量把耗時的操作放到子線程
文本處理（尺寸計算杨蛋、繪制）
// 文字計算
[@"text" boundingRectWithSize:CGSizeMake(100, MAXFLOAT) options:NSStringDrawingUsesLineFragmentOrigin attributes:nil context:nil];
// 文字繪制
[@"text" drawWithRect:CGRectMake(0, 0, 100, 100) options:NSStringDrawingUsesLineFragmentOrigin attributes:nil context:nil];
圖片處理（解碼、繪制）
- (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
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
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;
});
});
}
5. GPU 優(yōu)化：
1 盡量避免短時間內(nèi)大量圖片的顯示，盡可能將多張圖片合成一張進行顯示
2 GPU能處理的最大紋理尺寸是4096x4096六荒，一旦超過這個尺寸护姆，就會占用CPU資源進行處理矾端，所以紋理盡量不要超過這個尺寸
3 盡量減少視圖數(shù)量和層次
4 減少透明的視圖（alpha<1）掏击，不透明的就設置opaque為YES
5 盡量避免出現(xiàn)離屏渲染
6. 離屏渲染
在OpenGL中，GPU有2種渲染方式
On-Screen Rendering：當前屏幕渲染秩铆，在當前用于顯示的屏幕緩沖區(qū)進行渲染操作
Off-Screen Rendering：離屏渲染砚亭，在當前屏幕緩沖區(qū)以外新開辟一個緩沖區(qū)進行渲染操作
離屏渲染消耗性能的原因
需要創(chuàng)建新的緩沖區(qū)
離屏渲染的整個過程，需要多次切換上下文環(huán)境殴玛，先是從當前屏幕（On-Screen）切換到離屏（Off-Screen）捅膘；等到離屏渲染結(jié)束以后，將離屏緩沖區(qū)的渲染結(jié)果顯示到屏幕上滚粟，又需要將上下文環(huán)境從離屏切換到當前屏幕
哪些操作會觸發(fā)離屏渲染寻仗？
光柵化，layer.shouldRasterize = YES
遮罩凡壤，layer.mask
圓角署尤，同時設置layer.masksToBounds = YES、layer.cornerRadius大于0
考慮通過CoreGraphics繪制裁剪圓角亚侠，或者叫美工提供圓角圖片
陰影曹体，layer.shadowXXX
如果設置了layer.shadowPath就不會產(chǎn)生離屏渲染
7. 卡頓檢測
平時所說的“卡頓”主要是因為在主線程執(zhí)行了比較耗時的操作
可以添加Observer到主線程RunLoop中，通過監(jiān)聽RunLoop狀態(tài)切換的耗時硝烂，以達到監(jiān)控卡頓的目的
8 耗電優(yōu)化
耗電來源
CPU處理箕别，Processing
網(wǎng)絡，Networking
定位滞谢，Location
圖像串稀，Graphics
優(yōu)化方法
- 盡可能降低CPU、GPU功耗
- 少用定時器
- 優(yōu)化I/O操作
盡量不要頻繁寫入小數(shù)據(jù)狮杨，最好批量一次性寫入
讀寫大量重要數(shù)據(jù)時厨诸，考慮用dispatch_io，其提供了基于GCD的異步操作文件I/O的API禾酱。用dispatch_io系統(tǒng)會優(yōu)化磁盤訪問
數(shù)據(jù)量比較大的微酬，建議使用數(shù)據(jù)庫（比如SQLite、CoreData）
- 網(wǎng)絡優(yōu)化
減少颤陶、壓縮網(wǎng)絡數(shù)據(jù)
如果多次請求的結(jié)果是相同的颗管，盡量使用緩存
使用斷點續(xù)傳，否則網(wǎng)絡不穩(wěn)定時可能多次傳輸相同的內(nèi)容
網(wǎng)絡不可用時滓走，不要嘗試執(zhí)行網(wǎng)絡請求
讓用戶可以取消長時間運行或者速度很慢的網(wǎng)絡操作垦江，設置合適的超時時間
批量傳輸，比如搅方，下載視頻流時比吭，不要傳輸很小的數(shù)據(jù)包绽族，直接下載整個文件或者一大塊一大塊地下載。如果下載廣告衩藤，一次性多下載一些吧慢，然后再慢慢展示。如果下載電子郵件赏表，一次下載多封检诗，不要一封一封地下載
定位優(yōu)化
如果只是需要快速確定用戶位置，最好用CLLocationManager的requestLocation方法瓢剿。定位完成后逢慌，會自動讓定位硬件斷電
如果不是導航應用，盡量不要實時更新位置间狂，定位完畢就關(guān)掉定位服務
盡量降低定位精度攻泼，比如盡量不要使用精度最高的kCLLocationAccuracyBest
需要后臺定位時鉴象，盡量設置pausesLocationUpdatesAutomatically為YES忙菠，如果用戶不太可能移動的時候系統(tǒng)會自動暫停位置更新
盡量不要使用startMonitoringSignificantLocationChanges，優(yōu)先考慮startMonitoringForRegion:硬件檢測優(yōu)化
用戶移動炼列、搖晃只搁、傾斜設備時，會產(chǎn)生動作(motion)事件俭尖，這些事件由加速度計氢惋、陀螺儀、磁力計等硬件檢測稽犁。在不需要檢測的場合焰望，應該及時關(guān)閉這些硬件
9 App的啟動優(yōu)化
APP的啟動可以分為2種
冷啟動（Cold Launch）：從零開始啟動APP
熱啟動（Warm Launch）：APP已經(jīng)在內(nèi)存中，在后臺存活著已亥，再次點擊圖標啟動APP
- APP啟動時間的優(yōu)化熊赖，主要是針對冷啟動進行優(yōu)化
- 通過添加環(huán)境變量可以打印出APP的啟動時間分析（Edit scheme -> Run -> Arguments）
DYLD_PRINT_STATISTICS設置為1
如果需要更詳細的信息，那就將DYLD_PRINT_STATISTICS_DETAILS設置為1
APP的冷啟動可以概括為3大階段
dyld
runtime
main
另一種分類法：
main函數(shù)執(zhí)行前（dyld和runtime階段）
main函數(shù)執(zhí)行后
首屏渲染完成后
- APP的啟動 - dyld
dyld（dynamic link editor）虑椎，Apple的動態(tài)鏈接器震鹉，可以用來裝載Mach-O文件（可執(zhí)行文件、動態(tài)庫等）
啟動APP時捆姜，dyld所做的事情有
裝載APP的可執(zhí)行文件（app的.o文件的集合）传趾；
加載所有依賴的動態(tài)庫，進行rebase指針調(diào)整和bind符號綁定泥技；
當dyld把可執(zhí)行文件浆兰、動態(tài)庫都裝載完畢后，會通知Runtime進行下一步的處理
- APP的啟動 - runtime
啟動APP時，runtime所做的事情有
1.Objc 運行時的初始處理簸呈，包括 Objc 相關(guān)類的注冊榕订、category 注冊、selector 唯一性檢查等蜕便；
2.初始化劫恒，包括了執(zhí)行 +load() 方法、attribute((constructor)) 修飾的函數(shù)的調(diào)用玩裙、創(chuàng)建 C++ 靜態(tài)全局變量兼贸。
到此為止段直，可執(zhí)行文件和動態(tài)庫中所有的符號(Class吃溅，Protocol，Selector鸯檬，IMP决侈，…)都已經(jīng)按格式成功加載到內(nèi)存中，被runtime 所管理
- APP的啟動 - main
總結(jié)一下
APP的啟動由dyld主導喧务，將可執(zhí)行文件加載到內(nèi)存赖歌，順便加載所有依賴的動態(tài)庫
并由runtime負責加載成objc定義的結(jié)構(gòu)
所有初始化工作結(jié)束后，dyld就會調(diào)用main函數(shù)
接下來就是UIApplicationMain函數(shù)功茴，AppDelegate的application:didFinishLaunchingWithOptions:方法
APP的啟動優(yōu)化
按照不同的階段
dyld
減少動態(tài)庫庐冯、合并一些動態(tài)庫（定期清理不必要的動態(tài)庫）
減少Objc類、分類的數(shù)量坎穿、減少Selector數(shù)量（定期清理不必要的類展父、分類）
減少C++虛函數(shù)數(shù)量，控制 C++ 全局變量的數(shù)量玲昧。
Swift盡量使用struct
runtime
用+initialize方法和dispatch_once取代所有的attribute((constructor))栖茉、C++靜態(tài)構(gòu)造器、ObjC的+load
+load() 方法里的內(nèi)容可以放到首屏渲染完成后再執(zhí)行
main()函數(shù)執(zhí)行后
- main() 函數(shù)執(zhí)行后的階段孵延，指的是從 main() 函數(shù)執(zhí)行開始吕漂，到 appDelegate 的 didFinishLaunchingWithOptions 方法里首屏渲染相關(guān)方法執(zhí)行完成。
首屏初始化所需配置文件的讀寫操作尘应；
首屏列表大數(shù)據(jù)的讀然棠；
首屏渲染的大量計算等犬钢。
開發(fā)者會把各種初始化工作都放到這個階段執(zhí)行苍鲜，導致渲染完成滯后。更加優(yōu)化的開發(fā)方式娜饵，應該是從功能上梳理出哪些是首屏渲染必要的初始化功能坡贺，哪些是 App 啟動必要的初始化功能，而哪些是只需要在對應功能開始使用時才需要初始化的。梳理完之后遍坟，將這些初始化功能分別放到合適的階段進行拳亿。
首屏渲染完成后
首屏渲染后的這個階段，主要完成的是愿伴，非首屏其他業(yè)務服務模塊的初始化肺魁、監(jiān)聽的注冊、配置文件的讀取等,這個階段就是從渲染完成時開始隔节，到 didFinishLaunchingWithOptions 方法作用域結(jié)束時結(jié)束.
這個階段用戶已經(jīng)能夠看到 App 的首頁信息了鹅经，所以優(yōu)化的優(yōu)先級排在最后.
功能級別的啟動優(yōu)化
功能級別的啟動優(yōu)化，就是要從 main() 函數(shù)執(zhí)行后這個階段下手怎诫。
優(yōu)化的思路是： main() 函數(shù)開始執(zhí)行后到首屏渲染完成前只處理首屏相關(guān)的業(yè)務瘾晃，其他非首屏業(yè)務的初始化、監(jiān)聽注冊幻妓、配置文件讀取等都放到首屏渲染完成后去做
方法級別的啟動優(yōu)化
我們需要進一步做的蹦误，是檢查首屏渲染完成前主線程上有哪些耗時方法，將沒必要的耗時方法滯后或者異步執(zhí)行肉津。通常情況下强胰，耗時較長的方法主要發(fā)生在計算大量數(shù)據(jù)的情況下，具體的表現(xiàn)就是加載妹沙、編輯偶洋、存儲圖片和文件等資源。
對 App 啟動速度的監(jiān)控距糖，主要有兩種手段玄窝。
第一種方法是，定時抓取主線程上的方法調(diào)用堆棧肾筐，計算一段時間里各個方法的耗時.
Xcode 工具套件里自帶的 Time Profiler 哆料，采用的就是這種方式
第二種方法是，對 objc_msgSend 方法進行 hook 來掌握所有方法的執(zhí)行耗時吗铐。
hook objc_msgSend 這種方式的優(yōu)點是非常精確东亦，而缺點是只能針對 Objective-C 的方法。
