前言
本文主要是分享一下自己基于公司項目這一次優(yōu)化的心得和所遇到的坑，基于列表優(yōu)化原理，這篇文章 iOS性能優(yōu)化系列篇之“列表流暢度優(yōu)化”很清晰的闡述了，可以認(rèn)真仔細(xì)的閱讀兩遍
遇到的坑：
由于第一次系統(tǒng)的做這一次列表優(yōu)化，沒什么經(jīng)驗，就結(jié)合網(wǎng)上耳濡目染提到的什么離屏渲染和圖層混合什么的，一直在解決這一塊問題，折騰了一天，流暢性并沒有什么明顯改變，所以得根據(jù)具體的項目來分析，這個項目主要是CPU利用率高導(dǎo)致列表卡頓，所以我主要記錄一下有效的處理方案
流程
1.基于低配性能的機(jī)型運(yùn)行Release的包
2.Instruments分析，找出具體耗時的函數(shù)
3.分析耗時的函數(shù)并解決
4.再次運(yùn)行分析，看耗時函數(shù)有沒有成功解決
基于低配性能的機(jī)型運(yùn)行Release的包
剛開始做列表優(yōu)化直接是用的iPhoneX運(yùn)行的，發(fā)現(xiàn)做了代碼調(diào)整優(yōu)化后，沒有很明顯的判斷是否生效了，所以我們需要用一個低配的機(jī)型來運(yùn)行，還有蘋果基于release的包會做一些優(yōu)化，并且用戶看到的包也為Release的，因此我們要基于低配性能的機(jī)型運(yùn)行Release的包去做優(yōu)化
Instruments分析，找出具體耗時的函數(shù)
啟動程序點擊XCode選擇左上角-XCode->Open Developer Tool ->Instruments，打開Instruments再選擇CoreAnimation, 運(yùn)行真機(jī),滑動列表能看到對應(yīng)的FPS，選取一段FPS較低的區(qū)域
再點擊Threads切換到對應(yīng)的線程列表，點擊主線程，這時候可以看到主線程調(diào)用的函數(shù)列表，頂部的weight是按函數(shù)總時間(包括函數(shù)里調(diào)用函數(shù)的時間)排序，Selg Weight為每一個函數(shù)執(zhí)行的時間排序
這里對右側(cè)call tree選項有必要做一下說明[官方user guide翻譯]:
- Separate By Thread
線程分離,只有這樣才能在調(diào)用路徑中能夠清晰看到占用CPU最大的線程.
- Invert Call Tree
從上到下跟蹤堆棧信息.這個選項可以快捷的看到方法調(diào)用路徑最深方法占用CPU耗時,比如FuncA{FunB{FunC}},勾選后堆棧以C->B->A把調(diào)用層級最深的C顯示最外面.
- Hide Missing Symbols
如果dSYM無法找到你的APP或者調(diào)用系統(tǒng)框架的話，那么表中將看到調(diào)用方法名只能看到16進(jìn)制的數(shù)值,勾選這個選項則可以隱藏這些符號，便于簡化分析數(shù)據(jù).
- Hide System Libraries
這個就更有用了,勾選后耗時調(diào)用路徑只會顯示app耗時的代碼,性能分析普遍我們都比較關(guān)系自己代碼的耗時而不是系統(tǒng)的.基本是必選項.注意有些代碼耗時也會納入系統(tǒng)層級，可以進(jìn)行勾選前后前后對執(zhí)行路徑進(jìn)行比對會非常有用.
這樣就能得到基于App耗時大小排序的函數(shù)列表, 雙擊就能顯示每個函數(shù)耗時在具體哪一行代碼，然后具體問題具體分析，修改好后，再運(yùn)行（有時候沒有好的解決辦法,可以先注釋，然后運(yùn)行，看看這函數(shù)對列表性能的影響程度），看耗時是否降低，依次類推
這樣應(yīng)該卡頓就能解決了，但是在低配的性能手機(jī)，快速滑動依然會有掉幀的現(xiàn)象，像微博就做了快速滑動不加載Cell的機(jī)制，這樣滑動cell都是白屏，優(yōu)化之路需要不斷的嘗試，耐心很重要，這里分享的優(yōu)化僅僅是基于大量的文章基礎(chǔ)去每一次嘗試得到的經(jīng)驗，同比一線大廠，在低配機(jī)型快速滑動上優(yōu)化還是有一定的差距，也希望大佬能夠交流一下優(yōu)化的心得，一起學(xué)習(xí)一下
GPU調(diào)試的步驟
早起的版本還是在Instrument里調(diào)試，現(xiàn)在直接拿到Xcode（有些同學(xué)可能找不到，將圖附上）,具體的優(yōu)化步驟按照前言里的貼出的文章來就可以，這里就不贅述了
