大家好，我是極客時(shí)間專欄《iOS 開(kāi)發(fā)高手課》的作者戴銘。之前我在專欄中跟大家梳理過(guò)成為一名開(kāi)發(fā)高手所必備的知識(shí)體系，感興趣的同學(xué)可以直接去APP里免費(fèi)看看。今天想和大家一起分享一些干貨，App 啟動(dòng)速度怎么做優(yōu)化與監(jiān)控？

在文章開(kāi)始前，我們先設(shè)想這么一個(gè)場(chǎng)景：假設(shè)你在排隊(duì)結(jié)賬時(shí)，掏出手機(jī)打開(kāi)App甲準(zhǔn)備掃碼支付，結(jié)果半天進(jìn)不去，后面排隊(duì)的人給你壓力夠大吧。然后，你又打開(kāi)App乙，秒進(jìn)，支付完成。試想一下，以后再支付時(shí)你會(huì)選擇哪個(gè)App呢。

不難想象，在提供的功能和服務(wù)相似的情況下，一款A(yù)pp的啟動(dòng)速度，不單單是用戶體驗(yàn)的事情，往往還決定了它能否獲取更多的用戶。這就好像陌生人第一次碰面，第一感覺(jué)往往決定了他們接下來(lái)是否會(huì)繼續(xù)交往。

由此可見(jiàn)，啟動(dòng)速度的優(yōu)化必然就是App開(kāi)發(fā)過(guò)程中，不可或缺的一個(gè)環(huán)節(jié)。接下來(lái)，我就先和你一起分析下App在啟動(dòng)時(shí)都做了哪些事兒。

App 啟動(dòng)時(shí)都干些了什么事兒？

一般情況下，App的啟動(dòng)分為冷啟動(dòng)和熱啟動(dòng)。

• 冷啟動(dòng)是指， App 點(diǎn)擊啟動(dòng)前，它的進(jìn)程不在系統(tǒng)里，需要系統(tǒng)新創(chuàng)建一個(gè)進(jìn)程分配給它啟動(dòng)的情況。這是一次完整的啟動(dòng)過(guò)程。
• 熱啟動(dòng)是指 ，App 在冷啟動(dòng)后用戶將 App 退后臺(tái)，在 App 的進(jìn)程還在系統(tǒng)里的情況下，用戶重新啟動(dòng)進(jìn)入 App 的過(guò)程，這個(gè)過(guò)程做的事情非常少。

所以，今天這篇文章，我們就只展開(kāi)講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)得慢。

那么，究竟如何才能把啟動(dòng)時(shí)的所有耗時(shí)都找出來(lái)呢？解決這個(gè)問(wèn)題，你首先需要弄清楚 App在啟動(dòng)時(shí)都干了哪些事兒。

一般而言，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í)行后；
• 首屏渲染完成后。

整個(gè)啟動(dòng)過(guò)程的示意圖，如下所示：

圖1 App的整個(gè)啟動(dòng)過(guò)程

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() 方法、attributeconstructor 修飾的函數(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)系，蘋果公司建議使用更少的動(dòng)態(tài)庫(kù)，并且建議在使用動(dòng)態(tài)庫(kù)的數(shù)量較多時(shí)，盡量將多個(gè)動(dòng)態(tài)庫(kù)進(jìn)行合并。數(shù)量上，蘋果公司最多可以支持6個(gè)非系統(tǒng)動(dòng)態(tài)庫(kù)合并為一個(gè)。
• 減少加載啟動(dòng)后不會(huì)去使用的類或者方法。
• +load() 方法里的內(nèi)容可以放到首屏渲染完成后再執(zhí)行，或使用 +initialize() 方法替換掉。因?yàn)?#xff0c;在一個(gè) +load() 方法里，進(jì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 的 didFinishLaunchingWithOptions 方法里首屏渲染相關(guān)方法執(zhí)行完成。

首頁(yè)的業(yè)務(wù)代碼都是要在這個(gè)階段，也就是首屏渲染前執(zhí)行的，主要包括了：

• 首屏初始化所需配置文件的讀寫(xiě)操作；
• 首屏列表大數(shù)據(jù)的讀取；
• 首屏渲染的大量計(jì)算等。

