緣起：無線時代，APP流量敏感，為了統計APP內使用者行為，或者需要收集某些產品資料，往往需要進行日誌上報，日誌上報往往又非常費流量，有沒有一些好的節省流量的優化方法呢，這是本文將要討論的問題。

一、APP可不可以不進行日誌上報，而單純從伺服器日誌統計使用者的行為和產品資料？

答：不行，有些使用者行為是不會與伺服器進行互動的（例如TAB的點選），從伺服器日誌無法完成所有統計。

二、APP通常有一些什麼方法來上報日誌？

答：常用方法有三種：

1）利用類似於Google Analytics的第三方工具進行上報

2）自己制訂私有協議進行上報（例如TCP二進位制協議），優點是節省流量，缺點是開發成本高

3）使用HTTP上報，例如通過GET引數傳遞需要上報的資料，這種方案使用最為廣泛。

三、APP上報日誌協議細節是怎麼樣的？

答：一般是在web-server下放置一個空檔案，APP通過發起HTTP請求訪問這個空檔案，通過GET引數傳遞資料，通過分析access日誌來得到想要的資料。GET協議一般又有兩種方式，約定格式法
+ KV法

1）約定格式法：約定分隔符，約定佔位符，約定每個欄位的含義，例如：

http://daojia.com/up?[bj][20151021][1939][1][login]

APP和server約定好，空白檔案是up，分隔符是[]，第一個欄位[bj]是城市，第二個欄位[20151021]是日期，第三個欄位[1939]是時間，第四個欄位[1]是使用者id，第五個欄位[login]是行為

這個方法的缺點是，擴充套件性較差，有時候某些欄位沒有值，也必須在相應的位置保留佔位符（因為每個欄位是什麼含義都是事先約定好的），要想新增統計項，只能在GET後面新增[]

2）KV法：通過自解釋的kv方式來上報資料，上面的例子用KV法來上報，則上報形式為：

http://daojia.com/up?city=bj&date=20151021&time=1939&uid=1&action=login

這個方法的優點是擴充套件性好（好太多了），缺點是上報資料量比較大，KEY其實是冗餘的字元

筆者強烈建議使用第二種方法來上報資料，後文會簡述一些流量的優化方法。

四、APP上報日誌，流量很大，主要矛盾是什麼？

答：筆者瞭解到的主要矛盾有：

1）無效的流量較多，HTTP請求內有很多無效資料

2）URL冗餘，每次都要上報URL

3）KEY冗餘，每次都要上報KEY

4）上報頻度高，每當使用者進行了一個操作都要日誌上報的話，HTTP量還是很大的。

五、有什麼優化的方法？

答：針對上述1）-4）的主要矛盾，逐一進行優化：

1）手動構造HTTP請求，儘可能多的去除HTTP中的無效資料，只保留GET /up
HTTP/1.1和GET傳遞的資料

2）使用盡可能短的域名來接收上報的日誌，例如s.daojia.cn/a

3）使用盡可能短的KEY來標識資料，例如city=bj可以優化為c=bj，日誌收集方注意規範好KEY

4）批量非實時上報，先將資料儲存到APP本地儲存（例如sqlite中），定時上報，這類優化對於PV類，SUM類，AVG類統計尤為有效，例如，要統計登入按鈕的點選次數，三次點選，傳統統計可能需要上報三次

http://daojia.com/up?city=bj&date=20151021&time=1939&uid=1&action=login

http://daojia.com/up?city=bj&date=20151021&time=1939&uid=1&action=login

http://daojia.com/up?city=bj&date=20151021&time=1939&uid=1&action=login

優化後，只需要上報一次（注意加了一個count=3的引數）

http://daojia.com/up?city=bj&date=20151021&time=1939&uid=1&action=login&count=3

六、非實時上報，資料時效性怎麼保證？在什麼時機進行日誌上報呢？

答：資料的時效性會有一定的影響，但問題不大。為了優化，會在這樣的一些時間點進行上報：

1）特殊時間點：APP開啟時，APP關閉時等

2）按時間上報：例如每隔10分鐘上報一次

3）按資料量上報：例如每收集10條記錄才上報一次

一般來說上述三種優化方法會結合進行。

七、還有其他什麼優化方案？

答：資料壓縮也是一種常見的優化方案。