iOS runtime 研究笔记

1,099 阅读1分钟

1 前言

因为某个神秘的原因,对多个动态库的加载机制做了一些简单的测试。

ps. 部分测试结果可能会颠覆很多网友的认知

2 一、分类的 +load 方法执行时机可能早于类自身的 +load 方法

首先,我们分别准备两个动态库并添加下面的测试代码

动态库 A:

image.png

动态库 B:

image.png

对应日志如下:

注意:ClassA 分类 的 +load 方法执行时机早于 ClassA 自身的 +load 方法

原因分析:

  1. 启动时,dyld 会依次读取 APP 依赖的动态库

  2. 逆序通知 libobjc.A.dylib 的 load_images 函数执行加载任务

  3. 按照以下顺序执行 load 方法:

    1. 类自身的 +load 方法
    2. 分类的 +load 方法
  4. C++ 的 静态初始化方法 和通过 __attribute__((constructor)) 修饰的函数

本例中,FrameWorkB 是最后一个被依赖的动态库,所以,FrameWorkB 的内部的 ClassA 分类 的 +load 方法执行时机会早于 ClassA 自身的 +load 方法

3 二、分类的实例方法会覆盖类自身的实例方法

动态库 A:

image.png

动态库 B:

image.png

主程序:

image.png

通过日志,我们可以发现分类的 test 方法一定会覆盖类自身的 test 方法

文末推荐:iOS热门文集