一区二区三区日韩精品-日韩经典一区二区三区-五月激情综合丁香婷婷-欧美精品中文字幕专区

分享

騰訊Bugly干貨分享:Android應(yīng)用性能評測調(diào)優(yōu)

 QCamera 2015-06-17

前言


在智能手機App競爭越來越激烈的今天,Android App各項性能如CPU、內(nèi)存消耗等都是我們在開發(fā)測試中需要關(guān)注的指標(biāo),如何將App打造得更加“優(yōu)雅”是我們需要不斷追求探索的方向,下面我們從內(nèi)存和流暢度兩個緯度來說說如何對Android App進行評測和調(diào)優(yōu)。


一、內(nèi)存


內(nèi)存不是無限使用的,如果內(nèi)存過大或泄漏會出現(xiàn)OOM(Out Of Memory)、UI不流暢等問題,因此內(nèi)存也是一個稀缺資源,我們應(yīng)該保證沒有內(nèi)存泄漏且對不需要使用的內(nèi)存及時釋放。一般內(nèi)存測試或分析內(nèi)存問題可以分為下面幾步:


  • 編譯代碼

  • 選定測試場景(來自于經(jīng)驗&開發(fā))

  • 測試場景轉(zhuǎn)換成用例

  • 跑起工具Run用例

  • 結(jié)合代碼,分析,分析…


1.內(nèi)存測試通用的方法


測試分析內(nèi)存有以下幾種方法:


  • DDMS(Heap&Allocation Tracker)


Heap查看堆的分配情況:




主要關(guān)注兩項數(shù)據(jù):


1)Heap Size堆的大小,當(dāng)資源增加,當(dāng)前堆的空余空間不夠時,系統(tǒng)會增加堆的大小。

2)Allocated堆中已分配的大小,這是應(yīng)用程序?qū)嶋H占用的內(nèi)存大小,資源回收后,此項數(shù)據(jù)會變小。


注:如果進行反復(fù)操作,或堆的大小一直增加,則有內(nèi)存泄漏的隱患。


Allocation Tracker跟蹤內(nèi)存分配情況:




MAT(Memory Analyzer)


  • Leak Suspects:內(nèi)存泄露報告

  • Top Components:吃貨報告

  • Histogram:每個Class占用內(nèi)存

  • Dominator Tree:列出哪些對象占用內(nèi)存最多以及誰hold住這些對象


2. Android常見的內(nèi)存問題


Android常見的內(nèi)存問題有:


  • 萬惡的Static通常見到在單例模式


下面就是一個例子,static變量占用過大的內(nèi)存比例(7.1M),這里碰到該情況需要具體分析里面數(shù)據(jù)是否都是需要常駐的,不要把很多不相干的變量設(shè)為static屬性。




  • 多線程生命周期過長hold住本該釋放資源


這里需要自己搜索代碼查看是哪里一直hold住了資源導(dǎo)致沒有釋放。


  • 大胖子Bitmap




圖上可以看到Bitmap占用內(nèi)存很大(5.7M),利用MAT來找到他的outgoing和incoming引用:




可以找到這塊內(nèi)存的引用關(guān)系,然后找代碼。




在遇到圖片資源占用過大的情況,建議:


1)及時的銷毀;
2)設(shè)置一定的采樣率;
3)巧妙的運用軟引用(SoftRefrence)。



    • Cursor


    Cursor用完記得關(guān)掉,如果實在不確定Cursor是否關(guān)閉,可以在onDestroy中關(guān)了。




    總的來說,沒有嚴(yán)格意義上泄露只是你hold太久。


    二、流暢度


    對于App是否流暢這個維度,之前一直沒有一個客觀的數(shù)據(jù)來將用戶客觀感受和數(shù)據(jù)一一對應(yīng)起來。雖然之前有FPS(每秒幀數(shù))這個指標(biāo)來衡量,不過這對于App這樣的大部分時候可能沒有界面更新的軟件來說,是一個不恰當(dāng)?shù)目陀^數(shù)據(jù)(當(dāng)然FPS用于游戲或視頻類業(yè)務(wù)肯定是沒問題的)。在和我們的瀏覽器團隊溝通后,應(yīng)他們的需求(它不僅要做最快的瀏覽器,同時也要做最流暢的瀏覽器),MIG(專項測試組)多位同學(xué)一起來通過研究Android自身UI更新機制以及通過數(shù)學(xué)建模摸索出一個客觀數(shù)據(jù)指標(biāo)流暢度(SM: SMoothness)來量化流暢度這個客觀感受。


    首先從下面開始…


    1. Android如何繪制UI


    關(guān)于Android是如何去更新UI的,我相信有很多文章來介紹其中步驟以及過程,大體上可以用下圖來展示:




    從圖中可以看到,無論哪條路走下去始終都由SurfaceFlinger來控制最后更新。在Android版本更新過程中發(fā)現(xiàn)在Jelly Bean版本更新中,Google加入一個Project Butter來解決嚴(yán)重影響Android口碑問題之一的UI流暢性差的問題。而Project Butter中引入了三個核心元素,即VSync(垂直同步)、Triple Buffer和Choreographer。


    2. 先VSync開始


    在Android 4.1(JB)中引入了VSync機制,是Vertical Synchronization(垂直同步)的縮寫,是一種在PC上已經(jīng)很早就廣泛使用的技術(shù),可以簡單地把它認(rèn)為是一種定時中斷。




    如上圖所示在VSync機制下的繪制過程。從上面的圖看CPU和GPU處理時間都很快都少于一個VSync的間隔也就是16ms,并且每個間隔都有繪制的情況下那么當(dāng)前的FPS即是60幀。當(dāng)CPU和GPU處理時間都很慢或者因為其他的原因,比如在主線程中干活太多那么就會出現(xiàn)如下圖這樣的狀況。




    從上圖可以看到CPU和GPU處理時間因為各種原因比較慢都大于一個VSync的間隔(16ms),那么可以看到在第二個VSync還在處理A區(qū)域的繪制這樣就不可能實現(xiàn)理論上的FPS 60了同時也出現(xiàn)了丟幀(SF: Skipped Frame)。上圖為了便于理解用的是雙Buffer機制的情況,實際上Android 4.1在引入了Triple Buffer,所以當(dāng)雙Buffer不夠用時Triple Buffer丟幀的情況如下圖所示。




    Oh my ladygaga~~~這些把灑家看暈了…那打個比方講得通俗點。


    VSync機制就像是一臺轉(zhuǎn)速固定的發(fā)動機(60轉(zhuǎn)/s)。它每一轉(zhuǎn)帶動著去做一些UI相關(guān)的事情,但是不是每一轉(zhuǎn)都會有工作去做(就像有時在空擋,有時在D檔)。有時候因為各種阻力某一圈工作量比較重超過了16.6ms,那么這臺發(fā)動機這秒內(nèi)就不是60轉(zhuǎn)了,當(dāng)然也有可能被其他因素影響比如給油不足(主線程里干的活太多)等等。就會出現(xiàn)轉(zhuǎn)速降低的狀況我們把這個轉(zhuǎn)速叫做流暢度。



    3. 從FPS&丟幀到流暢度(SM: SMoothness)


    實際上在我們很多的Android App中,很少有需要不斷地去繪制的場景,很多時候都是靜態(tài)的。也就是會出現(xiàn)這樣的狀況,雖然1s中VSync的60個Loop中不是每個都在做繪制的工作FPS比較低,但并不能代表這個時候程序不流暢(如我將App放在那不動實測FPS為1)。所以FPS為1這個數(shù)并不能代表當(dāng)前App在UI上界面不流暢,因此1s內(nèi)VSync這個Loop運行了多少次更加能說明當(dāng)前App的流暢程度。So…另2個指標(biāo)比FPS更加能代表當(dāng)前的App是否處于流暢的狀態(tài)同樣這2個指標(biāo)更加能夠量化App卡頓的程度:


    • 丟幀(SF: Skipped Frame):如上圖所示情況應(yīng)該在16ms完成工作卻因各種原因沒做完,占了下n個16ms的時間,相當(dāng)于丟了n幀。

    • 流暢度(SM: SMoothness):和丟幀相對,在VSync機制中1s內(nèi)Loop運行的次數(shù)。


    1)和丟幀相對1s內(nèi)有60個Loop因為某幾次工作時間超過了16ms(丟幀),這樣Loop就無法運行60次(理論最大值)。


    2)當(dāng)流暢度越小的時候說明當(dāng)前程序越卡頓。


    4. 數(shù)數(shù):如何得到流暢度(SM: SMoothness)


    接著上面的結(jié)論如果在這樣的機制下每次Loop運行之前通知我下,我就記個數(shù)就好了。


    很幸運我們在新的Android的那一套機制中找到了一個畫圖的打雜工Choreographer這個對象。根據(jù)Google的官方API文檔描述他是用來協(xié)調(diào)animations、input以及drawing時序的,并且每個Looper共用一個Choreographer對象。


    Choreographer的定義和結(jié)構(gòu):



    5. 所以通過如上原理分析可以得出結(jié)論:


    • 根據(jù)了解文檔發(fā)現(xiàn)Android 4.1引入了VSync機制可以通過其Loop來了解當(dāng)前App最高繪制能力。


    1) 固定每隔16.6ms執(zhí)行一次(這個值是一個靜態(tài)變量會根據(jù)系統(tǒng)版本不同而采不同的值,目前測試版本是16.6ms這樣最高的刷新的幀率就控制在60FPS以內(nèi));


    2) 如果沒有以上事件的時候同樣也會運行這樣一個Loop;


    3) 所以這個Loop在1s之內(nèi)運行了多少次,即可以表示當(dāng)前App繪制的最高的能力,也就是Android App卡頓的程度…


    4) 另,在一次Loop時如果執(zhí)行時間超過了16.6ms,那么多于16.6ms的時間除以16.6ms,即是當(dāng)前App的丟幀(SF: Skipped Frame)。


    • 可以在Choreographer的回調(diào)FrameCallback中按秒計數(shù)表示當(dāng)前App的流暢程度。


    采用這樣方式就可以在App內(nèi)部觀測當(dāng)前App的流暢度。當(dāng)然,還有更簡單的方法,采用GT工具獲取流暢度,見下面步驟說明。


    6. 用GT動態(tài)注入被測程序獲取SM:


    1)打開被測App,然后打開GT在插件中選擇GT Injector:




    2)選擇被測進程&點擊射它:




    3)注入成功后Para界面會出現(xiàn)流暢度指標(biāo)以及被插入程序的CPU占有率這些并且會帶上被插入的進程名。將流暢度后面小方框勾選(表明記錄SM值到log文件),然后點擊Gather & Warning下小紅圈(表明開始記錄數(shù)值)。






    4)開始做相關(guān)的測試測試。


    5)完成測試后在剛才的界面點擊流暢度(SM)出現(xiàn)下列界面,然后點擊磁盤圖標(biāo),保存log到指定名字的文件夾。






    6)最后利用各種工具(比如應(yīng)用寶)把log導(dǎo)入到PC端進行后期處理(文件保存在SD卡/GT/GW/進程名/自定義文件夾名下)。



    注:以上的操作因為涉及到進程注入需要手機Root權(quán)限,如果不能使用可以郵件給我,地址見文章末尾處。


    7. 那么SM實際的測試效果如何?


    所以,我們拿a、b、c三個瀏覽器為例,對比評測下這樣的數(shù)據(jù)和人感受是否對應(yīng)得上。首先,我們?yōu)榱税迅泄俸腿说母惺軐?yīng)上特把主動感官分?jǐn)?shù)對應(yīng)到以下幾種描述如下表:



    場景1. 瀏覽妹子圖……看看流暢度(SM)和丟幀(SF)之間關(guān)系


    來看看流暢度(SM)和丟幀(SF)之間關(guān)系…這個數(shù)據(jù)是用瀏覽器瀏覽妹子圖時采集。因為丟幀是個不連續(xù)的過程,所以后面的圖中丟幀都是以點來表示其離散的狀態(tài)。




    從上面圖可以看出:


    • 丟幀(SF)越多流暢度(SM)越低…

    • 26:16秒后到26:42之間流暢度很低并且丟幀最密集,在這段期間流暢度主觀評分在2.5。

    • 再看看這期間流暢度,丟幀和主觀的對應(yīng)關(guān)系:




    從這個數(shù)據(jù)可以看到丟幀(SF)越多流暢度(SM)越低,并且主觀感覺是比較卡的(界面滑動明顯頓挫感,響應(yīng)用戶輸入有種慢半拍的感覺)。


    場景2. 看妹子圖……引入FPS看看這3者關(guān)系…


    同樣這段看妹子的過程中主觀感受也是在2.5分:




    這個數(shù)據(jù)里面引入了FPS數(shù)據(jù)。從上圖可以看出:


    • 雖然FPS曲線和SM曲線差不多而且同樣受丟幀的影響;

    • 里面有幾段比較奇怪的地方:


    1)流暢度很高FPS比較低,無丟幀情況…當(dāng)時靜置在某個界面沒有動此時主觀評分應(yīng)該在4.5左右;


    2)FPS比較高,丟幀很嚴(yán)重流暢度很低…當(dāng)時在不斷刷新很多圖片出來主觀評分應(yīng)該在2.0以下。


    把這2部分?jǐn)?shù)據(jù)放大看:


    流暢度很高FPS比較低無丟幀:




    本場景數(shù)據(jù)統(tǒng)計:




    這個局部場景雖然畫面一直在動,沒有丟幀F(xiàn)PS在20以下但是流暢度比較高。So…從次場景可以看出這樣流暢度SM比FPS更加適合來客觀描述Android App卡的程度。


    8. 問題來了:這么多數(shù)據(jù)實在hold不住


    從上面可以看出數(shù)據(jù)量比較大而且?guī)讉€產(chǎn)品條曲線之間有交錯那如何評定哪個在某些場景下更好呢?于是我們就想:通過SM數(shù)據(jù)判斷App流暢情況,并給出一個定量的結(jié)果。


    思路:


    1. 不能直接用平均值和方差。根據(jù)以往經(jīng)驗,通過平均值、方差等一些指標(biāo),并不好說明問題。如果卡頓時間出現(xiàn)較短,測試時間較長,則平均值和方差這種指標(biāo)不容易發(fā)現(xiàn)問題,但是又確實有卡頓。平均值和方差適合描述服從正態(tài)分布的隨機變量,但是測試得到的SM值并不是這樣的隨機變量。

    2. 將測試結(jié)果按卡頓和流暢分段,對每個卡頓區(qū)間段打分。參考了KM上一篇游戲流暢度評分的文章,該文章結(jié)合FPS平均值和卡頓的程度以及頻率,對游戲整體流暢度打分。但是普通App和游戲區(qū)別還是比較大的。對普通App來說,用戶不是一直在操作,不同的操作差異也較大,因此卡頓的頻率一般較低,用平均值和卡頓的頻率打分得到的結(jié)果可能會偏高。所以把測試過程按照卡頓和流暢分段,計算每個卡頓區(qū)間的打分和持續(xù)時間可能更有參考意義。

    3. 總體打分時加大卡頓時的權(quán)重,降低流暢區(qū)間的權(quán)重。雖然我們重點關(guān)注的可能是卡頓的地方,但是競品測試,以及兩個版本對比又需要有總體評判結(jié)果,不能只看局部。為了加大結(jié)果的區(qū)分度,對卡頓區(qū)間增加權(quán)重,對流暢區(qū)間降低權(quán)重。突出卡頓對整體評分的影響。因此,評估結(jié)果將包括兩部分:總體打分以及卡頓區(qū)間,流暢區(qū)間的持續(xù)時間和打分。


    流暢度評估方法:


    1. 預(yù)處理,每5個(秒)一組,取最低值。如果5秒內(nèi)出現(xiàn)多于一次卡頓(SM低于40),則再乘以一個和卡頓次數(shù)有關(guān)的權(quán)值(小于1)。說明:如果卡頓出現(xiàn)次數(shù)較少,平均值和方差不容易發(fā)現(xiàn)問題。因此沒有直接對數(shù)據(jù)評估,先進行了預(yù)處理,突出SM值低的部分,加大卡頓對總分的影響。


    處理前三組數(shù)據(jù):




    處理后三組數(shù)據(jù):




    2. 將處理后的數(shù)據(jù)按卡頓和流暢分段,針對每段打分。說明:如果只有最后總分,且流暢的時間較長,卡頓的數(shù)據(jù)容易被流暢的數(shù)據(jù)淹沒。而且有些測試場景存在一段流暢,一段卡頓的現(xiàn)象,卡頓并不一定在整個測試過程中存在。這樣分開流暢和卡頓的區(qū)間處 理,更容易看出卡頓的程度。


    3. 根據(jù)測試經(jīng)驗,對SM值對應(yīng)的卡頓嚴(yán)重程度打分。說明:根據(jù)測試同學(xué)的經(jīng)驗,流暢度指標(biāo)SM低于40時,用戶能感知到卡頓,SM在20以下卡頓比較嚴(yán)重。因此在打分時,SM值在20以下時打分最低,對應(yīng)0-20,在20-30區(qū)間打分低,對應(yīng)20-60,30-40區(qū)間打 分較低,對應(yīng)60-70,40以上打分在70以上。


    4. 總體打分時降低流暢區(qū)間的權(quán)重。說明:這樣處理的原因和第一項的原因一樣,我們更關(guān)注的是卡頓,流暢區(qū)間過長時會淹沒卡頓的數(shù)據(jù)。

    然后我們拿同一個測試場景下的測試數(shù)據(jù)出來對比一下:


    1)網(wǎng)頁滑動(Nexus 4上測試):


    測試方法:打開某網(wǎng)站,來回上下滑動,在滑動的過程中記錄流暢度數(shù)據(jù)。




    流暢度評估數(shù)據(jù):






    從上面的數(shù)據(jù)可以看出滑動瀏覽網(wǎng)頁的時候,其中c瀏覽器略微好于其他兩個。當(dāng)然這都是在性能比較好的手機(N4)上測試主觀感受差距不大但是從量化數(shù)據(jù)上可以看出優(yōu)劣。評分差距就和主觀感受拉開分值差不多能對應(yīng)上,從客觀上可以證明這套評分算法某種程度上的準(zhǔn)確性。




    作者簡介:葉方正 2008年加入騰訊,目前就職于無線研發(fā)部專項評測組。曾在微博、手機QQ、瀏覽器等項目組負(fù)責(zé)性能優(yōu)化工作,積累大量的移動終端平臺優(yōu)化以及評測經(jīng)驗,郵箱地址:Michaelye#tencent.com(請把#改成@)。


    本文為CSDN原創(chuàng),點擊“閱讀原文”可查看全文并參與討論。


    如果您喜歡這篇文章,請點擊右上角“…”將本文分享給你的朋友。

      本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點。請注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購買等信息,謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊一鍵舉報。
      轉(zhuǎn)藏 分享 獻(xiàn)花(0

      0條評論

      發(fā)表

      請遵守用戶 評論公約

      類似文章 更多

      国产成人免费高潮激情电| 台湾综合熟女一区二区| 熟女一区二区三区国产| 人人妻人人澡人人夜夜| 福利一区二区视频在线| 午夜精品麻豆视频91| 91偷拍视频久久精品| 激情亚洲一区国产精品久久| 精品国产亚洲av久一区二区三区 | 午夜福利黄片免费观看| 亚洲熟女少妇精品一区二区三区| 亚洲日本加勒比在线播放| 亚洲视频一区自拍偷拍另类| 国产一区二区在线免费| 国产精品二区三区免费播放心| 激情偷拍一区二区三区视频 | 亚洲天堂男人在线观看| 男人和女人黄 色大片| 日本熟妇熟女久久综合| 欧美人禽色视频免费看| 国产传媒免费观看视频| 大香蕉再在线大香蕉再在线| 亚洲一区二区精品福利| 亚洲国产av国产av| 欧美人妻少妇精品久久性色| 国产一级不卡视频在线观看| 国产传媒中文字幕东京热| 欧美一区二区三区播放| 久七久精品视频黄色的| 九九热精彩视频在线播放| 国产日韩久久精品一区| 国产内射一级一片内射高清视频| 在线播放欧美精品一区| 丰满少妇被猛烈撞击在线视频| 亚洲第一区二区三区女厕偷拍| 欧美不卡午夜中文字幕| 日本免费一级黄色录像| 久草热视频这里只有精品| 色老汉在线视频免费亚欧| 国产又粗又长又爽又猛的视频| 夫妻性生活黄色录像视频|