今天我們討論的hook方式僅僅是指Method Swizzle，fishhook、Cydia Substrate 等方式不在今天的討論范疇。
hook load方法我們主要面臨以下問題：
能不能hook：hook的原理是什么，
load方法和普通方法有什么不同？什么時(shí)機(jī)hook：我們經(jīng)常在
load方法中hook其他方法，那hookload方法在什么時(shí)機(jī)呢？
能不能hook?
首先，我們看下Objc中方法交換的原理，下面是一段典型的實(shí)現(xiàn)方法交換的代碼：
Class class = [self class];
// 原方法名和替換方法名
SEL originalSelector = @selector(isEqualToString:);
SEL swizzledSelector = @selector(swizzle_IsEqualToString:);
// 原方法和替換方法
Method originalMethod = class_getInstanceMethod(class, originalSelector);
Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
// 如果當(dāng)前類沒有原方法的實(shí)現(xiàn)IMP，先調(diào)用class_addMethod來給原方法添加實(shí)現(xiàn)
BOOL didAddMethod = class_addMethod(class,
originalSelector,
method_getImplementation(swizzledMethod),
method_getTypeEncoding(swizzledMethod));
if (didAddMethod) {// 添加方法實(shí)現(xiàn)IMP成功后，替換方法實(shí)現(xiàn)
class_replaceMethod(class,
swizzledSelector,
method_getImplementation(originalMethod),
method_getTypeEncoding(originalMethod));
} else { // 有原方法，交換兩個(gè)方法的實(shí)現(xiàn)
method_exchangeImplementations(originalMethod, swizzledMethod);
}
其中實(shí)現(xiàn)交換的關(guān)鍵方法是class_replaceMethod 和 method_exchangeImplementations，我們分別看下這兩個(gè)方法的實(shí)現(xiàn)原理（源碼來自：objc-runtime-new.mm）。
-
class_replaceMethodIMP class_replaceMethod(Class cls, SEL name, IMP imp, const char *types) { if (!cls) return nil; mutex_locker_t lock(runtimeLock); return addMethod(cls, name, imp, types ?: "", YES); }class_replaceMethod實(shí)際上調(diào)用的addMethods，入?yún)?code>replace = YES，我們看下addMethods的實(shí)現(xiàn)：static IMP addMethod(Class cls, SEL name, IMP imp, const char *types, bool replace) { IMP result = nil; runtimeLock.assertLocked(); checkIsKnownClass(cls); ASSERT(types); ASSERT(cls->isRealized()); method_t *m; if ((m = getMethodNoSuper_nolock(cls, name))) { // already exists if (!replace) { result = m->imp; } else { result = _method_setImplementation(cls, m, imp); } } else { // fixme optimize method_list_t *newlist; newlist = (method_list_t *)calloc(sizeof(*newlist), 1); newlist->entsizeAndFlags = (uint32_t)sizeof(method_t) | fixed_up_method_list; newlist->count = 1; newlist->first.name = name; newlist->first.types = strdupIfMutable(types); newlist->first.imp = imp; prepareMethodLists(cls, &newlist, 1, NO, NO); cls->data()->methods.attachLists(&newlist, 1); flushCaches(cls); result = nil; } return result; }addMethods中最終調(diào)用_method_setImplementation來替換Method的imp來實(shí)現(xiàn)方法替換：static IMP _method_setImplementation(Class cls, method_t *m, IMP imp) { runtimeLock.assertLocked(); if (!m) return nil; if (!imp) return nil; IMP old = m->imp; m->imp = imp; // Cache updates are slow if cls is nil (i.e. unknown) // RR/AWZ updates are slow if cls is nil (i.e. unknown) // fixme build list of classes whose Methods are known externally? flushCaches(cls); adjustCustomFlagsForMethodChange(cls, m); return old; } -
method_exchangeImplementationsmethod_exchangeImplementations的實(shí)現(xiàn)相對簡單：void method_exchangeImplementations(Method m1, Method m2) { if (!m1 || !m2) return; mutex_locker_t lock(runtimeLock); //交換IMP IMP m1_imp = m1->imp; m1->imp = m2->imp; m2->imp = m1_imp; // RR/AWZ updates are slow because class is unknown // Cache updates are slow because class is unknown // fixme build list of classes whose Methods are known externally? flushCaches(nil); adjustCustomFlagsForMethodChange(nil, m1); adjustCustomFlagsForMethodChange(nil, m2); }方法交換的核心是通過交換Method的imp來實(shí)現(xiàn)交換方法，而
method_exchangeImplementations入?yún)⑹?code>Method，Method通過class_getClassMethod或者class_getInstanceMethod獲取。class_getClassMethod最終還是調(diào)用的class_getInstanceMethod（注意：這里為什么用cls->getMeta()，我們后面介紹）：Method class_getClassMethod(Class cls, SEL sel) { if (!cls || !sel) return nil; return class_getInstanceMethod(cls->getMeta(), sel); }class_getInstanceMethod最終通過搜索方法列表找到對應(yīng)方法（調(diào)用棧較長，這里就不提供源碼了）。
通過上面的分析：如果load方法在類的方法列表中，就能實(shí)現(xiàn)方法交換。我們新建個(gè)帶個(gè)load和替換方法swizzle_load的類：
@implementation ClassA
+ (void)load {
NSLog(@"load");
}
+ (void)swizzle_load {
NSLog(@"swizzle_load");
}
@end
然后在main函數(shù)中寫一段測試代碼，獲取ClassA的方法列表：
void runTests (Class c ) {
unsigned int count;
Method *methods = class_copyMethodList(c, &count);
for (int i = 0; i < count; i++) {
Method method = methods[i];
SEL selector = method_getName(method);
NSString *name = NSStringFromSelector(selector);
NSLog(@"方法名：%@",name);
}
}
int main(int argc, const char * argv[]) {
@autoreleasepool {
runTests(ClassA.class);
}
return 0;
}
我們發(fā)現(xiàn)：ClassA的方法列表是空的。
為了理解這個(gè)原因，我們需要了解下元類（Meta Class）。我們知道Objc中方法的調(diào)用是通過給對象發(fā)消息實(shí)現(xiàn)的，對于實(shí)例方法是可行的，但是類方法呢？類方法的調(diào)用沒有“對象”可以發(fā)送消息。所以O(shè)bjc的設(shè)計(jì)者引入了元類：元類對象是描述類對象的類，每個(gè)類都有自己的元類，也就是類的isa指向的類，調(diào)用類方法實(shí)際上是給類的元類對象發(fā)送消息。上文中class_getClassMethod 的實(shí)現(xiàn)是調(diào)用class_getInstanceMethod并且入?yún)?cls->getMeta()正是這個(gè)原因。
了解了元類后，既然load方法是類方法，那我們嘗試獲取下ClassA元類的方法列表，將main函數(shù)中的代碼做下修改：
int main(int argc, const char * argv[]) {
@autoreleasepool {
Class metaClass = objc_getMetaClass("ClassA");
runTests(metaClass);
}
return 0;
}
HookTest[10929:9866637] 方法名：swizzle_load
HookTest[10929:9866637] 方法名：load
現(xiàn)在我們成功獲取到了ClassA的方法列表。方法列表中既然有load ，說明load方法是可以hook的了。我們新建ClassB，并且保證先調(diào)用ClassB的load方法（Compile Sources的順序：ClassB在ClassA前面），然后在ClassB中的load方法hook ClassA的load方法（注意：這里交換的是ClassA的元類的方法，其它類方法的hook同理）：
+ (void) load {
Class class = NSClassFromString(@"ClassA");
//交換的是ClassA的元類的方法
Class mateClass = objc_getMetaClass("ClassA");
// 原方法名和替換方法名
SEL originalSelector = @selector(load);
SEL swizzledSelector = @selector(swizzle_load);
// 原方法和替換方法
Method originalMethod = class_getClassMethod(class, originalSelector);
Method swizzledMethod = class_getClassMethod(class, swizzledSelector);
// 如果當(dāng)前類沒有原方法的實(shí)現(xiàn)IMP，先調(diào)用class_addMethod來給原方法添加實(shí)現(xiàn)
BOOL didAddMethod = class_addMethod(mateClass,
originalSelector,
method_getImplementation(swizzledMethod),
method_getTypeEncoding(swizzledMethod));
if (didAddMethod) {// 添加方法實(shí)現(xiàn)IMP成功后，替換方法實(shí)現(xiàn)
class_replaceMethod(mateClass,
swizzledSelector,
method_getImplementation(originalMethod),
method_getTypeEncoding(originalMethod));
} else { // 有原方法，交換兩個(gè)方法的實(shí)現(xiàn)
method_exchangeImplementations(originalMethod, swizzledMethod);
}
}
@end
運(yùn)行后發(fā)現(xiàn)：ClassA的swizzle_load方法并沒有被調(diào)用，load方法hook失敗。
什么時(shí)機(jī)hook？
上文中解決了元類、load 調(diào)用順序的問題，為什么還是失敗了呢？是不是hook的時(shí)機(jī)晚了呢？我們先來了解下load方法的調(diào)用原理，我們在ClassA的load方法打個(gè)斷點(diǎn)，看下調(diào)用棧：
動(dòng)態(tài)鏈接器dyld完成對二進(jìn)制文件（動(dòng)態(tài)庫，可執(zhí)行文件）的初始化后通過回調(diào)函數(shù)_dyld_objc_notify_register調(diào)用load_images和call_load_methods實(shí)現(xiàn)load方法的調(diào)用：
void
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將所有類的load方法加入到list中：
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++) {
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());
add_category_to_loadable_list(cat);
}
}
prepare_load_methods中調(diào)用schedule_class_load，的實(shí)現(xiàn)如下：
static void schedule_class_load(Class cls)
{
if (!cls) return;
ASSERT(cls->isRealized()); // _read_images should realize
if (cls->data()->flags & RW_LOADED) return;
// Ensure superclass-first ordering
schedule_class_load(cls->superclass);
add_class_to_loadable_list(cls);
cls->setInfo(RW_LOADED);
}
這里主要看下add_class_to_loadable_list的實(shí)現(xiàn)：
void add_class_to_loadable_list(Class cls)
{
IMP method;
loadMethodLock.assertLocked();
method = cls->getLoadMethod();
if (!method) return; // Don't bother if cls has no +load method
if (PrintLoading) {
_objc_inform("LOAD: class '%s' scheduled for +load",
cls->nameForLogging());
}
if (loadable_classes_used == loadable_classes_allocated) {
loadable_classes_allocated = loadable_classes_allocated*2 + 16;
loadable_classes = (struct loadable_class *)
realloc(loadable_classes,
loadable_classes_allocated *
sizeof(struct loadable_class));
}
loadable_classes[loadable_classes_used].cls = cls;
loadable_classes[loadable_classes_used].method = method;
loadable_classes_used++;
}
注意這里的method只是load方法的imp，并不是Method結(jié)構(gòu)體,看下getLoadMethod的實(shí)現(xiàn)：
IMP
objc_class::getLoadMethod()
{
runtimeLock.assertLocked();
const method_list_t *mlist;
ASSERT(isRealized());
ASSERT(ISA()->isRealized());
ASSERT(!isMetaClass());
ASSERT(ISA()->isMetaClass());
mlist = ISA()->data()->ro->baseMethods();
if (mlist) {
for (const auto& meth : *mlist) {
const char *name = sel_cname(meth.name);
if (0 == strcmp(name, "load")) {
return meth.imp;
}
}
}
return nil;
}
loadable_classes 記錄了所有有load方法的類和load方法的imp，prepare_load_methods結(jié)束后通過call_load_methods調(diào)用所有的load方法：
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;
}
call_class_loads的實(shí)現(xiàn):
static void call_class_loads(void)
{
int i;
// Detach current loadable list.
struct loadable_class *classes = loadable_classes;
int used = loadable_classes_used;
loadable_classes = nil;
loadable_classes_allocated = 0;
loadable_classes_used = 0;
// Call all +loads for the detached list.
for (i = 0; i < used; i++) {
Class cls = classes[i].cls;
load_method_t load_method = (load_method_t)classes[i].method;
if (!cls) continue;
if (PrintLoading) {
_objc_inform("LOAD: +[%s load]\n", cls->nameForLogging());
}
(*load_method)(cls, @selector(load));
}
// Destroy the detached list.
if (classes) free(classes);
}
通過上面的分析，我們知道了load方法為什么hook失敗的原因：在調(diào)用load方法之前，所有有load方法的類和load方法的imp已經(jīng)被記錄到loadable_classeslist中，所以后面再交換load方法的imp就沒用了。 那么hook的操作還能提前嗎，提前到prepare_load_methods之前呢？其實(shí)是可以的，了解dyld過程的可能知道：dyld對每個(gè)二進(jìn)制文件（動(dòng)態(tài)庫，可執(zhí)行文件）都會(huì)有一個(gè)load_images的回調(diào)，而這個(gè)回調(diào)的順序也是二進(jìn)制文件的加載順序，二進(jìn)制文件的加載順序是先動(dòng)態(tài)庫，再可執(zhí)行文件（從依賴關(guān)系的葉子節(jié)點(diǎn)開始加載）。如果我們在一個(gè)動(dòng)態(tài)庫中hook可執(zhí)行文件中的某個(gè)load方法應(yīng)該可以提前到可執(zhí)行文件的prepare_load_methods之前。
將ClassB制作成動(dòng)態(tài)庫，然后加到工程中，結(jié)構(gòu)如下：
運(yùn)行下后：
HookTest[21670:10529108] swizzle_load
如果要hook某個(gè)動(dòng)態(tài)庫中的load方法呢？原理是一樣的，找到在它前面加載的動(dòng)態(tài)庫即可。
綜上，load方法是可以hook的，不過成本較高。在大型App中，load方法在整個(gè)App的啟動(dòng)耗時(shí)中可能會(huì)有比較大的占比。在做啟動(dòng)優(yōu)化的過程中，需要計(jì)算load方法的耗時(shí)，如果使用日志的方式往往工作量巨大，甚至在多二進(jìn)制文件的工程中變得不可能，上面的hook方式可以作為參考。
