[[140437]]

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

我要做什么？

我現在做的是一個 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 了~