无码熟妇人妻av又大又粗,熟女久久久久久久久久久 ,国产女主播精品大秀系列

App啟動優化之二進制重排

如果要問2019年年底iOS最熱門技術是哪些，那當然是少不了8月底抖音發布一篇關于啟動優化的文章，其原理文章也說得蠻清楚的。鏈接如下：

簡單總結就是

二進制重排優化的是pre-main之前的時間
因為Mach-O文件的時候是分頁加載的，當用到某頁數據時才會去加載（類似懶加載），當進程訪問一個虛擬內存Page而對應的物理內存卻不存在時(例如函數和方法)，就會產生Page Fault（缺頁中斷）去加載該頁，雖然中斷時間很短，但是當page fault次數龐大時，耗時比想象的更多，而且通過App Store渠道分發的App，Page Fault還會進行簽名驗證。

查看pre-main耗時

可以通過給xcode設置參數來查看pre-main耗時檢測

具體操作如下

Edit Scheme -- 選擇一個Scheme（比如：Run）-- 選擇Arguments -- Environment Variables -- 點擊添加 -- 設置 name： DYLD_PRINT_STATISTICS value ： 1

1.png

啟動app可以看到以下打印

pre-main time: 1.3 seconds (100.0%)
dylib loading time: 161.47 milliseconds (12.2%)
rebase/binding time:  25.11 milliseconds (1.8%)
ObjC setup time: 444.37 milliseconds (33.5%)
initializer time: 691.82 milliseconds (52.2%)

從打印可以看出pre-main之前的耗時操作有如下這些：

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

那我們的優化方案可以從以下幾方面入手：

減少動態庫的個數，如果太多就使用合并的方式控制，這樣可以節約dylib loading及rebase/binding的時間
清理項目中未用到的類、類別、方法等，這樣可以節約Objc setup的時間
對于可以不在+load中處理的邏輯可以放到其他的函數中去處理，比如：+initialize；控制 C++ 全局變量的數量；這樣可以節約initializer的時間

除了以上優化手段，我們還可以借助LLVM為我們提供的優化方式，也就是今天的主題：二進制重排

查看app啟動產生的Page Faults

打開xcode的Instruments，選擇System Trace工具

2.png

重排

編譯器在生成二進制代碼的時候，默認按照鏈接的Object File(.o)順序寫文件，按照Object File內部的函數順序寫函數。（靜態庫文件.a就是一組.o文件的ar包，可以用ar -t查看.a包含的所有.o）

3.png

上圖，假設我們只有兩個page：page1/page2，其中綠色的method1和method3啟動時候需要調用，為了執行對應的代碼，系統必須進行兩個Page Fault。

優化：如果我們把method1和method3排布到一起，那么只需要一個Page Fault即可，這就是二進制文件重排的核心原理，如下圖

4.png

Xcode相關配置

order file文件路徑設置

有了上面的理論知識，那么我們需要將啟動時候調用的函數進行重排，讓它們盡可能的分配在同一個頁。比如load方法我們就將其找出來，放到一起。LLVM支持我們通過設置order來達到這個效果，如下圖

5.png

至于order file的文件內容是那些啟動時候需要調用的函數和方法，如下圖

6.png

看到這里你可能會有疑問，我們如何知道啟動時需要調用那些函數和方法呢？其實這也是二進制重排最難的地方。方法很多，抖音的文章也詳細說了，我們今天采用終極方案clang全局靜態插樁方法，下面會詳說。

Write Link Map File設置

這個主要是用來描述可執行文件的構造部分，包括了代碼段和數據段的分布情況。一句話總結就是能查看函數、方法的內存順序，我們重排的就是這些順序。 具體設置如下圖

7.png

設置完成后command + b編譯一下，再去對應的路徑就能看到生成的mapFile文件，直接打開（或者借助第三庫界面工具Link Map打開），如圖：

8.png

從mapFile可以看到load等啟動時需要調用的方法和函數分散得很開，當啟動執行的方法和函數很多時，那就可能分散在不同的頁。待會我們重排完之后再回來對比看重排前和重排后的區別。

