統計打點是 App 開發裡很重要的一個環節，App 的執行狀態、改版後的效果、使用者的各種行為等都需要打點，市面上也有不少可供選擇的第三方庫。 假設產品有這麼個需求：當使用者在詳情頁點選購買按鈕時，記錄一下事件。我們實現起來大概會是這樣
|
1 2 3 4 5 6 7 |
// DetailViewController.m - (void)onBuyButtonTapped:(UIButton *)button { // do some stuff, maybe send a request to server [XXXAnalytics event:kSomeEventYouDefined]; } |
這個需求就這樣輕鬆搞定了，但細細想想還是有不少問題的：
- 頁面上會有其他的 Button，可能每個 Button 都要放上這麼一段程式碼。
- 這些統計其實跟具體的業務無關，沒必要跟業務程式碼混雜在一起，不優雅。
- 當改版或者重構時，有可能忘了把相應的打點程式碼遷移過去。
所以需要一種更好的方式來做這件事，這就是使用 AOP(Aspect-Oriented-Programming)，翻譯過來就是「面向切面程式設計」
通過預編譯方式和執行期動態代理實現在不修改原始碼的情況下給程式動態統一新增功能的一種技術。
簡單來說，就是可以動態的在函式呼叫的前後插一段程式碼。iOS 可以使用 Pete Steinberger 開發的 Aspects 這個庫，大致原理是在 runtime 層，通過 swizzle method 來實現的。
來看一個小 Demo
|
1 2 3 |
[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 來做的話，大概就是這樣
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// 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]; } |
這樣統計程式碼就從業務程式碼中剝離出來了。但是又產生了一個新問題，多個 Button Event，豈不是要寫很多行這樣的程式碼，「重複」這樣的事情，作為一個程式設計師怎麼能忍，簡單，造一個方法
|
1 2 3 4 5 6 |
- (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]; } |
使用起來就像這樣
|
1 2 3 4 5 6 |
- (void)setupAnalytics { [self trackEventWithClass:DetailViewController selector:@seletor(onBuyButtonTapped:) event:kSomeEventYouDefined]; [self trackEventWithClass:ListViewController selector:@seletor(followButtonTapped:) event:kAnotherEventYouDefined]; // ... } |
看起來又幹淨了些。這時，產品經理又提了個需求：當這個按鈕點選時，如果已經登入了，傳送 EventA，如果沒有登入則傳送 EventB，也就是說，不再只是 [XXXAnalytics event:] 這麼簡單了，還需要加上額外的邏輯，這也難不倒我們，加上一個 block 即可。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
- (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，被幾輪蹂躪後，產品也慢慢地接受了這種驗收方式。後來某一天，忽然發現某一項或某幾項資料有異常，然後找到開發，瞄了一眼：哦，這個方法被重構了。或者新加的方法忘了加統計了。只能等到下個版本再加上了，如果只是一般的統計資料倒還好，跟錢相關的就麻煩了。
那麼有沒有一種直觀的驗證方式呢？當然，程式設計師是萬能的呀。一個理想的狀況是，產品開啟 App 後，開啟某個開關就能看到所有會傳送 Event 的按鈕，就像這樣
其中數字代表了 EventID。如何實現呢？還記得註冊事件時，我們有傳入 class 和 selector 麼，一般我們都會有一個 BaseViewController，那麼就可以在 BaseViewController 的 viewDidAppear: 裡做點文章了。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
// 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 的結構比較複雜時，不過只是內部用來做驗證，所以這也不是什麼問題。
看起來效果已經不錯了，有沒有可能讓這套體系再靈活一些？比如可以從後端制定打點規則？客戶端只是讀取一個配置檔案，就像這樣
|
1 2 3 4 5 6 7 8 9 10 |
- (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 也一併儲存下來傳送給服務端，當然這種操作只需在適當的時機做一下就可以了，比如整合打包時。
現在，這套體系就比較完整了。當然這只是我的一些構想，並沒有在實踐中嘗試過，所以肯定會踩到各種各樣的坑，不過至少看起來是個可行的方案。