iOS 統計打點那些事

標籤：

1、統計代碼埋點 so easy？

統計打點是 App 開發裡很重要的一個環節，App 的運行狀態、改版後的效果、使用者的各種行為等都需要打點，市面上也有不少可供選擇的第三方庫。 假設產品有這麼個需求：當使用者在詳情頁點擊購買按鈕時，記錄一下事件。我們實現起來大概會是這樣

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

這個需求就這樣輕鬆搞定了，但細細想想還是有不少問題的：

• 頁面上會有其他的 Button，可能每個 Button 都要放上這麼一段代碼。

• 這些統計其實跟具體的業務無關，沒必要跟業務代碼混雜在一起，不優雅。

• 當改版或者重構時，有可能忘了把相應的打點代碼遷移過去。

2、AOP 實現業務代碼與統計代碼解耦

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

通過先行編譯方式和運行期動態代理實現在不修改原始碼的情況下給程式動態統一添加功能的一種技術。

簡單來說，就是可以動態在函數調用的前後插一段代碼。iOS 可以使用 Pete Steinberger 開發的 Aspects 這個庫，大致原理是在 runtime 層，通過 swizzle method 來實現的。

來看一個小 Demo

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

這樣在 UIViewController 的 viewWillAppear: 被調用後，還會再調一下我們定義的 Block，這段日誌就會被輸出。而打點正好符合這種情境：正事幹完之後，額外幹一些跟業務無關的事情。

上面的例子，我們通過 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:^(id<AspectInfo> aspectInfo, BOOL animated) {        [XXXAnalytics event:kSomeEventYouDefined];    } error:NULL];}

3、多個 Button 事件怎麼辦？

這樣統計代碼就從業務代碼中剝離出來了。但是又產生了一個新問題，多個 Button Event，豈不是要寫很多行這樣的代碼，「重複」這樣的事情，作為一個程式員怎麼能忍，簡單，造一個方法

- (void)trackEventWithClass:(Class)klass selector:(SEL)selector event:(NSString *)event{    [klass aspect_hookSelector:@selector(selector) withOptions:AspectPositionAfter usingBlock:^(id<AspectInfo> aspectInfo, 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];    // ...}

4、統計事件有選擇邏輯呢？

看起來又乾淨了些。這時，產品經理又提了個需求：當這個按鈕點擊時，如果已經登入了，發送 EventA，如果沒有登入則發送 EventB，也就是說，不再只是 [XXXAnalytics event:] 這麼簡單了，還需要加上額外的邏輯，這也難不倒我們，加上一個 block 即可。

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

好了，現在只要不是太複雜的打點邏輯(那些需要方法上下文變數的)我們都能應付了，接下來就該等產品來驗收了。產品搬了個凳子坐在身邊，然後點一下 Button，看一下 Console，被幾輪蹂躪後，產品也慢慢地接受了這種驗收方式。後來某一天，忽然發現某一項或某幾項資料有異常，然後找到開發，瞄了一眼：哦，這個方法被重構了。或者新加的方法忘了加統計了。只能等到下個版本再加上了，如果只是一般的統計資料倒還好，跟錢相關的就麻煩了。

5、如何避免統計代碼被遺忘？

那麼有沒有一種直觀的驗證方式呢？當然，程式員是萬能的呀。一個理想的狀況是，產品開啟 App 後，開啟某個開關就能看到所有會發送 Event 的按鈕，就像這樣

其中數字代表了 EventID。如何?呢？還記得註冊事件時，我們有傳入 class 和 selector 麼，一般我們都會有一個 BaseViewController，那麼就可以在 BaseViewController 的 viewDidAppear: 裡做點文章了。

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

所以現在問題就剩下，如何根據 selector 找到對應的 Button，這裡要注意，有些 Button 可能要等網路請求完成才會出現，比如 TableViewCell 裡的 Button。

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

EventID 也一樣，之前在註冊時也會傳一個 EventID 過來，這裡直接顯示出來即可。對於那些傳 eventHandler 的就不行了。

所以理論上是可行的，效能上會稍微有點損耗，尤其是當 subViews 的結構比較複雜時，不過只是內部用來做驗證，所以這也不是什麼問題。

6、如何解決 APP 埋碼要發版的問題？

看起來效果已經不錯了，有沒有可能讓這套體系再靈活一些？比如可以從後端制定打點規則？用戶端只是讀取一個設定檔，就像這樣

- (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];    }];}

那如果在背景時候填錯了 Class 或 Selector 怎麼辦？還好有 objc_getClassList 和 class_copyMethodList 這兩個運行時方法，有了它們就可以在 App 啟動時掃一遍登入的類（過濾掉 UI / NS 開頭的），然後將它們的 seletor 也一併儲存下來發送給服務端，當然這種操作只需在適當的時機做一下就可以了，比如整合打包時。

現在，這套體系就比較完整了。當然這隻是我的一些構想，並沒有在實踐中嘗試過，所以肯定會踩到各種各樣的坑，不過至少看起來是個可行的方案。

7、Refer：

[1] iOS 統計打點那些事

http://limboy.me/ios/2015/09/09/ios-analytics.html

iOS 統計打點那些事