前言
互聯(lián)網(wǎng)時代, App作為于用戶交互的端, 可以說實際上是一個界面, 產(chǎn)品的業(yè)務, 服務都是由Server提供的. 而App與Server的交互依賴于網(wǎng)絡, 故而網(wǎng)絡優(yōu)化, 也是我們的App優(yōu)化中不可缺少的一個優(yōu)化項
1、網(wǎng)絡連接對用戶的影響
App的網(wǎng)絡連接對于用戶來說, 影響很多, 且多數(shù)情況下都很直觀, 直接影響用戶對這個App的使用體驗. 其中較為重要的幾點:
- 流量 App的流量消耗對用戶來說是比較敏感的, 畢竟流量是花錢的嘛. 現(xiàn)在大部分人的手機上都有安裝流量監(jiān)控的工具App, 用來監(jiān)控App的流量使用. 如果我們的App這方面沒有控制好, 會給用戶不好的使用體驗.
- 電量 電量相對于用戶來說, 沒有那么明顯. 一般用戶可能不會太注意. 但是如前文電量優(yōu)化中說的那樣, 網(wǎng)絡連接(radio)是對電量影響很大的一個因素. 所以我們也要加以注意.
- 用戶等待 也就是用戶體驗, 良好的用戶體驗, 才是我們留住用戶的第一步. 如果App請求等待時間長, 會給用戶網(wǎng)絡卡, 應用反應慢的感覺, 如果有對比, 有替代品, 我們的App很可能就會被用戶無情拋棄.
2、分析網(wǎng)絡連接的工具
2.1.NETwork Monitor
Android Studio內置的Monitor工具中就有一個Network Monitor:
其中:
- Rx — R(ecive) 表示下行流量, 即下載接收.
- Tx — T(ransmit) 表示上行流量, 即上傳發(fā)送.
2.2 網(wǎng)絡代理工具
一般來說, 網(wǎng)絡代理工具有兩個作用:
- 截獲網(wǎng)絡請求響應包, 分析網(wǎng)絡請求
- 設置代理網(wǎng)絡, 移動App開發(fā)中一般用來做不同網(wǎng)絡環(huán)境的測試, 例如wifi/4G/3G/弱網(wǎng)等.
代理工具很多, 諸如Wireshark, Fiddler, Charles等, 在此不一一細說了
3, 哪些方面取優(yōu)化網(wǎng)絡連接
簡單來說, 兩個方面:
減少Radio活躍時間
1. 也就是減少網(wǎng)絡數(shù)據(jù)獲取的頻次.
2. 這就減少了radio的電量消耗, 控制電量使用.
減少獲取數(shù)據(jù)包的大小
1. 可以減少流量消耗
2. 也可以讓每次請求更快, 在網(wǎng)絡情況不好的情況下也有良好表現(xiàn), 提升用戶體驗.
那么, 具體應該從哪些方面著手呢?
3.1 接口設計
API設計
App與Server之間的API設計要考慮網(wǎng)絡請求的頻次, 資源的狀態(tài)等. 以便App可以以較少的請求來完成業(yè)務需求和界面的展示.
例如, 注冊登錄. 正常會有兩個API, 注冊和登錄, 但是設計API時我們應該給注冊接口包含一個隱式的登錄. 來避免App在注冊后還得請求一次登錄接口(有可能失敗, 從而導致業(yè)務流程失敗).
再例如, 上文提到的獲取repo詳情, 實際上請求了4個接口, 請求了repo的信息, forks列表, contributors列表, readme, 這是因為github提供的接口是盡量單一職責的. 然而在我們的實際開發(fā)中, 我們的Server除了提供這些單一職責的小接口外, 最好還能組合一個滿足客戶端業(yè)務需求的repo詳情接口出來.
Gzip壓縮
使用Gzip來壓縮request和response, 減少傳輸數(shù)據(jù)量, 從而減少流量消耗.
考慮使用Protocol Buffer代替JSON
從前我們傳輸數(shù)據(jù)使用XML, 后來使用JSON代替了XML, 很大程度上也是為了可讀性和減少數(shù)據(jù)量(當然還有映射成POJO的方便程度).
Protocol Buffer是google推出的一種數(shù)據(jù)交換格式.
如果我們的接口每次傳輸?shù)臄?shù)據(jù)量很大的話, 可以考慮下protobuf, 會比JSON數(shù)據(jù)量小很多.
當然相比來說, JSON也有其優(yōu)勢, 可讀性更高.
圖片的Size
上面Network Monitor中看到的22s到27s之間的有多次請求, 且數(shù)據(jù)量還很大. 就是在獲取圖片資源.
圖片相對于接口請求來說, 數(shù)據(jù)量要大得多. 故而也是我們需要優(yōu)化的一個點.
我們可以在獲取圖片時告知服務器需要的圖片的寬高, 以便服務器給出合適的圖片, 避免浪費.
我們現(xiàn)在很多公司的圖片資源都是使用第三方的云存儲服務的(七牛, 阿里云存儲之類的).
以七牛為例, 可以在請求圖片的url中添加諸如質量, 格式, width, height等path來獲取合適的圖片資源:
<pre spellcheck="false" class="md-fences md-end-block ty-contain-cm modeLoaded" lang="JAVA" cid="n57" mdtype="fences" style="box-sizing: border-box; overflow: visible; font-family: var(--monospace); font-size: 0.9em; display: block; break-inside: avoid; text-align: left; white-space: normal; background-image: inherit; background-position: inherit; background-size: inherit; background-repeat: inherit; background-attachment: inherit; background-origin: inherit; background-clip: inherit; background-color: rgb(248, 248, 248); position: relative !important; border: 1px solid rgb(231, 234, 237); border-radius: 3px; padding: 8px 4px 6px; margin-bottom: 15px; margin-top: 15px; width: inherit; color: rgb(51, 51, 51); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">imageView2/<mode>/w/<LongEdge>
/h/<ShortEdge>
/format/<Format>
/interlace/<Interlace>
/q/<Quality>
/ignore-error/<ignoreError>
</pre>
3.2 網(wǎng)絡緩存
適當?shù)木彺? 既可以讓我們的應用看起來更快, 也能避免一些不必要的流量消耗.
3.3 打包網(wǎng)絡請求
當接口設計不能滿足我們的業(yè)務需求時. 例如可能一個界面需要請求多個接口, 或是網(wǎng)絡良好, 處于Wifi狀態(tài)下時我們想獲取更多的數(shù)據(jù)等.
這時就可以打包一些網(wǎng)絡請求, 例如請求列表的同時, 獲取Header點擊率較高的的item項的詳情數(shù)據(jù).
可以通過一些統(tǒng)計數(shù)據(jù)來幫助我們定位用戶接下來的操作是高概率的, 提前獲取這部分的數(shù)據(jù).
3.4 監(jiān)聽相關狀態(tài)
通過監(jiān)聽設備的狀態(tài):
- 休眠狀態(tài)
- 充電狀態(tài)
- 網(wǎng)絡狀態(tài)
結合JobScheduler來根據(jù)實際情況做網(wǎng)絡請求. 比方說Splash閃屏廣告圖片, 我們可以在連接到Wifi時下載緩存到本地; 新聞類的App可以在充電, Wifi狀態(tài)下做離線緩存.
3.5 弱網(wǎng)測試&優(yōu)化
除了正常的網(wǎng)絡優(yōu)化, 我們還需考慮到弱網(wǎng)情況下, App的表現(xiàn).
3.5.1 弱網(wǎng)測試
有幾種方式來模擬弱網(wǎng)進行測試.
Android Emulator
創(chuàng)建和啟動Android模擬器可以設置網(wǎng)絡速度和延遲:
創(chuàng)建時:
啟動時, 使用emulator命令:
使用網(wǎng)絡代理工具
以Charles為例:
保持手機和PC處于同一個局域網(wǎng), 在手機端wifi設置高級設置中設置代理方式為手動, 代理ip填寫PC端ip地址, 端口號默認8888.
其他模擬弱網(wǎng)方式
如果你恰好也是IOS的開發(fā)者, Apple提供了Network Link Conditioner, 非常好用.
可以模擬的網(wǎng)絡情況與上述類似:
如果你使用linux環(huán)境開發(fā), 還可以試下facebook出的ATC.
3.5.2 弱網(wǎng)優(yōu)化
利用上述工具模擬弱網(wǎng), 在弱網(wǎng)情況下體驗我們的App. 一般來說, 網(wǎng)絡延遲在60ms內, 是OK的, 超過200ms就比較糟糕了. 我們需要做的是在比較糟糕的網(wǎng)絡環(huán)境下還能給用戶較好的體驗.
弱網(wǎng)優(yōu)化, 本質上是在弱網(wǎng)的情況下能讓用戶流暢的使用我們的App. 我們要做的就是結合上述的優(yōu)化項:
- 壓縮/減少數(shù)據(jù)傳輸量
- 利用緩存減少網(wǎng)絡傳輸
- 針對弱網(wǎng)(移動網(wǎng)絡), 不自動加載圖片
- 界面先反饋, 請求延遲提交
例如, 用戶點贊操作, 可以直接給出界面的點贊成功的反饋, 使用JobScheduler在網(wǎng)絡情況較好的時候打包請求
