iOS深思篇 | 啓動時間的度量和優化

時間 2019-11-08

標籤 ios 深思啓動時間度量優化欄目 iOS 简体版

原文原文鏈接

一. 簡介

App的啓動時間是衡量一個App性能的重要指標，或者能夠說是App性能的第一印象。在這篇文章中，咱們將要介紹啓動時間的相關知識和打點統計。html

二. 啓動優化

2.1 App啓動方式

首先了解一下App的啓動方式分爲兩類：ios

1. 冷啓動：從零開始啓動App
2. 熱啓動：App已經存在內存當中，可是後臺存活着，再次點擊圖標啓動App
複製代碼

以後測試也依照這兩種啓動方式進行測試。通常來講啓動時間（點擊圖標 -> 顯示Launch Screen -> Launch Screen消失）在小於400ms是最佳的，而且系統限制了啓動時間不能夠大於20s，不然會由於watchdog(看門狗)機制被殺掉。在不一樣的生命週期時，超時時間的限制會有所差異：git

生命週期	超時時間
啓動 Launch	20 s
恢復 Resume	10 s
懸掛 Suspend	10 s
退出 Quit	6 s
後臺 Background	10 min

2.2 App啓動流程

啓動流程通常劃分爲pre-main(main函數以前)和main函數以後；github

2.2.1 pre-main

該階段各個時期的任務以及優化方法：web

階段	工做	優化
Load dylibs	Dyld從主執行文件的header獲取到須要加載的所依賴動態庫列表，而後它須要找到每一個 dylib，而應用所依賴的 dylib 文件可能會再依賴其餘 dylib，因此所須要加載的是動態庫列表一個遞歸依賴的集合	1.儘可能不使用內嵌（embedded）的dylib，加載內嵌dylib性能開銷較大；2.合併已有的dylib和使用靜態庫（static archives），減小dylib的使用個數；3.懶加載dylib，可是要注意dlopen()可能形成一些問題，且實際上懶加載作的工做會更多
Rebase和Bind	1. Rebase在Image內部調整指針的指向。在過去，會把動態庫加載到指定地址，全部指針和數據對於代碼都是對的，而如今地址空間佈局是隨機化，因此須要在原來的地址根據隨機的偏移量作一下修正。2. Bind是把指針正確地指向Image外部的內容。這些指向外部的指針被符號(symbol)名稱綁定，dyld須要去符號表裏查找，找到symbol對應的實現	1.減小ObjC類（class）、方法（selector）、分類（category）的數量；2.減小C++虛函數的的數量（建立虛函數表有開銷）；3.使用Swift structs（內部作了優化，符號數量更少）
Objc setup	1.註冊Objc類 (class registration)；2.把category的定義插入方法列表 (category registration)；3.保證每個selector惟一 (selector uniquing)	減小 Objective-C Class、Selector、Category 的數量，能夠合併或者刪減一些OC類
Initializers	1.Objc的+load()函數；2.C++的構造函數屬性函數；3.非基本類型的C++靜態全局變量的建立(一般是類或結構體)	1.少在類的+load方法裏作事情，儘可能把這些事情推遲到+initiailize；2.減小構造器函數個數，在構造器函數裏少作些事情；3.減小C++靜態全局變量的個數

對於pre-main階段，Xcode提供了各個階段時間消耗的方法， Product -> Scheme -> Edit Scheme -> Environment Variables 中將環境變量 DYLD_PRINT_STATISTICS設爲1;api

Total pre-main time: 955.81 milliseconds (100.0%)
         dylib loading time:  97.42 milliseconds (10.1%)
        rebase/binding time:  55.08 milliseconds (5.7%)
            ObjC setup time:  68.65 milliseconds (7.1%)
           initializer time: 734.45 milliseconds (76.8%)
           slowest intializers :
             libSystem.B.dylib :   7.65 milliseconds (0.8%)
    libMainThreadChecker.dylib :  36.33 milliseconds (3.8%)
                              ...
複製代碼

這裏額外補充一下其餘的dyld環境變量參數：性能優化

變量	描述
DYLD_PRINT_STATISTICS_DETAILS	打印啓動時間等詳細參數
DYLD_PRINT_SEGMENTS	日誌段映射
DYLD_PRINT_INITIALIZERS	日誌圖像初始化要求
DYLD_PRINT_BINDINGS	日誌符號綁定
DYLD_PRINT_APIS	日誌dyld API調用(例如，dlopen)
DYLD_PRINT_ENV	打印啓動環境變量
DYLD_PRINT_OPTS	打印啓動時命令行參數
DYLD_PRINT_LIBRARIES_POST_LAUNCH	日誌庫加載，但僅在main運行以後
DYLD_PRINT_LIBRARIES	日誌庫加載
DYLD_IMAGE_SUFFIX	首先搜索帶有這個後綴的庫

這個方法確實很方便，可是咱們若是想要本身度量per-main階段的時間消耗，又如何統計呢？因爲咱們主要針對冷啓動進行優化，就先介紹一下冷啓動的流程： bash

能夠將其概括爲三個階段：架構

1. dyld：加載鏡像，動態庫
2. RunTime方法
3. main函數初始化
複製代碼

從圖中能夠看出開發者在main以前能夠處理的是Run Image Initializers階段（對應Apple展現圖中的initializers階段），load加載、__attribute__((constructor))和C++靜態對象初始化;app

load耗時監測

