性能优化

#看这篇就够了--启动优化之二进制重排:理论及实践(附源码)

2021-08-11  本文已影响0人  Aracya

在做二进制重排之前,首先需要了解到几个知识点.例如:物理内存,虚拟内存,内存分页管理

物理内存

早期的操作系统,只有物理内存

当一个应用启动后,会全部加载到内存中,并按照内存真实地址排列

Pasted Graphic 5.png

这样就会面临一些问题,比如:

虚拟内存(官方文档)

MMU把虚拟内存地址ow.png

iOS中,一个虚拟内存与一个进程 一一对应,大小为4G, 虚拟内存里会分为很多页(Page),每页的大小16KB

当有了虚拟内存之后.CPU访问进程数据相对上面的有了变化:

相比早期的纯物理内存,虚拟内存的优势

ASLR (Address Space Layout Randomization)

首先如果没有ASLR,虚拟内存是有安全隐患的

ASLR可以弥补上述的安全缺陷

百度百科上ASLR的解释:(Address Space Layout Randomization ) 地址空间配置随机化;ASLR通过随机放置进程关键数据区域的地址空间来防止攻击者能可靠地跳转到内存的特定位置来利用函数

更直白的解释就如上面提到的:每次启动进程,系统都会重新建立对应的虚拟内存,并为虚拟内存分配一个ASLR随机值(Address Space Layout Randomization),数据的虚拟地址即为:ASLR随机值+偏移值,这样数据的虚拟地址每次都会变

了解上面的知识点后,下面会介绍二进制重排

二进制重排

上面有提到,当加载一个未加载到物理内存的数据时,会触发一个系统中断 (PageFault), 虽然单次耗时是毫秒级,但是有一种情况会出现大量的PageFault,那就是App启动, 通过二进制重排来减少App启动速度的核心就是减少App启动时PageFault的次数

在重排之前,我们可以先通过Link Map文件,来查看我们的项目加入到内存时的默认顺序是什么 (LinkMap记录了二进制文件的布局)

内容如下:


image.png

可以发现这个顺序默认是按照Compile Source的顺序,单个文件内的不同方法是按照代码书写的顺序

另外,我们还可以通过xcode - Instruments - System Trace来查看App启动时的pageFault次数

如截图:(用的是真实项目,项目相关信息打了马赛克)


image.png

这里有个问题:app首次打开的时候Page Fault的次数很多,打开之后再打开的话就比较少,当打开多个其他app的时候,在打开检测的app发现也会有不少Page Faults

这是由于操作系统的机制,当应用杀掉了,他所访问的物理内存不是立马就清空;它所访问的物理内存,需要通过其他app申请开辟覆盖释放掉,

我们要做的就是把启动所需要的代码,放在一起,放在最靠前的位置,减少启动时非必要的pageFault次数.

总结来讲就是以下两点

获取项目中启动时刻所调用的方法顺序

本文采用clang插桩方式:

原理: 在编译时刻,在每个函数内部,都会静态插入方法__sanitizer_cov_trace_pc_guard,然后我们在项目中注册其回调函数,App每次调用方法(包括OC方法,C语言方法,block等所有方法),都会通过__sanitizer_cov_trace_pc_guard来回调,由此我们可以记录App启动时所需的所有方法

build Settings - other c Flags
添加内容为 -fsanitize-coverage=func,trace-pc-guard

注: 官方文档上的-fsanitize-coverage=trace-pc-guard这种方式,会在while循环中同样插入hook代码,多次静态加入__sanitizer_cov_trace_pc_guard调用,导致死循环
所以我们要加func参数,代表只有hook函数时调用
#include <stdint.h>
#include <stdio.h>
#include <sanitizer/coverage_interface.h>
#include <dlfcn.h>

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) {

//    if (!*guard) return;

    void *PC = __builtin_return_address(0);

    Dl_info info;

    dladdr(PC, &info);

    printf("%s\n",info.dli_sname); //打印方法名字
}

image.png

可以通过LLDB来简单调试一下,为了效果明显,可以按照以下操作

可以通过log看到star和stop分别是0x102591898和0x1025918f8.
此时进行memory read,读取一下最后的内存地址里面的内容

(lldb) x 0x1025918f4

这里为什么是0x1025918f8 - 0x4 ?

start.png

start和stop都是uint32_t类型,占4个字节,end指向最后(如图),所以要获取最后一块内存地址中的内容,需要减0x4

