作者介紹：

黃浩宇

現就職於騰訊社交網路運營部，負責SNG社交網路業務移動類產品的業務運維工作，如QQ、Qzone業務優化及開發。
此前任職於阿里巴巴，負責天貓商城活動類業務的運維工作，如天貓雙11，天貓週年慶等。

導語

移動網際網路發展那麼快，運維技術也要適應業務的變化啊，這次小編找了騰訊牛人介紹的手機QQ和手機Qzone的速度優化實踐。

我們堅信不同垂直領域的運維分工會越來越不同，如何能在不同的業務形態上，利用運維技術和資料為業務帶來更大的價值，將是我們下一步探索的重點方向。

1. 關於使用者等待時間

對使用者來說，最直觀的感受就是APP的等待時間，所以我們首先要分析清楚APP到底在哪裡讓使用者等待，耗時在哪裡。

等待時間無非就以下三個：
· Server處理耗時
· 網路傳輸耗時
· 客戶端資料處理/UI渲染耗時

QQ/Qzone等產品由於已經有多年的Server端優化，大部分資料都是直接讀寫nosql資料庫，介面耗時基本都在30-120ms，優化Server實際的收益並不會很大。
下面主要介紹後兩個方向上的優化實踐。

2. 網路傳輸

首先我們需要統計資料在網路傳輸的耗時情況，才能知道優化網路傳輸有多少價值

2.1 網路傳輸耗時統計

網路耗時通過TCP協議的三次握手在服務端進行統計，優點是簡單快速低成本，具體方案如下：

1. 記錄下第一次握手時服務端收到SYNC包的時間Time1
2. 記錄下第三次握手時服務端收到的ACK包時間Time2
3. 兩個時間之差即是網路往返耗時RT（Time2-Time1）（見圖2.1）

圖2.1 從服務端測網路延時

通過實際資料統計，在不跨網訪問的情況下（訊號正常）：
· 4G耗時約30-100ms
· 3G耗時約 200-400ms

從速度結果上看，目前主流的3G/4G網速還是相當不錯的，但是由於行動網路的複雜性，從QQ和空間的業務返回碼監控上還是發現有不少問題:
· 跨網訪問
· 跨地區訪問
· 某些小運營商劫持等

下面分享下手機Qzone在接入元件的優化策略

2.2 手機Qzone WNS接入策略

簡介：WNS，手機QQ空間APP到服務端通訊框架，支援tcp、http協議

2.2.1使用私有協議直接IP長連線訪問（圖2.2）

優點：
· 減少DNS請求耗時
· 避免DNS域名劫持
· 單個連線併發多個數據請求減少連線數的開銷（相對http）
· 私服協議加密安全；

缺點：由於不走域名，首次連線需要額外的策略來找到合適的接入點，並且需要有重定向能力

圖2.2 私有協議直接IP長連線

2.2.2 首次連線策略

世界上最遙遠的距離就是你在聯通，而我在電信。在複雜的行動網路環境下，我們需要優化網路的接入策略避免跨網/跨地區訪問。

使用行動網路時我們先識別使用者的運營商，同時起4個連線，多個接入IP+多個埠+2種協議，再同時使用2種協議和多個埠是為了避免有些本地運營商的限制，使用第一個連線上的連線（見圖2.3）

圖2.3 首次併發嘗試連線

使用WIFI的使用者首次連線會優先使用域名嘗試連線。

當上面策略都連不上時客戶端會執行打分策略，使用備份IP列表連上一個速度最快的接入。

騰訊擁有國內大量的CDN節點，即使是偏遠地區也可以通過CDN節點接入做為代理！

優點：多種首次連線策略能有效的保證使用者最大可能的先連上伺服器，這在複雜的行動網路中特別重要！

缺點：首次連線有額外開銷；連線上不一定是最優的接入點；使用CDN節點做為代理接入成本較高

2.2.3 最優接入&重定向

連線上之後服務端通過GSLB IP庫識別使用者的出口IP，如果發現使用者的接入不是最優的接入，通過大資料分析該使用者在某個時段最應該使用的接入點，會下發重定向指令，讓客戶端連線到最優的服務端接入IP，WIFI下還會快取住SSID和接入IP。

優點：讓使用者能就近/最優接入，減少網路的耗時

缺點：少部分使用者首次使用需要連線2次伺服器；

