+load与+initialize

load与initialize的区别

一、调用方式

1、load是根据函数地址直接调用
2、initialize是通过objc_msgSend调用

二、调用时刻

1、load是runtime加载类、分类的时候调用(只会调用一次)
2、initialize是类第一次接收到消息的时候调用, 每一个类只会initialize一次(如果子类没有实现initialize方法, 会调用父类的initialize方法, 所以父类的initialize方法可能会调用多次)
3、load比initialize先调用

三、使用场景

load 和 initialize 方法本质都是做初始化的，只不过级别或者说针对的过程不一样。load 只会调用一次，在 main 方法调用之前做初始化，比如方法交换。initialize 方法针对的是 main 方法之后，而且是懒加载(类第一次接收到消息的时候调用)，使用到时才初始化。鉴于 objc_msgSend 的机制，存在多次调用的可能，但是可以使用代码进行判断。

四、load和initialize的调用顺序

1. load调用顺序

• 调用顺序，需要同时满足四种规则
  先调用类的load, 在调用分类的load
  先编译的类, 优先调用load
  调用子类的load之前, 会先调用父类的load(父类 -> 子类)
  没有父子关系的类及分类之间，按Build Phases ->Complie Source 中的编译顺序
• 特点：
  load在父类，子类，分类之间的调用不存在覆盖,只存在先后执行顺序

2. initialize调用顺序

• initialize调用的优先级为 (父类分类 > 父类) > (子类分类 > 子类)
• initialize在父类，子类，父分类，子分类之间的调用存在覆盖【（父类与子类）（父分类与子分类）本类与分类，两两存在覆盖关系，两组相互之间只会调用优先级最高的一个】，有优先级
• 特点：
  优先级：先分类后本类【分类覆盖本类】
  顺序是：先父类后子类【存在先后执行，不存在覆盖】
• 通过消息机制调用, 当子类没有initialize方法时, 会调用(父类分类>父类)的initialize方法, 所以(父类分类>父类)的initialize方法会调用多次

load示例1、父类（baseViewController），子类（categroyViewController）同时实现load方法scan方法，并在load里调用scan方法
方法执行顺序为

2021-05-07 11:05:18.530993+0800 ocProjectDemo[6277:3515374] baseViewController - load
2021-05-07 11:05:18.531616+0800 ocProjectDemo[6277:3515374] baseViewController - scan
2021-05-07 11:05:18.531734+0800 ocProjectDemo[6277:3515374] categroyViewController - load
2021-05-07 11:05:18.531826+0800 ocProjectDemo[6277:3515374] categroyViewController - scan

load示例2、父类（baseViewController）与父类分类(baseViewController+loadAndinitialize )，子类（categroyViewController）与子类分类(categroyViewController+subloadAndinitialize)同时实现load与scan方法，并在load里调用scan方法

2021-05-07 11:07:17.612013+0800 ocProjectDemo[6323:3517101] baseViewController - load
2021-05-07 11:07:17.612735+0800 ocProjectDemo[6323:3517101] baseViewController+loadAndinitialize - scan
2021-05-07 11:07:17.612868+0800 ocProjectDemo[6323:3517101] categroyViewController - load
2021-05-07 11:07:17.612987+0800 ocProjectDemo[6323:3517101] categroyViewController+subloadAndinitialize - scan
2021-05-07 11:07:17.613077+0800 ocProjectDemo[6323:3517101] categroyViewController+subloadAndinitialize - load
2021-05-07 11:07:17.613161+0800 ocProjectDemo[6323:3517101] categroyViewController+subloadAndinitialize - scan
2021-05-07 11:07:17.613453+0800 ocProjectDemo[6323:3517101] baseViewController+loadAndinitialize - load
2021-05-07 11:07:17.613581+0800 ocProjectDemo[6323:3517101] baseViewController+loadAndinitialize - scan

截屏2021-05-07 下午1.51.49.png

• 首先顺序为父类->子类->[分类，在Build Phases ->Complie Source 中的编译顺序]
• 分类中的scan覆盖了本类中的scan

load遗留问题，这里没有探究父类不实现load方法问题，没找到固定规律。能确定的是，若是父类未实现load方法，父类分类实现了load方法的话，会提前执行父类分类的load方法，再执行子类的load方法，然后执行子类分类的load方法。但是多个父类未实现load方法，父类分类的load方法之间的执行顺序就没有规律可言了。没有按照编译顺序，也没有按照父子类顺序，也没有按照本类分类的顺序

initialize示例1、父类（baseViewController），子类（categroyViewController）同时实现initialize方法

2021-05-07 11:32:47.317927+0800 ocProjectDemo[6967:3536479] baseViewController - initialize
2021-05-07 11:32:47.318105+0800 ocProjectDemo[6967:3536479] categroyViewController - initialize

initialize示例2、父类(baseViewController)与父类分类(baseViewController+loadAndinitialize)，子类(categroyViewController)同时实现initialize方法

2021-05-07 11:31:38.852613+0800 ocProjectDemo[6844:3535323] baseViewController+loadAndinitialize - initialize
2021-05-07 11:31:38.852817+0800 ocProjectDemo[6844:3535323] categroyViewController - initialize

initialize示例3、父类(baseViewController)与父类分类(baseViewController+loadAndinitialize)，子类(categroyViewController)子类分类(categroyViewController+subloadAndinitialize)同时实现initialize方法

2021-05-07 11:28:13.951750+0800 ocProjectDemo[6716:3532747] baseViewController+loadAndinitialize - initialize
2021-05-07 11:28:13.951928+0800 ocProjectDemo[6716:3532747] categroyViewController+subloadAndinitialize - initialize

initialize示例4、父类(baseViewController)实现initialize方法，父类分类,子类,子类分类不实现initialize方法

2021-05-07 13:34:10.833125+0800 ocProjectDemo[7680:3566149] baseViewController - initialize
2021-05-07 13:34:10.833329+0800 ocProjectDemo[7680:3566149] baseViewController - initialize

https://www.jianshu.com/p/b73ee3a91c7d
https://www.jianshu.com/p/e79a22e87c10
https://blog.csdn.net/weixin_44060108/article/details/107404870