iOS 类的加载（下）

在上一篇文章iOS类的加载（上）中，我们知道了类是如何从Mach-O中加载到内存，这篇文章我们来分析分类是如何加载到类里面的，以及分类和类的搭配使用情况

前提

在main函数中定义LGPerson的分类LG

#pragma mark -- LGPerson的分类
@interface LGPerson (LG)

@property (nonatomic, copy) NSString *cate_name;
@property (nonatomic, assign) int cat_age;

- (void)cate_instanceMethod1;
- (void)cate_instanceMethod2;
- (void)cate_instanceMethod3;
- (void)cate_instanceMethod;

@end

@implementation LGPerson (LG)

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

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

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

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

@end

下面我们将通过三种方式来探索分类的本质

• 【方式一】clang
• 【方式二】Xcode文档搜索Category
• 【方式三】objc源码搜索category_t

【方式一】clang

clang -rewrite-objc main.m -o main.cpp命令查看底层编译

• 分类的类型是_category_t

• 分类的倒数第二个0，表示的是没有协议，所以赋值为0
  

  image.png

• 搜索struct _category_t，如下所示

  • 其中有两个method_list_t，代表实例方法和类方法
    方法列表

• 搜索_CATEGORY_INSTANCE_METHODS_LGPerson_，
  

  image.png
  其中有3个方法，格式为：sel+签名+地址，是method_t结构体的属性即key
  image.png

• 搜索method_t，其中对应关系如下

  • name == sel
  • type == 方法签名

  • imp == 函数地址

    
    image.png

• 查看_prop_list_t，我们发现在分类中定义了的属性，但是在底层编译中并没有看到属性，如下图所示，这是因为分类中定义的属性没有对应的set、get方法，但是我们可以通过关联对象来进行设置
  

  image.png

【方式二】Xcode文档搜索Category

command + shift + O打开Xcode文档搜索Category

Xcode文档搜索

【方式三】通过objc源码搜索category_t

category_t

分类的加载

前提

创建两个分类LGA、LGB

image.png

上一篇文章iOS类的加载（上）中提到了分类的加载顺序是越晚加进来，越在前面
查看methodizeClass的源码实现，可以发现类的数据和分类的数据是分开处理的，是因为在编译阶段就已经确定好了方法的归属位置(实例方法在类中，类方法在元类中)，而分类是后面才加进来的

methodizeClass

其中分类是需要通过attatchToClass方法添加到类里面，分为下面三步

• 分类数据加载时机：根据类和分类是否实现load方法来区分
• attachCategories准备分类数据
• attachLists将分类数据添加到主类中

load_images

load_images方法的主要作用是加载镜像文件，其中最重要的有两个方法：prepare_load_methods（加载） 和 call_load_methods（调用）

load_images原理图

• 从所有的非懒加载类和分类中的+load分别添加到表中
• 调用类和分类的+load方法
  load_images原理图

load_images调用过程

调用过程

分类的加载时机

我们在LGPerson和LGA、LGB中均实现+load方法

我们通过第二步数据反推第一步加载时机

在上一篇文章中我们知道，在attachCategories方法时，必然有分类数据的加载，因此我们可以反过来查看什么时候调用了attachCategories，全局搜索发现有两个方法调用

• load_categories_nolock方法
  

  load_categories_nolock

• addToClass方法中，这里经过调试发现，从来不会进到if流程中，除非加载两次，一般的类一般只会加载一次
  

  addToClass

• 运行objc代码，打印日志，通过日志可以发现addToClass方法的下一步就是load_categories_nolock方法就是加载分类数据
  

  image.png

• 全局搜索load_categories_nolock的调用，有两次调用

  • 一次在loadAllCategories方法中
    image.png

• 一次在_read_images方法中
  

  image.png

• 但是经过调试发现，是不会走_read_images方法中的if流程的，而是走的loadAllCategories方法中的
  

  image.png

• 全局搜索查看loadAllCategories的调用，发现是在load_images时调用的
  

  image.png

通过堆栈信息分析

• 在attachCategories中加自定义逻辑的断点，bt查看堆栈信息
  image.png

所以综上所述，该情况下的分类的数据加载时机的反推路径为：attachCategories -> load_categories_nolock -> loadAllCategories -> load_images

而我们的分类加载正常的流程的路径为：realizeClassWithoutSwift -> methodizeClass -> attachToClass ->attachCategories

分类加载时机

LGPerson+分类LGA实现+load，分类LGB不实现+load方法

• 断点定在attachCategories中加自定义逻辑部分，一步步往下执行
  

  image.png

• 继续往下执行，会再次来到 attachCategories方法中断住
  

  image.png

总结：只要有一个分类是非懒加载分类，那么所有的分类都会被标记位非懒加载分类，意思就是加载一次 已经开辟了rwe，就不会再次懒加载，重新去处理 主类

分类和类的搭配使用

通过上面的两个例子，我们可以大致将类 和 分类 是否实现+load的情况分为4种

