原文鏈接:https://juejin.cn/post/6844903902710759431
load方法中能實(shí)現(xiàn)什么?
我們經(jīng)常會(huì)有一些需求:讓某方法的執(zhí)行先于main方法。比如要hook某個(gè)系統(tǒng)類的方法(hook UIViewController的viewWillAppear和viewDidDisappear通過(guò)AOP的方式實(shí)現(xiàn)埋點(diǎn)功能),或者做一些初始化操作。這時(shí)候我們經(jīng)常首先想到的就是重寫+(void) load {}方法。
為什么要放在load方法中?我們將從objc源碼去探究。
程序的裝載
main.m中的main方法被稱作程序的入口。但其實(shí)在執(zhí)行到main之前系統(tǒng)首先要裝載應(yīng)用程序并完成動(dòng)態(tài)鏈接,再初始化運(yùn)行環(huán)境,然后準(zhǔn)備好調(diào)用參數(shù),調(diào)用main方法來(lái)啟動(dòng)應(yīng)用程序并把執(zhí)行權(quán)限交于我們的代碼。
我們的代碼會(huì)引用到UIKit、Foundation等框架,還有一些沒(méi)有明確import的類庫(kù),比如libSystem、libobjc等??梢酝ㄟ^(guò)otool -L 可執(zhí)行文件名稱來(lái)查看鏈接的動(dòng)態(tài)庫(kù),他們都是dylib格式。
otool -L XXApp.app/XXApp
XXApp.app/XXApp:
/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.4)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 62.1.0)
/usr/lib/libprotobuf.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 274.22.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
/System/Library/Frameworks/ARKit.framework/ARKit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AVFoundation.framework/AVFoundation (compatibility version 1.0.0, current version 2.0.0)
動(dòng)態(tài)鏈接庫(kù)dyld
dyld是動(dòng)態(tài)鏈接器(dynamic link editor),是蘋果的動(dòng)態(tài)連接器。系統(tǒng)先讀取App的可執(zhí)行文件(Mach-O),從里面獲得dyld的路徑,然后加載dyld,然后加載程序相關(guān)依賴庫(kù),對(duì)庫(kù)進(jìn)行鏈接,最后調(diào)用每個(gè)依賴庫(kù)的初始化方法。ojbc的初始化就發(fā)生在這個(gè)時(shí)機(jī)。
objc setup
objc的初始化主要在_objc_init方法中完成。
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();
lock_init();
exception_init();
_dyld_objc_notify_register(&map_images, load_images, unmap_image);
}
這里我們可以看到,objc向dyld注冊(cè)了三個(gè)callback函數(shù)。當(dāng)我們的可執(zhí)行文件的image load 后會(huì)執(zhí)行l(wèi)oad_images方法。
load_images(const char *path __unused, const struct mach_header *mh)
{
// 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);
prepare_load_methods((const headerType *)mh);
}
// Call +load methods (without runtimeLock - re-entrant)
call_load_methods();
}
load_images方法中主要做了兩件事情prepare_load_methods,然后call_load_methods。其實(shí)就是準(zhǔn)備好load方法,然后調(diào)用(call)load方法。
我們接著查看call_load_methods方法的實(shí)現(xiàn),在do { } while中,首先調(diào)用class_loads,然后再調(diào)用category_loads。
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
while (loadable_classes_used > 0) {
call_class_loads();
}
// 2. Call category +loads ONCE
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;
}
load_images
的執(zhí)行發(fā)生在main方法之前,所以可確保時(shí)機(jī)的要求。
并且我們看到,class中的load方法先執(zhí)行,然后才會(huì)再執(zhí)行category中重寫的```load``方法。