最近在做一款陌生人社交的軟件絮短，市場(chǎng)上這類軟件都是大同小異髓棋。為了能讓產(chǎn)品比競(jìng)品更具競(jìng)爭(zhēng)力坑雅，做為開(kāi)發(fā)者辈挂，除了完成來(lái)自產(chǎn)品經(jīng)理需求外，我們能做的還有這些：
- 崩潰率優(yōu)化
- 交互的優(yōu)化
- 動(dòng)畫(huà)的優(yōu)化
我把App啟動(dòng)速度的優(yōu)化歸結(jié)在交互優(yōu)化中
一般情況下裹粤，App的啟動(dòng)分為冷啟動(dòng)和熱啟動(dòng)
- 冷啟動(dòng)
app啟動(dòng)前终蒂，它的進(jìn)程不在系統(tǒng)里，需要系統(tǒng)新創(chuàng)建一個(gè)進(jìn)程分配給他啟動(dòng)的情況遥诉，即App從被殺死的情況下啟動(dòng) - 熱啟動(dòng)
app在冷啟動(dòng)后將程序退到后臺(tái)拇泣，在app進(jìn)程還在系統(tǒng)里的情況下，用戶重 新啟動(dòng)進(jìn)入app的過(guò)程矮锈，即app從被掛起的情況下啟動(dòng)霉翔，這個(gè)過(guò)程做的事情非常少
這篇文章主要探討app冷啟動(dòng)的優(yōu)化
用戶能感知到的啟動(dòng)慢，其實(shí)都發(fā)生在主線程上苞笨，而主線程慢的原因有很多债朵，比如在主線程上執(zhí)行了大文件讀寫(xiě)操作、在渲染周期執(zhí)行了大量計(jì)算等瀑凝。但是序芦，有時(shí)候你會(huì)發(fā)現(xiàn)即使你把首屏顯示之前的這些主線程的耗時(shí)問(wèn)題都解決了，還是比競(jìng)品啟動(dòng)得慢粤咪。
一般而言谚中，App的啟動(dòng)時(shí)間，指的是從用戶點(diǎn)擊App開(kāi)始寥枝，到用戶看到第一個(gè)界面之間的時(shí)間宪塔，總結(jié)來(lái)說(shuō)，App的啟動(dòng)主要包括三個(gè)階段：
-
main()函數(shù)執(zhí)行前 -
main()函數(shù)執(zhí)行后 - 首屏渲染完成后
main()函數(shù)執(zhí)行前
在 main()函數(shù)執(zhí)行前脉顿，系統(tǒng)主要會(huì)做下面幾件事：
- 加載
可執(zhí)行文件（App的.o文件的集合） - 加載動(dòng)態(tài)鏈接庫(kù)蝌麸，進(jìn)行
rebase指針調(diào)整和bind符號(hào)綁定 -
objc 運(yùn)行時(shí)的初始處理点寥，包括objc相關(guān)類的注冊(cè)艾疟、category注冊(cè)、selector唯一性檢查等 - 初始化蔽莱，包括了執(zhí)行
+load()方法怠苔、attribute((constructor))修飾的函數(shù)的調(diào)用锅劝、創(chuàng)建C++靜態(tài)全局變量
響應(yīng)的玻粪，在這個(gè)階段對(duì)于啟動(dòng)速度優(yōu)化來(lái)說(shuō)劲室，可以做的事情包括:
-
減少動(dòng)態(tài)庫(kù)加載,每個(gè)庫(kù)本身都有依賴關(guān)系很洋，蘋(píng)果官方建議使用更少的動(dòng)態(tài)庫(kù)悠垛，并且建議在使用動(dòng)態(tài)庫(kù)的數(shù)量較多時(shí)斤讥，盡量將多個(gè)動(dòng)態(tài)庫(kù)進(jìn)行合并。數(shù)量上，蘋(píng)果公司最多可以支持6個(gè)非系統(tǒng)動(dòng)態(tài)庫(kù)合并為1個(gè) - 減少加載啟動(dòng)后不會(huì)去使用的類或者方法
-
+load()方法里的內(nèi)容可以放到首屏渲染完成后再執(zhí)行鉴竭，或使用+initialize方法替換掉。因?yàn)椋谝粋€(gè)+load()方法里，運(yùn)行運(yùn)行時(shí)方法替換操作會(huì)帶來(lái)4毫秒的消耗泰演，不要小看這4毫秒靴拱，積少成多本谜，執(zhí)行+load()方法對(duì)啟動(dòng)速度的影響會(huì)越來(lái)越大 - 控制
C++全局變量的數(shù)量
main()函數(shù)執(zhí)行后
main()函數(shù)執(zhí)行后的階段陌知，指的是從main() 函數(shù)執(zhí)行開(kāi)始赏参，到 appDelegate的(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {}方法里首屏渲染相關(guān)方法執(zhí)行完成
首頁(yè)的業(yè)務(wù)代碼都是要在這個(gè)階段，也就是首屏渲染前執(zhí)行的沿盅，主要包括了：
- 首屏初始化所需配置文件的讀寫(xiě)操作
- 首屏列表大數(shù)據(jù)的讀取
- 首屏渲染的大量計(jì)算等
很多時(shí)候把篓，我們會(huì)把各種初始化工作都放到這個(gè)階段執(zhí)行（如各類sdk初始化），導(dǎo)致渲染完成置后腰涧。更加優(yōu)化的開(kāi)發(fā)方式韧掩，應(yīng)該是從功能上梳理出哪些是首屏渲染必要的初始化功能，哪些是App啟動(dòng)必要的初始化功能窖铡，而哪些是只需要在對(duì)應(yīng)功能開(kāi)始使用時(shí)才需要初始化的疗锐。梳理完之后郎楼，將這些初始化功能分別放到合適的階段進(jìn)行。
首屏顯示完成后
首屏渲染完成后的這個(gè)階段窒悔，主要完成的是，非首屏其它業(yè)務(wù)服務(wù)模塊的初始化敌买、監(jiān)聽(tīng)的注冊(cè)简珠、配置文件的讀取等。從函數(shù)上來(lái)看虹钮，這個(gè)階段指的就是截止到(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {}方法作用域內(nèi)執(zhí)行首屏渲染之后的所有執(zhí)行方法聋庵。簡(jiǎn)單說(shuō)的話，這個(gè)階段就是從渲染完成時(shí)芙粱，到(BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {}方法作用域結(jié)束時(shí)結(jié)束祭玉。
這個(gè)階段用戶已經(jīng)能夠看到App的首頁(yè)信息了，所以優(yōu)化的優(yōu)先級(jí)排在最后春畔。但是脱货，那些會(huì)卡住主線程的方法還是需要最優(yōu)先處理的，不然還是會(huì)影響到用戶后面的交互操作律姨。
明白了App啟動(dòng)階段需要完成的工作后振峻，我們就可以有的放矢的進(jìn)行啟動(dòng)速度的優(yōu)化了。這些優(yōu)化择份，包括了功能級(jí)別和方法級(jí)別的優(yōu)化
功能級(jí)別的啟動(dòng)優(yōu)化
功能級(jí)別的啟動(dòng)優(yōu)化扣孟，就是要從main()函數(shù)執(zhí)行后這個(gè)階段入手
優(yōu)化的思路是：main()函數(shù)開(kāi)始執(zhí)行后到首屏渲染完成前只處理首屏相關(guān)的業(yè)務(wù)，其他非首屏業(yè)務(wù)的初始化荣赶、監(jiān)聽(tīng)注冊(cè)凤价、配置文件讀取等都放到首屏渲染完成后去做
方法級(jí)別的啟動(dòng)優(yōu)化
經(jīng)過(guò)功能級(jí)別的啟動(dòng)優(yōu)化，也就是將首屏業(yè)務(wù)所需的功能滯后以后拔创，當(dāng)用戶點(diǎn)擊App到看到首屏的時(shí)間將會(huì)很大程度的縮減利诺，也就達(dá)到了優(yōu)化App啟動(dòng)速度的目的。
在這之后剩燥，我們需要進(jìn)一步做的立轧，是堅(jiān)持首屏渲染完成前主線程上有哪些耗時(shí)方法，將沒(méi)必要的耗時(shí)方法滯后或者異步執(zhí)行躏吊。通常情況下氛改，耗時(shí)較長(zhǎng)的方法主要發(fā)生在計(jì)算大量數(shù)據(jù)的情況下，具體的表現(xiàn)就是加載比伏、編輯胜卤、儲(chǔ)存圖片和文件等資源
App啟動(dòng)速度的監(jiān)控
- 定時(shí)抓取主線程上的方法調(diào)用堆棧，計(jì)算一段時(shí)間里各個(gè)方法的耗時(shí)赁项。Xcode工具里的
Time Profile采用的就是這種方式 - 對(duì)
objc_msgSend方法進(jìn)行hook來(lái)掌握所有方法的執(zhí)行耗時(shí)
hook方法的意思是葛躏，在原方法開(kāi)始執(zhí)行時(shí)換成其他你指定的方法澈段，或者再原有方法執(zhí)行前后執(zhí)行你指定的方法，來(lái)達(dá)到掌握和改變指定方法的目的舰攒。
hook objc_msgSend這種方式的優(yōu)點(diǎn)是非常精確败富，而缺點(diǎn)是只能針對(duì)Objective-C方法。對(duì)于c方法和block摩窃，可以使用libffi 的ffi_call來(lái)達(dá)成hook兽叮。缺點(diǎn)就是編寫(xiě)維護(hù)相關(guān)工具門檻高
綜上，如果對(duì)于檢查結(jié)果精準(zhǔn)度要求高的話猾愿，推薦使用hool objc_msgSend方式來(lái)檢查啟動(dòng)方法的執(zhí)行耗時(shí)
