你好,歡迎來到IOS教程網

 Ios教程網 >> IOS訊息 >> 關於IOS >> 問題記錄:iOS 用戶行為統計代碼的剝離

問題記錄:iOS 用戶行為統計代碼的剝離

編輯:關於IOS

問題記錄:iOS 用戶行為統計代碼的剝離

本文由 作者:@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 了~

  1. 上一頁:
  2. 下一頁:
蘋果刷機越獄教程| IOS教程問題解答| IOS技巧綜合| IOS7技巧| IOS8教程
Copyright © Ios教程網 All Rights Reserved