iOS: runtime swizzle应用之-CXAppDel
写在前面
runtime中的Method Swizzling技术被称为OC的"黑魔法",iOS的hook技术都是由ta来实现的.本文通过解析 CXAppDeleagte 这个三方库的源码来讲解一下swizzle技术的实现和在实际开发中的应用
CXAppDeleagte的功能
首先讲解一下CXAppDeleagte的作用:
ta可以实现把AppDelegate中的业务逻辑拆分成多个模块.比如说你的AppDelegate中有三方库初始化, 新手教程展示逻辑, 广告业务的初始化等等功能, 代码都堆积在AppDelegate中会变得难以维护, 通过使用CXAppDeleagte可以让多个自定义的类文件注册响应程序的生命周期. 即把程序的生命周期响应事件分发给 A_AppDelegate, B_AppDelegate, C_AppDelegate.
CXAppDeleagte中只有一个类 - TYModule, 只看.h代码就能掌握其用法:
@interface TYModule : NSObject
/** 根据class注册 appdelegate 的方法调用 推荐用这个 */
+ (void)registerAppDelegateClass:(nonnull Class)cla;
/** 根据对象注册 appdelegate 的方法调用 注册后会持有该对象，酌情使用<单例的话就无所谓了> */
+ (void)registerAppDelegateObject:(nonnull id)obj;
@end
很简单,只有两个方法.作用分别是根据class注册或者根据对象注册,来响应程序的生命周期.
CXAppDeleagte的原理
想明白CXAppDeleagte的原理, 首先需要知道Method Swizzling能做什么. 举个简单的例子: 项目中有类A_Class, 其中有一个函数叫A_Function, 当你需要在A_Function调用时执行一些代码,但是又不想把代码直接写在A_Function里时, 你就可以创建一个B_Class, 在B_Class中增加B_Function, 并通过swizzle交换A_Function和B_Function的实现. 这样其他代码调用A_Function时, 会执行B_Function的代码块. 这样你就可以在B_Function中写你想要执行的代码, 并在执行结束之后继续执行A_Function里原有的代码.
当你明白Method Swizzling的功能之后, CXAppDeleagte的原理就很好理解了, 它把程序生命周期的响应函数swizzle到自己的方法中, 并分发给注册过的类和对象, 以此来实现多个类或对象响应生命周期函数.
Swizzle的实现
代码示例:
void Swizzle(Class class, SEL originalSelector, Method swizzledMethod)
{
//获取selector对应的Method
Method originalMethod = class_getInstanceMethod(class, originalSelector);
//获取Method对应的selector
SEL swizzledSelector = method_getName(swizzledMethod);
BOOL didAddMethod =
class_addMethod(class,
originalSelector,
method_getImplementation(swizzledMethod),
method_getTypeEncoding(swizzledMethod));
// 如果类中没有实现originalSelector对应的方法，那就先添加 Method，并将其 IMP 映射为 Swizzle 的实现。
// 然后替换swizzledSelector 的 IMP 为 Original 的实现；
// 否则交换二者 IMP。
if (didAddMethod && originalMethod) {
class_replaceMethod(class,
swizzledSelector,
method_getImplementation(originalMethod),
method_getTypeEncoding(originalMethod));
} else {
method_exchangeImplementations(originalMethod, swizzledMethod);
}
}
这就是一段典型的Method Swizzling的实现. 执行这段代码产生的结果是: 交换originalSelector和swizzledMethod两个函数的实现.即调用[self originalSelector]时, 代码会执行swizzledMethod.反之亦然.
熟练使用这些runtime API的话,实现swizzle其实很容易,但是深究其内部原理就需要花一些功夫, 对swizzle内部实现有兴趣的同学可以移步文章末提到的文章.
CXAppDeleagte源码解析
在了解了swizzle的作用和CXAppDeleagte的原理之后, 读源码就变的简单许多, 这里拆分讲解一下:
拦截setDelegate事件并swizzle管理生命周期响应函数:
#define ADD_SELECTOR_PREFIX(__SELECTOR__) @selector(TY_##__SELECTOR__)
#define SWIZZLE_DELEGATE_METHOD(__SELECTORSTRING__) \
Swizzle([delegate class], @selector(__SELECTORSTRING__), class_getClassMethod([TYModule class], ADD_SELECTOR_PREFIX(__SELECTORSTRING__))); \
@implementation UIApplication (DCX)
- (void)TY_setDelegate:(id <UIApplicationDelegate>)delegate {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
SWIZZLE_DELEGATE_METHOD(application: willFinishLaunchingWithOptions:);
SWIZZLE_DELEGATE_METHOD(application: didFinishLaunchingWithOptions:);
//swizzle其他的生命周期函数
......
});
[self TY_setDelegate:delegate];
}
@end
@implementation TYModule
+ (void)load {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
Swizzle([UIApplication class], @selector(setDelegate:), class_getInstanceMethod([UIApplication class], @selector(TY_setDelegate:)));
});
}
这段代码分为三部分: 1. SWIZZLE_DELEGATE_METHOD宏定义. 2. UIApplication的拓展方法TY_setDelegate. 3. TYModule的类方法 + (void)load. 这里可以看到在TYModule的load函数中, swizzle了UIApplication的setDelegate函数, 即在[UIApplication setDelegate:]之前, 会先执行TY_setDelegate中的代码.而TY_setDelegate中的宏SWIZZLE_DELEGATE_METHOD则实现了把delegate中的生命周期函数与TYModule中的自定义函数进行交换. 即在[UIApplication setDelegate:]阶段, TYModule这个类已经实现了对程序生命周期的管理.
使用两个集合记录注册过监听的类和对象:
static NSMutableSet<id> * TYModuleObjects;
static NSMutableSet<Class> * TYModuleClass;
+ (void)registerAppDelegateObject:(nonnull id) obj {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
TYModuleObjects = [NSMutableSet new];
});
[TYModuleObjects addObject:obj];
}
+ (void)registerAppDelegateClass:(nonnull Class)cla {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
TYModuleClass = [NSMutableSet new];
});
[TYModuleClass addObject:cla];
}
响应函数分发(以applicationDidBecomeActive:举例)
#define TY_APPDELEGATE_CALL_ORTHER( _cmd_, _application_, _args1_, _args2_, _args3_) \
for (id obj in TYModuleObjects) { \
if ([obj respondsToSelector:_cmd_]) { \
((void (*)(id, SEL, id , id , id , id))(void *)objc_msgSend)(obj,_cmd_,_application_,_args1_,_args2_,_args3_); \
} \
} \
for (Class cla in TYModuleClass) { \
if ([cla respondsToSelector:_cmd_]) { \
((void (*)(id, SEL, id , id , id , id))(void *)objc_msgSend)(cla,_cmd_,_application_,_args1_,_args2_,_args3_); \
} \
} \
void TY_Appdelegate_method(id _self_, SEL _cmd_, id _application_, id _args1_, id _args2_) {
SEL ty_selector = NSSelectorFromString([NSString stringWithFormat:@"TY_%@", NSStringFromSelector(_cmd_)]);
Method m = class_getClassMethod([TYModule class], ty_selector);
IMP method = method_getImplementation(m);
if (![NSStringFromSelector(_cmd_) hasPrefix:@"TY_"]) {
void (* callMethod)(id,SEL,id,id,id) = (void *)method;
callMethod(_self_,ty_selector,_application_,_args1_,_args2_);
}
TY_APPDELEGATE_CALL_ORTHER(_cmd_, _application_, _args1_, _args2_, nil)
}
@implementation TYModule
+ (void)TY_applicationDidBecomeActive:(UIApplication *)application {
TY_Appdelegate_method(self, _cmd, application, nil, nil);
}
......
@end
首先看TY_applicationDidBecomeActive, 由于已经实现了方法交换, 因此程序在调用applicationDidBecomeActive的时候会调用[TYModule TY_applicationDidBecomeActive:]. TY_Appdelegate_method里做了两件事:
-
去执行delegate里的 applicationDidBecomeActive:方法.
_cmd在Objective-C的方法中表示当前方法的selector, 但是由于TY_applicationDidBecomeActive与applicationDidBecomeActive已经交换,所以这里的cmd其实是applicationDidBecomeActive: 并不是TY_applicationDidBecomeActive. 说到这里有的同学可能会有疑问: 为什么在callMethod之前要给ty_selector拼上 "TY"的前缀呢?这样不就循环调用了吗? 其实不然,刚已经讲了,这两个方法已经进行了交换,因此调用TY_applicationDidBecomeActive时, 实际上会执行applicationDidBecomeActive的代码, 因此并不会出现循环调用的情况. -
通过调用宏TY_APPDELEGATE_CALL_ORTHER分发事件给注册过的类和对象.这个比较好理解, 在集合中取出注册过的类和对象, 执行objc_msgSend即可.
写在最后
贴几个我看过觉得不错的讲解runtime的文章.
