类的加载（上）

在上一篇文章dyld与objc的关联中了解了dyld与objc是如何关联的，本文来理解类的相关信息是如何加载到内存中。

map_images

3292520-8afcebb730d39b93.jpg

从此方法中我们看到了代码的重点为红色区域下面开始分析
此方法为加载镜像文件由于此文章主要研究重点为类
如类里面的方法属性协议等等怎么来的所以 _read_images为研究重点

_read_images 初探

从整体来分析将其代码块关掉在分析细节

_read_images.jpg

条件控制进行一次的加载
修复预编译阶段@selector的混乱问题
错误混乱的类处理
修复重映射一些没有被镜像文件加载进来的类
修复一些消息
当我们类里面有协议的时候：readProtocol
修复没有被加载的协议
分类的处理
类的加载处理
没有被处理的类，优化哪些被侵犯的类

条件控制进行一次的加载

打开代码块

截屏2020-10-19 下午4.13.12.png

小对象的判断
创建了一个表 gdb_objc_realized_classes 放类，它的意义在于查找快。

修复预编译阶段@selector的混乱问题

截屏2020-10-19 下午4.18.40.png

由于方法编号在于各个库的位置坐标不一样会把所有的加载到一块来统一调度。
例如一个方法编号 ,可能在各种库里都有虽说名字一样但是内存的地址不一样，所以需要fix up。
sel误区，sel并不是单纯的字符串。wwdc也讲过是一个带地址的字符串匹配

错误混乱的类处理

截屏2020-10-19 下午4.32.24.png

运行其源代码发现只是在readClass循环程序在正常运行但是从来没有来到过3602 行所以不做其研究
这里其实就是我们在编译时候类的信息发生混乱，有一些类的地址已经被移动了但是没有被删除，但是类的混乱一般情况下很少出现所已不做考虑。
所以说移动类的成本要比删除类新创建的成本要大（宁可删除重建不要一步一步移动内存开销大）
readClass研究重点通过 readClass函数可以从地址读取出类的名字(这里可以 lldb p cls 在 p newCls 可直观获取)
下面研究 readClass

readClass

为了不受到别的类的干扰我们在readClass代码写上控制条件改源码结构并打下断点研究我们要研究的类

截屏2020-10-19 下午4.56.28.png

@interface LGPerson : NSObject
@property (nonatomic, copy) NSString *kc_name;
@property (nonatomic, assign) int kc_age;

- (void)kc_instanceMethod1;
- (void)kc_instanceMethod2;
- (void)kc_instanceMethod3;

+ (void)kc_sayClassMethod;

@end
@implementation LGPerson

//+ (void)load{
//    
//}

- (void)kc_instanceMethod2{
    NSLog(@"%s",__func__);
}

- (void)kc_instanceMethod1{
    NSLog(@"%s",__func__);
}

- (void)kc_instanceMethod3{
    NSLog(@"%s",__func__);
}

+ (void)kc_sayClassMethod{
    NSLog(@"%s",__func__);
}


@end

继续分析看到了其 rw ro 的一些读取操作断点