clang全局靜態插樁

現在我們開始獲取啟動時候調用的所有函數和方法

clang官方文檔

首先在主項目Target--Build Settings中添加編譯選項

Other C Flags增加-fsanitize-coverage=func,trace-pc-guard，添加完之后編譯時編譯器會幫我們在所有函數和方法（包括block）中插入調用__sanitizer_cov_trace_pc_guard函數的代碼。如下圖：

9.png

（添加完-fsanitize-coverage=func,trace-pc-guard選項后，如果不添加下面這段代碼的話，就會編譯錯誤，原因就是找不到__sanitizer_cov_trace_pc_guard_init和__sanitizer_cov_trace_pc_guard）

那么我們只要在__sanitizer_cov_trace_pc_guard函數搞事情就好，代碼如下（把以下代碼復制到項目，我復制到工程首頁類）：


#import <dlfcn.h>
#import <libkern/OSAtomic.h>

//原子隊列
static  OSQueueHead symbolList = OS_ATOMIC_QUEUE_INIT;

//定義符號結構體
typedef struct {
    void *pc;
    void *next;
}CKNode;

void __sanitizer_cov_trace_pc_guard_init(uint32_t *start, uint32_t *stop)
{
  static uint64_t N;  // Counter for the guards.
  if (start == stop || *start) return;  // Initialize only once.
  printf("INIT: %p %p\n", start, stop);
  for (uint32_t *x = start; x < stop; x++)
    *x = ++N;  // Guards should start from 1.
}

void __sanitizer_cov_trace_pc_guard(uint32_t *guard)
{
    // 這個打開了就會跳過load方法
    //if (!*guard) return; 
    //利用__builtin_return_address(0)來獲得當前函數返回地址，也就是調用方的地址。
    void *PC = __builtin_return_address(0);
    CKNode *node = malloc(sizeof(CKNode));
    *node = (CKNode){PC,NULL};
    //進入
    OSAtomicEnqueue(&symbolList, node, offsetof(CKNode, next));
}

//只是為了方便隨便放置
-(void)viewDidAppear:(BOOL)animated
{
    [super viewDidAppear:animated];
    [self getOrderFile];
}

//保存orderFile文件
-(void)getOrderFile
{
    NSMutableArray <NSString *> * symbolNames = [NSMutableArray array];
    while (YES) {
        CKNode * node = OSAtomicDequeue(&symbolList, offsetof(CKNode, next));
        if (node == NULL) {
            break;
        }
        Dl_info info;
        //通過dladdr來將指針解析成Dl_info結構體信息
        dladdr(node->pc, &info);
        NSString * name = @(info.dli_sname);
        BOOL  isObjc = [name hasPrefix:@"+["] || [name hasPrefix:@"-["];
        NSString * symbolName = isObjc ? name: [@"_" stringByAppendingString:name];
        [symbolNames addObject:symbolName];
    }
    //逆序
    NSEnumerator * emt = [symbolNames reverseObjectEnumerator];
    //去重
    NSMutableArray<NSString *> *funcs = [NSMutableArray arrayWithCapacity:symbolNames.count];
    NSString * name;
    while (name = [emt nextObject]) {
        if (![funcs containsObject:name]) {
            [funcs addObject:name];
        }
    }

    //去掉本次方法調用的方法名
    [funcs removeObject:[NSString stringWithFormat:@"%s",__FUNCTION__]];
    NSString * funcStr = [funcs  componentsJoinedByString:@"\n"];
    NSString * filePath = [NSTemporaryDirectory() stringByAppendingPathComponent:@"ckTest.order"];
    NSData * fileContents = [funcStr dataUsingEncoding:NSUTF8StringEncoding];
    [[NSFileManager defaultManager] createFileAtPath:filePath contents:fileContents attributes:nil];
    NSLog(@"%@",funcStr);
}

