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

在文章開始前，我們先設想這么一個場景：假設你在排隊結賬時，掏出手機打開App甲準備掃碼支付，結果半天進不去，后面排隊的人給你壓力夠大吧。然后，你又打開App乙，秒進，支付完成。試想一下，以后再支付時你會選擇哪個App呢。

不難想象，在提供的功能和服務相似的情況下，一款App的啟動速度，不單單是用戶體驗的事情，往往還決定了它能否獲取更多的用戶。這就好像陌生人第一次碰面，第一感覺往往決定了他們接下來是否會繼續交往。

由此可見，啟動速度的優化必然就是App開發過程中，不可或缺的一個環節。接下來，我就先和你一起分析下App在啟動時都做了哪些事兒。

App 啟動時都干些了什么事兒？

一般情況下，App的啟動分為冷啟動和熱啟動。

• 冷啟動是指， App 點擊啟動前，它的進程不在系統里，需要系統新創建一個進程分配給它啟動的情況。這是一次完整的啟動過程。
• 熱啟動是指 ，App 在冷啟動后用戶將 App 退后臺，在 App 的進程還在系統里的情況下，用戶重新啟動進入 App 的過程，這個過程做的事情非常少。

所以，今天這篇文章，我們就只展開講App冷啟動的優化。

用戶能感知到的啟動慢，其實都發生在主線程上。而主線程慢的原因有很多，比如在主線程上執行了大文件讀寫操作、在渲染周期中執行了大量計算等。但是，有時你會發現即使你把首屏顯示之前的這些主線程的耗時問題都解決了，還是比競品啟動得慢。

那么，究竟如何才能把啟動時的所有耗時都找出來呢？解決這個問題，你首先需要弄清楚 App在啟動時都干了哪些事兒。

一般而言，App的啟動時間，指的是從用戶點擊App開始，到用戶看到第一個界面之間的時間?？偨Y來說，App的啟動主要包括三個階段：

• main() 函數執行前；
• main() 函數執行后；
• 首屏渲染完成后。

整個啟動過程的示意圖，如下所示：

圖1 App的整個啟動過程

main() 函數執行前

在 main() 函數執行前，系統主要會做下面幾件事情：

• 加載可執行文件（，也就是App的.o文件的集合）；
• 加載動態鏈接庫，進行 rebase 指針調整和 bind 符號綁定；
• Objc 運行時的初始處理，包括 Objc 相關類的注冊、category 注冊、selector 唯一性檢查等；
• 初始化，包括了執行 +load() 方法、attributeconstructor 修飾的函數的調用、創建 C++ 靜態全局變量。

相應地，這個階段對于啟動速度優化來說，可以做的事情包括：

• 減少動態庫加載。每個庫本身都有依賴關系，蘋果公司建議使用更少的動態庫，并且建議在使用動態庫的數量較多時，盡量將多個動態庫進行合并。數量上，蘋果公司最多可以支持6個非系統動態庫合并為一個。
• 減少加載啟動后不會去使用的類或者方法。
• +load() 方法里的內容可以放到首屏渲染完成后再執行，或使用 +initialize() 方法替換掉。因為，在一個 +load() 方法里，進行運行時方法替換操作會帶來 4 毫秒的消耗。不要小看這4毫秒，積少成多，執行+load() 方法對啟動速度的影響會越來越大。
• 控制C++ 全局變量的數量。

main() 函數執行后

main() 函數執行后的階段，指的是從main()函數執行開始，到appDelegate 的 didFinishLaunchingWithOptions 方法里首屏渲染相關方法執行完成。

首頁的業務代碼都是要在這個階段，也就是首屏渲染前執行的，主要包括了：

• 首屏初始化所需配置文件的讀寫操作；
• 首屏列表大數據的讀取；
• 首屏渲染的大量計算等。

很多時候，開發者會把各種初始化工作都放到這個階段執行，導致渲染完成滯后。更加優化的開發方式，應該是從功能上梳理出哪些是首屏渲染必要的初始化功能，哪些是 App 啟動必要的初始化功能，而哪些是只需要在對應功能開始使用時才需要初始化的。梳理完之后，將這些初始化功能分別放到合適的階段進行。

首屏渲染完成后

