前言
套餐雖然優惠，流量還是很貴，對用戶而言網路流量就是錢吶！用戶習慣打開系統自帶 APP 流量統計功能，從 APP 的角度，總不希望用戶一眼看出自家的 APP 是流量大戶，所以有必要花時間知道 APP 的流量怎么流失的，但是系統的流量統計功能只是很粗略的對每個 APP 消耗的流量總量（分時）進行統計，但是程式員需要對 APP 的流量進行更精細、多維度的分析，從而有針對性地優化 APP 資料流量，所以有了以下幾種方案，
（該文不僅僅包括流量優化，文末還列舉了Android程式各類性能優化，請慢慢閱讀）
一、資料快取
OkHttp 快取
如果我們仔細跟一下自己專案中的介面，就會發現很多對實時性沒有那么高要求的介面，使用快取不僅可以節約流量，而且能大幅提升資料訪問速度，
我們常用的網路庫，比如 OkHttp 和 Volley，都有比較好的快取實踐，
而且沒做快取對用戶體驗也不好，一般的 App 會在打開后顯示一個無資料的界面，和展示上一次的資料相比，這個用戶體驗其實是比較差的，
1. 無網攔截器
下面我們重點看下 OkHttp 的快取實踐，首先定義一個無網攔截器，
然后是給 OkHttpClient 添加攔截器，
添加了無網路攔截器后，當無網路的情況下打開我們的 App 時，也能獲取到上一次的資料，也能使用 App，這樣就能提升用戶體驗，
2. OkHttp 快取處理流程
OkHttp 的快取攔截器對于請求的處理流程如下，
過期時間與增量更新
1. 過期時間
在服務端回傳的資料中加上一個過期時間，這樣我們每次請求的時候判斷一下有沒有過期，如果沒有過期就不需要去重新請求，
2. 增量更新
資料增量更新的具體思路，就是在資料中加上一個版本的概念，每次接收資料都進行版本對比，只接收有變化的資料，
這樣傳輸的資料量就會減少很多，比如省市區和配置等資料比較少更新，如果每次都要請求省市區的資料，這就是在浪費流量，
我們只需要更新發生變化的資料，因為和服務器相關比較密切，在這里就不給大家舉例了，
二、資料壓縮
1. Gzip
對于 Post 請求，Body 是用 Gzip 壓縮的，也就是請求的時候帶上 Gzip 請求頭，服務端回傳的時候也加上 Gzip 壓縮，這樣資料流就是被壓縮過的，
2. 壓縮請求頭
請求頭也占用一定的體積，在請求頭不變的情況下，我們可以只傳遞一次，以后都只需要傳遞上一次請求頭的 MD5 值，服務端做一個快取，在需要請求頭中的某些資訊時，就可以直接從之前的快取中取，
3. 合并網路請求
每一個網路請求都會有冗余資訊，比如請求頭，而合并網路請求就可以減少冗余資訊的傳遞；
三、圖片壓縮
1. 縮略圖
圖片壓縮的第一個手段，就是在串列中優先使用縮略圖，因為展示原圖會加大記憶體消耗和流量消耗，而且在串列中直接展示原圖沒有意義，
下面是原圖和縮略圖的對比大小，縮略圖尺寸為原圖的 50%，大小為原圖的 10%，
2. WebP
圖片壓縮的第二個手段，就是使用 Webp 格式，下面是同一張圖片在 PNG 格式和 WebP 格式下的對比，WebP 格式的大小為 PNG 格式的 51%，
3. Luban
比如我們在上傳圖片的時候，做一個壓縮比如在本地是一個 2M 的圖片，完整地上傳上去意義不大，只會增加我們的流量消耗，最好是壓縮后再上傳，
而在圖片壓縮上做得比較好的就是魯班，下面我們來看下魯班的使用方法，
首先添加依賴，
dependencies {
// 圖片壓縮
implementation 'top.zibin:Luban:1.1.8'
}
然后添加對圖片進行壓縮，
下面這張圖片的原始大小為 1.6M，壓縮后變成了 213KB，體積為原始大小的 13%，
以上就是本文所有內容了，有需要了解更多Android性能優化的，請往下看，（文末有驚喜）
ANR問題決議
crash監控方案
啟動速度與執行效率優化專案實戰
記憶體優化
耗電優化
網路傳輸與資料存盤優化
apk大小優化
專案實戰
以上資料，有需要的可在我的QQ技術交流群里可以自助拿走，如果在學習或作業中遇到了問題，群里會有一些大神幫忙解答，有時你悶頭想一天，不如別人的三言兩語就醍醐灌頂，群793544421,也可點擊這里，加入我們圈子，共同進步，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/290810.html
標籤：其他