[[148848]]

統(tǒng)計(jì)打點(diǎn)是 App 開發(fā)里很重要的一個(gè)環(huán)節(jié)，App 的運(yùn)行狀態(tài)、改版后的效果、用戶的各種行為等都需要打點(diǎn)，市面上也有不少可供選擇的第三方庫。 假設(shè)產(chǎn)品有這么個(gè)需求：當(dāng)用戶在詳情頁點(diǎn)擊購買按鈕時(shí)，記錄一下事件。我們實(shí)現(xiàn)起來大概會(huì)是這樣

// DetailViewController.m 
 
- (void)onBuyButtonTapped:(UIButton *)button 
{ 
// do some stuff, maybe send a request to server 
[XXXAnalytics event:kSomeEventYouDefined]; 
} 

這個(gè)需求就這樣輕松搞定了，但細(xì)細(xì)想想還是有不少問題的：

頁面上會(huì)有其他的 Button，可能每個(gè) Button 都要放上這么一段代碼。

這些統(tǒng)計(jì)其實(shí)跟具體的業(yè)務(wù)無關(guān)，沒必要跟業(yè)務(wù)代碼混雜在一起，不優(yōu)雅。

當(dāng)改版或者重構(gòu)時(shí)，有可能忘了把相應(yīng)的打點(diǎn)代碼遷移過去。

所以需要一種更好的方式來做這件事，這就是使用 AOP(Aspect-Oriented-Programming)，翻譯過來就是「面向切面編程」

通過預(yù)編譯方式和運(yùn)行期動(dòng)態(tài)代理實(shí)現(xiàn)在不修改源代碼的情況下給程序動(dòng)態(tài)統(tǒng)一添加功能的一種技術(shù)。

簡單來說，就是可以動(dòng)態(tài)的在函數(shù)調(diào)用的前后插一段代碼。iOS 可以使用 Pete Steinberger 開發(fā)的 Aspects 這個(gè)庫，大致原理是在 runtime 層，通過 swizzle method 來實(shí)現(xiàn)的。

來看一個(gè)小 Demo

[UIViewController aspect_hookSelector:@selector(viewWillAppear:) withOptions:AspectPositionAfter usingBlock:^(idaspectInfo, BOOL animated) { 
NSLog(@"View Controller %@ will appear animated: %tu", aspectInfo.instance, animated); 
} error:NULL]; 

這樣在 UIViewController 的 viewWillAppear: 被調(diào)用后，還會(huì)再調(diào)一下我們定義的 Block，這段日志就會(huì)被輸出。而打點(diǎn)正好符合這種場景：正事干完之后，額外干一些跟業(yè)務(wù)無關(guān)的事情。

上面的例子，我們通過 AOP 來做的話，大概就是這樣

// DetailViewController.m 
- (void)onBuyButtonTapped:(UIButton *)button 
{ 
// do some stuff, maybe send a request to server 
// no need to call [XXXAnalytics event:] 
} 
 
// AppDelegate.m 
- (void)setupAnalytics 
{ 
[DetailViewController aspect_hookSelector:@selector(onBuyButtonTapped:) withOptions:AspectPositionAfter usingBlock:^(idaspectInfo, BOOL animated) { 
[XXXAnalytics event:kSomeEventYouDefined]; 
} error:NULL]; 
} 

這樣統(tǒng)計(jì)代碼就從業(yè)務(wù)代碼中剝離出來了。但是又產(chǎn)生了一個(gè)新問題，多個(gè) Button Event，豈不是要寫很多行這樣的代碼，「重復(fù)」這樣的事情，作為一個(gè)程序員怎么能忍，簡單，造一個(gè)方法

- (void)trackEventWithClass:(Class)klass selector:(SEL)selector event:(NSString *)event 
{ 
[klass aspect_hookSelector:@selector(selector) withOptions:AspectPositionAfter usingBlock:^(idaspectInfo, BOOL animated) { 
[XXXAnalytics event:event]; 
} error:NULL]; 
} 

使用起來就像這樣

- (void)setupAnalytics 
{ 
[self trackEventWithClass:DetailViewController selector:@seletor(onBuyButtonTapped:) event:kSomeEventYouDefined]; 
[self trackEventWithClass:ListViewController selector:@seletor(followButtonTapped:) event:kAnotherEventYouDefined]; 
// ... 
} 

看起來又干凈了些。這時(shí)，產(chǎn)品經(jīng)理又提了個(gè)需求：當(dāng)這個(gè)按鈕點(diǎn)擊時(shí)，如果已經(jīng)登錄了，發(fā)送 EventA，如果沒有登錄則發(fā)送 EventB，也就是說，不再只是 [XXXAnalytics event:] 這么簡單了，還需要加上額外的邏輯，這也難不倒我們，加上一個(gè) block 即可。

- (void)trackEventWithClass:(Class)klass 
selector:(SEL)selector 
eventHandler:(void (^)(idaspectInfo))eventHandler 
{ 
[klass aspect_hookSelector:@selector(selector) withOptions:AspectPositionAfter usingBlock:^(idaspectInfo, BOOL animated) { 
if (eventHandler) { 
eventHandler(aspectInfo); 
} 
} error:NULL]; 
} 
 