• 【情况1】非懒加载类 + 非懒加载分类

• 【情况2】非懒加载类 + 懒加载分类

• 【情况3】懒加载类 + 懒加载分类

• 【情况4】懒加载类 + 非懒加载分类

非懒加载类 与 非懒加载分类

主类和分类都实现了+load方法，综合前面的分析可以得出下面结论

• 类是通过_getObjc2NonlazyClassList加载数据的，即ro、rw的操作，对rwe初始化赋值是在extAlloc方法中

  • 调用路径为：map_images -> map_images_nolock -> _read_images -> readClass -> _getObjc2NonlazyClassList -> realizeClassWithoutSwift -> methodizeClass -> attachToClass,此时的mlists是一维数组，然后走到load_images部分

• 分类的数据加载是通过load_images加载到类中的

  • load_images --> loadAllCategories -> load_categories_nolock -> load_categories_nolock -> attachCategories -> attachLists，此时的mlists是二维数组

下面为源码中调试的打印日志

image.png

非懒加载类 与 懒加载分类

主类实现了+load方法，分类未实现+load方法

• 打开realizeClassWithoutSwift中的自定义断点，看一下ro

  • 查看kc_ro

    
    image.png

  • p kc_ro->baseMethodList
    

    image.png

  • p $1.get(0) 、$1.get(1) 、$1.get(2) 、$1.get(3) 、$1.get(4)
    

    image.png

  • p $1.get(5)、$1.get(10)
    

    image.png

• 来到prepareMethodLists的for循环部分
  

  image.png

• 来到fixupMethodList方法中的if (sort) {部分

  • 其中SortBySELAddress的源码实现如下：根据名字的地址进行排序
    image.png

• 走到mlist->setFixedUp();，在读取list
  

  image.png
  image.png

通过打印发现，仅对同名方法进行了排序，而分类中的其他方法是不需要排序的，其中imp地址是有序的（从小到大） -- fixupMethodList中的排序只针对 name 地址进行排序

• 不加任何断点，运行程序，获取打印日志

  
  image.png

非懒加载类 与 懒加载分类的数据加载 总结：

• 类 和 分类的加载是在read_images就加载数据了
• 其中data数据在编译时期就已经完成了

懒加载类 与 懒加载分类

主类和分类均未实现+load方法

• 不加任何断点，运行程序，获取打印日志

  
  image.png

其中realizeClassMaybeSwiftMaybeRelock是消息流程中慢速查找中有的函数，即在第一次调用消息时才有的函数

• 在readClass断住,然后读取kc_ro，即读取整个data
  image.png

此时的baseMethodList的count还是16，说明也是从data中读取出来的，所以不需要经过一层缓慢的load_images加载进来

总结：懒加载类 与 懒加载分类的数据加载是在消息第一次调用时加载

懒加载类 与 非懒加载分类

主类未实现+load方法， 分类实现了+load方法

• 不加任何断点，运行程序，获取打印日志

  
  image.png

• 在打印的日志中没有看到load_categories_nolock方法，查看attachCategories -- extAlloc -- attachToClass -- attachCategories，在attachToClass中加断点
  

  image.png

• 在readClass方法中断住，查看kc_ro
  

  image.png

其中baseMethodList的count是8个，打印看看：对象方法3个+属性的setget方法共4个+1个cxx方法 ，即 现在只有主类的数据

image.png

• 查看kc_ro结构

  
  image.png

• 打印日志

  
  image.png

• 为了调试分类的数据加载， 继续往下执行，bt查看堆栈：load_images -> loadAllCategories -> load_categories_nolock
  

  image.png

总结： 懒加载类 + 非懒加载分类的数据加载，只要分类实现了load，会迫使主类提前加载,即 主类 强行转换为 非懒加载类

总结

通过上面的分析可知：分类的本质是_category_t

• 有两个属性：name(类名)和cls(类对象)
• 有两个method_list_t方法列表：分类中实现的类方法和实例方法
• 一个protocol_list_t协议列表：分类中实现的协议
• 一个prop_list_t属性列表：分类中定义的属性，一般通过关联对象实现
• 分类中的属性是没有set、get方法

类和分类搭配使用，其数据的加载时机总结如下：

• 【情况1】非懒加载类 + 非懒加载分类，其数据的加载在load_images方法中，首先对类进行加载，然后把分类的信息贴到类中

-【情况2】非懒加载类 + 懒加载分类，其数据加载在read_image就加载数据，数据来自data，data在编译时期就已经完成，即data中除了类的数据，还有分类的数据，与类绑定在一起

-【情况3】懒加载类 + 懒加载分类 ，其数据加载推迟到 第一次消息时，数据同样来自data，data在编译时期就已经完成

-【情况4】懒加载类 + 非懒加载分类 ，只要分类实现了load，会迫使主类提前加载，即在_read_images中不会对类做实现操作，需要在load_images方法中触发类的数据加载，即rwe初始化，同时加载分类数据

image.png