微信為啥這么省流量？

答：APP登陸時，一般要拉取兩類數據，一類是“id列表型數據”，一類是“信息詳情型數據”，以微信為例，需要拉取

（1）好友列表List<user-id>，即所有好友的id（id+name）

（2）群組列表List<group-id>，即所有加入群的id（id+name）

（3）群友列表Map<group-id, List<group-user-id>>，所有群友的id（id+name）

（4）好友詳情Map<user-id, User>，所有好友的詳情（昵稱，備注，標簽，地區(qū)，相冊等）

（5）群組詳情Map<group-id, Group>，所有群組的詳情（二維碼，公告，是否免打擾等）

（6）群友詳情Map<group-id, Map<user-id, User>>，所有群友的詳情（昵稱，備注，標簽，地區(qū)，相冊等）

（7）其他，例如離線消息…

問題二：能不能在登錄的過程中不拉取這些數據，而在登錄后拉取？

答：如果登錄時不拉取，登陸后刷好友列表，刷群列表，群成員會很慢。

如果登錄時拉取，登陸過程可能會很慢（微信的“大月亮背景”要等多長時間？QQ登錄要等30s？）。

為了保證登錄后的體驗，一般是在登錄過程中拉取。

問題三：能不能直接復用客戶端本地的數據？

答：不能直接復用客戶端本地的數據，因為不能確保本地的數據是最新的。

核心問題：每次登錄都需要拉取，太費流量了，有沒有優(yōu)化方法？

答：常用優(yōu)化方法有兩種

（1）延遲拉取，按需拉取

（2）時間戳

問題五：延遲拉取，按需拉取為什么有效？為什么能夠減少拉取流量？

答：用戶在使用APP的過程中，有些數據是一定會使用到的，有些數據是不一定會使用到的。對于一定會使用到的數據，登錄時拉取可以提升后續(xù)用戶體驗。對于不一定會使用到的數據，登錄時拉取可能浪費流量，這些數據如果進行“延遲拉取”，可以節(jié)省流量。

問題六：哪些數據不登錄后不一定會使用，可以延遲拉取？

答：這個問題的答案和業(yè)務緊密相關，以微信為例

一定會使用到的數據：好友列表（主頁面要展示user-name），群組列表（主界面要展示group-name）

不一定會使用到的數據：好友詳情，群組詳情，群友列表，群友詳情

故，對于微信，登錄時只需要拉取好友列表（id+name）與群組列表（id+name）即可，而其他數據，等用戶真正點擊和使用時再拉取即可，這樣就可以大大減少拉取流量。

問題七：時間戳為什么有效？為什么能夠減少拉取流量？

答：本地數據不能直接使用的原因是，不確定數據是否最新，拉取服務器時間戳與本地時間戳進行比對，如果本地是最新的數據，就能避免重新拉取。id列表數據的變化頻度是比較低的（增加id，減少id），時間戳機制非常的有效。

問題八：加入時間戳機制后，數據拉取流程有什么變化？

答：假設有100個好友，以好友詳情數據的拉取為例，沒有時間戳之前，直接向服務器拉取這100個好友的詳情數據。

在有了時間戳之后，數據拉取流程變?yōu)椋?/span>

（1）先拉取100個好友的時間戳

（2）客戶端將100個好友的時間戳與本地時間戳對比，找出差異，假設有10個好友的信息發(fā)生了變化，時間戳改變了

（3）拉取有變化的10個好友的信息

優(yōu)點是：大大減少了數據傳輸量（由拉取100個好友，降低到拉取10個好友）

缺點是：增加了一次網絡交互（原來直接拉取，現在需要分別拉取時間戳與差異數據）

問題九：使用時間戳的同時，能否降低網絡交互次數呢？

答：可以！

客戶端對時間戳的使用，往往采取“客戶端拉取時間戳”+“客戶端比對時間戳”+“客戶端再次拉取差異數據”的方式進行，“時間戳比對”的的CPU計算發(fā)生在客戶端，其實，這個計算可以轉嫁到服務器，步驟為：

（1）客戶端上傳100個好友的時間戳

（2）“服務端”收到客戶端上傳的時間戳，與最新時間戳對比，找出差異，假設有10個好友的信息發(fā)生了變化，服務端可以直接將有差異的10個好友的數據返回

優(yōu)點是：客戶端減少了一次網絡請求

缺點是：比對時間戳差異的CPU計算由“端”轉嫁到了“云”

問題十：你怎么知道微信是這么做的？

答：...不知道，運營需要，故...

但是，“客戶端上傳時間戳”的方法，我們曾經是這么做的，希望對業(yè)界同仁有啟示作用。