load和initialize的区别

在Objective-C中,NSObject是根类,而NSObject.h的头文件中前两个方法就是load和initialize两个类方法,本篇文章就对这两个方法做下说明和整理。

0. 概述

Objective-C作为一门面向对象语言,有类和对象的概念。编译后,类相关的数据结构会保留在目标文件中,在运行时得到解析和使用。在应用程序运行起来的时候,类的信息会有加载和初始化过程。

其实在Java语言中也有类似的过程,JVM的ClassLoader也对类进行了加载、连接、初始化。

就像Application有生命周期回调方法一样,在Objective-C的类被加载和初始化的时候,也可以收到方法回调,可以在适当的情况下做一些定制处理。而这正是load和initialize方法可以帮我们做到的。

+ (void)load;

+ (void)initialize;

可以看到这两个方法都是以“+”开头的类方法,返回为空。通常情况下,我们在开发过程中可能不必关注这两个方法。如果有需要定制,我们可以在自定义的NSObject子类中给出这两个方法的实现,这样在类的加载和初始化过程中,自定义的方法可以得到调用。

从如上声明上来看,也许这两个方法和其它的类方法相比没什么特别。但是,这两个方法具有一定的“特殊性”,这也是这两个方法经常会被放在一起特殊提到的原因。详细请看如下几小节的整理。

1. load和initialize的共同特点

load和initialize有很多共同特点,下面简单列一下:

在不考虑开发者主动使用的情况下,系统最多会调用一次

如果父类和子类都被调用,父类的调用一定在子类之前

都是为了应用运行提前创建合适的运行环境

在使用时都不要过重地依赖于这两个方法,除非真正必要

2. load方法相关要点

废话不多说,直接上要点列表:

调用时机比较早,运行环境有不确定因素。具体说来,在iOS上通常就是App启动时进行加载,但当load调用的时候,并不能保证所有类都加载完成且可用,必要时还要自己负责做auto release处理。

补充上面一点,对于有依赖关系的两个库中,被依赖的类的load会优先调用。但在一个库之内,调用顺序是不确定的。

对于一个类而言,没有load方法实现就不会调用,不会考虑对NSObject的继承。

一个类的load方法不用写明[super load],父类就会收到调用,并且在子类之前。

Category的load也会收到调用,但顺序上在主类的load调用之后。

不会直接触发initialize的调用。

3. initialize方法相关要点

同样,直接整理要点:

initialize的自然调用是在第一次主动使用当前类的时候(lazy,这一点和Java类的“clinit”的很像)。

在initialize方法收到调用时,运行环境基本健全。

initialize的运行过程中是能保证线程安全的。

和load不同,即使子类不实现initialize方法,会把父类的实现继承过来调用一遍。注意的是在此之前,父类的方法已经被执行过一次了,同样不需要super调用。

由于initialize的这些特点,使得其应用比load要略微广泛一些。可用来做一些初始化工作,或者单例模式的一种实现方案。

4. 原理

“源码面前没有秘密”。最后,我们来看看苹果开放出来的部分源码。从中我们也许能明白为什么load和initialize及调用会有如上的一些特点。

其中load是在objc库中一个load_images函数中调用的,先把二进制映像文件中的头信息取出,再解析和读出各个模块中的类定义信息,把实现了load方法的类和Category记录下来,最后统一执行调用。

其中的prepare_load_methods函数实现如下:

void prepare_load_methods(header_info *hi)

{

Module mods;

unsigned int midx;

if (_objcHeaderIsReplacement(hi)) {

return;

}

mods = hi->mod_ptr;

for (midx = 0; midx < hi->mod_count; midx += 1)

{

unsigned int index;

if (mods[midx].symtab == nil)

continue;

for (index = 0; index < mods[midx].symtab->cls_def_cnt; index += 1)

{

Class cls = (Class)mods[midx].symtab->defs[index];

if (cls->info & CLS_CONNECTED) {

schedule_class_load(cls);

}

}

}

mods = hi->mod_ptr;

midx = (unsigned int)hi->mod_count;

while (midx-- > 0) {

unsigned int index;

unsigned int total;

Symtab symtab = mods[midx].symtab;

if (mods[midx].symtab == nil)

continue;

total = mods[midx].symtab->cls_def_cnt +

mods[midx].symtab->cat_def_cnt;

index = total;

while (index-- > mods[midx].symtab->cls_def_cnt) {

old_category *cat = (old_category *)symtab->defs[index];

add_category_to_loadable_list((Category)cat);

}

}

}

这大概就是主类中的load方法先于category的原因。再看下面这段:

static void schedule_class_load(Class cls)

{

if (cls->info & CLS_LOADED) return;

if (cls->superclass) schedule_class_load(cls->superclass);

add_class_to_loadable_list(cls);

cls->info |= CLS_LOADED;

}

这正是父类load方法优先于子类调用的原因。

再来看下initialize调用相关的源码。objc的库里有一个_class_initialize方法实现,如下:

void _class_initialize(Class cls)

{

assert(!cls->isMetaClass());

Class supercls;

BOOL reallyInitialize = NO;

supercls = cls->superclass;

if (supercls  &&  !supercls->isInitialized()) {

_class_initialize(supercls);

}

monitor_enter(&classInitLock);

if (!cls->isInitialized() && !cls->isInitializing()) {

cls->setInitializing();

reallyInitialize = YES;

}

monitor_exit(&classInitLock);

if (reallyInitialize) {

_setThisThreadIsInitializingClass(cls);

if (PrintInitializing) {

_objc_inform("INITIALIZE: calling +[%s initialize]",

cls->nameForLogging());

}

((void(*)(Class, SEL))objc_msgSend)(cls, SEL_initialize);

if (PrintInitializing) {

_objc_inform("INITIALIZE: finished +[%s initialize]",

cls->nameForLogging());

}

monitor_enter(&classInitLock);

if (!supercls  ||  supercls->isInitialized()) {

_finishInitializing(cls, supercls);

} else {

_finishInitializingAfter(cls, supercls);

}

monitor_exit(&classInitLock);

return;

}

else if (cls->isInitializing()) {

if (_thisThreadIsInitializingClass(cls)) {

return;

} else {

monitor_enter(&classInitLock);

while (!cls->isInitialized()) {

monitor_wait(&classInitLock);

}

monitor_exit(&classInitLock);

return;

}

}

else if (cls->isInitialized()) {

return;

}

else {

_objc_fatal("thread-safe class init in objc runtime is buggy!");

}

}

转载自三石道博客

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,233评论 4 360
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,013评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,030评论 0 241
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,827评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,221评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,542评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,814评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,513评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,225评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,497评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,998评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,342评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,986评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,055评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,812评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,560评论 2 271
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,461评论 2 266

推荐阅读更多精彩内容