如果在这基础上,再添加一个方法之后,同样的操作获取上述图中红框内的数字,我们会发现图中空框内的数字正是方法的数量 (注:红框内的18是16进制,代表有个24个方法)

我们可以添加汇编代码来看一下发生了什么

xcode - Debug - Debug Workflow - Always show Disassembly

给当前viewcontroller添加touchesBegan:withEvent:方法,并在方法内部添加断点,点击屏幕后:

image.png

可以看出已经给touchesBegan:withEvent:注入了方法__sanitizer_cov_trace_pc_guard.
此时如果在touchesBegan:withEvent:方法内部再调用一个方法testMethod(), 通过断点可以看到testMethod()方法内部也会被注入__sanitizer_cov_trace_pc_guard方法.

上述记录的方法是通过NSLog方式来打印的,如果在大型实战项目中,我们可以考虑把方法名字写入到本地文件, 我是参考了iOS启动优化:二进制重排这篇文章的方法,以下是全部代码,可拿来直接用,BinarySortTool.h公开一个类方法+ (void)writeSortedFileMethod;可以在App启动之后调用此方法,来写入文件

//  BinarySortTool.m

//  Created by qwer on 2021/8/10.

#import "BinarySortTool.h"
#include <stdint.h>
#include <stdio.h>
#include <sanitizer/coverage_interface.h>
#include <dlfcn.h>
#import <libkern/OSAtomic.h>

@implementation BinarySortTool

+ (void)writeSortedFileMethod {

    NSMutableArray<NSString *> * symbolNames = [NSMutableArray array];

    while (YES) {

        //offsetof 就是针对某个结构体找到某个属性相对这个结构体的偏移量

        SymbolNode * node = OSAtomicDequeue(&symbolList, offsetof(SymbolNode, next));

        if (node == NULL) break;

        Dl_info info;

        dladdr(node->pc, &info);

        

        NSString * name = @(info.dli_sname);

        

        // 添加 _

        BOOL isObjc = [name hasPrefix:@"+["] || [name hasPrefix:@"-["];

        NSString * symbolName = isObjc ? name : [@"_" stringByAppendingString:name];

        

        //去重

        if (![symbolNames containsObject:symbolName]) {

            [symbolNames addObject:symbolName];

        }

    }

    

    //取反

    NSArray * symbolAry = [[symbolNames reverseObjectEnumerator] allObjects];

    //将结果写入到文件

    NSString * funcString = [symbolAry componentsJoinedByString:@"\n"];

    NSString * filePath = [NSTemporaryDirectory() stringByAppendingPathComponent:@"binary.order"];

    NSData * fileContents = [funcString dataUsingEncoding:NSUTF8StringEncoding];

    BOOL result = [[NSFileManager defaultManager] createFileAtPath:filePath contents:fileContents attributes:nil];

    if (result) {

        NSLog(@"%@",filePath);

    }else{

        NSLog(@"文件写入出错");

    }
}

//原子队列

static OSQueueHead symbolList = OS_ATOMIC_QUEUE_INIT;

//定义符号结构体

typedef struct{

    void * pc;

    void * next;

}SymbolNode;


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;

}

void __sanitizer_cov_trace_pc_guard(uint32_t *guard) {

    //if (!*guard) return;  // Duplicate the guard check.

    void *PC = __builtin_return_address(0);

    SymbolNode * node = malloc(sizeof(SymbolNode));

    *node = (SymbolNode){PC,NULL};

    //入队

    // offsetof 用在这里是为了入队添加下一个节点找到 前一个节点next指针的位置

    OSAtomicEnqueue(&symbolList, node, offsetof(SymbolNode, next));

}

@end


至此,我们会拿到.order的文件,由于项目隐私问题就不提供.order内容的截图了

拿到了.order文件后,就剩下最后一步了

更改App数据加入到内存的顺序

这一步相对上面的操作,就轻松很多了,直接去build settings设置一下order file的路径即可

Pasted Graphic 6.png

到此,启动优化之二进制重排就结束了.我们可以通过上述介绍过的Instruments - System trace来验证一下page fault次数,不过要注意上述提到过当杀死App后,其所对应的物理内存的内容不会立刻被清除的问题,可以尝试多打开几个App后再打开自己的项目,或者清除所有后台然后关机开机.


参考:

抖音研发实践:基于二进制文件重排的解决方案 APP启动速度提升超15%

iOS启动优化:二进制重排

上一篇下一篇

猜你喜欢

热点阅读