偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

【干貨】手機QQ及Qzone速度優(yōu)化實踐

移動開發(fā)
移動互聯(lián)網(wǎng)發(fā)展那么快,運維技術也要適應業(yè)務的變化啊,這次小編找了騰訊牛人介紹的手機QQ和手機Qzone的速度優(yōu)化實踐。

作者介紹:

黃浩宇

現(xiàn)就職于騰訊社交網(wǎng)絡運營部,負責SNG社交網(wǎng)絡業(yè)務移動類產(chǎn)品的業(yè)務運維工作,如QQ、Qzone業(yè)務優(yōu)化及開發(fā)。

此前任職于阿里巴巴,負責天貓商城活動類業(yè)務的運維工作,如天貓雙11,天貓周年慶等。

導語

移動互聯(lián)網(wǎng)發(fā)展那么快,運維技術也要適應業(yè)務的變化啊,這次小編找了騰訊牛人介紹的手機QQ和手機Qzone的速度優(yōu)化實踐。

我們堅信不同垂直領域的運維分工會越來越不同,如何能在不同的業(yè)務形態(tài)上,利用運維技術和數(shù)據(jù)為業(yè)務帶來更大的價值,將是我們下一步探索的重點方向。

1. 關于用戶等待時間

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

等待時間無非就以下三個:

  • Server處理耗時
  • 網(wǎng)絡傳輸耗時
  • 客戶端數(shù)據(jù)處理/UI渲染耗時

QQ/Qzone等產(chǎn)品由于已經(jīng)有多年的Server端優(yōu)化,大部分數(shù)據(jù)都是直接讀寫nosql數(shù)據(jù)庫,接口耗時基本都在30-120ms,優(yōu)化Server實際的收益并不會很大。

下面主要介紹后兩個方向上的優(yōu)化實踐。

2. 網(wǎng)絡傳輸

首先我們需要統(tǒng)計數(shù)據(jù)在網(wǎng)絡傳輸?shù)暮臅r情況,才能知道優(yōu)化網(wǎng)絡傳輸有多少價值

2.1 網(wǎng)絡傳輸耗時統(tǒng)計

網(wǎng)絡耗時通過TCP協(xié)議的三次握手在服務端進行統(tǒng)計,優(yōu)點是簡單快速低成本,具體方案如下:

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

 [[193829]]  

圖2.1 從服務端測網(wǎng)絡延時

通過實際數(shù)據(jù)統(tǒng)計,在不跨網(wǎng)訪問的情況下(信號正常):

  • 4G耗時約30-100ms
  • 3G耗時約 200-400ms

從速度結(jié)果上看,目前主流的3G/4G網(wǎng)速還是相當不錯的,但是由于移動網(wǎng)絡的復雜性,從QQ和空間的業(yè)務返回碼監(jiān)控上還是發(fā)現(xiàn)有不少問題:

  • 跨網(wǎng)訪問
  • 跨地區(qū)訪問
  • 某些小運營商劫持等

下面分享下手機Qzone在接入組件的優(yōu)化策略

2.2 手機Qzone WNS接入策略

簡介:WNS,手機QQ空間APP到服務端通信框架,支持tcp、http協(xié)議

2.2.1使用私有協(xié)議直接IP長連接訪問(圖2.2)

優(yōu)點:

  • 減少DNS請求耗時
  • 避免DNS域名劫持
  • 單個連接并發(fā)多個數(shù)據(jù)請求減少連接數(shù)的開銷(相對http)
  • 私服協(xié)議加密安全;

缺點:由于不走域名,首次連接需要額外的策略來找到合適的接入點,并且需要有重定向能力

 

圖2.2 私有協(xié)議直接IP長連接

2.2.2 首次連接策略

世界上最遙遠的距離就是你在聯(lián)通,而我在電信。在復雜的移動網(wǎng)絡環(huán)境下,我們需要優(yōu)化網(wǎng)絡的接入策略避免跨網(wǎng)/跨地區(qū)訪問。

使用移動網(wǎng)絡時我們先識別用戶的運營商,同時起4個連接,多個接入IP+多個端口+2種協(xié)議,再同時使用2種協(xié)議和多個端口是為了避免有些本地運營商的限制,使用第一個連接上的連接(見圖2.3)

 

圖2.3 首次并發(fā)嘗試連接