首屏渲染后的這個階段，主要完成的是，非首屏其他業務服務模塊的初始化、監聽的注冊、配置文件的讀取等。從函數上來看，這個階段指的就是截止到 didFinishLaunchingWithOptions 方法作用域內執行首屏渲染之后的所有方法執行完成。簡單說的話，這個階段就是從渲染完成時開始，到 didFinishLaunchingWithOptions 方法作用域結束時結束。

這個階段用戶已經能夠看到 App 的首頁信息了，所以優化的優先級排在最后。但是，那些會卡住主線程的方法還是需要最優先處理的，不然還是會影響到用戶后面的交互操作。

明白了App啟動階段需要完成的工作后，我們就可以有的放矢地進行啟動速度的優化了。這些優化，包括了功能級別和方法級別的啟動優化。接下來，我們就從這兩個角度展開看看。

我們先來看看功能級別的啟動優化

我想，你所在的團隊一定面臨過啟動階段的代碼功能堆積、無規范、難維護的問題吧。在 App 項目開發初期，開發人員不多、代碼量也沒那么大時，這種情況比較少見。但到了后期 ，App 業務規模擴大，團隊人員水平參差不齊，各種代碼問題就會爆發出來，終歸需要來次全面治理。

而全面治理過程中的手段、方法和碰到的問題，對于后面的規范制定以及啟動速度監控都有著重要的意義。那么，我們要怎樣從功能級別來進行全面的啟動優化治理呢？

功能級別的啟動優化，就是要從main() 函數執行后這個階段下手。

優化的思路是： main() 函數開始執行后到首屏渲染完成前只處理首屏相關的業務，其他非首屏業務的初始化、監聽注冊、配置文件讀取等都放到首屏渲染完成后去做。這里有一張功能級別的啟動優化示意圖，如下圖所示：

圖2 功能級別的啟動優化示意圖

接下來，我們再看看方法級別的啟動優化

經過功能級別的啟動優化，也就是將非首屏業務所需的功能滯后以后，從用戶點擊 App 到看到首屏的時間將會有很大程度的縮短，也就達到了優化App啟動速度的目的。

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

那么，你覺得是不是只需要優化對資源的操作就可以了呢？

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

比如，我以前使用的 ReactiveCocoa框架（這是一個 iOS 上的響應式編程框架），每創建一個信號都有6毫秒的耗時。這樣，稍不注意各種信號的創建就都被放在了首屏渲染完成前，進而導致App的啟動速度大幅變慢。

類似這樣單個方法耗時不多，但是由于堆積導致App啟動速度大幅變慢的方法數不勝數。所以，你需要一個能夠對啟動方法耗時進行全面、精確檢查的手段。

那么問題來了，有哪些監控手段？這些監控手段各有什么優缺點？你又該如何選擇呢？

目前來看，對App啟動速度的監控，主要有兩種手段。

第一種方法是，定時抓取主線程上的方法調用堆棧，計算一段時間里各個方法的耗時。Xcode 工具套件里自帶的 Time Profiler ，采用的就是這種方式。

這種方式的優點是，開發類似工具成本不高，能夠快速開發后集成到你的 App 中，以便在真實環境中進行檢查。

說到定時抓取，就會涉及到定時間隔的長短問題。

• 定時間隔設置得長了，會漏掉一些方法，從而導致檢查出來的耗時不精確；
• 而定時間隔設置得短了，抓取堆棧這個方法本身調用過多也會影響整體耗時，導致結果不準確。

這個定時間隔如果小于所有方法執行的時間（比如 0.002秒），那么基本就能監控到所有方法。但這樣做的話，整體的耗時時間就不夠準確。一般將這個定時間隔設置為0.01秒。這樣設置，對整體耗時的影響小，不過很多方法耗時就不精確了。但因為整體耗時的數據更加重要些，單個方法耗時精度不高也是可以接受的，所以這個設置也是沒問題的。

總結來說，定時抓取主線程調用棧的方式雖然精準度不夠高，但也是夠用的。

第二種方法是，對 objc_msgSend 方法進行 hook 來掌握所有方法的執行耗時。

hook 方法的意思是，在原方法開始執行時換成執行其他你指定的方法，或者在原有方法執行前后執行你指定的方法，來達到掌握和改變指定方法的目的。