想知道load方法執行的時間，就不可避免的須要獲取+load類和分類的方法。目前我瞭解到的也是有兩種，一種是經過runtime api，去讀取對應鏡像下全部類及其元類，並逐個遍歷元類的實例方法，若是方法名稱爲load，則執行hook操做，表明庫是AppStartTime；一種是和 runtime同樣，直接經過getsectiondata函數，讀取編譯時期寫入mach-o文件DATA段的__objc_nlclslist和 __objc_nlcatlist節，這兩節分別用來保存no lazy class列表和no lazy category列表，所謂的no lazy結構，就是定義了+load方法的類或分類，表明庫是A4LoadMeasure。

先說一下兩種方案對比結果：

庫	load偏差	統計範圍
AppStartTime	100ms左右	類
A4LoadMeasure	50ms左右	類和分類

從測試結果來看，固然咱們會選擇後者，還統計了分類load加載。並且從性能上看，前者會for循環調用object_getClass()方法，該方法會觸發類的realize 操做，給類開闢可讀寫的信息存儲空間、調整成員變量佈局、插入分類方法屬性等操做，簡單來講就是讓類變成可用(realized)狀態，這樣當有大量的類進行該操做時，會額外增長per-main時間，形成沒必要要的開銷。

//獲取no lazy class 列表和 no lazy category 列表
static NSArray <LMLoadInfo *> *getNoLazyArray(const struct mach_header *mhdr) {
    NSMutableArray *noLazyArray = [NSMutableArray new];
    unsigned long bytes = 0;
    Class *clses = (Class *)getDataSection(mhdr, "__objc_nlclslist", &bytes);
    for (unsigned int i = 0; i < bytes / sizeof(Class); i++) {
        LMLoadInfo *info = [[LMLoadInfo alloc] initWithClass:clses[i]];
        if (!shouldRejectClass(info.clsname)) [noLazyArray addObject:info];
    }
    
    bytes = 0;
    Category *cats = getDataSection(mhdr, "__objc_nlcatlist", &bytes);
    for (unsigned int i = 0; i < bytes / sizeof(Category); i++) {
        LMLoadInfo *info = [[LMLoadInfo alloc] initWithCategory:cats[i]];
        if (!shouldRejectClass(info.clsname)) [noLazyArray addObject:info];
    }
    
    return noLazyArray;
}

//hook 類和分類的 +load 方法
static void hookAllLoadMethods(LMLoadInfoWrapper *infoWrapper) {
    unsigned int count = 0;
    Class metaCls = object_getClass(infoWrapper.cls);
    Method *methodList = class_copyMethodList(metaCls, &count);
    for (unsigned int i = 0, j = 0; i < count; i++) {
        Method method = methodList[i];
        SEL sel = method_getName(method);
        const char *name = sel_getName(sel);
        if (!strcmp(name, "load")) {
            LMLoadInfo *info = nil;
            if (j > infoWrapper.infos.count - 1) {
                info = [[LMLoadInfo alloc] initWithClass:infoWrapper.cls];
                [infoWrapper insertLoadInfo:info];
                LMAllLoadNumber++;
            } else {
                info = infoWrapper.infos[j];
            }
            ++j;
            swizzleLoadMethod(infoWrapper.cls, method, info);
        }
    }
    free(methodList);
}
複製代碼

Tip: 這裏說明一個問題，A4LoadMeasure用LMAllLoadNumber定位最後一次打印有計算偏差，稍微取巧了一下，改成在主線程獲取，具體可查看demo;

attribute((constructor))和C++對象靜態初始化

__attribute__是GNU C特點的一個編譯器屬性，能夠經過iOS attribute瞭解一下；它與load,main,initialize的調用順序以下：

load -> attribute((constructor)) -> main -> initialize

好了，接下來，咱們再次對比下這兩個三方庫：

庫	static initialize偏差
AppStartTime	30ms左右
A4LoadMeasure	40ms左右

統計下來，前者數據相對更精確一點，最主要的是打印了方法指針；A4LoadMeasure統計的方案我不敢苟同，只是在__attribute__((constructor))方法做用域先後打點就是C++ Static Initializers端所用時間？這波兒操做看不懂了；獲取__mod_init_func（初始化的全局函數地址）段更值得認同；

簡單介紹下初始化函數大體執行順序以下：

initializeMainExecutable -> ImageLoader::runInitializers -> ImageLoader::doInitialization -> ImageLoaderMachO::doModInitFunctions

最後一個函數是主要處理的邏輯，下面👇附上代碼：

//該函數主要負責處理__DATA下的__mod_init_func
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 = &sectionsStart[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);
        }
    }
}

複製代碼

這裏有一個問題說明下，原文也提到了，if ( ! this->containsAddress((void*)func) )這個判斷函數地址是否在當前image的地址空間中，因爲咱們是在動態庫中作函數地址替換，替換後的函數地址都是動態庫中的了，沒有在其餘 image中，因此當其餘image執行到這個判斷時，就拋出了異常。在demo工程中這個現象還不明顯，當工程架構複雜一些，這個問題就比較明顯了；

三. 工程說明

目前工程已支持pod引入:

pod 'A0PreMainTime'

#******子組件單獨引入***********
#pre-main階段耗時檢測
pod 'A0PreMainTime/PreMainTime'
#業務時間度量
pod 'A0PreMainTime/TimeMonitor'
複製代碼

具體請查看A0PreMainTime

學習：

擴展：

dyld詳解

提交到AppStore問題：不支持的體系結構x86

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。