使用WIFI的用戶首次連接會優(yōu)先使用域名嘗試連接。

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

騰訊擁有國內(nèi)大量的CDN節(jié)點,即使是偏遠地區(qū)也可以通過CDN節(jié)點接入做為代理!

優(yōu)點:多種首次連接策略能有效的保證用戶最大可能的先連上服務器,這在復雜的移動網(wǎng)絡中特別重要!

缺點:首次連接有額外開銷;連接上不一定是最優(yōu)的接入點;使用CDN節(jié)點做為代理接入成本較高

2.2.3 最優(yōu)接入&重定向

連接上之后服務端通過GSLB IP庫識別用戶的出口IP,如果發(fā)現(xiàn)用戶的接入不是最優(yōu)的接入,通過大數(shù)據(jù)分析該用戶在某個時段最應該使用的接入點,會下發(fā)重定向指令,讓客戶端連接到最優(yōu)的服務端接入IP,WIFI下還會緩存住SSID和接入IP。

優(yōu)點:讓用戶能就近/最優(yōu)接入,減少網(wǎng)絡的耗時

缺點:少部分用戶首次使用需要連接2次服務器;

2.2.4 使用字典做數(shù)據(jù)壓縮

減少帶寬開銷;安全

2.2.5 心跳

避免長連接斷開

2.2.6 單連接并發(fā)請求

相對多連接單請求的傳統(tǒng)HTTP模式(HTTP 2.0之前),用單連接可以大大減少客戶端和服務端開銷

結(jié)論

移動網(wǎng)絡上我們能做的優(yōu)化無非就是減少連接,減少請求,避免跨網(wǎng)跨區(qū),優(yōu)化協(xié)議。而隨著4G/光纖的快速發(fā)展,以后越來越多用戶在網(wǎng)絡上的耗時會越來越少,意味著我們網(wǎng)絡策略上的優(yōu)化效果收益也會越來越低,這時我們把目光投向終端。

3. 終端耗時

同上,首先需要確認終端的耗時情況以確認優(yōu)化預期和目標。

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

可以得出這樣的結(jié)論:終端的問題很嚴重,而且跟用戶操作體驗直接相關!

3.1 Android/IOS系統(tǒng)背景

既然是想優(yōu)化移動客戶端,那對于操作系統(tǒng)(Android和IOS)需要有個基本的了解,兩者都是基于UNIX/LINUX開發(fā)的系統(tǒng),對于運維人員來說很多概念都很好理解。

其中比較重要的一條設計理念是:Android和IOS都能進行多線程開發(fā),其中有一個是主線程也稱UI線程,UI線程是唯一有權限操作用戶UI的線程,如果用戶在操作有體驗上的問題,那肯定是因為主線程被堵塞或沒有足夠的運行資源。所以從主線程的監(jiān)控和系統(tǒng)資源的占用入手。

3.2 監(jiān)控的策略

怎么判斷終端出現(xiàn)卡慢等性能問題呢?通過上面對andoid和ios的背景介紹,我們的目標放在主線程的監(jiān)控上,這邊主要有2種監(jiān)控策略:

1).監(jiān)控函數(shù)間調(diào)用耗時

當主線程調(diào)用函數(shù)調(diào)用超過N秒時,主線程處于等待堵塞狀態(tài),用戶所有UI行為暫停,所以認為終端出現(xiàn)卡的情況。

缺點:無法準確反應用戶的體驗

優(yōu)點:實現(xiàn)成本低,開銷低

2).監(jiān)控屏幕FPS,監(jiān)控掉幀數(shù)

當用戶操作時發(fā)生頁面掉幀時,認為用戶發(fā)生卡慢或卡頓(如圖3-1)

優(yōu)點:真實反應用戶的體驗,而且能對卡慢卡頓的體驗分級,如分為短卡、長卡

缺點:有額外的FPS監(jiān)控開銷,經(jīng)過測試該開銷大概占整個APP開銷的2%

 

如圖3-1監(jiān)控屏幕FPS的次數(shù)

3.3 堆棧的采集

監(jiān)控的策略有,接下來應該考慮怎樣配合監(jiān)控策略,把“案發(fā)現(xiàn)場”的數(shù)據(jù)獲取出來并上報至服務端。

