1. <tr id="33chb"><label id="33chb"></label></tr>
  2. <pre id="33chb"></pre>
    當前位置:首頁 > 短網址資訊 > 正文內容

    騰訊url.cn團隊移動App的網絡優化:短鏈接打開速度優化到原來15%歷程

    導讀:在移動應用開發中,應用上線了只是一個開始,噩夢在后面:手機越用越卡為哪般?手機發燙是為何?誰偷走了用戶的錢包?如何瘦成一道閃電?這些問題解決起來都是非常麻煩的,騰訊移動品質中心(url.cn)成立了專項測試團隊來解決這些問題。


    最近幾年,我們針對 Apps 的網絡性能優化工作并不多,但每一次都是投入人手較多、時間跨度較長的大任務。本文將給讀者們一個一年多以前為公司的某產品成功優化短鏈接打開速度的案例。速度、成功率與流量正好是 Apps 網絡優化的幾大重點,希望本文我們分享的思路能夠給諸位正在開展或將來會開展此類工作的讀者們一些啟發。


    在上文手機QQ上傳速度提升8倍秘訣:解決速度與成功率的“魚翅”項目 中,我們重點講解了提升上傳速度和成功率的“魚翅”項目,分析了在移動網絡下影響上傳速度和成功率的因素,一次次的調優算法并驗證,最終提煉出了能應對網絡質量瞬息萬變的魚翅算法。而本文則是講解了我們在不刪減功能的前提下是如何提升某產品待機流量的,重點講解了短鏈接打開速度測試的基本方法,短網址服務自動化測試的經驗以及提煉出的流量優化的通用方法。


    目前,國內幾大運營商的移動數據業務還都處于按流量計費狀態,且超出套餐外的流量收費較為昂貴。 那么,一款 APP 是否消耗過多的流量,在用戶體驗方面影響就顯得比較大。


    一年多前,部門內的某安卓版的產品收到用戶投訴,從安卓系統的流量統計中查看到該產品消耗的背景流量偏高,背景流量即 APP 在用戶無操作時后臺運行消耗的流量,主要用于一些推薦和更新等信息的推送,這部分流量對用戶是有意義的,但是如果消耗過多而用戶沒有感知到足夠信息的推送,在用戶看來就等于是變相的“偷”走了用戶的金錢。


    我們經過自測,該產品在常駐后臺運行時 24 小時消耗流量 600KB 左右,而競品流量消耗在 150KB 左右,一個月下來也是一筆不小的開銷,我們團隊對該產品的背景流量進行了認真的分析和優化,經歷了 4 個月左右的努力,成功的將 24 小時背景流量降到了 100KB 以下,并且基本功能無刪減。優化后的版本上線后為用戶節省了大量的流量,也就是替用戶省了錢,收到用戶的一致好評。


    整個流量優化階段現在回頭想來,經歷過三個大的階段。


    1. 首先,我們花了大量的精力研究如何測試流量消耗,如何精確的得到每個功能點消耗了多少流量,因為如果我們不了解現狀,根本無法去優化流量;

    2. 其次,我們針對每個功能點,根據其功能邏輯,探討優化方法,以及從全局來看,這些功能點有無精簡的可能,從項目之初的無任何優化經驗,到項目結束時總結和固化了眾多的流量優化經驗,我們成功的將流量降到了理想范圍;

    3. 最后,我們思考如何將本次優化的成果持續保持下去,即后續的新增特性不能惡化流量消耗,我們開發并完善了流量自動化監控系統,有力的保障了后續的版本流量不惡化。


    下面我們就按照項目的三個階段來詳細的分享優化過程中積累的經驗和方法。


    一、摸清現狀


    項目之初,我們對該產品的短鏈接加載情況進行了詳細的摸底,我們要搞清楚,我們的短網址打開的時間到底消耗在哪了?有沒有多余和浪費?


    1、短鏈接打開速度測試方法


    首先我們對該產品 24 小時的消耗的背景流量進行測試。那么流量測試都有什么方法呢?首先得搞清楚流量是什么?我們的手機通過運營商的網絡訪問 Internet,運營商替我們的手機轉發數據報文,數據報文的總大?。ㄗ止潝担┘戳髁?,這里的數據報文包含手機上下行的報文。由于數據報文采用 IP 協議傳輸,運營商計算的流量一般都是包含 IP 頭的數據報文大小。


    搞清楚了流量的定義之后,那么我們可以思考如何來獲取應用消耗的流量。最直接的辦法就是在手機上抓包,分析報文的總大小,即為應用消耗的流量;如果手機沒有 root,不方便抓包時,可以設置一個代理服務器,手機通過 WiFi,設置為代理服務器方式訪問 Internet,在設置的代理服務器上抓包進行流量分析。另外,安卓系統目前也提供了 TCP 流量的統計,如果被測應用使用的是 TCP 協議,則可以直接取該統計值來計算流量。


    間接的流量測試方法比如通過第三方流量監控軟件來獲取流量,還有通過運營商的流量查詢方法(短信,營業廳等方法)來獲取流量的消耗情況,也都可以達到我們獲取流量的目的。


    大家在流量測試的過程中,需要根據自身應用的特點,因地制宜的選擇最合適方便的測試方法。下面我們詳細的介紹兩種最常用的流量測試方法:抓包測試法、統計測試法。


    1) 抓包測試法


    測量流量最直接的方法就是抓包。在 APP 運行期間,把手機收發的所有報文都抓取下來,再計算收發報文總大小,即 APP 消耗的流量。但是如果我們需要測試某一個 APP 消耗的流量呢?項目之初,我們想到的方法是通過第三方應用,來禁用其他 APP 的聯網權限。下面詳細介紹一下這種方法的操作步驟:


    第一步:限制其他 APP 聯網權限


    手機上很多 APP 的進程是常駐后臺的,即使不運行,也會有網絡報文。所以,為了準確的抓取被測應用的報文,需禁止其他應用的聯網權限。我們可以通過手機管家類的軟件來禁止聯網。如圖 5-3 所示,為騰訊手機管家對應用聯網控制的界面。



    圖 手機管家禁止聯網示意


    第二步:手機上抓包


    安卓系統上常用的抓包工具是 tcpdump,具體的操作步驟如下:


    1) PC 上安裝 adb,直接下載或者通過 eclipse 中的安卓開發環境自帶的工具集獲得。


    2) 下載 tcpdump: http://www.strazzere.com/Android/tcpdump


    3) 檢查設備連接情況。



    4) 把 tcpdump 拷貝至 /data/local 目錄,注意,/data/local 目錄需要 root 權限才能拷入,所以先使用 adb push 拷貝至手機 /sdcard 目錄,再使用 adb shell 進入命令行,使用 su 進入 root 狀態, cp 至 /data/local 目錄。



    5) 為 tcpdump 添加可執行權限



    6) 啟動抓包,使用命令 /data/local/tcpdump -p -vv -s 0 -w /sdcard/capture.pcap


    “ Got”后面的數字表示當前抓到的包的數量。如果在變化,表示有網絡流量。


    7) 我們剛剛把抓包的結果保存在了 /sdcard 目錄下,導出抓包的結果到電腦。


    大家看了這么多步驟是不是覺得很復雜,不過不要緊,我們自研的 GT 工具已經把 tcpdump 抓包功能集成進去了,后面介紹 GT 的章節里面會詳細介紹抓包方法,在手機上有用戶操作界面可以實現一鍵式抓包,另外 GT 也提供了命令行方式的接口啟動抓包,啟動命令為:


    adb shell am broadcast – a com.tencent.wstt.gt.plugin.tcpdump.startTest – es filepath “/sdcard/GT/Tcpdump/Capture/test.pcap”


    停止抓包命令為:


    adb shell am broadcast -a com.tencent.wstt.gt.plugin.tcpdump.endTest


    后面可以看到,命令行方式可以方便的做進自動化測試腳本中。


    第三步:根據抓包文件統計短鏈接加載時的流量


    這里需要對抓包文件分析,獲得抓取的報文總流量,目前 PC 上的抓包軟件 wireshark 就提供這樣的統計功能。用 wireshark 打開剛剛的抓包文件,點擊 Statistics->Summary,如圖 5-4 所示。



    圖 wireshark 流量統計功能


    流量的數值為 Bytes 一行的 Displayed 一欄。如圖 5-5 所示。



    圖 wireshark 流量統計詳細頁


    2)統計測試法


    安卓系統自身提供了 TCP 收發長度的統計功能,一般 APP 和后臺服務器之間的通信都是基于 TCP 的,所以我們可以利用此統計來測試我們 APP 的流量,而且安卓提供的該統計功能是按照 APP 緯度來統計,不需要禁止其他 APP 的聯網權限。


    下面簡單的介紹一下操作步驟:


    1) 使用 ps 命令查看所測 APP 的 uid,如下圖舉例,手機 QQ 的 UID 為 10000 + 155 = 10155(即紅框數字 +10000)。


    2) 進入 /proc/uid_stat/10155 目錄, cat 獲取當前 tcp_snd 和 tcp_rcv 的初始值。



    3) 進行測試一段時間后再次獲取 tcp_snd 和 tcp_rcv 的值。



    4) 所測時間內的流量計算。


    發送流量: tcp_snd_new – tcp_snd_old = 418375 – 391582 = 26793 bytes

    接受流量: tcp_rcv_new – tcp_rcv_old = 5902341 – 5840747 = 61594 bytes


    了解了流量測試方法,我們就開始著手測試我們產品的流量消耗情況。


    2、每天 24 小時待機測試的短網址加速


    在開始測試流量時,我們首先需要搞清楚測試場景,我們需要測試產品的背景流量,在不操作 APP 的情況下,我們的測試時長是多少?為了研究這個問題,我們經過了詳細的測試,發現一天中每個時間段的流量都是不一樣的,即上午的一小時消耗的流量可能就與下午的一小時消耗的流量不一樣。在研究了 APP 的運行機制后,我們發現, APP 后臺運行時的流量一般都是按照時間策略觸發的,每天的各個時間段的發包頻率是不一樣的,基于這種機制,我們就需要測試 24 小時 APP 的背景流量。


    搞清楚了測試場景之后,擺在我們面前的難題來了,如果每輪測試都需要 24 小時,那我們的測試效率太低了,每次優化后的版本都需要測試 24 小時,我們可能一年也做不完這個項目。所以我們開始著手研究如何提升測試效率。


    首先想到的是讓系統的時間跑得快一些,比如說實際的一秒鐘,我們讓系統的時間變化一分鐘,這樣 24 小時不就變成 24 分鐘了嗎?我們趕緊驗證我們的想法,我們自己寫了一個 APP,周期性的改變系統時間,發現這種方法是湊效的,但是相比于正常 24 小時的流量,這種方法測試出來的流量是偏少的,通過日志打印,我們發現這種加速方案對大部分協議是生效的,但是對一部分協議不生效,我們對不生效的協議進行了代碼分析,發現這部分協議的發送是采用了相對定時器的機制發送,相對定時器是基于系統 ticks 計數來進行任務調度的,修改系統時間對此不湊效。


    我們開始想到的解決辦法是在代碼中重構相對定時器的函數,例如傳入的參數是一小時調度一次,重構后的相對定時器首先會將傳入參數除以 60,再傳遞給系統相對定時器函數,這種辦法是湊效的,但是有一個缺點,就是必須單獨編譯一個版本,不能直接使用發布版本來測試,這也會對我們的測試效率產生影響,后來經過研究,我們想到了 hook 的方式,動態重構發布版本的相對定時器函數,達到了同樣的功效。


    最后我們將研究成果和方法總結概括一下:


    1) 基于時間點的定時任務采用周期性修改系統時間來加速。


    這種方式在代碼實現時是調用了 (AlarmManager)am.set(AlarmManager.RTC_WAKEUP, point, sender) 方法,其中 point 為系統絕對時間,周期性的修改系統時間加速該類定時任務是有效的,這里我們使用 APP 的方式來實現,每隔一秒使系統時間增長一分鐘。


    2) 相對定時器任務采用 hook 的方式重構定時器函數。


    相對定時器采用 Handler 的 sendMessageDelayed(msg, long) 方法進行定時調度,該方法是基于系統 ticks 計數來進行任務定時調度的,我們采用 hook 的方式,修改系統的 sendMessageDelayed 函數,將傳入的時間除以 60,這樣, 1 小時的周期定時器實際為 1 分鐘。 Hook 采用 xposed 框架開發。


    使用這兩種加速方式, 24 分鐘即可完成 24 小時的流量測試,大大提升了測試效率。


    這種方法也有局限性,比如后臺服務器下發的 push 等信息是后臺服務器根據自身的時間策略下發的,終端的這種加速對后臺是不起作用的,但是,由于 push 的流量占比不是很大,所以在我們的優化中這種影響是可以忽略的。


    3、短鏈接加速度精細化監控


    項目進行到這里我們已經能很快的獲得 24 小時 APP 的背景流量了,但是這個流量數值是無法指導我們后續的優化工作的,因為我們不知道從哪個網絡功能開始著手分析。所以我們需要搞清楚,我們這些流量消耗都干了什么事情。


    首先,我們跟業務開發團隊進行了溝通,跟開發人員了解流量現狀,我們了解到,我們這款 APP 沒有采用長連接,所以服務器上的更新,通知等信息是需要 APP 周期性的向服務器發送查詢消息來獲取的,不同業務的查詢消息的發送頻率是不一樣的。由于業務開發團隊是按照特性( feature)來劃分的,各自為營,不同開發小組開發的消息結構和發送機制也都是不統一的,而且有很多消息的發送時機選擇得也不是很好,服務器返回的內容很多都不是最精簡的,存在冗余,所以導致消耗流量過多。


    面對如此雜亂無章的流量消耗,我們需要搞清楚我們的 APP 每條 IP 報文的功能,都干了什么事情,理清楚了這些之后才能進行邏輯上的優化,進而進行流量的優化。下面會詳細介紹我們是如何理清楚當前的流量消耗的,如何變無序為有序的。


    1)按照短域名進行流量細分


    首先,我們對抓包進行了詳細的分析,由于我們的 APP 與后臺通信只使用了 HTTP 協議,所以從抓包中是能分析出一些細節的,我們發現 HTTP 報文發往的 host,即域名,例如 www.tencent.com,是不盡相同的,域名是用來區分不同的后臺服務器的,代表不同的功能,這種方式有助于不同的后臺服務器處理不同功能的報文,這樣后臺服務器可以按照功能來獨立部署和升級?;谶@個發現,我們首先對報文按照域名來分類。


    下面我們詳細介紹一下如何按照域名來分別統計流量。首先使用 wireshark 自帶的過濾功能只顯示 HTTP 報文,在 filter 處輸入 http 即可,如圖所示。



    圖 過濾 HTTP 報文


    這樣 wireshark 的視圖總就只剩下 HTTP 報文了,我們點開一條報文,點開 HTTP 的內容,可以看到有 Host 字段,該字段表示該條 HTTP 報文通信的后臺服務器的域名。那么如何統計抓包中共向多少后臺服務器發送過請求呢,可以按照如下方法進行。


    首先,在上面按照 HTTP 過濾條件過濾之后的基礎上,點擊 File->Export Packet Dissections -> as “ Plain Text” file,如圖所示。



    圖 報文導出為文本


    該步驟可以將過濾后的報文的詳細信息(包含 HTTP 頭的信息)存儲成文本。格式如圖所示。



    圖 報文文本格式


    使用 Notepad++ 的搜索功能,搜索關鍵字“ Host:”,點擊“在當前文件中查找”,在搜索結果框中會列出所有的結果,所有的 Host 一目了然。如圖所示。




    圖 報文文本中過濾域名


    那么,對于某一個域名,可以使用條件 HTTP.host == "www.test.com" 將該域名的報文過濾出來,如下圖所示,然后就可以得知該域名的 IP 地址。一般同一個域名可能有多個 IP 地址與之對應,因為目前后臺服務器一般是一個集群,每個終端都會被負荷分擔至某幾個 IP 的服務器。如圖 5-10 所示。



    圖 確定域名的 IP


    然后使用 IP 地址過濾,以上圖舉例,過濾條件為: IP.src == 140.207.54.68 || IP.dst == 140.207.54.68 || IP.src == 140.207.69.61 || IP.dst == 140.207.69.61。過濾的結果如圖所示。



    圖 按照 IP 過濾的結果


    點擊 Statistics->Summary,就會統計過濾出的報文的總大小,即該域名下的流量。如圖所示。



    圖 按照域名過濾出的結果


    當然,上面是手動分析方法,比較費時,而且無法在自動化測試腳本中實現,這里介紹一種 Python 實現的自動分析腳本的方法。 pcap2har 為一個分析 pcap 抓包的 Python 庫文件,下載地址為 https://github.com/andrewf/pcap2har。下面為一個簡單的 Python 示例程序,打印了 test.pcap 抓包中所有 HTTP 報文的 host,請求報文大小,響應報文大小。


    #! /usr/bin/env python


    # -*- encoding: utf-8 -*-

    from pcap2har import pcap

    from pcap2har import httpsession

    dispatcher = pcap.EasyParsePcap('test.pcap')

    session = httpsession.HttpSession(dispatcher)

    for entry in session.entries:

    request = entry.request

    response = entry.response

    print request.host

    print len(request.msg.body)

    print response.body_length


    可以使用 Python 實現統計每個域名的 HTTP 流量。然后結合上面流量測試方法提到的 GT 的命令行方式進行抓包,我們將手機抓包,從手機上拷貝抓包文件,按照域名統計流量這三部分功能在自動化測試腳本中實現了,再結合手機時間加速方案,我們能很快的進行一輪測試,并得到本輪測試按照域名細分的結果。


    經過了多輪測試取平均值的方式,我們得到了如下的結果如下表所示。


    表 各域名對應的流量一覽


    我們測試的 APP 的后臺服務器域名共有四個,其中大部分流量都集中在 www.test1.com 上,我們查看這部分報文的內容,發現是無法解析的,因為測試的 APP 與該服務器通信時采用了私有的協議進行報文傳輸,所以后面我們開始研究如何將這 540KB 流量按照功能來細分。


    2)短域名下的短鏈接按功能細分


    對于報文采用私有協議實現的,要解析這部分報文,需要使用私有協議進行解析,我們 APP 的私有協議的實現方式是類似 Protobuf 的二進制編碼方式,即每個協議的結構都是預先定義好的,每個協議都需要按照預定義的格式來解析,即如果協議報文的結構發生變化,解析的方式也是需要更新的。


    一開始我們想到的方法是將報文解析算法集成到我們的自動化分析腳本中,這樣就能將抓包的報文內容解析出來,但是這種方法帶來的后果是自動化腳本中的報文解析算法需要實時同步主線版本中的內容,因為網絡交互的報文后續的版本是會不斷變化的,這樣對于自動化腳本的維護成本就會太高。


    后來我們想到了直接在 APP 中輸出報文解析的結果,以日志的方式存儲,后期自動化腳本獲取日志來得到報文解析的結果。當然 APP 的報文日志打印功能需要增加配置,缺省是關閉的,正式版本不進行該內容打印,測試時將該配置打開,記錄日志供自動化腳本使用。通過打印日志的分析,最終統計到的結果如下表所示。


    表 各業務邏輯對應的流量一覽


    這里我們選取了 5 個最主要的流量消耗,其他還有很多流量消耗較少的報文,由于優化空間較小,不在此一一列舉。至此,我們就得到了我們的產品 24 小時的消耗的背景流量總大小,以及按照域名和功能細分后的各個協議邏輯報文的大小,有了這些精細化的數據,我們才能更深一步的進行優化方案的分析。


    二、短網址優化精簡


    搞清楚了所有交互的報文后,我們需要來優化具體的邏輯和報文,對于各個功能,如何在對原有邏輯無損和不影響用戶體驗的情況下進行流量優化呢,下面我們詳細介紹一下我們的分析方法和優化思路,以及在優化過程中總結出來的法則。


    1、單個協議內容消除重復和浪費


    項目之初,面對眾多的協議,對這些協議的功能和發送邏輯也不是很了解,很多人感覺無從下手。我們的經驗就是按流量消耗從大到小依次分析各個協議報文,這里對單個協議的分析包含功能和代碼邏輯的分析,優化主要是不影響功能的情況下去除交互報文的冗余。


    我們將協議交互的請求和響應各個字段都打印出來,詳細的進行分析,很快我們就看到響應報文中是存在冗余和浪費的,最典型的一個協議報文就是動態獲取配置,一般 APP 的配置都不是客戶端寫死的,而是服務器上動態配置的,這樣對于一些功能,能方便的在服務器上更改配置,而不需要發布版本。我們的 APP 的配置項也很多,比如報文發送的時間點策略,其他的策略,我們從打印中就能看出,一次響應中的配置項的報文長度就高達 4KB,而且獲取配置的報文是一小時發送一次的,一天 24 次,就是 96KB 的流量消耗,在配置不變的情況下,每次響應的 4KB 報文的配置數據是完全一致的,這個完全沒必要,每次只需要將有變化的配置項下發下來即可。


    我們當即與開發團隊討論,開發團隊也表示,當初這種實現方法是最簡單的,要做到增量下發配置項實現上復雜一些,因為不同的終端當前的配置項都是不一樣的,后臺服務器如何判斷哪些配置項需要下發給某個終端,哪些不需要,是一個難題。我們經過討論和方案設計,找到了一個較好的解決方案。下面我們將我們的解決方案總結一下。


    我們為服務器的全體配置項引入一個新的參數:版本號 version,從 1 開始遞增( 0 表示沒有獲取過配置項),每次后臺服務器修改了某一個配置項,即更新當前最新的版本號,同時記錄下該版本號變化的配置項的索引號,每次客戶端的請求報文中都必須攜帶客戶端的配置項的版本號,服務器將客戶端的版本號與最新的版本號比較,然后從配置項變化表中查詢變化的配置項,將變化的配置項的內容和最新的版本號下發給客戶端。整個過程如圖所示。



    圖 全量與增量拉取數據對比


    例子中 Server 有四個配置項,中間修改了第二個配置項,全量拉取的方法每次都將四個配置項的信息都下發,修改成增量拉取后, Server 只需要維持一張各個 Version 變動的配置項的索引號表,即可實現對每個客戶端每次只下發有變化的配置項了。 Version 1 由于是第一個版本號,所以表中記錄了所有的配置項索引號,表示客戶端第一次拉取的配置項是全量下發的。


    我們使用該方法分析了其他的協議,還有兩個協議存在該問題,也使用同樣的方法進行了優化,效果顯著。


    使用了該方法優化后,我們仍發現有個別協議較耗短鏈接的資源,其中有一個協議為拉取熱詞,即 APP 搜索框中推薦的用戶搜索最多的詞語,這個功能也是所有 APP 中常用的一個功能,如圖 5-14 所示。



    圖 熱詞示意


    即使使用了增量拉取,一天中也會出現 2~3 次的拉取,因為這個內容一天中確實會變化,因為用戶每天搜索的詞語都是不一樣的。由于熱詞一次下發的量過大,我們最終從功能邏輯上分析, APP 在后臺運行,用戶沒有操作的情況下,有沒有必要拉取這個信息?原先的設計是在用戶沒有操作的情況下,預取該信息,在用戶打開 APP 時搜索框直接就顯示最新的熱詞,在用戶體驗方面當然是最好的了,如果不預取,我們只要保證每次用戶點開 APP 去增量獲取一次最新的熱詞即可,所以在移動網絡后臺運行時我們修改成不發送該協議, WiFi 下的預取策略我們維持了原樣,畢竟 WiFi 下是不消耗移動網絡流量的。


    我們把這一階段的優化經驗提煉成兩個優化法則:


    法則一:增量拉取數據


    APP 與后臺服務器交互時,每次只傳輸有變化的數據,不變的數據不要重復傳輸。


    法則二:界面展示的數據非 WiFi 下不預取


    非 WiFi 情況下,對于短網址界面展示的數據,在 短網址后臺運行時盡量不去拉取。


    2、報文發送頻率和時機的優化


    在將單個協議報文的流量優化之后,我們需要繼續從系統層面深度挖掘優化方法,我們通過和競品對比,發現我們每天發送的報文數量是遠遠高于競品的,于是我們思考, APP 后臺運行時用戶沒有操作,是什么驅動我們的 APP 發送了這么多報文的 ?


    首先我們發現的是信息上報,對于每款 APP 來說,由于運營的需要,需要后臺服務器上采集終端的一些信息,比如上面所說的后臺服務器的配置更改,每次配置更改后我們需要統計,有多少用戶的 APP 配置已經生效,這里就需要在終端拉取了最新的配置后上報給服務器一條信息,就是終端成功更新配置的時間或者版本號。類似于這種運營需要信息上報的地方很多,我們發現 APP 后臺運行時這些信息上報都是實時上報的,如上配置項舉例, APP 每次成功拉取到最新配置后即實時上報一條信息。這樣導致我們的 APP 一天有 30 多條的信息上報,每次信息上報的報文的實際內容其實是不大的,但是報文的頭部是很大的,因為需要標識是哪個終端,就需要使用終端 ID,常用的是 GUID,一個 100 多字節的字符串,還有很多其他字段,由于歷史原因,我們 APP 的協議報文頭共有 400 字節,我們想優化這個報文頭,但是經過詳細的與開發了解背景后決定先不改了,因為很多字段都是因為歷史原因添加上去的,是有用的。


    經過思考,我們對這種實時信息上報提出疑問,后臺服務器需要立即得到這種信息嗎?答案肯定是否的,運營也不是實時去查看這種數據的,所以我們只要保證用戶當天上報該類統計信息即可。于是我們做了一個信息緩存,將需要上報的信息先緩存起來,然后周期性的上報,這里我們選取了 3 小時的周期,一天上報 8 次,這種非實時信息上報為我們節省了很多流量。


    其次,我們發現對于某些發送頻率較高的協議報文,研究了功能后發現移動網絡下用戶點擊的概率其實是不高的,比如視頻的推送,應用更新的推送等等,這些功能都是較費流量的,對于這些功能,移動網絡下其實發送頻率可以降低,但是不能不發,因為存在某些用戶,流量是足夠的。所以修改后的方法是 WiFi 下發送頻率不變,非 WiFi 下發送頻率減半,這樣流量可以節省一半。


    我們把這一階段的優化經驗提煉成兩個優化法則:


    法則三:實時的信息上報后臺運行時改成非實時上報


    后臺運行時產生的日志,先緩存起來,后續周期性的統一上報。


    法則四:非 WiFi 場景降低耗流量的功能的網絡通信頻率


    對于某些網絡通信,給用戶推送了一些較費流量的功能,這些網絡通信在非 WiFi 場景下可以適當降低頻率。


    3、多個報文合并發送


    經過前面的優化,我們已經發現報文的頭是有 400 字節的,由于產品開發團隊的現狀,分屬于不同 feature team 的功能都是在各自的模塊中實現的,所以各個團隊的周期性的任務都是分別進行的,比如后臺運行時 1 小時與后臺交互一次,這種消息我們就發現有兩個, 3 小時與后臺交互一次的消息又有兩個。這種現狀最直接的影響就是報文數量比競品多很多,報文的協議頭開銷就不容忽視。簡單計算一下, 1 小時周期的報文一天發送 24 次, 3 小時的報文一天發送 8 次,這樣一天共有 24*2+8*2 = 64 個消息,報文頭開銷 400*64 = 25600 字節。


    對于這種情況,我們將這些周期性的發送消息進行了合并,放在一個消息中與后臺服務器交互,打破了 feature team 的壁壘,這樣一天只有 24 次的消息通信,報文頭的開銷為 400*24 = 9600 字節,流量消耗大大降低。


    這一階段提煉了一個準則:


    法則五:合并網絡請求,減少請求次數


    4、充分利用 WiFi 傳輸信息


    相信進行到這一步,可挖的優化點已經不多,其實換一個角度,我們還能想到一些優化點。目前大部分用戶每天都是能連接 WiFi 一段時間的,不管是公共 WiFi 和公司或者家里的 WiFi,我們后臺運行的那些報文如果能充分利用好 WiFi,也能為用戶節省流量。比如非實時信息上報,前面優化完之后是 3 小時周期上報,但是上報的時機如果用戶不是連接的 WiFi,也會上報,就會消耗流量,其實我們做一個簡單的處理,就能收到很好的效果,每次非實時信息上報時都判斷一下網絡,如果是 WiFi,則立即上報,如果不是 WiFi,則再等待一個周期,如果下一個周期 3 小時內用戶連接了 WiFi,則在連接 WiFi 的時刻立即上報,如果用戶 3 小時內沒有連接 WiFi,仍然是在移動網絡下上報。


    當然,具體的協議和功能需要根據其特點靈活的利用 WiFi 傳輸信息,在 WiFi 時需要盡量傳輸信息,不在 WiFi 時要盡量等待下一個 WiFi 連接的到來。


    這一階段提煉了一個準則:


    法則六:盡量利用 WiFi 傳輸信息


    當然,流量優化的方法不限于這六個法則,需要結合具體的邏輯,制定最佳的方案。比如長連接對于 push 類的消息的下發是比較省流量的,它只需要少量的心跳來維持連接,然后服務器有更新和推送等消息時直接通過長連接下發下來,不需要客戶端周期性的向服務器發送請求,競品里面有很多邏輯就是使用了長連接,所以流量消耗較少。但是考慮到引入長連接對產品的架構改動較大,所以這個優化只是排了一個長期計劃來一步步實現,不可能短期內實現。


    2.3 優化過程中的經驗與思考


    本案例講解了一般的流量測試和優化方法,簡單將我們整個流量優化過程中的一些項目經驗總結一下。


    1) 流量優化開始,需要對當前流量的協議和各個協議的流量消耗進行精細化監控,摸清當前的現狀。各個協議背后的業務邏輯也需要了解清楚,當初為啥要這樣設計,報文交互的頻率是基于什么考慮的,后續的優化是需要在此基礎上繼續探討可行性方案的。


    2) 流量優化團隊的工作因為涉及到各個開發小組,在項目開始之初是需要得到各個開發小組的支撐許諾的,各個開發小組需要給流量優化項目預留人力的,后續分析的各個優化點涉及的團隊是需要進行相關的開發工作的。


    3) 小步快跑,優化點按計劃分批合入發布版本。流量優化涉及到的優化點比較多,實務比較雜,可以按照一個月一個發布版本的節奏,及時將完成的優化點合入版本發布,不要等到最后一次性合入,因為主版本的代碼隨著特性開發總是在變的,不及時合入發布版本,時間一長,優化點的代碼就會和主線產生差異,合入的代價就會增大。


    4) 自動化流量監控平臺需要項目之初就搭建,該平臺的精細化監控,既可以提供流量優化分析的素材,又可以快速驗證每個優化點修改后的版本,會大大提升開發和測試效率。


    5) 及時總結,每一階段的優化完成后,需要將經驗總結和固化,后續的優化根據這些經驗,能更快的進行分析。


    6) 不能為了流量優化而犧牲功能,這一點尤其重要,我們在整個流量過程中都遵循該原則,每個優化點的修改都不能降低用戶體驗。如果因為降流量,用戶的體驗降低,這個就是舍本逐末,畢竟,用戶體驗是第一位的。


    本文節選自機械工業出版社《短網址性能評測與優化》第 5 章。由機械工業出版社華章IT授權。基于移動閱讀的考慮,部分內容進行了排版調整,想了解本書全部詳細內容,可以在各大書店購買。

    掃描二維碼推送至手機訪問。

    版權聲明:本文由短鏈接發布,如需轉載請注明出處。

    本文鏈接:http://www.virginiabusinesslawupdate.com/article_320.html

    分享給朋友:

    相關文章

    如何進行網站分析?

    如何進行網站分析?

    網站分析的首要目標是提升線上客戶的用戶體驗。短網址分析不是提供報表的一種技術,而是優化網站的一個有效的流程。下述的框架有助于在公司建立數據驅動的文化,去監測客戶與網站的交互,細分客戶群體,了解每個不同群體的行為,分析不同營銷活動的回報率,以...

    大家一定注意了 Chrome 的插件 User-Agent Switcher 是個木馬!

    hrome 商店搜索 User-Agent Switcher,排第一的這個插件(45 萬用戶),是一個木馬...https://chrome.google.com/webstore/detail/user-agent-switcher-fo...

    模具價格怎么談?該學學成本核算和報價技巧了!

    模具價格怎么談?該學學成本核算和報價技巧了!

    模具的報價與結算方式有很多,也不盡相同。但是都有一個共同點,即努力使模具的技術與經濟指標有機地結合,產生雙方共同效益。使得模具由估價到報價,由報價到合同價格;由合同價格到結算價格,即形成真正實際的模具價格,實行優質優價。這個過程里,人們總是...

    100個外國人60個用微信支付,支付寶尷尬了

    100個外國人60個用微信支付,支付寶尷尬了

    很多人認為我國移動互聯網的發展“讓老外驚呆了”,但微信的大數據給出了不一樣的答案。在我國的“老外”用微信發表情的數量比我國典型用戶多45%,每月人均發送微信紅包次數高達10次。今日微信發布的在華外國用戶微信日子觀察陳述顯示,微信不僅是我國人...

    ofo飛鴿代工廠探訪:一分鐘造4輛車

    ofo飛鴿代工廠探訪:一分鐘造4輛車

    共享單車競爭趨于“白熱化”的同時,各地方正在趕緊辦理整治亂停亂放。大家不禁思考,這些單車終究產于何處?怎樣的流程才能讓單車在短時間內大批下線?帶著疑問,短網址資訊小編走進天津飛鴿自行車廠,對ofo出產線進行了實地看望?! ≡谶@家位于天津市區...

    解析百雀羚的廣告為什么刷爆朋友圈

    雖然我們曉得這是一則廣告,但是我們還是想要看到最后一刻,這就是好的想法和創意帶給我們的吸收力。朋友圈被百雀羚的廣告刷屏,繼寶馬的H5廣告之后,這家降生于1931年的企業再次用一種十分新奇的方式火爆了整個朋友圈。雖然我們曉得這是一則廣告,但是...

    發表評論

    訪客

    ◎歡迎參與討論,請在這里發表您的看法和觀點。
    一本色综合网久久
    1. <tr id="33chb"><label id="33chb"></label></tr>
    2. <pre id="33chb"></pre>