iOS"添加方法"对项目代码侵入性较少的实现
最近公司项目做用户大数据信息采集，需要采集App端在页面切换/交互操作的时候需要统计页面显示/页面消失事件，要给后端统计系统发送采集logs记录。
但项目中ViewController之前没有做任何继承关系（无基类Controller），所以在几十上百个Controller的项目里，一个一个添加耗时不说，也不利于后期维护，那也是不推荐使用的蠢方法。
1、利用Objective-C 中的对象继承
继承在面向对象开发中是非常常用的。
优点：继承可以实现代码的复用，减少代码冗余。将所有重复的内容合并在一起，可以使代码有效率，简洁，才意味着是一个成功的架构。否则，修改代码时需要修改多处，就很容易出错。
缺点：继承造成类与类之间耦合性太强。
现在项目工程中都会有一个BaseViewController，所有新建的ViewController都继承BaseViewController，通过往BaseViewController中添加一些公共方法/属性可以被他们的子类所调用；这是统一工程中所有视图控制器样式的一个主要途径。
如果项目中没有ViewController基类的话，重新创建一个基类也不难。
-
新建一个BaseViewController，在所需采集统计的地方写公共方法；
-
处理项目ViewController的继承关系，将项目中默认继承ViewController的替换继承BaseViewController；
左侧边栏搜索替换
: UIViewController，替换成: XXBaseViewController
这种方法比较考验耐心和细心，更换了默认的继承关系。会更改很多类，侵入性虽说很大。但考虑到以后的维护成本，在控制器类还不庞大的情况下，建议使用此种方法。不能完成的是原项目已经有继承关系了，但继承关系比较负责。这时候就要更加小心（除了处理可能多个父类，还要处理没继承的控制器），相当于给他们造了一个祖宗~
2、利用Category和Runtime交换系统方法并添加方法（系统主动调用load）
load函数调用特点如下:
当类被引用进项目的时候就会执行load函数(在main函数开始执行之前）,与这个类是否被用到无关,每个类的load函数只会自动调用一次.由于load函数是系统自动加载的，因此不需要调用父类的load函数，否则父类的load函数会多次执行。
- 1、当父类和子类都实现load函数时,父类的load方法执行顺序要优先于子类；
- 2、当子类未实现load方法时,不会调用父类load方法；
- 3、类中的load方法执行顺序要优先于类别(Category)；
- 4、当有多个类别(Category)都实现了load方法,这几个load方法都会执行,但执行顺序不确定(其执行顺序与类别在Compile Sources中出现的顺序一致)；
- 5、当然当有多个不同的类的时候,每个类load 执行顺序与其在Compile Sources出现的顺序一致；
- 新建一个UIViewController 的category，引人runtime头文件
#import <objc/runtime.h>
- 重写load方法
+ (void)load {
[super load];
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
// 交换VC页面完全显示方法
__mmc_tracer_swizzleMethod([self class], @selector(viewDidAppear:), @selector(__mmc_tracer_viewDidAppear:));
// 交换VC页面完全消失方法
__mmc_tracer_swizzleMethod([self class], @selector(viewDidDisappear:), @selector(__mmc_tracer_viewDidDisappear:));
});
}
- 使用runtime实现方法交换
void __mmc_tracer_swizzleMethod(Class class, SEL originalSelector, SEL swizzledSelector){
Method originalMethod = class_getInstanceMethod(class, originalSelector);
Method swizzledMethod = class_getInstanceMethod(class, swizzledSelector);
BOOL didAddMethod =
class_addMethod(class,
originalSelector,
method_getImplementation(swizzledMethod),
method_getTypeEncoding(swizzledMethod));
if (didAddMethod) {
class_replaceMethod(class,
swizzledSelector,
method_getImplementation(originalMethod),
method_getTypeEncoding(originalMethod));
} else {
method_exchangeImplementations(originalMethod, swizzledMethod);
}
}
- 替换的交换方法中添加自己需要的采集方法（
注意：要调用自己的方法一次，因为自己也要实现被交换之前方法的内部实现），但要注意忽略系统控制器类的方法。
/** 只忽略了部分常用系统原生contrlloer
* 通过继承父类来实现 相对于hook来说 是较为准确的,因为需要被统计的页面都是继承于这个父类的控制器,而其他的如UINavigationController,系统自带的UIAlertController等则不会误入统计数据当中
*/
+ (BOOL)isIgnoreSystemViewController:(id)instance {
return
[instance isKindOfClass:[UITabBarController class]] ||
[instance isKindOfClass:[UINavigationController class]] ||
[instance isKindOfClass:[UISearchController class]] ||
[instance isKindOfClass:[UIAlertController class]] ||
[instance isKindOfClass:[UISearchController class]] ||
[instance isKindOfClass:[UIActivityViewController class]];
}
- (void)__mmc_tracer_viewDidAppear:(BOOL)animated {
[self __mmc_tracer_viewDidAppear:animated]; //由于方法已经被交换,这里调用的实际上是viewDidAppear:方法
if ([UIViewController isIgnoreSystemViewController:self]) {
//TODO: 实现页面显示的打点采集方法
}
}
- (void)__mmc_tracer_viewDidDisappear:(BOOL)animated {
[self __mmc_tracer_viewDidDisappear:animated]; //由于方法已经被交换,这里调用的实际上是viewDidDisappear:方法
if ([UIViewController isIgnoreSystemViewController:self]) {
//TODO: 实现页面消失的打点采集方法
}
}
3、利用Aspects实行方法hook （被动调用，类似通知监听）
Aspects是AOP（面向切面编程）思想在iOS下OC的实现。Aspects可以用于hook函数，让函数执行一些副操作。为嵌入不同函数中的功能相同的操作，每类功能相同的操作可以抽取出一个切面。
- OOP针对业务处理过程的实体及其属性和行为进行抽象封装，以获得更加清晰高效的逻辑单元划分；
- AOP则是针对业务处理过程中的切面进行提取，它所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果。
核心原理：当被 hook 的 selector 被执行的时候，首先根据 selector找到了
objc_msgForward / _objc_msgForward_stret,而这个会触发消息转发，从而进入forwardInvocation。同时由于forwardInvocation的指向也被修改了，因此会转入新的forwardInvocation函数，在里面执行需要嵌入的附加代码，完成之后，再转回原来的 IMP。
常用的两个方法
- 写一个内部私有方法hook所有UIViewController的所有实例的显示与消失方法，在采集类初始化的时候调用（建议：初始化方法中应该有一个是否由该采集SDK主动采集页面显示与隐藏的
BOOL参数，在该参数下初始化为最佳时机）。
/** 只忽略了部分常用系统原生contrlloer
* 通过继承父类来实现 相对于hook来说 是较为准确的,因为需要被统计的页面都是继承于这个父类的控制器,而其他的如UINavigationController,系统自带的UIAlertController等则不会误入统计数据当中
*/
- (BOOL)isIgnoreSystemViewController:(id)instance {
return
[instance isKindOfClass:[UITabBarController class]] ||
[instance isKindOfClass:[UINavigationController class]] ||
[instance isKindOfClass:[UISearchController class]] ||
[instance isKindOfClass:[UIAlertController class]] ||
[instance isKindOfClass:[UISearchController class]] ||
[instance isKindOfClass:[UIActivityViewController class]];
}
- (void)hookAllViewControllerAppearAndDisappear {
/// hook 控制器的显示和消失 分别打log
// 显示
[UIViewController aspect_hookSelector:@selector(viewDidAppear:) withOptions:AspectPositionAfter usingBlock:^(id<AspectInfo> aspectInfo, BOOL animated) {
if (![self isIgnoreSystemViewController:aspectInfo.instance]) {
// 不是忽略VC则采集
[[self class] addBeginLogPageView:NSStringFromClass([aspectInfo.instance class])];
}
} error:NULL];
// 消失
[UIViewController aspect_hookSelector:@selector(viewDidDisappear:) withOptions:AspectPositionAfter usingBlock:^(id<AspectInfo> aspectInfo, BOOL animated) {
if (![self isIgnoreSystemViewController:aspectInfo.instance]) {
// 不是忽略VC则采集
[[self class] addEndLogPageView:NSStringFromClass([aspectInfo.instance class])];
}
} error:NULL];
}
hook方案有一个好处就是可以避免代码入侵，做到更加广泛的通用性。通过swizzling我们可以将原method与自己加入的method相结合，即不需要在原有工程中加入代码，又能做到全局覆盖。
三种方案对比:
1、通过继承父类来实现，相对于hook来说，是较为准确的。因为需要被统计的页面都是继承于这个父类的控制器，而其他的如UINavigationController、UIAlertController等则不会误入统计数据当中。
2、上面提到 hook方案是通过hook UIViewController
viewDidLoad/viewDidAppear等方法，而这些方法实际上每个Controller 都会调用，那么就会出现不该出现的Controller 也出现在这里(如上面说到的UINavigationController和UIAlertController)。但hook方案一个比较好的特点是无代码入侵，在不修改项目代码的前提下完成工作。 3、两种hook的对比：分类的方法只要分类被load则就开始hook, 时机并不能自己控制，而且也不能自己开关控制是否hook或者终止hook操作。一个由程序员主动调用（Aspects），一个由系统调用（分类）。由于可控性最后还是选择了
Aspects来进行hook。但要做的是通用的大数据采集类，以后公司内部所有App都可能会用到，在不知道是哪个App有什么Controller的情况下，hook显然成了最好的方法。当然要注意筛选掉系统的Controller，避免重复采集无用的数据。 如果要做内部封装的话显然Aspects hook的方式好一点，不然的话你就要暴露出API提供给分类，或者将分类写入封装类内部。这样代码比较长不利于后期维护。还有最重要的一点就是：使用
Aspects可以留一个开关给外部，是否需要sdk帮助采集所有界面的出现和消失，或者交给使用者自己采集界面信息。