“案發(fā)現(xiàn)場”數(shù)據(jù)除了系統(tǒng)資源,如CPU、內(nèi)存等,最重要的一定是代碼的執(zhí)行堆棧數(shù)據(jù)。由于移動終端性能資源有限,在采集堆棧數(shù)據(jù)的時候要非常注意對系統(tǒng)的影響,所以需要定好觸發(fā)采集堆棧的時機,這邊主要也有2種采集方案:

3.3.1 開啟額外的線程記錄主線程堆棧

額外啟動一個子線程,子線程記錄著主線程的堆棧數(shù)據(jù),當發(fā)生卡頓的時候從該線程獲取到堆棧數(shù)據(jù),優(yōu)點是只需要引入一個很小的SDK包,而且無視版本的編譯方法和虛擬機。獲取堆棧的策略也分為 消極策略和積極策略

消極策略:

認為卡慢卡頓的問題在短時間內(nèi)只會發(fā)生一次,如果錯過了將無法獲取到真實的現(xiàn)場堆棧。

該策略的做法是:子線程時刻獲取著主線程的堆棧,當主線程發(fā)生問題時,通過發(fā)生問題的開始時間戳和結(jié)束時間戳,在子線程獲取到案發(fā)時的堆棧數(shù)據(jù)(如圖3-2)

缺點:需要子線程時刻記錄主線程堆棧,開銷大

優(yōu)點:獲取到的堆棧數(shù)據(jù)準確 

 

圖3-1監(jiān)控主線程函數(shù)調(diào)用耗時

積極策略:

認為卡慢卡頓的問題在短時間內(nèi)會發(fā)生幾次或持續(xù)發(fā)生一段時間。

該策略的做法是:當主線程發(fā)生問題時,激活子線程獲取堆棧,在接下來的N秒內(nèi)在子線程獲取X個堆棧

缺點:堆棧有隨機性,獲取到的堆棧是案發(fā)后的堆棧

優(yōu)點:額外開銷極少,對APP基本沒影響

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

通過在編譯階段使用工具在每個函數(shù)調(diào)用點加入耗時統(tǒng)計函數(shù)

缺點:增加APP包大小,經(jīng)過測試約增加APP10~20%的包大小,而且不同編譯方法和虛擬機需要不同的工具支持打樁嵌入;缺少系統(tǒng)調(diào)用數(shù)據(jù)

優(yōu)點:無需運行時的額外線程額外開銷

2種方案都各有優(yōu)點各有可取之處,但由于產(chǎn)品對包大小有嚴格限制,目前在QQ和Qzone主要采用方案1

3.4 大數(shù)據(jù)聚類分析

前面提到,方案1的消極策略對終端性能影響較大,但是積極策略獲取到的數(shù)據(jù)有隨機性,即客戶端無法精確的捕獲到問題堆棧。

而目前我們主要采用積極策略+大數(shù)據(jù)聚類分析的方法來分析問題。這一方案的基本思想是如果一段邏輯代碼真的有性能問題,那大多數(shù)用戶都發(fā)生。

所以我們采用對堆棧數(shù)據(jù)做聚類分析的方法,將能形成數(shù)據(jù)規(guī)模的堆棧找出來,過濾掉偶爾由于隨機性獲取到的無關堆棧。

對堆棧的聚類統(tǒng)計上,我們主要通過構(gòu)建CT(ClimbingTree)來解決。

ClimbingTree是內(nèi)部叫法,主要思路是通過堆棧生成堆棧樹,并利用海量數(shù)據(jù)加權計算(主要是函數(shù)耗時)到樹上,最后根據(jù)權重將同層節(jié)點運行從左到右進行排序,并將設定閾值以下的節(jié)點運行剪枝。

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

3.4.1 構(gòu)建CT(ClimbingTree)圖

先將一個用戶的一個上報堆棧數(shù)據(jù)先進行預處理,包括解密文件、翻譯堆棧函數(shù)、格式化堆棧、過濾掉無關數(shù)據(jù)等步驟,最終生成一條業(yè)務函數(shù)調(diào)用關系鏈。

根據(jù)調(diào)用關系,合并同個用戶多個調(diào)用關系鏈,相同節(jié)點耗時相加,并按每個樹節(jié)點的耗時從左到右排序,生成函數(shù)調(diào)用關系樹(見圖3-3)

圖3-3 函數(shù)調(diào)用關系樹