// 使用 
[self trackEventWithClass:DetailViewController selector:@seletor(onBuyButtonTapped:) eventHandler:^(idaspectInfo){ 
user.loggedIn ? [XXXAnalytics event:EventA] : [XXXAnalytics event:EventB]; 
}]; 

好了，現(xiàn)在只要不是太復(fù)雜的打點(diǎn)邏輯(那些需要方法上下文變量的)我們都能應(yīng)付了，接下來就該等產(chǎn)品來驗(yàn)收了。產(chǎn)品搬了個(gè)凳子坐在身邊，然后點(diǎn)一下 Button，看一下 Console，被幾輪蹂躪后，產(chǎn)品也慢慢地接受了這種驗(yàn)收方式。后來某一天，忽然發(fā)現(xiàn)某一項(xiàng)或某幾項(xiàng)數(shù)據(jù)有異常，然后找到開發(fā)，瞄了一眼：哦，這個(gè)方法被重構(gòu)了。或者新加的方法忘了加統(tǒng)計(jì)了。只能等到下個(gè)版本再加上了，如果只是一般的統(tǒng)計(jì)數(shù)據(jù)倒還好，跟錢相關(guān)的就麻煩了。

那么有沒有一種直觀的驗(yàn)證方式呢？當(dāng)然，程序員是***的呀。一個(gè)理想的狀況是，產(chǎn)品打開 App 后，開啟某個(gè)開關(guān)就能看到所有會(huì)發(fā)送 Event 的按鈕，就像這樣

其中數(shù)字代表了 EventID。如何實(shí)現(xiàn)呢？還記得注冊(cè)事件時(shí)，我們有傳入 class 和 selector 么，一般我們都會(huì)有一個(gè) BaseViewController，那么就可以在 BaseViewController 的 viewDidAppear: 里做點(diǎn)文章了。

// BaseViewController.m 
- (void)viewDidAppear:(BOOL)animated 
{ 
[super viewDidAppear:animated]; 
// 獲取已經(jīng)注冊(cè)過的 classes 
NSDictionary *registeredClasses = [OurAnalytics sharedInstance].registeredClasses; 
 
[registeredClasses enumerateKeysAndObjectsUsingBlock:^(NSString *className, NSArray *selectors, BOOL *stop) { 
if ([self isKindOfClass:NSClassFromString(className)]) { 
// 如何根據(jù) selector 找到它的宿主？ 
} 
}]; 
} 

所以現(xiàn)在問題就剩下，如何根據(jù) selector 找到對(duì)應(yīng)的 Button，這里要注意，有些 Button 可能要等網(wǎng)絡(luò)請(qǐng)求完成才會(huì)出現(xiàn)，比如 TableViewCell 里的 Button。

沒有想到太方便的方法，簡單粗暴點(diǎn)就是設(shè)置個(gè) Timer 每隔一段時(shí)間掃一下 subviews，如果是 button 或 包含 tapGesture 的，就拿它們的 action 對(duì)比一下，如果 match 就可以高亮那個(gè) button / view 了。

EventID 也一樣，之前在注冊(cè)時(shí)也會(huì)傳一個(gè) EventID 過來，這里直接顯示出來即可。對(duì)于那些傳 eventHandler 的就不行了。

所以理論上是可行的，性能上會(huì)稍微有點(diǎn)損耗，尤其是當(dāng) subViews 的結(jié)構(gòu)比較復(fù)雜時(shí)，不過只是內(nèi)部用來做驗(yàn)證，所以這也不是什么問題。

看起來效果已經(jīng)不錯(cuò)了，有沒有可能讓這套體系再靈活一些？比如可以從后端制定打點(diǎn)規(guī)則？客戶端只是讀取一個(gè)配置文件，就像這樣

- (void)setupAnalytics 
{ 
// analyticsRules 是從配置文件中讀取出來的 
[analyticsRules enumerateObjectsUsingBlock:^(NSDictionary *rules, NSUInteger idx, BOOL *stop) { 
Class klass = NSClassFromString(rules[@"class"]); 
SEL selector = NSSelectorFromString(rules[@"selector"]); 
NSString *eventID = rules[@"eventID"]; 
[self trackEventWithClass:klass seletor:seletor event: eventID]; 
}]; 
} 

那如果在后臺(tái)的時(shí)候填錯(cuò)了 Class 或 Selector 怎么辦？還好有 objc_getClassList 和 class_copyMethodList 這兩個(gè)運(yùn)行時(shí)方法，有了它們就可以在 App 啟動(dòng)時(shí)掃一遍已注冊(cè)的類（過濾掉 UI / NS 開頭的），然后將它們的 seletor 也一并保存下來發(fā)送給服務(wù)端，當(dāng)然這種操作只需在適當(dāng)?shù)臅r(shí)機(jī)做一下就可以了，比如集成打包時(shí)。

現(xiàn)在，這套體系就比較完整了。當(dāng)然這只是我的一些構(gòu)想，并沒有在實(shí)踐中嘗試過，所以肯定會(huì)踩到各種各樣的坑，不過至少看起來是個(gè)可行的方案。