1 網(wǎng)絡(luò)優(yōu)化從哪些緯度開展?

僅僅重視流量不夠巧颈。
網(wǎng)絡(luò)流量的消耗量：精確
整體均值掩蓋單點(diǎn)問題

正確認(rèn)識：
網(wǎng)絡(luò)相關(guān)監(jiān)控：全面薪伏。 請求成功率
粗粒度監(jiān)控不能幫助我們發(fā)現(xiàn)猾瘸、解決深層次問題勉盅。

網(wǎng)絡(luò)優(yōu)化維度：
1）流量消耗：
一段時(shí)間流量消耗的精準(zhǔn)度量铆农，網(wǎng)絡(luò)類型牺氨、前后臺
2）監(jiān)控相關(guān)：
用戶流量消耗均值、異常率（消耗多墩剖、次數(shù)多）
完整鏈路全部監(jiān)控（Request猴凹、Response），主動上報(bào)
3）網(wǎng)絡(luò)請求質(zhì)量
4）用戶體驗(yàn)：請求速度岭皂、成功率
5）監(jiān)控相關(guān)：請求時(shí)長郊霎、業(yè)務(wù)成功率、失敗率爷绘、Top失敗接口
6）其他
公司成本：帶寬书劝、服務(wù)器數(shù)、CDN
7）耗電
優(yōu)化誤區(qū)：
只關(guān)注流量消耗土至、忽視其他維度
只關(guān)注均值购对、整體，忽略了個體數(shù)據(jù)陶因。 但看百分占比沒有意義骡苞。

2. 網(wǎng)絡(luò)優(yōu)化工具選擇

NetworkProfiler
顯示實(shí)時(shí)網(wǎng)絡(luò)活動：發(fā)送、接收數(shù)據(jù)及連接數(shù)
需要手動啟用高級分析
只支持HttpUrlConnection 和 OkHttp網(wǎng)絡(luò)庫

抓包工具
Charles楷扬、Fiddler解幽、Wireshark、TcpDump
Charles
1）斷點(diǎn)功能
2）Map Local毅否。模擬假數(shù)據(jù)
3）弱網(wǎng)環(huán)境模擬亚铁。 Throttle
Stetho
強(qiáng)大的應(yīng)用調(diào)試橋蝇刀，連接Android 和 Chrome
對比競品螟加，相同case對比流量消耗
異常監(jiān)控超過正常指標(biāo)

3. 精準(zhǔn)獲取流量消耗實(shí)戰(zhàn)
線上線下流量獲取
前臺后臺流量獲取
如何判斷App流量消耗偏高？
絕對值看不出高低

測試方案
設(shè)置—— 流量管理
抓包工具：只允許本App聯(lián)網(wǎng)
可以解決大多數(shù)問題，但是線上場景線下可能遇不到

線上流量獲取方案
TrafficStats:
API8 以上重啟以來的流量數(shù)據(jù)統(tǒng)計(jì) （無法獲取某個時(shí)間段內(nèi)的流量消耗捆探。）
getUidRxBytes(int uid ) 制定Uid的接收流量
getTotalTxBytes() 總發(fā)送流量

NetwortStatsManager：
API23之后流量統(tǒng)計(jì)
可獲取指定時(shí)間間隔內(nèi)的流量信息
可獲取不同網(wǎng)絡(luò)類型下的消耗
難題：線上反饋App后臺跑流量
只獲取一個時(shí)間段的值不夠全面然爆。
后臺定時(shí)任務(wù) ——> 獲取時(shí)間間隔內(nèi)流量
——> 記錄前后臺 ——> 分別計(jì)算
——> 上報(bào)APM后臺 ——> 流量治理依據(jù)

ExecutorService
          .newScheduleThreadPool(1)
        .schedule(new Runnable(){}, 30, TimeUnit.SECONDS);

getApplication().registerActivityLifecycleCallbacks(){
            onActivityCreated
            onActivityStarted
            onActivityResumed
            
            // 認(rèn)為是在前臺
            onActivityPaused
            // 退到后臺去了
}

4. 網(wǎng)絡(luò)請求流量優(yōu)化實(shí)戰(zhàn)

數(shù)據(jù)：Api、資源包（升級包黍图、H5曾雕、RN）、配置信息
圖片：下載助被、上傳
監(jiān)控：APM相關(guān)剖张、單點(diǎn)問題相關(guān)

服務(wù)器返回加上過期時(shí)間，避免每次重新獲取揩环。
節(jié)約流量且大幅提高數(shù)據(jù)訪問速度搔弄，更好的用戶體驗(yàn)
OkHttp都有較好實(shí)踐。

增量數(shù)據(jù)更新
加上版本的概念丰滑，只傳輸有變化的數(shù)據(jù)顾犹。
配置信息、省市區(qū)縣等更新
數(shù)據(jù)壓縮
Post請求Body使用GZip壓縮
請求頭壓縮
圖片上傳之前必須壓縮

圖片壓縮庫：Luban
優(yōu)化發(fā)送頻率和時(shí)機(jī)

合并網(wǎng)絡(luò)請求褒墨、減少請求次數(shù)炫刷。 （節(jié)約Header）
性能日志上報(bào)：批量 + 特定場景上報(bào) （wifi下上傳。）

圖片相關(guān)
圖片使用策略細(xì)化：優(yōu)先縮略圖
使用webp格式

5. 網(wǎng)絡(luò)請求質(zhì)量優(yōu)化實(shí)戰(zhàn)

質(zhì)量指標(biāo)：
網(wǎng)絡(luò)請求成功率郁妈、網(wǎng)絡(luò)請求速度

