[[140437]]

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

我要做什么？

我現(xiàn)在做的是一個 app 里面的用戶行為統(tǒng)計(jì)，簡單來說就是記錄下用戶從哪個頁面跳轉(zhuǎn)到哪個頁面，在頁面上都點(diǎn)擊了哪些按鈕，點(diǎn)擊了幾次等等之類的東西。

統(tǒng)計(jì)工具用的是現(xiàn)成的 Google Analytics，F(xiàn)lurry，MixPanel，我要做的就是將他們集成進(jìn)我的統(tǒng)計(jì)模塊代碼，并進(jìn)行各種業(yè)務(wù)事件的統(tǒng)計(jì)。

以Flurry為例，當(dāng)點(diǎn)擊登錄按鈕clickShootButtonAction被調(diào)用要做一條用戶行為統(tǒng)計(jì)，統(tǒng)計(jì)代碼是這樣的

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

或者

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

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

這是正常的嗎？

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

對我們來說，最理想的情況下，Controller 里面這種代碼越少越好，***是一行都沒有，包含個頭文件就能自動統(tǒng)計(jì)那該多好。因?yàn)槿绻獎冸x統(tǒng)計(jì)代碼，或者更換統(tǒng)計(jì)方式，都是非常方便。

但實(shí)際情況不容樂觀！??！

有解嗎？

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

• 類似 viewDidLoad、viewWillAppear 這種 ViewController 的生命周期的方法；
• 調(diào)用就進(jìn)行一次事件統(tǒng)計(jì)的方法；
• 在方法內(nèi)，滿足條件才統(tǒng)計(jì)的方法；

那么問題來了，如果我們不希望在 Controller 里面直接添加統(tǒng)計(jì)代碼，應(yīng)該怎么統(tǒng)計(jì)上面的三種方法？

剝離統(tǒng)計(jì) ViewController 生命周期的統(tǒng)計(jì)代碼

這類方法的統(tǒng)計(jì)比較簡單，寫個 UIViewController 的 category，hook UIViewController 的中需要統(tǒng)計(jì)的方法，然后將頭文件塞到要統(tǒng)計(jì)的 ViewController 即可。

剝離調(diào)用一次就統(tǒng)計(jì)的統(tǒng)計(jì)代碼

這個統(tǒng)計(jì)代碼的剝離比較麻煩，麻煩的點(diǎn)在于這些方法是根據(jù)業(yè)務(wù)邏輯產(chǎn)生的，每個 ViewController 中的方法都不一致，沒法用統(tǒng)一的方式來處理。

關(guān)于這類代碼的剝離，我查了一些資料，請教一些同學(xué)，又在一些技術(shù)群討論了下，確實(shí)可以剝離，但方法都不太可靠，所以不建議使用，以下一一列舉。

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

這個方法來自最近上傳的《禪與 Objective-C 編程藝術(shù)》***一小節(jié) 面向切面編程 中。通過在 SPOC 配置文件中添加類名和方法，hook 類里面的方法，然后進(jìn)行統(tǒng)計(jì)。

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

首先統(tǒng)計(jì)模塊代碼和業(yè)務(wù)代碼是分散在兩個地方，統(tǒng)計(jì)是根據(jù)具體的類名和方法名的字符串來 hook 后進(jìn)行統(tǒng)計(jì)操作。因?yàn)榻y(tǒng)計(jì)模塊比較獨(dú)立，由一個單獨(dú)的人來寫，其他人去寫業(yè)務(wù)代碼。業(yè)務(wù)開發(fā)的同學(xué)隨意修改個方法名還是比較正常的。當(dāng)業(yè)務(wù)開發(fā)的同學(xué)改了個方法名，一般不會想到統(tǒng)計(jì)這邊也要改；統(tǒng)計(jì)這邊的同學(xué)也不知道業(yè)務(wù)的同學(xué)改了什么。所以這種只有調(diào)試時(shí)，碰到統(tǒng)計(jì)異常才會去檢查這里，可維護(hù)性太差。

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

所以這種不推薦使用！

• 方法二：約定方法名?

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

所以這種也不推薦使用！

剝離滿足條件才統(tǒng)計(jì)的統(tǒng)計(jì)代碼

無解！

想過去真真是無解啊！因?yàn)槲覀兦懊嫠玫姆椒ê退悸坊倦x不開 AOP，而 AOP 本身是 hook 一整個方法，在方法前后添加一些自定義的操作。AOP 是沒有辦法了解方法內(nèi)部是什么樣的，更何談去統(tǒng)計(jì)方法內(nèi)滿足了一定條件再統(tǒng)計(jì)事件。

怎么辦？

老老實(shí)實(shí)的將統(tǒng)計(jì)代碼寫到相關(guān)的方法里面吧，真沒轍了！

***的憂傷

折騰了這么些來回，結(jié)果還是沒法將統(tǒng)計(jì)代碼和業(yè)務(wù)代碼分開。原以為統(tǒng)計(jì)模塊應(yīng)該是一個獨(dú)立的模塊，結(jié)果卻捅到各個Controller代碼里面去，實(shí)在令人憂傷。

那么到底是什么原因造成了這樣一個結(jié)局？

回頭看看，我們一開始就默認(rèn)了統(tǒng)計(jì)模塊是一個獨(dú)立的模塊，應(yīng)該與業(yè)務(wù)邏輯分開來。但實(shí)際上統(tǒng)計(jì)是和業(yè)務(wù)緊密結(jié)合的一個模塊，所以是不是可以這么想。統(tǒng)計(jì)模塊的代碼也屬于業(yè)務(wù)邏輯呢？

不管怎樣，這么想就可以心安理得的把統(tǒng)計(jì)代碼寫進(jìn) Controller 了~