合并多個用戶的調(diào)用關系樹,剪掉閾值下低權重的節(jié)點樹枝,就可以生成CT(ClimbingTree)。這棵樹里就包含了所有問題堆棧的數(shù)據(jù)聚集,并且問題嚴重程度從左到右排序(見圖3-4)。

圖假設每個節(jié)點耗時為1s,那么CT里A-B-C這條調(diào)用關系鏈很有可能就是問題所在的函數(shù)調(diào)用關系鏈(因為C節(jié)點對父節(jié)點的耗時占比為:2/4=50%)

 

圖3-4 CT圖

CT的優(yōu)點在于將海量的數(shù)據(jù)聚集統(tǒng)計到少量的森林數(shù)據(jù)節(jié)點里(約壓縮90%-95%的數(shù)據(jù)量)

由于左子節(jié)點一定比右節(jié)點耗時長,所以往往左子節(jié)點即是影響父節(jié)點的問題所在,通過分析左子節(jié)點占父節(jié)點的耗時占比可以得到最根源的耗時函數(shù)所在(見圖3-4、圖3-5)  

 

圖3-5 尋找最根源的耗時函數(shù)節(jié)點

3.5 終端常見性能問題總結(jié)

最常見的問題在主線程做長耗時操作,如

  • 數(shù)據(jù)庫操作
  • 網(wǎng)絡連接等待
  • 網(wǎng)絡數(shù)據(jù)等待
  • 復雜邏輯計算
  • SD卡檢查或讀寫

常用的優(yōu)化方法:

使用子線程做異步操作,如數(shù)據(jù)庫的寫操作,配置網(wǎng)絡拉取等可預加載的提前預加載,例如利用APP打開等待首頁的時間打開網(wǎng)絡長連接,對視頻音頻數(shù)據(jù)做預加載等

能延后處理的異步延后處理,如SD卡檢查,異步發(fā)消息等

3.6 案例&效果

QQ IOS某幾個版本經(jīng)過優(yōu)化之后的卡慢投訴數(shù)據(jù):

 

Qzone Android:某幾個版本的卡慢發(fā)生率(卡慢發(fā)生率=卡慢發(fā)生人數(shù)/使用人數(shù)) 

 

4.總結(jié)

在高速發(fā)展的移動互聯(lián)網(wǎng)時代,運維技術要適應業(yè)務的變化,本文介紹的手機QQ和手機Qzone的速度優(yōu)化實踐,是騰訊運維利用大數(shù)據(jù)技術為業(yè)務創(chuàng)造價值的小案例。

我們堅信隨著運維崗位的發(fā)展,不同垂直領域的運維分工也會隨之而生,如何能在不同的業(yè)務形態(tài)上,利用運維技術和數(shù)據(jù)為業(yè)務帶來更大的價值,用數(shù)據(jù)說話讓數(shù)據(jù)發(fā)聲,將是我們下一步探索的重點方向。 

責任編輯:龐桂玉 來源: Android技術之家
相關推薦

2024-12-03 11:12:47

2019-11-05 10:00:06

手機QQQQ空間QQ

2019-03-15 15:00:49

Webpack構(gòu)建速度前端

2011-06-29 14:27:58

網(wǎng)站優(yōu)化

2021-07-28 10:10:30

ITIT領導IT管理

2021-01-08 09:40:40

優(yōu)化VUE性能

2011-10-21 15:39:29

手機QQ手機管家

2009-07-14 10:13:38

MyEclipse優(yōu)化

2022-05-12 11:41:16

開發(fā)框架程序

2023-05-12 09:58:05

編譯優(yōu)化

2021-12-24 08:01:44

Webpack優(yōu)化打包

2011-09-26 14:51:05

QQ手機管家

2011-11-10 18:56:40

2011-10-21 14:57:32

QQ手機管家Android節(jié)電

2021-02-09 07:35:16

手機QQ紅包APP

2021-07-25 09:18:04

QQ騰訊移動應用

2020-03-23 15:15:57

MySQL性能優(yōu)化數(shù)據(jù)庫

2013-03-27 09:17:17

Android開發(fā)AndroidList

2009-06-25 14:09:37

優(yōu)化MyEclipse

2009-09-04 11:34:31

NetBeans優(yōu)化
點贊
收藏

51CTO技術棧公眾號