/** 代碼相關細節總結：
    1、增加-fsanitize-coverage=func,trace-pc-guard，添加完之后編譯時編譯器會幫我們在所有函數和方法（包括block）中插入調用`__sanitizer_cov_trace_pc_guard`函數的代碼。
    2、利用__builtin_return_address(0)來獲得當前函數返回地址，也就是調用方的地址。
    3、通過dladdr來將指針解析成Dl_info結構體信息，其中dli_sname就是符號的名稱。

    typedef struct dl_info {
        const char      *dli_fname;    /* Pathname of shared object */
        void            *dli_fbase;    /* Base address of shared object */
        const char      *dli_sname;    /* Name of nearest symbol */
        void            *dli_saddr;    /* Address of nearest symbol */
    } Dl_info;
*/

執行以上代碼最后會在app的沙盒的tmp目錄下生成orderFile文件（需要改路徑的可以自己修改一下代碼），打開查看，如下圖

10.png

有了這份orderFile文件，我們可以去xcode里設置（就是按照上面說的xcode相關配置 -> 1. order file文件路徑設置）。

設置完，再編譯下，再看下link map file文件，如圖

11.png

接著我們看下重排后的Page Fault耗時和pre-main的時間

12.png

從上圖可以看到page Fault的次數從3000+減少到2000+，時間從900+ms到400+ms

再看下pre-main

Total pre-main time: 926.43 milliseconds (100.0%)
dylib loading time: 150.69 milliseconds (16.2%)
rebase/binding time:  32.49 milliseconds (3.5%)
ObjC setup time:  88.75 milliseconds (9.5%)
initializer time: 654.27 milliseconds (70.6%)

跟之前的1.3s對比明顯優化了0.4s左右（可能我用來測試的項目類比較多），效果還是挺明顯的，但是這個時間每次都是有差異的，只能算大概。

注意事項說明

因為優化都是毫秒級別的，所以可能很難從肉眼上面看出來。
優化效果跟項目"大小"有關。
主要優化的是“冷啟動”，平常我們認為把app從后臺刪掉，再重新啟動就是冷啟動，但是如果從“從后臺刪掉”到“重新啟動”這中間時間間隔短的話，其實app的數據還是在內存里，這時候啟動會很快，因為app數據還在內存里（通過Page Fault的次數就能證明），所以要想更好的測試重排優化的時間，建議把app從后臺刪掉后，多開幾個其他的app后，再去啟動你要測試的app，這時再去看Page Fault耗時和pre-main的時間。
我們剛才hook的只是我們工程的那些源碼文件，像靜態庫那些已經編譯好的庫，我們是沒有hook的，也就是說想要做到極致，也要把靜態庫那些重排，但是這個可能比較難，因為有可能靜態庫那些是別人提供的。
上面page fault的優化時間跟pre-main實際打印的時間有差異，感覺以pre-main實際加載的時間為準好點。
orderFile里面列舉的方法和函數名稱如果在源碼里找不到對應的方法和函數也是沒關系的，編譯器會直接忽略這些，clang還是很智能的。
每次時間都會有差異，只能大概估算。
文章很多內容都是從其他博客借鑒的，本文只是把個人覺得好的那些湊在一塊，簡單總結下，如有錯請指正，不喜勿噴，謝謝。

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频

iOS啟動優化之二進制重排

iOS啟動優化之二進制重排

App啟動優化之二進制重排

簡單總結就是

查看pre-main耗時

那我們的優化方案可以從以下幾方面入手：

查看app啟動產生的Page Faults

重排

Xcode相關配置

clang全局靜態插樁

注意事項說明

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美 国产 综合 欧美 视频

iOS啟動優化之二進制重排

App啟動優化之二進制重排

簡單總結就是

查看pre-main耗時

那我們的優化方案可以從以下幾方面入手：

查看app啟動產生的Page Faults

重排

Xcode相關配置

clang全局靜態插樁

注意事項說明

三个男躁一个女,国精产品一区一手机的秘密,麦子交换系列最经典十句话,欧美国产综合欧美视频