為什麼别人家的APP，上報日志就這麼省流量？

為了統計APP内使用者行為，或者需要收集某些産品資料，APP往往需要進行日志上報，日志上報往往又非常費流量，大家的APP是怎麼上報日志的呢？

畫外音：使用者流量的大頭，是日志上報？

APP可不可以不上報日志，隻從伺服器日志統計使用者的行為和産品資料？

不行，有些使用者行為不會與伺服器進行互動，例如“卡片切換”，伺服器日志無法完成所有統計。

APP一般如何上報日志？

常用方法有這麼幾種。

（1）使用類似于Google Analytics的第三方工具；

優點：無需開發

缺點：不能做個性化統計

（2）自己制訂私有協定進行上報；

優點：節省流量

缺點：開發成本高

畫外音：例如，TCP二進制協定，可定制化，又省流量。

（3）使用HTTP協定，通過GET參數傳遞需要上報的資料。

如何通過HTTP協定進行上報？

可以在Web-Server下放置一個檔案，APP發起HTTP請求通路這個檔案，通過GET參數傳遞資料，并通過分析access日志來得到想要的資料。

如何通過GET參數傳遞資料？

一般又有兩種方式：

（1）約定格式法；

（2）KV法。

什麼是“約定格式法”？

約定格式法：約定分隔符，約定占位符，約定每個字段的含義，例如：

http://daojia.com/up?

bj1939[login]

約定如下：

（1）被通路檔案是up；

（2）分隔符是[]；

（3）第一個字段[bj]代表城市，第二個字段代表日期，第三個字段代表時間，第四個字段代表使用者id，第五個字段代表行為。

該方法缺點是：擴充性較差，有時候某些字段沒有值，也必須在相應的位置保留占位符，因為每個字段的含義都是事先約定好的，要想新增統計項，隻能在GET後面新增[]。

什麼是“KV法”？

KV法：通過GET參數自解釋的KV方式來上報資料。

上面的例子用KV法來上報，則上報形式為：

該方法的優點是：擴充性好。

缺點是：上報資料量比較大，非常消耗流量。

為什麼會這麼消耗流量呢？

之是以消耗流量，主要有這樣一些原因：

（1）無效流量多，HTTP封包有很多無效資料；

（2）URL備援，每次都要上報URL；

（3）KEY備援，每次都要上報KEY；

（4）上報頻度高，使用者每次操作都要日志上報的話，上報量很大。

有沒有節省流量的方法呢？

針對上述1-4點，常見的優化方案有這樣一些。

痛點1：HTTP請求内無效資料多。

解決方案：手動構造HTTP請求，盡可能多的去除HTTP中的無效資料。

畫外音：

如果使用第三方庫構造HTTP請求，可能會帶上你并不需要的UA資料。

自己構造，則可以隻保留GET /up HTTP/1.1和GET傳遞的必須資料；

痛點2：URL備援。

解決方案：使用盡可能短的域名來接收上報的日志。

畫外音：例如，s.daojia.cn/a

痛點3：KEY備援。

解決方案：使用盡可能短的KEY來辨別資料，日志收集方一定要統一規範好KEY。

畫外音：例如，city=bj可以優化為c=bj

一個BAD CASE，由于沒有規範，曾經某個部門上報使用者ID，不同項目中重複埋點，上報了4次：

name=shenjian&user_id=123&uid=123&user_name=shenjian

而上述name、user_id、uid、user_name都屬于重複上報。

痛點4：上報頻率高。

解決方案：先将資料儲存到APP本地存儲，再定時上報，這類優化對于PV類，SUM類，AVG類統計尤為有效。

例如，要統計登入按鈕的點選次數，三次點選，傳統統計可能需要上報三次：優化後，增加了一個參數，隻需要上報一次：

非實時上報，應該在什麼時機進行日志上報呢？

如果進行合并上報，或者批量上報，資料的時效性會有一定的影響。

畫外音：如果政策合理，資料誤差會非常小。

為了優化，會在這樣的一些時間點進行上報：

（1）特殊時間點上報：例如，APP打開，關閉，背景轉入活躍時；

（2）按時間批量上報：例如，每隔10分鐘才上報一次；

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

還有其他什麼優化方案？

批量上報，資料壓縮。

希望，文章的邏輯是清晰的。

本文轉自“架構師之路”公衆号，58沈劍提供。