本文由 作者：@MicroCai 授權轉載

這兩天在搞一個統計模塊，把碰到的問題和一些討論記錄下來，所以本文沒有答案，沒有解決方案，僅是討論而已。

我要做什麼？

我現在做的是一個 app 裡面的用戶行為統計，簡單來說就是記錄下用戶從哪個頁面跳轉到哪個頁面，在頁面上都點擊了哪些按鈕，點擊了幾次等等之類的東西。

統計工具用的是現成的 Google Analytics，Flurry，MixPanel，我要做的就是將他們集成進我的統計模塊代碼，並進行各種業務事件的統計。

以 Flurry 為例，當點擊登錄按鈕 clickShootButtonAction 被調用要做一條用戶行為統計，統計代碼是這樣的

-?(IBAction)clickShootButtonAction
{
????//?執行下面這句話，在?Flurry?的後台就能看到這個事件的記錄
????[Flurry?logEvent:@"點擊拍照按鈕"];
}

或者

-?(IBAction)clickShootButtonAction
{
????//?執行下面這句話，在?Flurry?的後台就能看到這個事件的記錄
????//?與上面不同的是，這邊記錄的是用戶的一條行為路徑
????//?表示：用戶拍照後，在照片分享頁，將照片分享到了?Facebook
????[Flurry?logEvent:@"保存分享照片"?withParameters:{@"分享到":@"Facebook"}];
}

而在應用裡面記錄上百個用戶行為是很正常的事情。也就說類似上面的這種代碼在 Controller 裡面可能要出現幾百次，還散落在各處。

這是正常的嗎？

如果這些代碼遍布我們的工程，使得統計模塊和業務代碼耦合度極高，造成剝離困難，無法重用等等各種的問題，寫起來手累心也累。

對我們來說，最理想的情況下，Controller 裡面這種代碼越少越好，最好是一行都沒有，包含個頭文件就能自動統計那該多好。因為如果要剝離統計代碼，或者更換統計方式，都是非常方便。

但實際情況不容樂觀！！！

有解嗎？

根據統計的事件，我們把需要統計的方法大致歸類為以下三種，統計剝離的難度也逐級遞增

• 類似 viewDidLoad、viewWillAppear 這種 ViewController 的生命周期的方法；

• 調用就進行一次事件統計的方法；

• 在方法內，滿足條件才統計的方法；

那麼問題來了，如果我們不希望在 Controller 裡面直接添加統計代碼，應該怎麼統計上面的三種方法？

剝離統計 ViewController 生命周期的統計代碼

這類方法的統計比較簡單，寫個 UIViewController 的 category，hook UIViewController 的中需要統計的方法，然後將頭文件塞到要統計的 ViewController 即可。

剝離調用一次就統計的統計代碼

這個統計代碼的剝離比較麻煩，麻煩的點在於這些方法是根據業務邏輯產生的，每個 ViewController 中的方法都不一致，沒法用統一的方式來處理。

關於這類代碼的剝離，我查了一些資料，請教一些同學，又在一些技術群討論了下，確實可以剝離，但方法都不太可靠，所以不建議使用，以下一一列舉。

• 方法一：AOP + SPOC 配置文件?

這個方法來自最近微博上傳的《禅與 Objective-C 編程藝術》最後一小節 面向切面編程 中。通過在 SPOC 配置文件中添加類名和方法，hook 類裡面的方法，然後進行統計。

乍看之下，這個思路非常不錯，寫起來爽歪歪，要添加統計代碼時，只要在配置文件中加一下就 OK，嗨到不行。但後來一想這種方式實際執行起來是會有問題的。

首先統計模塊代碼和業務代碼是分散在兩個地方，統計是根據具體的類名和方法名的字符串來 hook 後進行統計操作。因為統計模塊比較獨立，由一個單獨的人來寫，其他人去寫業務代碼。業務開發的同學隨意修改個方法名還是比較正常的。當業務開發的同學改了個方法名，一般不會想到統計這邊也要改；統計這邊的同學也不知道業務的同學改了什麼。所以這種只有調試時，碰到統計異常才會去檢查這裡，可維護性太差。

所以這種方法是寫的人爽，維護的人非常非常的不爽！?

所以這種不推薦使用！

• 方法二：約定方法名?

從開發的開始就約定好，比如需要統計的函數（例如 IBAction 之類的，按照約定命名），然後 hook objc-sendmessage 函數，統計所需的方法。這個方法其實和方法一類似，所以也有同樣的問題。而且人為約定沒有特別強的約束力，稍不留神就忘了方法名的約定，而且也沒有編譯器警告、錯誤的提示，根本就不會想到這時候要按照約定的規則命名。再且需求是經常變動的，有些原先不需要統計的內容，後來突然又要統計了，按照這種規則就要改方法名，整體的感覺就是場面太混亂了。

所以這種也不推薦使用！

剝離滿足條件才統計的統計代碼

無解！

想過去真真是無解啊！因為我們前面所用的方法和思路基本離不開 AOP，而 AOP 本身是 hook 一整個方法，在方法前後添加一些自定義的操作。AOP 是沒有辦法了解方法內部是什麼樣的，更何談去統計方法內滿足了一定條件再統計事件。

怎麼辦？

老老實實的將統計代碼寫到相關的方法裡面吧，真沒轍了！

最後的憂傷

折騰了這麼些來回，結果還是沒法將統計代碼和業務代碼分開。原以為統計模塊應該是一個獨立的模塊，結果卻捅到各個 Controller 代碼裡面去，實在令人憂傷。

那麼到底是什麼原因造成了這樣一個結局？

回頭看看，我們一開始就默認了統計模塊是一個獨立的模塊，應該與業務邏輯分開來。但實際上統計是和業務緊密結合的一個模塊，所以是不是可以這麼想。統計模塊的代碼也屬於業務邏輯呢？

不管怎樣，這麼想就可以心安理得的把統計代碼寫進 Controller 了~