Http請求過程
請求到達(dá)運(yùn)營商的Dns服務(wù)器并解析成對應(yīng)的IP地址
創(chuàng)建連接浑玛，根據(jù)IP地址找到對應(yīng)的服務(wù)器，發(fā)起一個請求
服務(wù)器找到對應(yīng)的資源原路返回訪問的用戶

DNS相關(guān)
問題：DNS被劫持圃庭、DNS解析慢
方案：使用HttpDNS锄奢，繞過運(yùn)營商域名解析過程
不是傳統(tǒng)地向DNS服務(wù)器的53端口發(fā)送請求。而是使用Http協(xié)議向DNS服務(wù)器的80端口發(fā)送請求剧腻。
優(yōu)勢：繞過LocalDNS的劫持拘央。加快解析過程。降低平均訪問時(shí)長书在、提高連接成功率灰伟。

協(xié)議版本升級
1.0：版本TCP連接不復(fù)用
1.1：引入持久連接，但數(shù)據(jù)通訊按次序進(jìn)行
2.0：多工儒旬，客戶端栏账、服務(wù)端雙向?qū)崟r(shí)通信

網(wǎng)絡(luò)請求質(zhì)量監(jiān)控
接口請求耗時(shí)、成功率栈源、錯誤碼
圖片加載的每一步耗時(shí)
網(wǎng)絡(luò)容災(zāi)機(jī)制
備用服務(wù)器分流挡爵。
多次失敗后一定時(shí)間內(nèi)不進(jìn)行請求，避免雪崩效應(yīng)甚垦。

其它
CDN加速茶鹃、提高帶寬涣雕、動靜資源分離（更新后清理緩存）
減少傳輸量，注意請求時(shí)機(jī)及頻率
OkHttp的請求池

6. 網(wǎng)絡(luò)體系化方案建設(shè)

線下測試相關(guān)

方案：只抓單獨(dú)APP
側(cè)重點(diǎn)：請求有誤闭翩、多余挣郭，網(wǎng)絡(luò)切換、弱網(wǎng)疗韵、無網(wǎng)測試

線上監(jiān)控相關(guān)

1）服務(wù)端監(jiān)控
請求耗時(shí)（區(qū)分地域兑障、時(shí)間段、版本蕉汪、機(jī)型）
失敗率（業(yè)務(wù)失敗與請求失斄饕搿）
Top失敗接口、異常接口

2）客戶端監(jiān)控
接口的每一步詳細(xì)信息（DNS者疤、連接先蒋、請求等）
請求次數(shù)、網(wǎng)絡(luò)包大小宛渐、失敗原因

3）圖片監(jiān)控
異常監(jiān)控體系
服務(wù)器防刷：超限拒絕訪問
客戶端：大文件預(yù)警竞漾、異常兜底策略
單點(diǎn)問題追查

7. 網(wǎng)絡(luò)優(yōu)化問題

1）在網(wǎng)絡(luò)方面你們做了哪些監(jiān)控，建立了哪些指標(biāo)
演進(jìn)過程窥翩、優(yōu)化背景业岁。
初期沒有意識到，由于wifi場景下網(wǎng)速快寇蚊，成功率也就比較高笔时。沒有注意到相關(guān)問題。
用戶量增大仗岸，界面打不開或者比較慢允耿。流量消耗比較多。剛開始沒有數(shù)據(jù)支撐所有沒有辦法確認(rèn)用戶的反饋是否正確扒怖。
不知道線上用戶的真實(shí)用戶體驗(yàn)是怎么樣较锡。
如果單純依靠用戶反饋，那么這樣的異常感知靈敏度是非常低的盗痒。所以就補(bǔ)上了網(wǎng)絡(luò)情況的監(jiān)控蚂蕴。

1——流量監(jiān)控 2——質(zhì)量監(jiān)控
質(zhì)量：請求成功率、每步耗時(shí)俯邓、狀態(tài)碼
客戶端統(tǒng)計(jì)了每個請求的每步耗時(shí)骡楼，比如DNS解析時(shí)間，建立連接等時(shí)間稽鞭，接口失敗原因鸟整。在合適時(shí)間點(diǎn)上報(bào)給服務(wù)器。
流量：精確統(tǒng)計(jì)朦蕴、前后臺
下發(fā)指令篮条。獲取用戶的流量消耗情況祠乃。如何獲取的前后端獲取的。講述一下兑燥。單日消耗流量均值，以及前后臺消耗琴拧。

2）如何有效的降低用戶流量消耗
數(shù)據(jù)：緩存降瞳、增量更新
梳理了項(xiàng)目中展示類的接口，選出了對時(shí)效性不是那么強(qiáng)的接口蚓胸，做了數(shù)據(jù)的緩存挣饥。一段時(shí)間內(nèi)的數(shù)據(jù)直接從本地讀取而不重新走網(wǎng)絡(luò)請求。避免無意義的浪費(fèi)沛膳。
添加進(jìn)了版本號的概念扔枫，每次更新只添加變化的數(shù)據(jù)∏掳玻可以非常多地減少流量消耗短荐。

上傳：壓縮。body的壓縮叹哭。圖片的壓縮忍宋。
Feed時(shí)僅采用縮略圖，同樣格式的圖片轉(zhuǎn)換成webp风罩，也有一定比例的壓縮糠排。均有云服務(wù)輕松幫我們轉(zhuǎn)換。

3）用戶反饋消耗流量多這種問題怎么查超升？
部分用戶遇到流量消耗比較多肯定存在入宦，用戶很多反饋類型也很多。有些用戶的操作路徑很詭異室琢，讓自己的賬戶體系出錯乾闰。從而遇到了異常情況，部分用戶遇到了A/B Test盈滴。更多地消耗了流量汹忠。

精確流量獲取能力。
所有請求大小及次數(shù)的監(jiān)控雹熬。
主動預(yù)警能力宽菜。
體系化的思維能力！