<article class="_2rhmJa">
在 WWDC 2016 和 2017 都有提到啟動(dòng)這塊的原理和性能優(yōu)化思路，可見(jiàn)啟動(dòng)時(shí)間拌阴，對(duì)于開(kāi)發(fā)者和用戶們來(lái)說(shuō)是多么的重要称龙，本文就談?wù)勅绾尉_的度量 App 的啟動(dòng)時(shí)間，啟動(dòng)時(shí)間由 main 之前的啟動(dòng)時(shí)間和 main 之后的啟動(dòng)時(shí)間兩部分組成涕侈。
圖是 Apple 在 WWDC 上展示的 PPT，是對(duì) main 之前啟動(dòng)所做事的一個(gè)簡(jiǎn)單總結(jié)煤辨。main 之后的啟動(dòng)時(shí)間如何考量呢裳涛？這個(gè)更多靠大家自己定義，有的人把 main 到 didFinishLaunching 結(jié)束的這一段時(shí)間作為指標(biāo)众辨，有的人把 main 到第一個(gè) ViewController 的 viewDidAppear 作為考量指標(biāo)端三。不管如何，我覺(jué)得都是一定程度上可以反映問(wèn)題的鹃彻。
Xcode 測(cè)量 pre-main 時(shí)間
對(duì)于如何測(cè)試啟動(dòng)時(shí)間技肩，Xcode 提供了一個(gè)很贊的方法，只需要在 Edit scheme -> Run -> Arguments 中將環(huán)境變量 DYLD_PRINT_STATISTICS 設(shè)為 1浮声，就可以看到 main 之前各個(gè)階段的時(shí)間消耗。
Total pre-main time: 341.32 milliseconds (100.0%)
dylib loading time: 154.88 milliseconds (45.3%)
rebase/binding time: 37.20 milliseconds (10.8%)
ObjC setup time: 52.62 milliseconds (15.4%)
initializer time: 96.50 milliseconds (28.2%)
slowest intializers :
libSystem.dylib : 4.07 milliseconds (1.1%)
libMainThreadChecker.dylib : 30.75 milliseconds (9.0%)
AFNetworking : 19.08 milliseconds (5.5%)
LDXLog : 10.06 milliseconds (2.9%)
Bigger : 7.05 milliseconds (2.0%)
還有一個(gè)方法獲取更詳細(xì)的時(shí)間旋奢，只需將環(huán)境變量 DYLD_PRINT_STATISTICS_DETAILS 設(shè)為 1 就可以泳挥。
total time: 1.0 seconds (100.0%)
total images loaded: 243 (0 from dyld shared cache)
total segments mapped: 721, into 93608 pages with 6173 pages pre-fetched
total images loading time: 817.51 milliseconds (78.3%)
total load time in ObjC: 63.02 milliseconds (6.0%)
total debugger pause time: 683.67 milliseconds (65.5%)
total dtrace DOF registration time: 0.07 milliseconds (0.0%)
total rebase fixups: 2,131,938
total rebase fixups time: 37.54 milliseconds (3.5%)
total binding fixups: 243,422
total binding fixups time: 29.60 milliseconds (2.8%)
total weak binding fixups time: 1.75 milliseconds (0.1%)
total redo shared cached bindings time: 29.32 milliseconds (2.8%)
total bindings lazily fixed up: 0 of 0
total time in initializers and ObjC +load: 93.76 milliseconds (8.9%)
libSystem.dylib : 2.58 milliseconds (0.2%)
libBacktraceRecording.dylib : 3.06 milliseconds (0.2%)
CoreFoundation : 1.85 milliseconds (0.1%)
Foundation : 2.61 milliseconds (0.2%)
libMainThreadChecker.dylib : 42.73 milliseconds (4.0%)
ModelIO : 1.93 milliseconds (0.1%)
AFNetworking : 18.76 milliseconds (1.7%)
LDXLog : 9.46 milliseconds (0.9%)
libswiftCore.dylib : 1.16 milliseconds (0.1%)
libswiftCoreImage.dylib : 1.51 milliseconds (0.1%)
Bigger : 3.91 milliseconds (0.3%)
Reachability : 1.48 milliseconds (0.1%)
ReactiveCocoa : 1.56 milliseconds (0.1%)
SDWebImage : 1.41 milliseconds (0.1%)
SVProgressHUD : 1.23 milliseconds (0.1%)
total symbol trie searches: 133246
total symbol table binary searches: 0
total images defining weak symbols: 30
total images using weak symbols: 69
線上如何度量 pre-main 時(shí)間
如果不依靠 Xcode 我們也是可以對(duì) main 之前的時(shí)間進(jìn)行一個(gè)考量的。當(dāng)然至朗，這個(gè)時(shí)間的度量更多關(guān)注的是開(kāi)發(fā)者可控的啟動(dòng)段姜挺。也就是第一個(gè)圖展示的 Initializer 段热康，在這段時(shí)間里處理 C++ 靜態(tài)對(duì)象的 initializer、ObjC Load 方法的執(zhí)行。
度量 ObjC Load 方法
如何計(jì)算這一段時(shí)間呢茶凳？最容易想到的就是攔截打點(diǎn)，如何攔截成為難點(diǎn)响禽。這里把目光轉(zhuǎn)向 dyld 源碼并村，看看有什么發(fā)現(xiàn)。整個(gè)初始化過(guò)程都是從 initializeMainExecutable 方法開(kāi)始的腾啥。dyld 會(huì)優(yōu)先初始化動(dòng)態(tài)庫(kù)东涡，然后初始化 App 的可執(zhí)行文件。
void initializeMainExecutable()
{
// record that we've reached this step
gLinkContext.startedInitializingMainExecutable = true;
// run initialzers for any inserted dylibs
ImageLoader::InitializerTimingList initializerTimes[allImagesCount()];
initializerTimes[0].count = 0;
const size_t rootCount = sImageRoots.size();
if ( rootCount > 1 ) {
for(size_t i=1; i < rootCount; ++i) {
sImageRoots[i]->runInitializers(gLinkContext, initializerTimes[0]);
}
}
// run initializers for main executable and everything it brings up
sMainExecutable->runInitializers(gLinkContext, initializerTimes[0]);
那么不難想到倘待，只要在動(dòng)態(tài)庫(kù)的 load 函數(shù)中 Hook App 中所有的 Load 函數(shù)疮跑，然后打點(diǎn)就可以啦。但是凸舵，現(xiàn)在很多項(xiàng)目庫(kù)都是使用 Cocoapods 管理的祖娘，并且很多都使用了 use_frameworks，那么也就是說(shuō)我們的 App 并不是一個(gè) 單一的可執(zhí)行文件啊奄，它是有主 image 文件和很多動(dòng)態(tài)庫(kù)共同組成的渐苏。按照剛才那種方法掀潮，是沒(méi)辦法統(tǒng)計(jì)到自己引入的動(dòng)態(tài)庫(kù)的 load 函數(shù)的執(zhí)行時(shí)間的。下一步要考慮的就是整以，如何找到最早加載的動(dòng)態(tài)庫(kù)呢胧辽？然后在其 load 函數(shù)中做 Hook 就可以。
動(dòng)態(tài)庫(kù)的 load 順序是與 Load Commands 順序和依賴關(guān)系息息相關(guān)的公黑。如圖所示：
就拿我們引入的動(dòng)態(tài)庫(kù)來(lái)說(shuō)邑商， AFNetworking 會(huì)優(yōu)先 load ，被依賴的動(dòng)態(tài)庫(kù)會(huì)優(yōu)先 load凡蚜。下面是我自己打點(diǎn)測(cè)試的結(jié)果人断，LDXlog 被 Bigger 依賴，所以 AFNetworking 最早 load 朝蜘，然后是 LDXlog恶迈，依次按照 Load Commands 順序加載。
2017-09-23 13:45:01.683817+0800 AAALoadHook[27267:1585198] AFNetworking
2017-09-23 13:45:01.696816+0800 AAALoadHook[27267:1585198] LDXLog
2017-09-23 13:45:01.707312+0800 AAALoadHook[27267:1585198] Bigger
2017-09-23 13:45:01.708875+0800 AAALoadHook[27267:1585198] Reachability
2017-09-23 13:45:01.710732+0800 AAALoadHook[27267:1585198] REACtive
2017-09-23 13:45:01.712066+0800 AAALoadHook[27267:1585198] SDWE
2017-09-23 13:45:01.713650+0800 AAALoadHook[27267:1585198] SVProgressHUD
2017-09-23 13:45:01.714499+0800 AAALoadHook[27267:1585198] 我是主工程
上面的測(cè)試讓我產(chǎn)生一個(gè)錯(cuò)覺(jué)谱醇，以為動(dòng)態(tài)庫(kù)加載是和字母順序相關(guān)的暇仲，其實(shí)并不是這樣，因?yàn)槲沂褂玫亩际?pod 管理的動(dòng)態(tài)庫(kù)副渴，這個(gè)順序被 CocoaPods 排序過(guò)了奈附，所以才會(huì)有如此結(jié)果。在此感謝@冬瓜@monkey的干貨解答煮剧。
也就是說(shuō)斥滤，只要把我們的統(tǒng)計(jì)庫(kù)命名為 A 開(kāi)頭的庫(kù)（我們的庫(kù)目前均使用 pod 管理），并在內(nèi)部加入打點(diǎn)就可以啦勉盅。再次總結(jié)下整體的思路：
- 找到最早 load 的動(dòng)態(tài)庫(kù)
- 在 load 函數(shù)中獲取 App 中的所有可執(zhí)行文件
- hook 對(duì)應(yīng)的可執(zhí)行文件的 load 函數(shù)
- 統(tǒng)計(jì)每個(gè) load 函數(shù)的時(shí)間佑颇、全部 load 函數(shù)的整體時(shí)間
- 上報(bào)統(tǒng)計(jì)分析
由于代碼比較多，粘貼過(guò)來(lái)的話博客太長(zhǎng)了草娜，所以想了解源碼的話挑胸，可以點(diǎn)擊這個(gè)鏈接：https://github.com/joy0304/JoyDemo/tree/master/HookLoad
剛才的統(tǒng)計(jì)還有一些要注意的事項(xiàng)，就是不能為了統(tǒng)計(jì)性能宰闰，自己卻造成了性能問(wèn)題嗜暴，獲取所有的類并且 Hook load 函數(shù)還是比較耗時(shí)的，控制不好反而增加了啟動(dòng)時(shí)間议蟆。
度量 C++ Static Initializers
剛才提到了初始化的入口是 initializeMainExecutable闷沥，該函數(shù)會(huì)執(zhí)行 ImageLoader::runInitializers 方法，然后會(huì)調(diào)用 ImageLoader::doInitialization咐容，最后會(huì)執(zhí)行到 doModInitFunctions 方法舆逃。
void ImageLoaderMachO::doModInitFunctions(const LinkContext& context)
{
if ( fHasInitializers ) {
const uint32_t cmd_count = ((macho_header*)fMachOData)->ncmds;
const struct load_command* const cmds = (struct load_command*)&fMachOData[sizeof(macho_header)];
const struct load_command* cmd = cmds;
for (uint32_t i = 0; i < cmd_count; ++i) {
if ( cmd->cmd == LC_SEGMENT_COMMAND ) {
const struct macho_segment_command* seg = (struct macho_segment_command*)cmd;
const struct macho_section* const sectionsStart = (struct macho_section*)((char*)seg + sizeof(struct macho_segment_command));
const struct macho_section* const sectionsEnd = §ionsStart[seg->nsects];
for (const struct macho_section* sect=sectionsStart; sect < sectionsEnd; ++sect) {
const uint8_t type = sect->flags & SECTION_TYPE;
if ( type == S_MOD_INIT_FUNC_POINTERS ) {
Initializer* inits = (Initializer*)(sect->addr + fSlide);
const size_t count = sect->size / sizeof(uintptr_t);
for (size_t j=0; j < count; ++j) {
Initializer func = inits[j];
// <rdar://problem/8543820&9228031> verify initializers are in image
if ( ! this->containsAddress((void*)func) ) {
dyld::throwf("initializer function %p not in mapped image for %s\n", func, this->getPath());
}
func(context.argc, context.argv, context.envp, context.apple, &context.programVars);
}
}
}
}
cmd = (const struct load_command*)(((char*)cmd)+cmd->cmdsize);
}
}
}
這段代碼實(shí)在是長(zhǎng)，它會(huì)從 mod_init_func 這個(gè) section 中讀取所有的函數(shù)指針，然后執(zhí)行函數(shù)調(diào)用路狮，這些函數(shù)指針對(duì)應(yīng)的正是我們的 C++ Static Initializers 和 __attribute__((constructor))修飾的函數(shù)虫啥。
因?yàn)樗鼈兊膱?zhí)行順序在 load 函數(shù)之后，所以可以在 load 函數(shù)中把 mod_init_func 中的地址都替換成我們的 hook 函數(shù)指針奄妨，然后再把原函數(shù)指針保存到一個(gè)全局?jǐn)?shù)據(jù)中涂籽，當(dāng)執(zhí)行我們的 hook 函數(shù)時(shí)，從全局?jǐn)?shù)組中取出原函數(shù)地址執(zhí)行砸抛。在這里張貼下主要代碼评雌，更多可以參考這個(gè)鏈接：https://github.com/everettjf/Yolo/blob/master/HookCppInitilizers/hook_cpp_init.mm
void myInitFunc_Initializer(int argc, const char* argv[], const char* envp[], const char* apple[], const struct MyProgramVars* vars){
++g_cur_index;
OriginalInitializer func = (OriginalInitializer)g_initializer->at(g_cur_index);
CFTimeInterval start = CFAbsoluteTimeGetCurrent();
func(argc,argv,envp,apple,vars);
CFTimeInterval end = CFAbsoluteTimeGetCurrent();
}
static void hookModInitFunc(){
Dl_info info;
dladdr((const void *)hookModInitFunc, &info);
#ifndef __LP64__
const struct mach_header *mhp = (struct mach_header*)info.dli_fbase;
unsigned long size = 0;
MemoryType *memory = (uint32_t*)getsectiondata(mhp, "__DATA", "__mod_init_func", & size);
#else
const struct mach_header_64 *mhp = (struct mach_header_64*)info.dli_fbase;
unsigned long size = 0;
MemoryType *memory = (uint64_t*)getsectiondata(mhp, "__DATA", "__mod_init_func", & size);
#endif
for(int idx = 0; idx < size/sizeof(void*); ++idx){
MemoryType original_ptr = memory[idx];
g_initializer->push_back(original_ptr);
memory[idx] = (MemoryType)myInitFunc_Initializer;
}
}
剛才 hook load 函數(shù)時(shí)遇到的問(wèn)題，對(duì)于 C++ Static Initializers 會(huì)不會(huì)存在呢直焙？是存在的景东，我想要在一個(gè)動(dòng)態(tài)庫(kù)中統(tǒng)計(jì) App 中所有可執(zhí)行文件的 C++ Static Initializers 的執(zhí)行時(shí)間，但是 dyld 中有這么一段代碼：
if ( type == S_MOD_INIT_FUNC_POINTERS ) {
Initializer* inits = (Initializer*)(sect->addr + fSlide);
const size_t count = sect->size / sizeof(uintptr_t);
for (size_t j=0; j < count; ++j) {
Initializer func = inits[j];
// <rdar://problem/8543820&9228031> verify initializers are in image
if ( ! this->containsAddress((void*)func) ) {
dyld::throwf("initializer function %p not in mapped image for %s\n", func, this->getPath());
}
func(context.argc, context.argv, context.envp, context.apple, &context.programVars);
}
}
if ( ! this->containsAddress((void*)func) ) 這里會(huì)做一個(gè)判斷奔誓，判斷函數(shù)地址是否在當(dāng)前 image 的地址空間中斤吐，因?yàn)槲覀兪窃谝粋€(gè)獨(dú)立的動(dòng)態(tài)庫(kù)中做函數(shù)地址替換，替換后的函數(shù)地址都是我們動(dòng)態(tài)庫(kù)中的厨喂，并沒(méi)有在其他 image 中和措，所以當(dāng)其他 image 執(zhí)行到這個(gè)判斷時(shí)，就拋出了異常蜕煌。這個(gè)問(wèn)題好像無(wú)解派阱，所以我們的 C++ Static Initializers 時(shí)間統(tǒng)計(jì)稍有不足。
Xcode For Static Initializers
Apple 在 https://developer.apple.com/videos/play/wwdc2017/413/ 中公布了一個(gè)新的追蹤 Static Initializers 時(shí)間消耗的方案幌绍， Instruments 增加了一個(gè)叫做 Static Initializer Tracing 的工具，可以方便排查每個(gè) Static Initializer 的時(shí)間消耗故响。（我還沒(méi)更新最新版本傀广，暫不實(shí)踐）
main 之后的時(shí)間度量
main 到 didFinishLaunching 結(jié)束或者第一個(gè) ViewController 的viewDidAppear 都是作為 main 之后啟動(dòng)時(shí)間的一個(gè)度量指標(biāo)。這個(gè)時(shí)間統(tǒng)計(jì)直接打點(diǎn)計(jì)算就可以彩届，不過(guò)當(dāng)遇到時(shí)間較長(zhǎng)需要排查問(wèn)題時(shí)伪冰，只統(tǒng)計(jì)兩個(gè)點(diǎn)的時(shí)間其實(shí)不方便排查，目前見(jiàn)到比較好用的方式就是為把啟動(dòng)任務(wù)規(guī)范化樟蠕、粒子化贮聂，針對(duì)每個(gè)任務(wù)都有打點(diǎn)統(tǒng)計(jì)，這樣方便后期問(wèn)題的定位和優(yōu)化寨辩。
優(yōu)化吓懈？
其實(shí)優(yōu)化的，很多公司都有博客寫道靡狞。既然談到了啟動(dòng)監(jiān)控就稍微寫一點(diǎn)個(gè)人覺(jué)得比較使用的優(yōu)化方案吧耻警。
- 目前很多項(xiàng)目使用 use_frameworks 的 pod 動(dòng)態(tài)庫(kù)，系統(tǒng)的動(dòng)態(tài)庫(kù)有共享緩存等優(yōu)化方案，但是我們的動(dòng)態(tài)庫(kù)變多了的話會(huì)非常耗時(shí)甘穿，所以合并動(dòng)態(tài)庫(kù)是一個(gè)有效且可行的方案
- 把啟動(dòng)任務(wù)細(xì)分腮恩，不需要及時(shí)初始化，不需要在主線程初始化的温兼，都選擇異步延時(shí)加載
- 監(jiān)控好 load 和 Static Initializers 的時(shí)間消耗秸滴，一不小心就容易出現(xiàn)幾百毫秒的時(shí)間消耗
- 還有很多其他公司實(shí)踐的方案，我都收集了下來(lái)募判，可以參考：https://github.com/joy0304/Joy-Blog/blob/master/iOSCollection.md
</article>
167人點(diǎn)贊
轉(zhuǎn)自 Joy___
鏈接：http://www.reibang.com/p/c14987eee107