hook objc_msgSend 這種方式的優點是非常精確，而缺點是只能針對 Objective-C 的方法。當然，對于 c 方法和 block 也不是沒有辦法，你可以使用 libffi 的 ffi_call 來達成 hook，但缺點就是編寫維護相關工具門檻高。

關于，libffi 相關的內容，我會在后面的第35篇文章“libffi：動態調用和定義 C 函數”里和你詳細說明。

綜上，如果對于檢查結果精準度要求高的話，我比較推薦你使用 hook objc_msgSend 方式來檢查啟動方法的執行耗時。

如何做一個方法級別啟動耗時檢查工具來輔助分析和監控？

使用 hook objc_msgSend 方式來檢查啟動方法的執行耗時時，我們需要實現一個稱手的啟動時間檢查工具。那么，我們應該如何實現這個工具呢？

現在，我就一步一步地和你說說具體怎么做。

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

Objective-C 里每個對象都會指向一個類，每個類都會有一個方法列表，方法列表里的每個方法都是由 selector、函數指針和 metadata 組成的。

objc_msgSend 方法干的活兒，就是在運行時根據對象和方法的selector 去找到對應的函數指針，然后執行。也就是說，objc_msgSend 是 Objective-C 里方法執行的必經之路，能夠控制所有的 Objective-C 的方法。

objc_msgSend 本身是用匯編語言寫的，這樣做的原因主要有兩個：

• 一個原因是，objc_msgSend 的調用頻次最高，在它上面進行的性能優化能夠提升整個 App 生命周期的性能。而匯編語言在性能優化上屬于原子級優化，能夠把優化做到極致。所以，這種投入產出比無疑是最大的。
• 另一個原因是，其他語言難以實現未知參數跳轉到任意函數指針的功能。

現在，蘋果公司已經開源了Objective-C 的運行時代碼。你可以在蘋果公司的開源網站，找到 objc_msgSend的源碼。

圖3 objc_msgSend 全架構實現源代碼文件列表

上圖列出的是所有架構的實現，包括 x86_64 等。objc_msgSend 是 iOS 方式執行最核心的部分，編程領域的寶藏，值得你深入探究和細細品味。

objc_msgSend方法執行的邏輯是：先獲取對象對應類的信息，再獲取方法的緩存，根據方法的selector 查找函數指針，經過異常錯誤處理后，最后跳到對應函數的實現。

按照這個邏輯去看源碼會更加清晰，更容易注意到實現細節。閱讀 objc_msgSend 源碼是編寫方法級耗時工具的一個必要的環節，后面還需要編寫一些對應的匯編代碼。

接下來，我們再看看怎么 hook objc_msgSend 方法？

Facebook 開源了一個庫，可以在iOS上運行的Mach-O二進制文件中動態地重新綁定符號，這個庫叫 fishhook。你可以在GitHub 上，查看fishhook的代碼。

fishhook 實現的大致思路是，通過重新綁定符號，可以實現對 c 方法的 hook。dyld 是通過更新 Mach-O 二進制的 __DATA segment 特定的部分中的指針來綁定 lazy 和 non-lazy 符號，通過確認傳遞給 rebind_symbol 里每個符號名稱更新的位置，就可以找出對應替換來重新綁定這些符號。

下面，我針對 fishhook 里的關鍵代碼，和你具體說下 fishhook 的實現原理。

首先，遍歷 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)); }}

接下來，找到符號表相關的 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 符號表。實現代碼如下：

// 找到 base 符號表的地址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 符號表uint32_t *indirect_symtab = (uint32_t *)(linkedit_base + dysymtab_cmd-\u0026gt;indirectsymoff);

最后，有了符號表和傳入的方法替換數組，就可以進行符號表訪問指針地址的替換了，具體實現如下：

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]; } // 符號表訪問指針地址的替換 indirect_symbol_bindings[i] = cur-\u0026gt;rebindings[j].replacement; goto symbol_loop; } } cur = cur-\u0026gt;next; }symbol_loop:;

以上，就是 fishhook 的實現原理了。這里的每一步，都對應有代碼實現，你可以點擊文稿查看相應的代碼。fishhook 是對底層的操作，其中查找符號表的過程和堆棧符號化實現原理基本類似，了解了其中原理對于理解可執行文件 Mach-O 內部結構會有很大的幫助。

接下來，我們再看一個問題：只靠 fishhook 就能夠搞定 objc_msgSend 的 hook 了嗎？