很多時(shí)候，開(kāi)發(fā)者會(huì)把各種初始化工作都放到這個(gè)階段執(zhí)行，導(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è)階段指的就是截止到 didFinishLaunchingWithOptions 方法作用域內(nèi)執(zhí)行首屏渲染之后的所有方法執(zhí)行完成。簡(jiǎn)單說(shuō)的話，這個(gè)階段就是從渲染完成時(shí)開(kāi)始，到 didFinishLaunchingWithOptions 方法作用域結(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í)別的啟動(dòng)優(yōu)化。接下來(lái)，我們就從這兩個(gè)角度展開(kāi)看看。

我們先來(lái)看看功能級(jí)別的啟動(dòng)優(yōu)化

我想，你所在的團(tuán)隊(duì)一定面臨過(guò)啟動(dòng)階段的代碼功能堆積、無(wú)規(guī)范、難維護(hù)的問(wèn)題吧。在 App 項(xiàng)目開(kāi)發(fā)初期，開(kāi)發(fā)人員不多、代碼量也沒(méi)那么大時(shí)，這種情況比較少見(jiàn)。但到了后期 ，App 業(yè)務(wù)規(guī)模擴(kuò)大，團(tuán)隊(duì)人員水平參差不齊，各種代碼問(wèn)題就會(huì)爆發(fā)出來(lái)，終歸需要來(lái)次全面治理。

而全面治理過(guò)程中的手段、方法和碰到的問(wèn)題，對(duì)于后面的規(guī)范制定以及啟動(dòng)速度監(jiān)控都有著重要的意義。那么，我們要怎樣從功能級(jí)別來(lái)進(jìn)行全面的啟動(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)化示意圖，如下圖所示：

圖2 功能級(jí)別的啟動(dòng)優(yōu)化示意圖

接下來(lái)，我們?cè)倏纯捶椒?jí)別的啟動(dòng)優(yōu)化

經(jīng)過(guò)功能級(jí)別的啟動(dòng)優(yōu)化，也就是將非首屏業(yè)務(wù)所需的功能滯后以后，從用戶點(diǎn)擊 App 到看到首屏的時(shí)間將會(huì)有很大程度的縮短，也就達(dá)到了優(yōu)化App啟動(dòng)速度的目的。

在這之后，我們需要進(jìn)一步做的，是檢查首屏渲染完成前主線程上有哪些耗時(shí)方法，將沒(méi)必要的耗時(shí)方法滯后或者異步執(zhí)行。通常情況下，耗時(shí)較長(zhǎng)的方法主要發(fā)生在計(jì)算大量數(shù)據(jù)的情況下，具體的表現(xiàn)就是加載、編輯、存儲(chǔ)圖片和文件等資源。

那么，你覺(jué)得是不是只需要優(yōu)化對(duì)資源的操作就可以了呢？

當(dāng)然不是。就像 +load() 方法，一個(gè)耗時(shí)4毫秒，100個(gè)就是400毫秒，這種耗時(shí)用戶也是能明顯感知到的。

比如，我以前使用的 ReactiveCocoa框架（這是一個(gè) iOS 上的響應(yīng)式編程框架），每創(chuàng)建一個(gè)信號(hào)都有6毫秒的耗時(shí)。這樣，稍不注意各種信號(hào)的創(chuàng)建就都被放在了首屏渲染完成前，進(jìn)而導(dǎo)致App的啟動(dòng)速度大幅變慢。

類似這樣單個(gè)方法耗時(shí)不多，但是由于堆積導(dǎo)致App啟動(dòng)速度大幅變慢的方法數(shù)不勝數(shù)。所以，你需要一個(gè)能夠?qū)?dòng)方法耗時(shí)進(jìn)行全面、精確檢查的手段。

那么問(wèn)題來(lái)了，有哪些監(jiān)控手段？這些監(jiān)控手段各有什么優(yōu)缺點(diǎn)？你又該如何選擇呢？

目前來(lái)看，對(duì)App啟動(dòng)速度的監(jiān)控，主要有兩種手段。

第一種方法是，定時(shí)抓取主線程上的方法調(diào)用堆棧，計(jì)算一段時(shí)間里各個(gè)方法的耗時(shí)。Xcode 工具套件里自帶的 Time Profiler ，采用的就是這種方式。

這種方式的優(yōu)點(diǎn)是，開(kāi)發(fā)類似工具成本不高，能夠快速開(kāi)發(fā)后集成到你的 App 中，以便在真實(shí)環(huán)境中進(jìn)行檢查。

說(shuō)到定時(shí)抓取，就會(huì)涉及到定時(shí)間隔的長(zhǎng)短問(wèn)題。

