在做二进制重排之前,首先需要了解到几个知识点.例如:物理内存,虚拟内存,内存分页管理 等
物理内存
早期的操作系统,只有物理内存
当一个应用启动后,会全部加载到内存中,并按照内存真实地址排列
这样就会面临一些问题,比如:
- 内存会不够用
- 不安全,因为在内存中App是使用真实地址访问,所以App可以访问其以外的内存
虚拟内存(官方文档)
iOS中,一个虚拟内存与一个进程 一一对应,大小为4G, 虚拟内存里会分为很多页(Page),每页的大小16KB
当有了虚拟内存之后.CPU访问进程数据相对上面的有了变化:
- 一个进程启动后,系统为该进程建立一个对应的虚拟内存,里面记录了进程每项数据的虚拟内存地址(比如图中"进程1虚拟页表")
- 当进程的某部分活跃后，MMU(
Memory Management Unit-内存管理单元)会把这部分数据的虚拟内存地址翻译成其对应的物理内存地址,然后CPU通过物理地址访问到物理内存上的数据。 - 如果在page上没有找到对应的物理地址时(
图中"进程1虚拟页表的"P2)，说明此page上所关联的进程数据没被加载到物理内存中，此时会触发缺页异常（Page Fault），中断当前进程，先将当前页所对应的进程数据加载到物理内存中，然后page会记录该项数据的物理地址，CPU再通过物理地址来访问内存上的数据(此过程耗时是毫秒级)
相比早期的纯物理内存,虚拟内存的优势
- 内存使用更高效：进程的数据经过分页管理后，只将活跃的page所关联的数据加载在物理内存中，当物理内存都被占用的时候，此时会覆盖掉不活跃的内存，加载当前活跃的page数据，这样就能提高对内存的使用效率
- 内存数据更安全：每次启动进程，系统都会重新建立对应的虚拟内存，并为虚拟内存分配一个
ASLR随机值（Address Space Layout Randomization），数据的虚拟地址即为：ASLR随机值+偏移值，这样数据的虚拟地址每次都会变，并且CPU是通过虚拟内存来间接访问物理内存的，在这个过程中物理内存地址没有暴露出来，所以就能保证内存数据的安全性
ASLR (Address Space Layout Randomization）
首先如果没有ASLR,虚拟内存是有安全隐患的
- 每个虚拟页表开头都是0 (0~4G).如果做静态分析,定位到一个函数,找到函数偏移地址,每次都可拿到该函数
ASLR可以弥补上述的安全缺陷
百度百科上ASLR的解释：(Address Space Layout Randomization ) 地址空间配置随机化；ASLR通过随机放置进程关键数据区域的地址空间来防止攻击者能可靠地跳转到内存的特定位置来利用函数
更直白的解释就如上面提到的:每次启动进程，系统都会重新建立对应的虚拟内存，并为虚拟内存分配一个ASLR随机值（Address Space Layout Randomization），数据的虚拟地址即为：ASLR随机值+偏移值，这样数据的虚拟地址每次都会变
了解上面的知识点后,下面会介绍二进制重排
二进制重排
上面有提到,当加载一个未加载到物理内存的数据时,会触发一个系统中断 (PageFault), 虽然单次耗时是毫秒级,但是有一种情况会出现大量的PageFault,那就是App启动, 通过二进制重排来减少App启动速度的核心就是减少App启动时PageFault的次数
在重排之前,我们可以先通过Link Map文件,来查看我们的项目加入到内存时的默认顺序是什么 (LinkMap记录了二进制文件的布局)
- xcode - build settings - Write Link Map File - 设为YES
- run一下项目,然后到项目工程目录的Products找到 xxx.app,右键show in finder
- 往回退两层目录,然后按照目录
Intermediates.noindex/项目名字.build/Debug-iphonesimulator/项目名字.build/项目名字-LinkMap-normal-arm64.txt找到linkMap文件
内容如下:
可以发现这个顺序默认是按照Compile Source的顺序,单个文件内的不同方法是按照代码书写的顺序
另外,我们还可以通过xcode - Instruments - System Trace来查看App启动时的pageFault次数
如截图:(用的是真实项目,项目相关信息打了马赛克)
这里有个问题:app首次打开的时候Page Fault的次数很多，打开之后再打开的话就比较少，当打开多个其他app的时候，在打开检测的app发现也会有不少Page Faults
这是由于操作系统的机制，当应用杀掉了，他所访问的物理内存不是立马就清空；它所访问的物理内存，需要通过其他app申请开辟覆盖释放掉,
我们要做的就是把启动所需要的代码,放在一起,放在最靠前的位置,减少启动时非必要的pageFault次数.
总结来讲就是以下两点
- 找到App启动时所需要调用的所有函数
- 更改App数据加入到内存的顺序
获取项目中启动时刻所调用的方法顺序
- HOOK objc_msgSend(); 能够覆盖所有OC的方法,此篇文章不考虑. (可以看我的另一篇文章有一些Hook的介绍)
- fishhook: 可hook到c方法
- clang插桩(官方文档)
本文采用clang插桩方式:
原理: 在编译时刻,在每个函数内部,都会静态插入方法__sanitizer_cov_trace_pc_guard,然后我们在项目中注册其回调函数,App每次调用方法(包括OC方法,C语言方法,block等所有方法),都会通过__sanitizer_cov_trace_pc_guard来回调,由此我们可以记录App启动时所需的所有方法
- 配置 other c Flags
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); //打印方法名字
}
可以通过LLDB来简单调试一下,为了效果明显,可以按照以下操作
- 新建一个项目,随便写几个方法,并把上述代码加进去(加哪里都可以,可以加在ViewController.m)
- 然了后再来个点击相应的方法,运行项目后,断电加在__sanitizer_cov_trace_pc_guard(如图), 然后点击屏幕触发点击方法,走入断点
可以通过log看到star和stop分别是0x102591898和0x1025918f8.
此时进行memory read,读取一下最后的内存地址里面的内容
(lldb) x 0x1025918f4
这里为什么是0x1025918f8 - 0x4 ?
start和stop都是uint32_t类型,占4个字节,end指向最后(如图),所以要获取最后一块内存地址中的内容,需要减0x4
如果在这基础上,再添加一个方法之后,同样的操作获取上述图中红框内的数字,我们会发现图中空框内的数字正是方法的数量 (注:红框内的18是16进制,代表有个24个方法)
我们可以添加汇编代码来看一下发生了什么
xcode - Debug - Debug Workflow - Always show Disassembly
给当前viewcontroller添加touchesBegan:withEvent:方法,并在方法内部添加断点,点击屏幕后:
可以看出已经给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的路径即可
到此,启动优化之二进制重排就结束了.我们可以通过上述介绍过的Instruments - System trace来验证一下page fault次数,不过要注意上述提到过当杀死App后,其所对应的物理内存的内容不会立刻被清除的问题,可以尝试多打开几个App后再打开自己的项目,或者清除所有后台然后关机开机.
参考:
