針對行動網路開發的優化建議

李鬆峰發表於2013-11-30
優化

……

8.5 爆發傳輸資料並轉為空閒

移動無線介面專門為爆發性傳輸做過優化，這一點應該儘可能利用。比如，把請求分組，儘可能多和快地下載資料，然後讓無線模組轉為空閒。這樣，既可以獲得最大的網路吞吐量，也能節約電量。

針對行動網路開發的優化建議 估算網路速度唯一正確的方式，就是使用它！LTE和HSPA+等最新一代網路，每隔1毫秒就會動態分配一次資源，而且更適合爆發性的資料傳輸。換句話說，要想快，就要簡單：批量請求，預先下載儘可能多的資料，然後讓網路空閒。

基於此，一個重要的結論就是：漸進載入資源在行動網路中弊大於利。每次只下載一點資料會導致應用的吞吐量和延遲都搖擺不定，同時消耗的電量可能也會更多。因此，要儘可能預先下載資料，預測使用者接下來可能需要看什麼，提前下載，儘量讓無線模組空閒：

  • 如果需要大型音訊或視訊檔案，考慮提前下載整個檔案，而不要以位元為單位地流式下載；
  • 預先取得應用內容，通過測量和統計工具來辨別什麼內容適合提前下載；
  • 預先取得第三方內容，比如廣告，通過應用程式提前顯示並更新它們的狀態；
  • 允許裝置關閉無線模組，保持其空閒，不要忘了優化和消除間歇性傳輸（參見7.3.5節中的“46%的電量消耗僅傳輸0.2%的資料”）。

構建和評估預取模型

預取內容總會存在矛盾：一方面，你希望儘可能下載更少的資料，另一方面，你又想減少延遲和吞吐量的變動，同時降低對電池的影響。哪一方面更重要呢？這樣問本身就是錯誤的。答案永遠與應用的具體使用情境，以及你選擇用來評估預取策略有效性的指標相關。

重點在哪裡？最低限度，要做到三個變數的平衡：傳輸的位元組數、對電池的影響，還有網路吞吐量及延遲的變動。而且，如前所述，這三個變數並不相互排斥。一次下載較多位元組可能會帶來更大的吞吐量！

對於能準確預測使用模式的應用，可以採取激進的預取策略，將電量消耗降到最低，提升使用者體驗，同時避免大下載量的開銷。相反，不夠好的預取策略可能會下載大量不必要的資料，降低整體使用者體驗。

要確定應用的具體行為，首先要確定你的主要目標，以及應用的主要使用模式。然後，根據這些因素決定預取策略，並收集資料以驗證你的預測，如此反覆。

8.6 把負載轉移到Wi-Fi網路

目前的行業預測顯示，世界範圍內幾乎90%的無線流量都源自室內，而且經常是在有Wi-Fi連線的區域內。雖然最新4G網路的峰值吞吐量和延遲時間都與Wi-Fi不相上下，但每月的資料流量往往都有上限，畢竟移動上網是按量計費的，價格並不便宜。另外，Wi-Fi連線下的大資料量傳輸更省電（參見7.3.1節“3G、4G和Wi-Fi對電源的要求”），也不需要RRC。

可能的情況下，特別是對需要處理較大資料量的應用，都應該利用Wi-Fi連線。如果檢測不到Wi-Fi連線，可以建議使用者開啟Wi-Fi連線，以提升體驗和節省電量。

8.7 遵從協議和應用最佳實踐

網路基礎設施的分層架構有一個最大的優點，那就是把物理交付介面從傳輸層中抽象了出來，而傳輸層又把路由和資料交付從應用協議中抽象了出來。這種分離的結果就是API具有獨立性，但為了取得端到端的最佳效能，我們仍然要考慮整個架構。

本章主要討論了行動網路物理層的獨立效能，比如RRC的存在、電池使用時間的問題，以及行動網路中獨有的路由延遲。在物理層之上，是我們前幾章已經介紹過的的傳輸和會話協議，針對它們的優化同樣甚至更加重要：

  • 2.5節“針對TCP的優化建議”;
  • 3.3節“針對UDP的優化建議”;
  • 4.7節“針對TLS的優化建議”。

通過重用持久連線、將伺服器和資料部署到離客戶端更近的地方、優化TLS部署，以及其他所有優化措施，對行動網路而言只會更加重要，因為行動網路的往返時間長，而頻寬永遠都很昂貴。

當然，我們的優化策略並不會止步於傳輸和會話協議，這兩方面只是基礎。從現在開始，我們還必須考慮不同應用協議（HTTP 1.0、1.1和2.0），以及通用Web應用開發最佳實踐對效能的影響。繼續閱讀吧，還沒有結束呢！

相關文章