相信大家在项目开发中都使用过重写+(void)load方法来进行一些初始化。那它的调用为什么比main函数调用还要靠前，整体调用流程到底是怎么样的，今天我们就来分析一下吧~
查看调用堆栈
新建一个iOS工程，在ViewController中重写+(void)load方法并打个断点，bt打印日志如下：
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1
* frame #0: 0x00000001092ffe17 testObjc`+[ViewController load](self=ViewController, _cmd="load") at ViewController.m:17:5
frame #1: 0x0000000109b165e3 libobjc.A.dylib`load_images + 1442
frame #2: 0x0000000109313e54 dyld_sim`dyld::notifySingle(dyld_image_states, ImageLoader const*, ImageLoader::InitializerTimingList*) + 425
frame #3: 0x0000000109322887 dyld_sim`ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 437
frame #4: 0x0000000109320bb0 dyld_sim`ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 188
frame #5: 0x0000000109320c50 dyld_sim`ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 82
frame #6: 0x00000001093142a9 dyld_sim`dyld::initializeMainExecutable() + 199
frame #7: 0x0000000109318d50 dyld_sim`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 4431
frame #8: 0x00000001093131c7 dyld_sim`start_sim + 122
frame #9: 0x000000010ee8985c dyld`dyld::useSimulatorDyld(int, macho_header const*, char const*, int, char const**, char const**, char const**, unsigned long*, unsigned long*) + 2308
frame #10: 0x000000010ee874f4 dyld`dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) + 837
frame #11: 0x000000010ee82227 dyld`dyldbootstrap::start(dyld3::MachOLoaded const*, int, char const**, dyld3::MachOLoaded const*, unsigned long*) + 453
frame #12: 0x000000010ee82025 dyld`_dyld_start + 37
接下来继续往下执行，在main函数上打个断点，然后bt打印日志如下：
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 3.1
frame #0: 0x000000010930009d testObjc`main(argc=1, argv=0x00007ffee68ffcc0) at main.m:16:16
* frame #1: 0x000000010b267415 libdyld.dylib`start + 1
可以看到这两个调用栈都是从libdyld.dylib中的方法开始的。dyld负责了我们应用程序的启动加载，那它到底做了什么，接下来我们就从dyld的源码层面开始分析吧（相关代码可以从苹果的openSource上下载到）。
dyld流程分析
在dyld开源代码中搜索_dyld_start，其使用汇编语言实现，后续调用流程为dyldbootstrap::start->dyld::_main可以看到在main方法中做了很多事情，主要是准备环境，初始化，加载主程序等。其中比较关键的是主程序的初始化流程：initializeMainExecutable->runInitializers->processInitializers->recursiveInitialization->doInitialization,看一下实现：
bool ImageLoaderMachO::doInitialization(const LinkContext& context)
{
CRSetCrashLogMessage2(this->getPath());
// mach-o has -init and static initializers
//执行所有image的初始化
doImageInit(context);
//执行被声明成构造函数属性的函数
doModInitFunctions(context);
CRSetCrashLogMessage2(NULL);
return (fHasDashInit || fHasInitializers);
}
doModInitFunctions中会确保libSystem.dylib的初始化方法libSystem_initializer先被调用,然后内部调用libdispatch.dylib库中的libdispatch_init -> _os_object_init -> _objc_init,
然而_objc_init的实现是在runtime源码中，看一下其源码实现：
void _objc_init(void)
{
static bool initialized = false;
if (initialized) return;
initialized = true;
// fixme defer initialization until an objc-using image is found?
environ_init();
tls_init();
static_init();
runtime_init();
exception_init();
cache_init();
_imp_implementationWithBlock_init();
//调用dyld中的注册方法，把load_images函数地址传过去
_dyld_objc_notify_register(&map_images, load_images, unmap_image);
#if __OBJC2__
didCallDyldNotifyRegister = true;
#endif
}
其中比较关键的是_dyld_objc_notify_register -> registerObjCNotifiers方法的调用，registerObjCNotifiers方法又回到了libdyld.dylib中，所以这个调用链是把runtime中的load_images函数地址存储在libdyld.dylib中的全局变量sNotifyObjCInit上。
至此dyld的doInitialization方法中执行完毕，继续回到recursiveInitialization方法往下执行调用context.notifySingle -> sNotifyObjCInit()，流程又回到runtime层的load_images方法来，看一下方法实现：
void load_images(const char *path __unused, const struct mach_header *mh)
{
if (!didInitialAttachCategories && didCallDyldNotifyRegister) {
didInitialAttachCategories = true;
loadAllCategories();
}
// Return without taking locks if there are no +load methods here.
if (!hasLoadMethods((const headerType *)mh)) return;
recursive_mutex_locker_t lock(loadMethodLock);
// Discover load methods
{
mutex_locker_t lock2(runtimeLock);
//准备待调用的load方法列表
prepare_load_methods((const headerType *)mh);
}
// Call +load methods (without runtimeLock - re-entrant)
//一次性加载所有load方法
call_load_methods();
}
主要是加载category，准备待执行的load方法列表，然后一次性调用所有的load方法。
看一下prepare_load_methods中的实现：
void prepare_load_methods(const headerType *mhdr)
{
size_t count, i;
runtimeLock.assertLocked();
//读取所有的类信息
classref_t const *classlist =
_getObjc2NonlazyClassList(mhdr, &count);
for (i = 0; i < count; i++) {
//把类的load方法加到list列表
schedule_class_load(remapClass(classlist[i]));
}
//加载所有的分类信息
category_t * const *categorylist = _getObjc2NonlazyCategoryList(mhdr, &count);
for (i = 0; i < count; i++) {
category_t *cat = categorylist[i];
Class cls = remapClass(cat->cls);
if (!cls) continue; // category for ignored weak-linked class
if (cls->isSwiftStable()) {
_objc_fatal("Swift class extensions and categories on Swift "
"classes are not allowed to have +load methods");
}
realizeClassWithoutSwift(cls, nil);
ASSERT(cls->ISA()->isRealized());
//把分类中的load方法加到list中
add_category_to_loadable_list(cat);
}
}
就是把所有类的load方法和所有分类的load方法分别放到两个list中。并且schedule_class_load中加载类的load方法是时是递归调用的，所以父类的load方法在前面。接下来调用了call_load_methods：
void call_load_methods(void)
{
static bool loading = NO;
bool more_categories;
loadMethodLock.assertLocked();
// Re-entrant calls do nothing; the outermost call will finish the job.
if (loading) return;
loading = YES;
void *pool = objc_autoreleasePoolPush();
do {
// 1. Repeatedly call class +loads until there aren't any more
//先调用类的load方法
while (loadable_classes_used > 0) {
call_class_loads();
}
// 2. Call category +loads ONCE
//再调用分类的load方法
more_categories = call_category_loads();
// 3. Run more +loads if there are classes OR more untried categories
} while (loadable_classes_used > 0 || more_categories);
objc_autoreleasePoolPop(pool);
loading = NO;
}
可以看到是先调用了call_class_loads，然后调用call_category_loads，所以load方法的调用顺序是，父类->子类->category，至此，load方法的调用流程就分析结束了。
而initializeMainExecutable方法流程结束后就通知可以进入main方法中了，也也是为什么load比main方法先执行的原因。