在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!");
}
}
轉載自三石道博客
