【原】iOS动态性(五)一种可复用且解耦的用户统计实现(运行时Runtime)

为了达到更好的阅读效果，强烈建议跳转 到这里 查看文章。

iOS动态性是我的关于iOS运行时的系列文章，由浅入深，从理论到实践。本文是第5篇。有兴趣可以看看我之前的文章。

用户行为统计(User Behavior Statistics, UBS)一直是移动互联网产品中必不可少的环节，也俗称埋点。在保证移动端流量不会受较大影响的前提下，PM们总是希望埋点覆盖面越广越好。目前常规的做法是将埋点代码封装成工具类，但凡工程中需要埋点(如点击事件、页面跳转)的地方都插入埋点代码。一旦项目越来越复杂，你会发现埋点的代码散落在程序的各个角落，不利于维护以及复用。本文旨在 探讨 利用iOS的运行时机制实现一种可复、解耦、容易维护的用户统计方案。探讨毕竟是探讨，欢迎到留言讨论。本文虽有些长却是用心之作，希望你有耐心看完。

该方案的完成将会用到以下知识：

一、常规埋点做法

接着开头的话题，我们先回顾一下主流的埋点是怎么做的。我粗糙地将埋点分为两种：1、页面统计，包括页面停留时间、页面进入次数；2、交互事件统计，包括单击、双击、手势交互等。

1)常规页面统计埋点

以统计页面进入次数为例，最简单粗暴的做法是在所有页面的 viewDidAppear: 以及 viewDidDisappear: 中分别埋点，将自己对应的pageID上传给服务端。代码大概长酱紫：

@implementation HomeViewController //...other methods - (void)viewDidAppear:(BOOL)animated {     [super viewWillAppear:animated];     [WUserStatistics sendEventToServer:@"PAGE_EVENT_HOME_ENTER"]; }  - (void)viewDidDisappear:(BOOL)animated {     [super viewDidDisappear:animated];     [WUserStatistics sendEventToServer:@"PAGE_EVENT_HOME_LEAVE"]; } @end

+[WUserStatistics sendEventToServer:] 封装网络请求，将ID上传给服务器。上述方案有以下弊端：

第3点提到的“脏代码”意思是用户行为分析这种业务其实跟主业务没太大关系， 不应该保持如此高的耦合度 ，因为这些代码会干扰我们对项目主业务的维护。这个我个人看法。

2)常规交互事件埋点

常规做法一般在交互事件的selector中获取该事件的ID并上传给服务端，代码大概长酱紫：

- (IBAction)onFavBtnPressed:(id)sender {     [WUserStatistics sendEventToServer:@"CTRL_EVENT_HOME_FAV"];     //...do other things } 

稍微大一点的APP如果采用这种方式，那诸如此类的埋点代码将遍地都是。它的缺点参考页面统计埋点部分，其复用性基本为零，也就是在新项目中根本无法复用埋点代码。

小总结一下，采用常规的做法虽然直观方便，但在 可复用性、可维护性 等方面有所欠缺。在我看来，借助运行时可以很好地避开这些缺点。

二、Method Swizzling、Hook与代码注入

由于Runtime知识不属于本文的重点，这里只简单介绍。在iOS中，我们可以在运行时替换两个方法的实现，达到“勾住”某个方法并注入代码的目的。具体做法是:

这种技术也称为 Method Swizzling ，属于面向切面编程(Aspect-Oriented Programming)的一种实现。

替换两个方法的实现，代码一般长酱紫：

@interface WHookUtility : NSObject + (void)swizzlingInClass:(Class)cls originalSelector:(SEL)originalSelector swizzledSelector:(SEL)swizzledSelector; @end  @implementation WHookUtility  + (void)swizzlingInClass:(Class)cls originalSelector:(SEL)originalSelector swizzledSelector:(SEL)swizzledSelector {     Class class = cls;     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);     } } @end 

这个 WHookUtility 工具类下文会用到。比如现在我们要勾住 UIViewController 的 viewWillAppear: 方法，可以这样做：

@implementation UIViewController (userStastistics) + (void)load {     static dispatch_once_t onceToken;     dispatch_once(&onceToken, ^{         SEL originalSelector = @selector(viewWillAppear:);         SEL swizzledSelector = @selector(swiz_viewWillAppear:);         [WHookUtility swizzlingInClass:[self class] originalSelector:originalSelector swizzledSelector:swizzledSelector];     }); } #pragma mark - Method Swizzling - (void)swiz_viewWillAppear:(BOOL)animated {     //插入需要执行的代码     NSLog(@"我在viewWillAppear执行前偷偷插入了一段代码");     //不能干扰原来的代码流程，插入代码结束后要让本来该执行的代码继续执行     [self swiz_viewWillAppear:animated]; } @end 

