iOS 打点方案设计
一、背景
业务扩展的需要，对用户行为数据的收集和分析也就日益重要，前期实现的打点方案是直接在业务代码中埋点，与业务结合的太深，无法跨app使用，且开发测试都比较麻烦。基于以上，我们设计了统计sdk，用以解决开发和测试成本，降低客户端打点的复杂度。
二、业务分析
打点类型
- pageView打点，页面显示后提交的打点
- pageClick打点，用户点击事件产生的用户行为打点
- pageExchange打点，打开新的页面窗口，纪录页面流转的打点
- exposure打点，用户浏览时，曝光产品的打点
- mobile_log打点，用来记录一些不是用户交互行为的打点
行为与业务数据
打点纪录的不仅仅是用户的操作行为，还需要涉及到具体用户操作的业务数据。 例如，用户点击收藏，则打点事件中应该有收藏的物品的ID或者其他属性等。用户浏览一段商品列表，曝光中应该有具体商品的信息上报，如ID，商品类型，商品sku等。
sdk的设计原则是要脱离业务数据的，但是打点的核心就是上报该有的业务数据。 经过对各种现有第三方统计sdk的调查，现有的可视化埋点， 代码埋点等， 不能实现我公司复杂的业务统计需求。为了可以跨app使用，同时尽量不添加与业务无关的统计代码，做到AOP编程。最终我们确定方案，使用runtime底层拦截所有的点击事件及相应的滑动事件，同时事先声明业务数据，绑定相应的控件，实现打点。
声明业务数据
将业务数据和界面元素绑定，形成一个包含业务数据的独特视图。技术实现上可以扩展视图的属性。
如view上 扩展 个analysisData的属性，在这个view 成的时候，定义 份业务 数据赋予analysisData。当这个view有 户操作产 打点的时候，则取 analysisData作为业务数据解析上传。针对可复用的视图类型，则需要有搭配的数据源，保证复用后取到的业务数据是用户操作的界面元素对应的业务数据。
比如，一个收藏按钮需要打点，那么开发同学，需要按sdk的规范给该按钮的扩展属性赋值，声明相应的业务数据，那么在sdk打点时，才能有业务数据上报。没有声明业务数据的用户操作默认为无打点事件。
三、模块设计
行为抓取模块
- 按钮点击事件的抓取
- 手势事件的抓取
- tableView和collectionView代理事件的抓取
抓取模块可以抓取到大部分用户的行为操作，收集模块负责这次行为是否需要统计。将需要统计的行为，按照配置解析模块的规则，进行对应的业务数据解析及封装相应的上报数据。
数据收集模块
收集模块负责判断抓取到的用户行为操作是否需要统计。将需要统计的行为，按照配置解析模块的规则，进行对应的业务数据解析及封装相应的上报数据。
数据组装模块
组装模块负责将收集模块的打点数据，根据配置文件的相应配置，组装为对应格式的上报数据，然后传递给上报模块。
打点数据存储模块
将收集模块数据结构处理好的打点数据，构建每项打点数据之间的用户行为关联，形成可以分析用户行为的打点数据链，并进行存储。根据配置文件的上报规则，选择相应的时机进行上报。
数据上报模块
负责上报打点数据。此处进行最后封装和数据加密，根据配置文件中的上报URL，上报规则，选择在适当的时机调用相应的接口，完成上报。
打点sdk主要由以上四个模块组成，类图如下：
打点sdk.jpg
四、具体技术实现
实现按钮点击事件的抓取
方法：扩展UIControl
+ (void)bzmstatistic_swizzleMethod {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[self swizzleInstanceMethod:@selector(sendAction:to:forEvent:) with:@selector(mySendAction:to:forEvent:)];
});
}
- (void)mySendAction:(SEL)action to:(nullable id)target forEvent:(nullable UIEvent *)event {
//先执行打点，在执行业务操作，因为out需要lastPageExchange
[[BZMStatisticInterceptionManager sharedInstance] control:self sendAction:action to:target forEvent:event];
[self mySendAction:action to:target forEvent:event];
}
实现手势事件的抓取
方法：扩展UITapGestureRecognizer
+ (void)bzmstatistic_swizzleMethod {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[self swizzleInstanceMethod:@selector(initWithTarget:action:) with:@selector(myInitWithTarget:action:)];
[self swizzleInstanceMethod:@selector(addTarget:action:) with:@selector(myAddTarget:action:)];
});
}
- (instancetype)myInitWithTarget:(nullable id)target action:(nullable SEL)action {
UITapGestureRecognizer *instance = [self myInitWithTarget:[BZMStatisticInterceptionManager sharedInstance] action:@selector(tapGestureRecognizerDidTap:)];
[instance myAddTarget:target action:action];
return instance;
}
- (void)myAddTarget:(id)target action:(SEL)action {
[self myAddTarget:[BZMStatisticInterceptionManager sharedInstance] action:@selector(tapGestureRecognizerDidTap:)];
[self myAddTarget:target action:action];
}
tableView和collectionView代理事件的抓取
方法：扩展对应类，交换setDelegate:方法，设置代理转发(DelegateForwarder)类为真正的collectionView的代理。
这里只列举collectionView的实现，tableView的实现和collectionView类似
@interface UICollectionView ()
@property (nonatomic, strong) UICollectionViewDelegateForwarder *delegateForward;
@end
@implementation UICollectionView (DelegateForward)
+ (void)bzmstatistic_swizzleMethod {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[self swizzleInstanceMethod:@selector(setDelegate:) with:@selector(setMyDelegate:)];
});
}
- (void)setMyDelegate:(id<UICollectionViewDelegate>)delegate {
[self setDelegateForward:nil];
if (!delegate) {
[self setMyDelegate:nil];
return;
}
UICollectionViewDelegateForwarder *delegateForwarder = [[UICollectionViewDelegateForwarder alloc] init];
delegateForwarder.delegate = delegate;
[self setDelegateForward:delegateForwarder];
[self setMyDelegate:nil];
[self setMyDelegate:delegateForwarder];
}
- (void)setDelegateForward:(UICollectionViewDelegateForwarder *)delegateForward {
objc_setAssociatedObject(self, @selector(delegateForward), delegateForward, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
}
- (UICollectionViewDelegateForwarder *)delegateForward {
return objc_getAssociatedObject(self, @selector(delegateForward));
}
代理转发类UICollectionViewDelegateForwarder内的方法实现
- (void)forwardInvocation:(NSInvocation *)invocation
{
if (invocation.selector == @selector(init)) {
//说明delegate已经被释放，不能识别当前消息的方法签名，所以这里直接return
return;
}
/* 这里要注意一下，消息转发过程中的invocation并不会retain形参，也不会weak形参，此时应该是unsafe_unretained的形参。
* 也就是说，如果不加下面的这句话，假设形参已经被释放，执行[invocation invokeWithTarget:]，调用对应target的方法时，
* 系统此时会自动retain形参，可是此时形参已经释放，是野指针，对野指针调用retain方法，会导致程序直接崩溃。
* 所以一定要加[invocation retainArguments]。
*/
[invocation retainArguments];
SEL selector = [invocation selector];
if([_delegate respondsToSelector:selector])
{
BZMStatisticInterceptionManager *sd = [BZMStatisticInterceptionManager sharedInstance];
if ([sd respondsToSelector:selector]) {
[invocation invokeWithTarget:sd];
}
[invocation invokeWithTarget:_delegate];
}
}
- (BOOL)respondsToSelector:(SEL)selector
{
BOOL resule = [_delegate respondsToSelector:selector];
return resule;
}
- (id)methodSignatureForSelector:(SEL)selector
{
if (!_delegate) {
/* 如果delegate已经被释放，此时已经没法获取这次消息的方法签名。
* delegate释放也说明了此次消息已经没用，所以只需要使程序不崩溃即可，此次消息的结果已经不重要。
* 如果直接返回nil，程序会立刻崩溃，所以这里返回NSObject的init方法的方法签名。
* 实际上此处可以返回随便写个名字的selector的签名，只需要在forwardInvocation:中识别出来即可。
*/
return [NSObject instanceMethodSignatureForSelector:@selector(init)];
}
return [(NSObject *)_delegate methodSignatureForSelector:selector];
}
五、与同行业的对比
这里主要与美团的进行了一下对比。
- 美团的方案：无痕埋点+声明埋点+代码埋点3种混合，大约70%左右的埋点需求通过无痕埋点解决，而对于另外30%的埋点需求，仍然需要使用声明式埋点和代码埋点。
- 我们的方案：声明埋点+代码埋点2种。无痕埋点要求业务字段可以通过数据关联获取，即可以通过接口返回。但是目前我们的5种业务，mobile_log打点因为不是有用户交互行为出发的，所以没法通过检测交互实现，使用了代码埋点。其他4中业务，因为要求的业务字段不可以单纯的通过接口全部获取，所以不能使用无痕打点，所以采用了声明埋点这种方式。
对比之后可以看出，我们现在的方案缺点为：没有无痕埋点。优点为：我们的方案可以通过消息转发的方式，实现exposure这种业务的声明打点。我们的方案还多了动态配置的一些功能，比如动态配置上报时间或者上报条数，动态调整上报数据的格式及相应字段等，这些是目前美团没有实现的。
感谢小组成员littlewish的帮助及整理。