2.2.4 使用字典做資料壓縮

減少頻寬開銷；安全

2.2.5 心跳

避免長連線斷開

2.2.6 單連線併發請求

相對多連線單請求的傳統HTTP模式（HTTP 2.0之前），用單連線可以大大減少客戶端和服務端開銷

結論

行動網路上我們能做的優化無非就是減少連線，減少請求，避免跨網跨區，優化協議。而隨著4G/光纖的快速發展，以後越來越多使用者在網路上的耗時會越來越少，意味著我們網路策略上的優化效果收益也會越來越低，這時我們把目光投向終端。

3. 終端耗時

同上，首先需要確認終端的耗時情況以確認優化預期和目標。

通過在客戶端埋點的上報監控，發現手機Qzone某個灰度版本使用者一些操作之後3秒以上沒響應比率最高達30%；手機QQ某個灰度版本由於UI問題導致畫面掉幀比率約15%，在投訴的問題分類中，卡、慢、卡頓投訴量長期居前三甲。

可以得出這樣的結論：終端的問題很嚴重，而且跟使用者操作體驗直接相關！

3.1 Android/IOS系統背景

既然是想優化移動客戶端，那對於作業系統（Android和IOS）需要有個基本的瞭解，兩者都是基於UNIX/LINUX開發的系統，對於運維人員來說很多概念都很好理解。

其中比較重要的一條設計理念是：Android和IOS都能進行多執行緒開發，其中有一個是主執行緒也稱UI執行緒，UI執行緒是唯一有許可權操作使用者UI的執行緒，如果使用者在操作有體驗上的問題，那肯定是因為主執行緒被堵塞或沒有足夠的執行資源。所以從主執行緒的監控和系統資源的佔用入手。

3.2 監控的策略

怎麼判斷終端出現卡慢等效能問題呢？通過上面對andoid和ios的背景介紹，我們的目標放在主執行緒的監控上，這邊主要有2種監控策略：

1. 監控函式間呼叫耗時
   當主執行緒呼叫函式呼叫超過N秒時，主執行緒處於等待堵塞狀態，使用者所有UI行為暫停，所以認為終端出現卡的情況。

   缺點：無法準確反應使用者的體驗

   優點：實現成本低，開銷低

2. 監控螢幕FPS，監控掉幀數
   當用戶操作時發生頁面掉幀時，認為使用者發生卡慢或卡頓（如圖3-1）

   優點：真實反應使用者的體驗，而且能對卡慢卡頓的體驗分級，如分為短卡、長卡

   缺點：有額外的FPS監控開銷，經過測試該開銷大概佔整個APP開銷的2%

如圖3-1監控螢幕FPS的次數

3.3 堆疊的採集

監控的策略有，接下來應該考慮怎樣配合監控策略，把“案發現場”的資料獲取出來並上報至服務端。

“案發現場”資料除了系統資源，如CPU、記憶體等，最重要的一定是程式碼的執行堆疊資料。由於移動終端效能資源有限，在採集堆疊資料的時候要非常注意對系統的影響，所以需要定好觸發採集堆疊的時機，這邊主要也有2種採集方案：

3.3.1 開啟額外的執行緒記錄主執行緒堆疊

額外啟動一個子執行緒，子執行緒記錄著主執行緒的堆疊資料，當發生卡頓的時候從該執行緒獲取到堆疊資料，優點是隻需要引入一個很小的SDK包，而且無視版本的編譯方法和虛擬機器。獲取堆疊的策略也分為 消極策略和積極策略

1. 消極策略：
   認為卡慢卡頓的問題在短時間內只會發生一次，如果錯過了將無法獲取到真實的現場堆疊。
   該策略的做法是：子執行緒時刻獲取著主執行緒的堆疊，當主執行緒發生問題時，通過發生問題的開始時間戳和結束時間戳，在子執行緒獲取到案發時的堆疊資料（如圖3-2）

   缺點：需要子執行緒時刻記錄主執行緒堆疊，開銷大

   優點：獲取到的堆疊資料準確

圖3-1監控主執行緒函式呼叫耗時

1. 積極策略：
   認為卡慢卡頓的問題在短時間內會發生幾次或持續發生一段時間。

   該策略的做法是：當主執行緒發生問題時，啟用子執行緒獲取堆疊，在接下來的N秒內在子執行緒獲取X個堆疊

   缺點：堆疊有隨機性，獲取到的堆疊是案發後的堆疊

   優點：額外開銷極少，對APP基本沒影響

3.3.2 在編譯階段打樁/嵌入埋點

通過在編譯階段使用工具在每個函式呼叫點加入耗時統計函式

缺點：增加APP包大小，經過測試約增加APP10~20%的包大小，而且不同編譯方法和虛擬機器需要不同的工具支援打樁嵌入；缺少系統呼叫資料

優點：無需執行時的額外執行緒額外開銷

2種方案都各有優點各有可取之處，但由於產品對包大小有嚴格限制，目前在QQ和Qzone主要採用方案1

3.4 大資料聚類分析

前面提到，方案1的消極策略對終端效能影響較大，但是積極策略獲取到的資料有隨機性，即客戶端無法精確的捕獲到問題堆疊。

而目前我們主要採用積極策略+大資料聚類分析的方法來分析問題。這一方案的基本思想是如果一段邏輯程式碼真的有效能問題，那大多數使用者都發生。

所以我們採用對堆疊資料做聚類分析的方法，將能形成資料規模的堆疊找出來，過濾掉偶爾由於隨機性獲取到的無關堆疊。

對堆疊的聚類統計上，我們主要通過構建CT（ClimbingTree）來解決。

ClimbingTree是內部叫法，主要思路是通過堆疊生成堆疊樹，並利用海量資料加權計算（主要是函式耗時）到樹上，最後根據權重將同層節點執行從左到右進行排序，並將設定閾值以下的節點執行剪枝。

ClimbingTree的特點是同一父節點的子節點權重大小從左到右遞減

3.4.1 構建CT（ClimbingTree）圖

先將一個使用者的一個上報堆疊資料先進行預處理，包括解密檔案、翻譯堆疊函式、格式化堆疊、過濾掉無關資料等步驟，最終生成一條業務函式呼叫關係鏈。

根據呼叫關係，合併同個使用者多個呼叫關係鏈，相同節點耗時相加，並按每個樹節點的耗時從左到右排序，生成函式呼叫關係樹（見圖3-3）

圖3-3 函式呼叫關係樹

合併多個使用者的呼叫關係樹，剪掉閾值下低權重的節點樹枝，就可以生成CT（ClimbingTree）。這棵樹裡就包含了所有問題堆疊的資料聚集，並且問題嚴重程度從左到右排序（見圖3-4）。

圖假設每個節點耗時為1s，那麼CT裡A-B-C這條呼叫關係鏈很有可能就是問題所在的函式呼叫關係鏈（因為C節點對父節點的耗時佔比為：2/4=50%）

圖3-4 CT圖

CT的優點在於將海量的資料聚集統計到少量的森林資料節點裡（約壓縮90%-95%的資料量）

由於左子節點一定比右節點耗時長，所以往往左子節點即是影響父節點的問題所在，通過分析左子節點佔父節點的耗時佔比可以得到最根源的耗時函式所在（見圖3-4、圖3-5）

圖3-5 尋找最根源的耗時函式節點

3.5 終端常見效能問題總結

最常見的問題在主執行緒做長耗時操作，如
· 資料庫操作
· 網路連線等待
· 網路資料等待
· 複雜邏輯計算
· SD卡檢查或讀寫

常用的優化方法：
使用子執行緒做非同步操作，如資料庫的寫操作，配置網路拉取等可預載入的提前預載入，例如利用APP開啟等待首頁的時間開啟網路長連線，對視訊音訊資料做預載入等
能延後處理的非同步延後處理，如SD卡檢查，非同步發訊息等

3.6 案例&效果

1. QQ IOS某幾個版本經過優化之後的卡慢投訴資料：

Qzone Android：某幾個版本的卡慢發生率（卡慢發生率=卡慢發生人數/使用人數）

4.總結

在高速發展的移動網際網路時代，運維技術要適應業務的變化，本文介紹的手機QQ和手機Qzone的速度優化實踐，是騰訊運維利用大資料技術為業務創造價值的小案例。

我們堅信隨著運維崗位的發展，不同垂直領域的運維分工也會隨之而生，如何能在不同的業務形態上，利用運維技術和資料為業務帶來更大的價值，用資料說話讓資料發聲，將是我們下一步探索的重點方向。

文章出處：高效運維（greatops）