• 定時(shí)間隔設(shè)置得長(zhǎng)了，會(huì)漏掉一些方法，從而導(dǎo)致檢查出來(lái)的耗時(shí)不精確；
• 而定時(shí)間隔設(shè)置得短了，抓取堆棧這個(gè)方法本身調(diào)用過(guò)多也會(huì)影響整體耗時(shí)，導(dǎo)致結(jié)果不準(zhǔn)確。

這個(gè)定時(shí)間隔如果小于所有方法執(zhí)行的時(shí)間（比如 0.002秒），那么基本就能監(jiān)控到所有方法。但這樣做的話，整體的耗時(shí)時(shí)間就不夠準(zhǔn)確。一般將這個(gè)定時(shí)間隔設(shè)置為0.01秒。這樣設(shè)置，對(duì)整體耗時(shí)的影響小，不過(guò)很多方法耗時(shí)就不精確了。但因?yàn)檎w耗時(shí)的數(shù)據(jù)更加重要些，單個(gè)方法耗時(shí)精度不高也是可以接受的，所以這個(gè)設(shè)置也是沒(méi)問(wèn)題的。

總結(jié)來(lái)說(shuō)，定時(shí)抓取主線程調(diào)用棧的方式雖然精準(zhǔn)度不夠高，但也是夠用的。

第二種方法是，對(duì) objc_msgSend 方法進(jìn)行 hook 來(lái)掌握所有方法的執(zhí)行耗時(shí)。

hook 方法的意思是，在原方法開(kāi)始執(zhí)行時(shí)換成執(zhí)行其他你指定的方法，或者在原有方法執(zhí)行前后執(zhí)行你指定的方法，來(lái)達(dá)到掌握和改變指定方法的目的。

hook objc_msgSend 這種方式的優(yōu)點(diǎn)是非常精確，而缺點(diǎn)是只能針對(duì) Objective-C 的方法。當(dāng)然，對(duì)于 c 方法和 block 也不是沒(méi)有辦法，你可以使用 libffi 的 ffi_call 來(lái)達(dá)成 hook，但缺點(diǎn)就是編寫(xiě)維護(hù)相關(guān)工具門檻高。

關(guān)于，libffi 相關(guān)的內(nèi)容，我會(huì)在后面的第35篇文章“l(fā)ibffi：動(dòng)態(tài)調(diào)用和定義 C 函數(shù)”里和你詳細(xì)說(shuō)明。

綜上，如果對(duì)于檢查結(jié)果精準(zhǔn)度要求高的話，我比較推薦你使用 hook objc_msgSend 方式來(lái)檢查啟動(dòng)方法的執(zhí)行耗時(shí)。

如何做一個(gè)方法級(jí)別啟動(dòng)耗時(shí)檢查工具來(lái)輔助分析和監(jiān)控？

使用 hook objc_msgSend 方式來(lái)檢查啟動(dòng)方法的執(zhí)行耗時(shí)時(shí)，我們需要實(shí)現(xiàn)一個(gè)稱手的啟動(dòng)時(shí)間檢查工具。那么，我們應(yīng)該如何實(shí)現(xiàn)這個(gè)工具呢？

現(xiàn)在，我就一步一步地和你說(shuō)說(shuō)具體怎么做。

首先，你要了解為什么 hook 了 objc_msgSend 方法，就可以 hook 全部 Objective-C 的方法？

Objective-C 里每個(gè)對(duì)象都會(huì)指向一個(gè)類，每個(gè)類都會(huì)有一個(gè)方法列表，方法列表里的每個(gè)方法都是由 selector、函數(shù)指針和 metadata 組成的。

objc_msgSend 方法干的活兒，就是在運(yùn)行時(shí)根據(jù)對(duì)象和方法的selector 去找到對(duì)應(yīng)的函數(shù)指針，然后執(zhí)行。也就是說(shuō)，objc_msgSend 是 Objective-C 里方法執(zhí)行的必經(jīng)之路，能夠控制所有的 Objective-C 的方法。

objc_msgSend 本身是用匯編語(yǔ)言寫(xiě)的，這樣做的原因主要有兩個(gè)：

• 一個(gè)原因是，objc_msgSend 的調(diào)用頻次最高，在它上面進(jìn)行的性能優(yōu)化能夠提升整個(gè) App 生命周期的性能。而匯編語(yǔ)言在性能優(yōu)化上屬于原子級(jí)優(yōu)化，能夠把優(yōu)化做到極致。所以，這種投入產(chǎn)出比無(wú)疑是最大的。
• 另一個(gè)原因是，其他語(yǔ)言難以實(shí)現(xiàn)未知參數(shù)跳轉(zhuǎn)到任意函數(shù)指針的功能。

現(xiàn)在，蘋果公司已經(jīng)開(kāi)源了Objective-C 的運(yùn)行時(shí)代碼。你可以在蘋果公司的開(kāi)源網(wǎng)站，找到 objc_msgSend的源碼。

圖3 objc_msgSend 全架構(gòu)實(shí)現(xiàn)源代碼文件列表

上圖列出的是所有架構(gòu)的實(shí)現(xiàn)，包括 x86_64 等。objc_msgSend 是 iOS 方式執(zhí)行最核心的部分，編程領(lǐng)域的寶藏，值得你深入探究和細(xì)細(xì)品味。

objc_msgSend方法執(zhí)行的邏輯是：先獲取對(duì)象對(duì)應(yīng)類的信息，再獲取方法的緩存，根據(jù)方法的selector 查找函數(shù)指針，經(jīng)過(guò)異常錯(cuò)誤處理后，最后跳到對(duì)應(yīng)函數(shù)的實(shí)現(xiàn)。

按照這個(gè)邏輯去看源碼會(huì)更加清晰，更容易注意到實(shí)現(xiàn)細(xì)節(jié)。閱讀 objc_msgSend 源碼是編寫(xiě)方法級(jí)耗時(shí)工具的一個(gè)必要的環(huán)節(jié)，后面還需要編寫(xiě)一些對(duì)應(yīng)的匯編代碼。

接下來(lái)，我們?cè)倏纯丛趺?hook objc_msgSend 方法？

Facebook 開(kāi)源了一個(gè)庫(kù)，可以在iOS上運(yùn)行的Mach-O二進(jìn)制文件中動(dòng)態(tài)地重新綁定符號(hào)，這個(gè)庫(kù)叫 fishhook。你可以在GitHub 上，查看fishhook的代碼。

fishhook 實(shí)現(xiàn)的大致思路是，通過(guò)重新綁定符號(hào)，可以實(shí)現(xiàn)對(duì) c 方法的 hook。dyld 是通過(guò)更新 Mach-O 二進(jìn)制的 __DATA segment 特定的部分中的指針來(lái)綁定 lazy 和 non-lazy 符號(hào)，通過(guò)確認(rèn)傳遞給 rebind_symbol 里每個(gè)符號(hào)名稱更新的位置，就可以找出對(duì)應(yīng)替換來(lái)重新綁定這些符號(hào)。

下面，我針對(duì) fishhook 里的關(guān)鍵代碼，和你具體說(shuō)下 fishhook 的實(shí)現(xiàn)原理。

首先，遍歷 dyld 里的所有image，取出 image header 和 slide。代碼如下：

