启动优化

2023-06-26  本文已影响0人  xxttw
image.png
按照不同阶段的优化
rebase

每次应用启动时,我们获取到的地址都是变化的, 虚拟内存技术出现后, 就出现了ASLR(地址空间布局随机) 如下图:


image.png
image.png

修正偏移(rebase)
那么问题来了: 既然我们每次启动应用地址都是随机的, 我们如何找到真正存储某个函数的地址呢
Link Map File : 链接映射文件, 里面记录了每个类所生成的可执行文件的路径,CPU架构,目标文件,符号等信息
在buildSettings- 设置 Write Link Map File为YES,将 Link Map File(链接映射文件)写入到本地

image.png

我们可以根据应用启动的ASLR随机地址, 和Link Map File里的方法偏移量和修复这函数的真是内存地址,这个过程就是rebase


image.png

比如我们的ASLR地址为0x0000000102c88000 viewDidLoad方法的偏移量为0x100001C04
那么我们可以得出viewDidLoad函数的真实地址
rebase的结果如下图

image.png

从上面的结果来看,rebase之后的地址就是 -[ViewController viewDidLoad]的真是地址

符号绑定bindging

主要是针对外部函数的绑定, 指的是在运行时通过外部符号去找到真正的存放这个外部函数的地址

3.1.3 无用类清理

从前面的分析章节我们知道,不管是 rebase&bind 还是 Objc Init 阶段,工程中类及分类的代码量都会影响这几个阶段的耗时,尤其是大型 App 中不断发展的业务导致代码量巨多,而很多业务和代码在上线后并没有用到,所以对于这些无用代码的清理也能减少启动耗时。另外,无用代码清理对于包大小的收益更大,云音乐在包大小优化中做了无用代码的清理6

那么,如何才能找出哪些代码没有被用到呢?一般可以分为静态代码扫描和线上大数据统计两种方式。静态代码扫描还是从 MachO 出发, MachO 中的_objc_selrefs_objc_classrefs两个 section 中存储了引用到的 sel 和 class,而在__objc_classlistsection 中存储了所有的 sel 和 class,通过比较两者数据的差集就可以获取没有被用到的类。而我们知道 OC 是一门动态语言,所以很多类都是运行时调用,在删除类之前需要确保没有被真正地调用。线上大数据统计则采用类元数据中相应的标记为是否被初始化来统计。我们知道,在 OC 中,每个类都有自己的元数据,在元数据中的一个标记位存储着自己是否被初始化,这个标记位不受任何因素影响,只要有被初始化就会打标记,在 OC 的源码中获取标记位的方式如下:

struct objc_class : objc_object {
    bool isInitialized() {
        return getMeta()->data()->flags & RW_INITIALIZED;
    }
}
 - (BOOL)isUsedClass:(NSString *)cls { 
     Class metaCls = objc_getMetaClass(cls.UTF8String); 
     if (metaCls) { 
         uint64_t *bits = (__bridge void *)metaCls + 32; 
         uint32_t *data = (uint32_t *)(*bits & FAST_DATA_MASK); 
         if ((*data & RW_INITIALIZED) > 0) { 
             return YES; 
         } 
     } 
     return NO; 
 }
image.png
上一篇 下一篇

猜你喜欢

热点阅读