當然還不夠。我前面也說了，objc_msgSend 是用匯編語言實現的，所以我們還需要從匯編層面多加點料。

你需要先實現兩個方法 pushCallRecord 和 popCallRecord，來分別記錄 objc_msgSend 方法調用前后的時間，然后相減就能夠得到方法的執行耗時。

下面我針對arm64架構，編寫一個可保留未知參數并跳轉到 c 中任意函數指針的匯編代碼，實現對 objc_msgSend 的 Hook。

arm64 有31個64 bit 的整數型寄存器，分別用 x0 到 x30 表示。主要的實現思路是：

• 第一，入棧參數，參數寄存器是 x0~ x7。對于objc_msgSend方法來說，x0 第一個參數是傳入對象，x1 第二個參數是選擇器 _cmd。syscall 的 number 會放到 x8 里。
• 第二，交換寄存器中保存的參數，將用于返回的寄存器 lr 中的數據移到 x1 里。
• 第三，使用 bl label 語法調用 pushCallRecord 函數。
• 第四，執行原始的 objc_msgSend，保存返回值。
• 第五，使用 bl label 語法調用 popCallRecord 函數。

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

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; // 交換參數. \u0026quot;mov x2, x1\\u0026quot; \u0026quot;mov x1, lr\\u0026quot; \u0026quot;mov x3, sp\\u0026quot; // 調用 preObjc_msgSend，使用 bl label 語法。bl 執行一個分支鏈接操作，label 是無條件分支的，是和本指令的地址偏移，范圍是 -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 棧頂的偏移地址讀起 \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; // 調用原始 objc_msgSend。使用 blr xn 語法。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; // 調用 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 無條件分支到寄存器中的地址 \u0026quot;br x9\u0026quot; );}

現在，你就可以得到每個 Objective-C 方法的耗時了。接下來，我們再看看怎樣才能夠做到像下圖那樣記錄和展示方法調用的層級關系和順序呢？

圖4 方法調用層級和順序

不要著急，我來一步一步地跟你說。

第一步，設計兩個結構體：CallRecord 記錄調用方法詳細信息，包括 obj 和 SEL 等；ThreadCallStack 里面，需要用 index 記錄當前調用方法樹的深度。

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

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

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

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 默認空間 cs-\u0026gt;allocatedLength = DEFAULT_CALLSTACK_DEPTH; cs-\u0026gt;index = cs-\u0026gt;lastPrintedIndex = cs-\u0026gt;lastHitIndex = -1; cs-\u0026gt;numWatchHits = 0; pthread_setspecific(threadKey, cs); //保存數據 } return cs;}

第三步，因為要記錄深度，而一個方法的調用里會有更多的方法調用，所以我們可以在方法的調用里增加兩個方法 pushCallRecord 和 popCallRecord，分別記錄方法調用的開始時間和結束時間，這樣才能夠在開始時對深度加一、在結束時減一。

//開始時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;}//結束時static inline CallRecord * popCallRecord(ThreadCallStack *cs) { return \u0026amp;cs-\u0026gt;stack[cs-\u0026gt;index--]; //減少深度}

耗時檢查的完整代碼，你可以在我的開源項目里查看，你可以點擊文稿中的鏈接找到這個項目。在需要檢測耗時時間的地方調用 [SMCallTrace start]，結束時調用 stop 和 save 就可以打印出方法的調用層級和耗時了。你還可以設置最大深度和最小耗時檢測，來過濾不需要看到的信息。

有了這樣一個檢查方法耗時的工具，你就可以在每個版本開發結束后執行一次檢查，統計總耗時以及啟動階段每個方法的耗時，有針對性地觀察啟動速度慢的問題。如果你在線上做個灰度開關，還可以監控線上啟動慢的一些特殊情況。

接下來，我們小結一下今天的主要內容

啟動速度優化和監控的重要性不言而喻，加快 App 的啟動速度對用戶的體驗提升是最大的。

啟動速度的優化也有粗有細：粗上來講，這需要對啟動階段功能進行分類整理，合理地將和首屏無關的功能滯后，放到首屏渲染完成之后，保證大頭兒沒有問題；細的來講，這就需要些匠人精神，使用合適的工具，針對每個方法進行逐個分析、優化，每個階段都做到極致。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。