更多关于Runtime、method swizzling、面向切面编程的介绍请参考这里

三、基于运行时的埋点方案

为了便于下文叙述，先引入一个简单的项目，共有两个页面( HomeViewController ， DetailViewController )，如下：

需求是

1)统计两个页面的展示与离开次数

这部分应该比较直观了，摒弃掉在每个controller中埋点的方式，我们对UIViewController添加category从而Hook到 viewWillAppear: 与 viewWillDisappear: 。在这两个方法中注入埋点代码：

这时候问题来了，项目中每个页面都会有自己的页面事件编号(pageEventID)，此处的埋点代码如何知道要发送什么pageEventID给服务端呢？轻松祭出 if-else 神器：

- (NSString *)pageEventID:(BOOL)bEnterPage {     NSString *selfClassName = NSStringFromClass([self class]);     NSString *pageEventID = nil;     if ([selfClassName isEqualToString:@"HomeViewController"]) {         pageEventID = bEnterPage ? @"EVENT_HOME_ENTER_PAGE" : @"EVENT_HOME_LEAVE_PAGE";     } else if ([selfClassName isEqualToString:@"DetailViewController"]) {         pageEventID = bEnterPage ? @"EVENT_DETAIL_ENTER_PAGE" : @"EVENT_DETAIL_LEAVE_PAGE";     }     //else if (<#expression#>)... }

当然，我们可以有更优雅的方式，比如用一个配置表替代上面一长串的 if 判断，这样无论页面数怎么增加，代码始终是那么一小段。我们新建一个 WGlobalUserStatisticsConfig.plist 的配置表来存放每个页面在进入以及离开时的pageEventID，结构如下：

因此，页面进出统计中获取pageEventID的代码始终是以下这几句：

- (NSString *)pageEventID:(BOOL)bEnterPage {     NSDictionary *configDict = [self dictionaryFromUserStatisticsConfigPlist];     NSString *selfClassName = NSStringFromClass([self class]);     return configDict[selfClassName][@"PageEventIDs"][bEnterPage ? @"Enter" : @"Leave"]; }  - (NSDictionary *)dictionaryFromUserStatisticsConfigPlist {     NSString *filePath = [[NSBundle mainBundle] pathForResource:@"WGlobalUserStatisticsConfig" ofType:@"plist"];     NSDictionary *dic = [NSDictionary dictionaryWithContentsOfFile:filePath];     return dic; }

效果如下：

以上就是完成了页面进出统计的埋点，并且达到了我们的第三点预期：对现有代码基本无影响。 通过Method Swizzling的方式现有的工程甚至不需要 import 任何文件！ 后期代码变动时需要维护的仅仅是plist配置表。

2)统计收藏、分享单击事件的次数

通过观察方法名和参数，我们有理由怀疑是倒数第二个，因其携带了不少貌似有价值的信息：

- (void)sendAction:(SEL)action to:(nullable id)target forEvent:(nullable UIEvent *)event;

于是写出测试代码看看：

@implementation UIControl (userStastistics)  + (void)load {     static dispatch_once_t onceToken;     dispatch_once(&onceToken, ^{         SEL originalSelector = @selector(sendAction:to:forEvent:);         SEL swizzledSelector = @selector(swiz_sendAction:to:forEvent:);         [WHookUtility swizzlingInClass:[self class] originalSelector:originalSelector swizzledSelector:swizzledSelector];     }); }  #pragma mark - Method Swizzling - (void)swiz_sendAction:(SEL)action to:(id)target forEvent:(UIEvent *)event; {     //插入埋点代码     [self performUserStastisticsAction:action to:target forEvent:event];     [self swiz_sendAction:action to:target forEvent:event]; }  - (void)performUserStastisticsAction:(SEL)action to:(id)target forEvent:(UIEvent *)event; {     NSLog(@"/n***hook success./n[1]action:%@/n[2]target:%@ /n[3]event:%ld", NSStringFromSelector(action), target, (long)event); } @end

Log如下图：

可以看到，通过category+method swizzling的方式在没有修改现有工程任何代码的情况下已经成功Hook到所有点击事件，在Hook代码中我们知道了一个点击事件的 target 也就是ViewController，也知道了点击事件的响应函数名，知道了点击的 TouchSet 。这些信息已经能满足埋点需求了。

与页面统计埋点类似，我们同样采用plist配置表的方式避免一大长串的 if-else 判断：

有了这张配置表就很容易得到某次单击事件的事件ID(ControlEventID)：

NSString *actionString = NSStringFromSelector(action);//获取SEL string NSString *targetName = NSStringFromClass([target class]);//viewController name NSDictionary *configDict = [self dictionaryFromUserStatisticsConfigPlist]; eventID = configDict[targetName][@"ControlEventIDs"][actionString];

埋点效果如图：

到这里先做了阶段性的总结，本文提出的思路有以下优越性：

四、基于单元测试的后期维护

俗话说，创业难守业更难。前面的思路基本可以完成初步的埋点需求。但是在实际项目中代码重构是很频繁的。这意味着在多人协作开发、代码重构频繁的项目中响应事件方法甚至页面名称都可能被改掉，造成事件ID获取不到导致埋点失效。代码变动的情况无非以下几种(这里只介绍响应事件发生改变的情况)：

单测代码如下：

- (void)testIfUserStatisticsConfigPlistValid {     NSDictionary *configDict = [self dictionaryFromUserStatisticsConfigPlist];     XCTAssertNotNil(configDict, @"WGlobalUserStatisticsConfig.plist加载失败");          [configDict enumerateKeysAndObjectsUsingBlock:^(NSString *  _Nonnull key, id  _Nonnull obj, BOOL * _Nonnull stop) {         XCTAssert([obj isKindOfClass:[NSDictionary class]], @"plist文件结构可能已经改变，请确认");         NSString *targetPageName = key;         Class pageClass = NSClassFromString(targetPageName);         id pageInstance = [[pageClass alloc] init];                  //一个pageDict对应一个页面，存放pageID,所有的action及对应的eventID         NSDictionary *pageDict = (NSDictionary *)obj;                  //页面配置信息         NSDictionary *pageEventIDDict = pageDict[@"PageEventIDs"];                  //交互配置信息         NSDictionary *controlEventIDDict = pageDict[@"ControlEventIDs"];                  XCTAssert(pageEventIDDict, @"plist文件未包含PageID字段或者该字段值为空");         XCTAssert(controlEventIDDict, @"plist文件未包含EventIDs字段或者该字段值为空");                  [pageEventIDDict enumerateKeysAndObjectsUsingBlock:^(NSString *  _Nonnull key, id  _Nonnull value, BOOL * _Nonnull stop) {             XCTAssert([value isKindOfClass:[NSString class]], @"plist文件结构可能已经改变，请确认");             XCTAssertNotNil(value, @"EVENT_ID为空，请确认");         }];                  [controlEventIDDict enumerateKeysAndObjectsUsingBlock:^(NSString *  _Nonnull key, id  _Nonnull value, BOOL * _Nonnull stop) {             XCTAssert([value isKindOfClass:[NSString class]], @"plist文件结构可能已经改变，请确认");             NSString *actionName = key;             SEL actionSel = NSSelectorFromString(actionName);             XCTAssert([pageInstance respondsToSelector:actionSel], @"代码与plist文件函数不匹配，请确认：-[%@ %@]", targetPageName, actionName);                          //EVENT_ID不能为空             XCTAssertNotNil(value, @"EVENT_ID为空，请确认");         }];     }];      }

我们来测试一下，如果把 HomeViewController 的 onFavBtnPressed: 改成 onMyFavBtnPressed: 后单元测试的结果就是：

这种改变给单测轻松捕捉到了，

上图中的log已经明确指出 -[HomeViewController onFavBtnPressed:] 方法发生了改变。

代码略。如果对单元测试不熟悉，可以参考 单元测试

小总结：合理的单元测试可以为本文方案的后期维护减轻相当大的负担，测试用例的完备性很重要，需要用心设计考虑周全。

五、结语

以上就是结合运行时所设计出的用户统计思路全部内容。应该说该方案的可复用性与解耦程度都是不错的，既适合于新建的工程，也适合于已经创建的工程。利用Method Swizzling把埋点代码集中管理其实也是合理的，有利于专人开发、跟踪及维护。当然以上思路只考虑简单的情形，更复杂的情况就需要变通了，但总体思路就是如此。

本文 demo地址 ，记得star噢！

• 喜欢本文可以点一下 喜欢 并 关注 我，或者 留个言示个爱 (抛媚眼中)
• 不喜欢可以留言提建议，我必虚心接受
• 欢迎转载