相信大家在项目开发中都使用过重写+(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
方法先执行的原因。
网友评论