if (!_rebindings_head-\u0026gt;next) { _dyld_register_func_for_add_image(_rebind_symbols_for_image);} else { uint32_t c = _dyld_image_count(); // 遍歷所有 image for (uint32_t i = 0; i \u0026lt; c; i++) { // 讀取 image header 和 slider _rebind_symbols_for_image(_dyld_get_image_header(i), _dyld_get_image_vmaddr_slide(i)); }}

接下來(lái)，找到符號(hào)表相關(guān)的 command，包括 linkedit segment command、symtab command 和 dysymtab command。代碼如下：

segment_command_t *cur_seg_cmd;segment_command_t *linkedit_segment = NULL;struct symtab_command* symtab_cmd = NULL;struct dysymtab_command* dysymtab_cmd = NULL;uintptr_t cur = (uintptr_t)header + sizeof(mach_header_t);for (uint i = 0; i \u0026lt; header-\u0026gt;ncmds; i++, cur += cur_seg_cmd-\u0026gt;cmdsize) { cur_seg_cmd = (segment_command_t *)cur; if (cur_seg_cmd-\u0026gt;cmd == LC_SEGMENT_ARCH_DEPENDENT) { if (strcmp(cur_seg_cmd-\u0026gt;segname, SEG_LINKEDIT) == 0) { // linkedit segment command linkedit_segment = cur_seg_cmd; } } else if (cur_seg_cmd-\u0026gt;cmd == LC_SYMTAB) { // symtab command symtab_cmd = (struct symtab_command*)cur_seg_cmd; } else if (cur_seg_cmd-\u0026gt;cmd == LC_DYSYMTAB) { // dysymtab command dysymtab_cmd = (struct dysymtab_command*)cur_seg_cmd; }}

然后，獲得 base 和 indirect 符號(hào)表。實(shí)現(xiàn)代碼如下：

// 找到 base 符號(hào)表的地址uintptr_t linkedit_base = (uintptr_t)slide + linkedit_segment-\u0026gt;vmaddr - linkedit_segment-\u0026gt;fileoff;nlist_t *symtab = (nlist_t *)(linkedit_base + symtab_cmd-\u0026gt;symoff);char *strtab = (char *)(linkedit_base + symtab_cmd-\u0026gt;stroff);// 找到 indirect 符號(hào)表uint32_t *indirect_symtab = (uint32_t *)(linkedit_base + dysymtab_cmd-\u0026gt;indirectsymoff);

最后，有了符號(hào)表和傳入的方法替換數(shù)組，就可以進(jìn)行符號(hào)表訪問(wèn)指針地址的替換了，具體實(shí)現(xiàn)如下：

uint32_t *indirect_symbol_indices = indirect_symtab + section-\u0026gt;reserved1;void **indirect_symbol_bindings = (void **)((uintptr_t)slide + section-\u0026gt;addr);for (uint i = 0; i \u0026lt; section-\u0026gt;size / sizeof(void *); i++) { uint32_t symtab_index = indirect_symbol_indices[i]; if (symtab_index == INDIRECT_SYMBOL_ABS || symtab_index == INDIRECT_SYMBOL_LOCAL || symtab_index == (INDIRECT_SYMBOL_LOCAL | INDIRECT_SYMBOL_ABS)) { continue; } uint32_t strtab_offset = symtab[symtab_index].n_un.n_strx; char *symbol_name = strtab + strtab_offset; if (strnlen(symbol_name, 2) \u0026lt; 2) { continue; } struct rebindings_entry *cur = rebindings; while (cur) { for (uint j = 0; j \u0026lt; cur-\u0026gt;rebindings_nel; j++) { if (strcmp(\u0026amp;symbol_name[1], cur-\u0026gt;rebindings[j].name) == 0) { if (cur-\u0026gt;rebindings[j].replaced != NULL \u0026amp;\u0026amp; indirect_symbol_bindings[i] != cur-\u0026gt;rebindings[j].replacement) { *(cur-\u0026gt;rebindings[j].replaced) = indirect_symbol_bindings[i]; } // 符號(hào)表訪問(wèn)指針地址的替換 indirect_symbol_bindings[i] = cur-\u0026gt;rebindings[j].replacement; goto symbol_loop; } } cur = cur-\u0026gt;next; }symbol_loop:;

以上，就是 fishhook 的實(shí)現(xiàn)原理了。這里的每一步，都對(duì)應(yīng)有代碼實(shí)現(xiàn)，你可以點(diǎn)擊文稿查看相應(yīng)的代碼。fishhook 是對(duì)底層的操作，其中查找符號(hào)表的過(guò)程和堆棧符號(hào)化實(shí)現(xiàn)原理基本類似，了解了其中原理對(duì)于理解可執(zhí)行文件 Mach-O 內(nèi)部結(jié)構(gòu)會(huì)有很大的幫助。

接下來(lái)，我們?cè)倏匆粋€(gè)問(wèn)題：只靠 fishhook 就能夠搞定 objc_msgSend 的 hook 了嗎？

當(dāng)然還不夠。我前面也說(shuō)了，objc_msgSend 是用匯編語(yǔ)言實(shí)現(xiàn)的，所以我們還需要從匯編層面多加點(diǎn)料。

你需要先實(shí)現(xiàn)兩個(gè)方法 pushCallRecord 和 popCallRecord，來(lái)分別記錄 objc_msgSend 方法調(diào)用前后的時(shí)間，然后相減就能夠得到方法的執(zhí)行耗時(shí)。

下面我針對(duì)arm64架構(gòu)，編寫(xiě)一個(gè)可保留未知參數(shù)并跳轉(zhuǎn)到 c 中任意函數(shù)指針的匯編代碼，實(shí)現(xiàn)對(duì) objc_msgSend 的 Hook。

arm64 有31個(gè)64 bit 的整數(shù)型寄存器，分別用 x0 到 x30 表示。主要的實(shí)現(xiàn)思路是：

• 第一，入棧參數(shù)，參數(shù)寄存器是 x0~ x7。對(duì)于objc_msgSend方法來(lái)說(shuō)，x0 第一個(gè)參數(shù)是傳入對(duì)象，x1 第二個(gè)參數(shù)是選擇器 _cmd。syscall 的 number 會(huì)放到 x8 里。
• 第二，交換寄存器中保存的參數(shù)，將用于返回的寄存器 lr 中的數(shù)據(jù)移到 x1 里。
• 第三，使用 bl label 語(yǔ)法調(diào)用 pushCallRecord 函數(shù)。
• 第四，執(zhí)行原始的 objc_msgSend，保存返回值。
• 第五，使用 bl label 語(yǔ)法調(diào)用 popCallRecord 函數(shù)。

具體的匯編代碼，你可以點(diǎn)擊文稿查看如下所示：

static void replacementObjc_msgSend() { __asm__ volatile ( // sp 是堆棧寄存器，存放棧的偏移地址，每次都指向棧頂。 // 保存 {q0-q7} 偏移地址到 sp 寄存器 \u0026quot;stp q6, q7, [sp, #-32]!\\u0026quot; \u0026quot;stp q4, q5, [sp, #-32]!\\u0026quot; \u0026quot;stp q2, q3, [sp, #-32]!\\u0026quot; \u0026quot;stp q0, q1, [sp, #-32]!\\u0026quot; // 保存 {x0-x8, lr} \u0026quot;stp x8, lr, [sp, #-16]!\\u0026quot; \u0026quot;stp x6, x7, [sp, #-16]!\\u0026quot; \u0026quot;stp x4, x5, [sp, #-16]!\\u0026quot; \u0026quot;stp x2, x3, [sp, #-16]!\\u0026quot; \u0026quot;stp x0, x1, [sp, #-16]!\\u0026quot; // 交換參數(shù). \u0026quot;mov x2, x1\\u0026quot; \u0026quot;mov x1, lr\\u0026quot; \u0026quot;mov x3, sp\\u0026quot; // 調(diào)用 preObjc_msgSend，使用 bl label 語(yǔ)法。bl 執(zhí)行一個(gè)分支鏈接操作，label 是無(wú)條件分支的，是和本指令的地址偏移，范圍是 -128MB 到 +128MB \u0026quot;bl __Z15preObjc_msgSendP11objc_objectmP13objc_selectorP9RegState_\\u0026quot; \u0026quot;mov x9, x0\\u0026quot; \u0026quot;mov x10, x1\\u0026quot; \u0026quot;tst x10, x10\\u0026quot; // 讀取 {x0-x8, lr} 從保存到 sp 棧頂?shù)钠频刂纷x起 \u0026quot;ldp x0, x1, [sp], #16\\u0026quot; \u0026quot;ldp x2, x3, [sp], #16\\u0026quot; \u0026quot;ldp x4, x5, [sp], #16\\u0026quot; \u0026quot;ldp x6, x7, [sp], #16\\u0026quot; \u0026quot;ldp x8, lr, [sp], #16\\u0026quot; // 讀取 {q0-q7} \u0026quot;ldp q0, q1, [sp], #32\\u0026quot; \u0026quot;ldp q2, q3, [sp], #32\\u0026quot; \u0026quot;ldp q4, q5, [sp], #32\\u0026quot; \u0026quot;ldp q6, q7, [sp], #32\\u0026quot; \u0026quot;b.eq Lpassthrough\\u0026quot; // 調(diào)用原始 objc_msgSend。使用 blr xn 語(yǔ)法。blr 除了從指定寄存器讀取新的 PC 值外效果和 bl 一樣。xn 是通用寄存器的64位名稱分支地址，范圍是0到31 \u0026quot;blr x9\\u0026quot; // 保存 {x0-x9} \u0026quot;stp x0, x1, [sp, #-16]!\\u0026quot; \u0026quot;stp x2, x3, [sp, #-16]!\\u0026quot; \u0026quot;stp x4, x5, [sp, #-16]!\\u0026quot; \u0026quot;stp x6, x7, [sp, #-16]!\\u0026quot; \u0026quot;stp x8, x9, [sp, #-16]!\\u0026quot; // 保存 {q0-q7} \u0026quot;stp q0, q1, [sp, #-32]!\\u0026quot; \u0026quot;stp q2, q3, [sp, #-32]!\\u0026quot; \u0026quot;stp q4, q5, [sp, #-32]!\\u0026quot; \u0026quot;stp q6, q7, [sp, #-32]!\\u0026quot; // 調(diào)用 postObjc_msgSend hook. \u0026quot;bl __Z16postObjc_msgSendv\\u0026quot; \u0026quot;mov lr, x0\\u0026quot; // 讀取 {q0-q7} \u0026quot;ldp q6, q7, [sp], #32\\u0026quot; \u0026quot;ldp q4, q5, [sp], #32\\u0026quot; \u0026quot;ldp q2, q3, [sp], #32\\u0026quot; \u0026quot;ldp q0, q1, [sp], #32\\u0026quot; // 讀取 {x0-x9} \u0026quot;ldp x8, x9, [sp], #16\\u0026quot; \u0026quot;ldp x6, x7, [sp], #16\\u0026quot; \u0026quot;ldp x4, x5, [sp], #16\\u0026quot; \u0026quot;ldp x2, x3, [sp], #16\\u0026quot; \u0026quot;ldp x0, x1, [sp], #16\\u0026quot; \u0026quot;ret\\u0026quot; \u0026quot;Lpassthrough:\\u0026quot; // br 無(wú)條件分支到寄存器中的地址 \u0026quot;br x9\u0026quot; );}

現(xiàn)在，你就可以得到每個(gè) Objective-C 方法的耗時(shí)了。接下來(lái)，我們?cè)倏纯?strong>怎樣才能夠做到像下圖那樣記錄和展示方法調(diào)用的層級(jí)關(guān)系和順序呢？

圖4 方法調(diào)用層級(jí)和順序

不要著急，我來(lái)一步一步地跟你說(shuō)。

第一步，設(shè)計(jì)兩個(gè)結(jié)構(gòu)體：CallRecord 記錄調(diào)用方法詳細(xì)信息，包括 obj 和 SEL 等；ThreadCallStack 里面，需要用 index 記錄當(dāng)前調(diào)用方法樹(shù)的深度。

有了 SEL 再通過(guò) NSStringFromSelector 就能夠取得方法名，有了 obj 通過(guò) object_getClass 能夠得到 Class ，再用 NSStringFromClass 就能夠獲得類名。結(jié)構(gòu)的完整代碼如下：

// Shared structures.typedef struct CallRecord_ { id obj; //通過(guò) object_getClass 能夠得到 Class 再通過(guò) NSStringFromClass 能夠得到類名 SEL _cmd; //通過(guò) NSStringFromSelector 方法能夠得到方法名 uintptr_t lr; int prevHitIndex; char isWatchHit;} CallRecord;typedef struct ThreadCallStack_ { FILE *file; char *spacesStr; CallRecord *stack; int allocatedLength; int index; //index 記錄當(dāng)前調(diào)用方法樹(shù)的深度 int numWatchHits; int lastPrintedIndex; int lastHitIndex; char isLoggingEnabled; char isCompleteLoggingEnabled;} ThreadCallStack;

第二步，pthread_setspecific() 可以將私有數(shù)據(jù)設(shè)置在指定線程上，pthread_getspecific() 用來(lái)讀取這個(gè)私有數(shù)據(jù)。利用這個(gè)特性，我們就可以將 ThreadCallStack 的數(shù)據(jù)和該線程綁定在一起，隨時(shí)進(jìn)行數(shù)據(jù)存取。代碼如下：

static inline ThreadCallStack * getThreadCallStack() { ThreadCallStack *cs = (ThreadCallStack *)pthread_getspecific(threadKey); //讀取 if (cs == NULL) { cs = (ThreadCallStack *)malloc(sizeof(ThreadCallStack));#ifdef MAIN_THREAD_ONLY cs-\u0026gt;file = (pthread_main_np()) ? newFileForThread() : NULL;#else cs-\u0026gt;file = newFileForThread();#endif cs-\u0026gt;isLoggingEnabled = (cs-\u0026gt;file != NULL); cs-\u0026gt;isCompleteLoggingEnabled = 0; cs-\u0026gt;spacesStr = (char *)malloc(DEFAULT_CALLSTACK_DEPTH + 1); memset(cs-\u0026gt;spacesStr, ' ', DEFAULT_CALLSTACK_DEPTH); cs-\u0026gt;spacesStr[DEFAULT_CALLSTACK_DEPTH] = '\\0'; cs-\u0026gt;stack = (CallRecord *)calloc(DEFAULT_CALLSTACK_DEPTH, sizeof(CallRecord)); //分配 CallRecord 默認(rèn)空間 cs-\u0026gt;allocatedLength = DEFAULT_CALLSTACK_DEPTH; cs-\u0026gt;index = cs-\u0026gt;lastPrintedIndex = cs-\u0026gt;lastHitIndex = -1; cs-\u0026gt;numWatchHits = 0; pthread_setspecific(threadKey, cs); //保存數(shù)據(jù) } return cs;}

第三步，因?yàn)橐涗浬疃?#xff0c;而一個(gè)方法的調(diào)用里會(huì)有更多的方法調(diào)用，所以我們可以在方法的調(diào)用里增加兩個(gè)方法 pushCallRecord 和 popCallRecord，分別記錄方法調(diào)用的開(kāi)始時(shí)間和結(jié)束時(shí)間，這樣才能夠在開(kāi)始時(shí)對(duì)深度加一、在結(jié)束時(shí)減一。

//開(kāi)始時(shí)static inline void pushCallRecord(id obj, uintptr_t lr, SEL _cmd, ThreadCallStack *cs) { int nextIndex = (++cs-\u0026gt;index); //增加深度 if (nextIndex \u0026gt;= cs-\u0026gt;allocatedLength) { cs-\u0026gt;allocatedLength += CALLSTACK_DEPTH_INCREMENT; cs-\u0026gt;stack = (CallRecord *)realloc(cs-\u0026gt;stack, cs-\u0026gt;allocatedLength * sizeof(CallRecord)); cs-\u0026gt;spacesStr = (char *)realloc(cs-\u0026gt;spacesStr, cs-\u0026gt;allocatedLength + 1); memset(cs-\u0026gt;spacesStr, ' ', cs-\u0026gt;allocatedLength); cs-\u0026gt;spacesStr[cs-\u0026gt;allocatedLength] = '\\0'; } CallRecord *newRecord = \u0026amp;cs-\u0026gt;stack[nextIndex]; newRecord-\u0026gt;obj = obj; newRecord-\u0026gt;_cmd = _cmd; newRecord-\u0026gt;lr = lr; newRecord-\u0026gt;isWatchHit = 0;}//結(jié)束時(shí)static inline CallRecord * popCallRecord(ThreadCallStack *cs) { return \u0026amp;cs-\u0026gt;stack[cs-\u0026gt;index--]; //減少深度}

耗時(shí)檢查的完整代碼，你可以在我的開(kāi)源項(xiàng)目里查看，你可以點(diǎn)擊文稿中的鏈接找到這個(gè)項(xiàng)目。在需要檢測(cè)耗時(shí)時(shí)間的地方調(diào)用 [SMCallTrace start]，結(jié)束時(shí)調(diào)用 stop 和 save 就可以打印出方法的調(diào)用層級(jí)和耗時(shí)了。你還可以設(shè)置最大深度和最小耗時(shí)檢測(cè)，來(lái)過(guò)濾不需要看到的信息。

有了這樣一個(gè)檢查方法耗時(shí)的工具，你就可以在每個(gè)版本開(kāi)發(fā)結(jié)束后執(zhí)行一次檢查，統(tǒng)計(jì)總耗時(shí)以及啟動(dòng)階段每個(gè)方法的耗時(shí)，有針對(duì)性地觀察啟動(dòng)速度慢的問(wèn)題。如果你在線上做個(gè)灰度開(kāi)關(guān)，還可以監(jiān)控線上啟動(dòng)慢的一些特殊情況。

接下來(lái)，我們小結(jié)一下今天的主要內(nèi)容

啟動(dòng)速度優(yōu)化和監(jiān)控的重要性不言而喻，加快 App 的啟動(dòng)速度對(duì)用戶的體驗(yàn)提升是最大的。

啟動(dòng)速度的優(yōu)化也有粗有細(xì)：粗上來(lái)講，這需要對(duì)啟動(dòng)階段功能進(jìn)行分類整理，合理地將和首屏無(wú)關(guān)的功能滯后，放到首屏渲染完成之后，保證大頭兒沒(méi)有問(wèn)題；細(xì)的來(lái)講，這就需要些匠人精神，使用合適的工具，針對(duì)每個(gè)方法進(jìn)行逐個(gè)分析、優(yōu)化，每個(gè)階段都做到極致。

總結(jié)

以上是生活随笔為你收集整理的APP启动速度是门面，如何做到极致优化？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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