所有的項(xiàng)目腰奋，只要到一定級別 都會涉及到此問題，它用來收集用戶操作行為抱怔，統(tǒng)計用戶的焦點(diǎn)點(diǎn)擊劣坊，以及測試page到達(dá)率，相關(guān)業(yè)務(wù)的轉(zhuǎn)化率等有著最重要的指標(biāo)屈留。公司都是根據(jù)此數(shù)據(jù)來做出決策局冰，其實(shí)高層作出決策的最重要依據(jù)，也受各大領(lǐng)導(dǎo)關(guān)注最多的東西灌危，重要性不多說康二。
現(xiàn)在，我想總結(jié)一下在我經(jīng)歷的過程中這個不是系統(tǒng)的東西變成系統(tǒng)的過程勇蝙。
1.在APP 3.0版本之前 沫勿，后端，前端都是發(fā)送最重要的統(tǒng)計數(shù)據(jù)，其只想當(dāng)于一個上傳接口产雹，將一段json串串給后端烫罩，在VC中我門通過AFNetwork，ASI 直接去網(wǎng)絡(luò)請求洽故，沒有架構(gòu)贝攒，沒有耦合，完全case to case處理 时甚，遇到一個處理一個
2.在APP 4.0版本 我們將這個單獨(dú)出來成為一個庫開出來幾個接口隘弊，大家傳入一些參數(shù)，然后這個模塊來處理 緩存荒适，上傳時機(jī) 梨熙，批處理等各種策略。這個時候的APP業(yè)務(wù)還是比較單一刀诬，相對來說 1.0 可以耦合復(fù)用 拉出來為庫即可咽扇。
3.在APP5.0版本 整個移動業(yè)務(wù) 各個公司都受夠了APP版本迭代慢的問題，開始出現(xiàn)平臺化架構(gòu)模式來滿足千變?nèi)f化的運(yùn)營需求陕壹，內(nèi)容編輯需求质欲，甚至廣告展示需求，在一個page內(nèi)可以配置出盡量多的模版糠馆。由后端來決定前段展示的樣式嘶伟，這也就造就了要統(tǒng)計的東西爆發(fā)性的增長，由于頁面都是動態(tài)的配置所以又碌，所以發(fā)送時機(jī)需求的實(shí)時化 統(tǒng)計參數(shù)的直線增長九昧，使得原有的接口已經(jīng)完全無法適應(yīng)當(dāng)前的需求，那么重構(gòu)隨之而來毕匀。
這次重構(gòu)主要解決兩個問題：
1.發(fā)送時機(jī)可控制
2.demol依托后端數(shù)據(jù)結(jié)構(gòu)铸鹰，即后端可控
3.如何平滑過渡舊版本
4.性能
解決了此問題，感覺以后再也不用折騰了皂岔，然而變化太快了蹋笼。
4.在6.0版本，伴隨著公司收購凤薛，伴隨著各個賺錢的業(yè)務(wù)均整合到移動端姓建，隨之而來的 統(tǒng)計系統(tǒng)有3到4個系統(tǒng)（各個業(yè)務(wù)以前都有自己的獨(dú)立統(tǒng)計），初始的時候缤苫，各個業(yè)務(wù)都是以庫的形勢加入速兔，這樣能快速整合進(jìn)工程享受基線帶來巨大流量變現(xiàn)，但是隨著業(yè)務(wù)加入的增多活玲，導(dǎo)致工程中集合的統(tǒng)計庫都有N個涣狗，并且各種發(fā)送時機(jī)谍婉，導(dǎo)致包一下大讓人驚人，并且有些第三方庫竟然重復(fù)N邊镀钓，隨著老大的強(qiáng)硬穗熬，這次整合也在所難免，這次重構(gòu)主要解決的問題是：
1.整合各個業(yè)務(wù)線的統(tǒng)計系統(tǒng)丁溅，以后規(guī)整成一個
2.基線所有統(tǒng)計的庫去重唤蔗，
3.各個業(yè)務(wù)可自定義參數(shù)
4.提供改變固定參數(shù)接口，以適應(yīng)特殊業(yè)務(wù)需求改變固定參數(shù)的需要窟赏。
5.提供平滑過渡方案妓柜。
