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

// DetailViewController.m

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

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

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

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

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

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

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

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

來看一個小 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: 被調用後，還會再調一下我們定義的 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:^(idaspectInfo, BOOL animated) {
        [XXXAnalytics event:kSomeEventYouDefined];
    } error:NULL];
}

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

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

看起來又干淨了些。這時，產品經理又提了個需求：當這個按鈕點擊時，如果已經登錄了，發送 EventA，如果沒有登錄則發送 EventB，也就是說，不再只是 [XXXAnalytics event:] 這麼簡單了，還需要加上額外的邏輯，這也難不倒我們，加上一個 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];
}];

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

那麼有沒有一種直觀的驗證方式呢？當然，程序員是萬能的呀。一個理想的狀況是，產品打開 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 的結構比較復雜時，不過只是內部用來做驗證，所以這也不是什麼問題。

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

- (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 也一並保存下來發送給服務端，當然這種操作只需在適當的時機做一下就可以了，比如集成打包時。

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