基于GUI的Android移動(dòng)軟件性能測(cè)試①

谷林濤,徐立華

(華東師范大學(xué) 計(jì)算機(jī)科學(xué)與軟件工程學(xué)院,上海 200062)

隨著智能手機(jī)的日益普及,以及移動(dòng)設(shè)備硬件性能的不斷提升,移動(dòng)應(yīng)用軟件(以下簡(jiǎn)稱APP)越來越多的走進(jìn)人們的生活.根據(jù)IDC2017統(tǒng)計(jì),85.1%的手機(jī)使用了Android平臺(tái).根據(jù)國(guó)外Android開源平臺(tái)FDroid統(tǒng)計(jì),每個(gè)月在Google Play上發(fā)布的新型APP平均數(shù)量多達(dá)五萬.受益于Android的開源性,開發(fā)一個(gè)APP的成本相對(duì)較低,研發(fā)時(shí)間相對(duì)較短.但由于開發(fā)者水平不同,以及Android系統(tǒng)定制化現(xiàn)象嚴(yán)重,APP程序質(zhì)量一直成為大家關(guān)注的焦點(diǎn).因此如何保證APP上線后的程序質(zhì)量,成為了開發(fā)者們關(guān)注的焦點(diǎn),也是學(xué)術(shù)界關(guān)注的一項(xiàng)熱點(diǎn).

現(xiàn)有工作的焦點(diǎn)是對(duì)APP運(yùn)行時(shí)的正確性展開研究,避免運(yùn)行時(shí)APP崩潰,給用戶帶來不良體驗(yàn).但APP在運(yùn)行時(shí)頻繁出現(xiàn)頁面渲染時(shí)間長(zhǎng)、操作反饋慢,甚至出現(xiàn)未響應(yīng)的情況,也會(huì)給用戶帶來的不良的使用體驗(yàn).因此,在APP上線之前對(duì)其進(jìn)行性能測(cè)試,確保運(yùn)行時(shí)流暢也是必不可少的.

近幾年來,學(xué)術(shù)界對(duì)Android性能的分析已經(jīng)逐漸開展,并和自動(dòng)化測(cè)試一起進(jìn)行研究探索.

Linares-vasquez[1]等通過對(duì)開源社區(qū)APP中issue事件的分析,詳細(xì)歸納了導(dǎo)致APP性能出現(xiàn)異常,如線程問題,GUI問題,內(nèi)存問題的原因.

Hecht等[2]提出通過靜態(tài)分析,針對(duì)Get/Set、靜態(tài)方法、以及HashMap的使用分析了對(duì)性能的影響,并通過實(shí)驗(yàn)驗(yàn)證了優(yōu)化上述代碼可以提高Android運(yùn)行的性能,減少頁面的渲染時(shí)間.

Liu等[3]提出了通過靜態(tài)掃描的方式,將APP的bytecode作為入?yún)?通過分析主進(jìn)程中的代碼和getView()的回調(diào)函數(shù)的代碼,來檢測(cè)Android程序中是否存在性能問題.

Hussein等[4]詳細(xì)分析了Java的GC機(jī)制對(duì)APP運(yùn)行時(shí)的影響,并做了量化分析,從垃圾回收這個(gè)角度分析了APP的性能問題.

除了通過靜態(tài)分析,還有動(dòng)態(tài)執(zhí)行的方式.通過動(dòng)態(tài)執(zhí)行,監(jiān)控運(yùn)行時(shí)是否頻繁觸發(fā)GC.或是監(jiān)控View層是否多次繪制,這些手段都可以有效地發(fā)現(xiàn)性能問題.但在測(cè)試過程當(dāng)中,都沒有提出如何進(jìn)行自動(dòng)化的測(cè)試,忽略了性能測(cè)試也需要像功能測(cè)試一樣,實(shí)現(xiàn)自動(dòng)化,方便開發(fā)者使用.

相比傳統(tǒng)軟件,Android程序基于事件驅(qū)動(dòng)的交互方式,使得整個(gè)程序不以線性的方式運(yùn)行.在Reaves等[5]工作中描述了Android的生命周期,使用組件的通訊機(jī)制,頻繁的系統(tǒng)和頁面的回調(diào)機(jī)制,這些特征給Android的自動(dòng)化帶來極大的挑戰(zhàn).在Choudhary等[6]工作中,比較了動(dòng)態(tài)執(zhí)行的工具的效果,其中A3E[7],Dynodroid[8],Monkey[9],GUIRipper[10]等都嘗試通過動(dòng)態(tài)執(zhí)行來對(duì)Android程序進(jìn)行正確性測(cè)試.最終的結(jié)論是,從傳統(tǒng)的代碼覆蓋率效果來評(píng)估,Monkey工具的代碼覆蓋率最高.但Monkey無意義的點(diǎn)擊,以及無法分析頁面信息,使得這個(gè)方法無法滿足性能測(cè)試中需要對(duì)頁面分析的條件.其他的工具使用在性能測(cè)試上,發(fā)現(xiàn)其無法較多發(fā)現(xiàn)APP的頁面狀態(tài),因此不能更多的發(fā)現(xiàn)性能問題.因此,我們需要針對(duì)性能測(cè)試,設(shè)計(jì)特殊的遍歷模式,從而可以有效的發(fā)現(xiàn)性能問題.

Su等[11]通過對(duì)APP建立概率模型,對(duì)APP進(jìn)行隨機(jī)測(cè)試,獲得了良好的效果.他們通過隨機(jī)的方式側(cè)重在程序崩潰的測(cè)試上,使用代碼覆蓋率評(píng)估效果.而性能問題,則是希望遍歷更多狀態(tài)不同的頁面.因此,在自動(dòng)化的遍歷過程中,能發(fā)現(xiàn)更多的頁面狀態(tài),才能更有效地發(fā)現(xiàn)性能問題.

針對(duì)上述問題以及挑戰(zhàn),本文提出基于GUI的Android自動(dòng)化性能測(cè)試技術(shù),并使用Java作為開發(fā)語言,實(shí)現(xiàn)了該自動(dòng)遍歷框架.本框架通過使用UiAutomator對(duì)Android頁面在測(cè)試過程中實(shí)施進(jìn)行抓取,分析,通過安卓調(diào)試橋(Android Debug Bridge,ADB)向終端機(jī)發(fā)送事件,通過對(duì)頁面渲染時(shí)間的監(jiān)控,捕獲頁面延遲的情況.本文提出的自動(dòng)化性能測(cè)試方法具有以下優(yōu)勢(shì).

(1)該工具通過對(duì)頁面的分析、聚類,可以獲得APP更多的運(yùn)行頁面狀態(tài),通過僅發(fā)送有效操作事件,以縮短測(cè)試時(shí)間.

(2)在遍歷過程中,該框架會(huì)實(shí)時(shí)對(duì)頁面進(jìn)行截圖,將操作行為記入log日志,通過監(jiān)控模塊獲取頁面渲染時(shí)間,根據(jù)截圖和操作信息,恢復(fù)問題現(xiàn)場(chǎng),方便開發(fā)者方便地定位延遲的原因.

(3)本工具可以配置操作信息,在測(cè)試過程中,指定在對(duì)應(yīng)的輸入框輸入相應(yīng)的信息,以解決在Monkey測(cè)試過程中,遇到文本框無法輸入正確的信息,導(dǎo)致遍歷無法順利進(jìn)行的問題.

(4)本工具可以同時(shí)在多臺(tái)機(jī)器上測(cè)試APP,以提供給開發(fā)者進(jìn)行不同機(jī)型上同時(shí)進(jìn)行性能測(cè)試的功能.

1 相關(guān)技術(shù)介紹

1.1 UiAutomator介紹

UiAutomator[12]是Android 4.0之后自帶的基于GUI的自動(dòng)化測(cè)試工具.UiAutomator可以將手機(jī)頁面的布局信息抽象為樹形結(jié)構(gòu),以xml文件的形式存儲(chǔ).通過對(duì)xml文件的解析,可以獲取控件的具體信息.比如控件類型(TextView,Button等),控件可以被操作的行為(Clickable,Scrollable等),控件的布局位置.也可獲取控件之間的層級(jí)關(guān)系等信息.本框架的實(shí)現(xiàn)使用該技術(shù),在測(cè)試過程中,實(shí)施抓取、分析測(cè)試過程中的頁面信息,并每次生成一次測(cè)試操作.

1.2 安卓調(diào)試橋(ADB)介紹

ADB[13]是一個(gè)非常強(qiáng)大的PC端命令行工具.通過使用ADB,我們可以從PC端輕松地發(fā)送指令至手機(jī)端.ADB可以實(shí)現(xiàn)對(duì)手機(jī)的指定位置實(shí)現(xiàn)點(diǎn)擊事件、滑動(dòng)事件、截圖事件、傳輸文件、發(fā)送廣播、以及對(duì)手機(jī)端文件的操作.

通過使用ADB forword,還可以實(shí)現(xiàn)手機(jī)端和PC端通過Socket端口進(jìn)行通信,本框架的底層使用了ADB向手機(jī)端發(fā)送shell指令實(shí)現(xiàn)對(duì)手機(jī)端的點(diǎn)擊滑動(dòng)、文件傳輸?shù)炔僮?通過ADB forword,通過Socket端口和手機(jī)端進(jìn)行數(shù)據(jù)交互.

1.3 Xposed介紹

Xposed[14]是一款在可以不修改Android應(yīng)用程序的前提下,改變APP相關(guān)行為的框架.可以實(shí)現(xiàn)對(duì)一些指定方法執(zhí)行前后插入執(zhí)行代碼,在本框架中,我們對(duì)Loop,以及Android系統(tǒng)的VSync進(jìn)行監(jiān)控,獲得實(shí)時(shí)幀數(shù)和Loop執(zhí)行時(shí)長(zhǎng)的信息.

2 框架的設(shè)計(jì)與實(shí)現(xiàn)

Android基于事件驅(qū)動(dòng)的運(yùn)行模式,使得傳統(tǒng)的自動(dòng)化遍歷方法很難在該模式下取得良好的效果.Android程序運(yùn)行時(shí)具有大量多變的人機(jī)交互的GUI,運(yùn)行環(huán)境又非常復(fù)雜.因此在現(xiàn)有相關(guān)工作中,對(duì)頁面的建模、以及測(cè)試之前的靜態(tài)分析在Android的測(cè)試過程中并未取得良好的測(cè)試效果.綜合考慮了Android的GUI多以及環(huán)境復(fù)雜的特點(diǎn),以及隨機(jī)測(cè)試在Android測(cè)試中的優(yōu)越性,本文提出了基于GUI的自動(dòng)化性能測(cè)試,對(duì)APP的頁面進(jìn)行分析,聚合狀態(tài),并根據(jù)狀態(tài)不斷地更新每個(gè)控件在隨機(jī)測(cè)試下被觸發(fā)的概率值.以促使在自動(dòng)化遍歷過程當(dāng)中,能尋找到更多的界面狀態(tài),遍歷更多的程序狀態(tài),以發(fā)現(xiàn)性能上的問題.

該框架總共分為兩個(gè)模塊,其一是執(zhí)行模塊,其二是日志分析模塊.

在執(zhí)行引擎中,主要部分是ADB模塊,該框架是通過ADB的方式連接手機(jī)和計(jì)算機(jī),并發(fā)送點(diǎn)擊、滑動(dòng)等指令,也負(fù)責(zé)傳輸U(kuò)iAutomator產(chǎn)生的xml文件.而通信模塊負(fù)責(zé)與計(jì)算機(jī)實(shí)現(xiàn)一部分?jǐn)?shù)據(jù)交互.

APP狀態(tài)管理模塊負(fù)責(zé)維護(hù)遍歷APP的各個(gè)頁面狀態(tài).一個(gè)APP根據(jù)Activity名稱劃分為多個(gè)Activity狀態(tài),每個(gè)Activity中又存在多個(gè)UI的狀態(tài),相似的狀態(tài)會(huì)被合并,而不同的狀態(tài)會(huì)被新建.每個(gè)狀態(tài)都是由UiAutomator提供的xml文件抽象而成,存儲(chǔ)了所有的控件信息.而行為生成器就會(huì)根據(jù)對(duì)應(yīng)的UI狀態(tài),對(duì)APP發(fā)送對(duì)應(yīng)的操作.

日志記錄是一個(gè)獨(dú)立的模塊,負(fù)責(zé)記錄遍歷APP時(shí)候的操作行為,通過Xposed所產(chǎn)生的幀數(shù)監(jiān)控,以及APP執(zhí)行時(shí)候的狀態(tài)監(jiān)控.

系統(tǒng)架構(gòu)圖如圖1所示.

圖1 系統(tǒng)架構(gòu)圖

APP狀態(tài)模塊的具體行為是在獲取一個(gè)Android手機(jī)運(yùn)行頁面后,首先判斷該頁面所屬的Activity是否被遍歷過.若沒有被遍歷過,則會(huì)生成一個(gè)新的頁面狀態(tài)的實(shí)例,加入到Activity的頁面狀態(tài)中.若被遍歷過,則會(huì)對(duì)比是否與之前的頁面相似.若相似,則合并兩個(gè)頁面的狀態(tài).若不相似,則新建頁面狀態(tài)的實(shí)例,并繼續(xù)加入到該Activity的頁面狀態(tài)中去,是該框架的核心模塊,UI判斷的相似算法在下文中闡述.

每個(gè)頁面實(shí)例會(huì)記錄被執(zhí)行過的歷史記錄,行為生成器會(huì)根據(jù)被測(cè)的歷史記錄,對(duì)每個(gè)控件生成不同的觸發(fā)概率值.最終會(huì)根據(jù)這些不同的概率觸發(fā)值,隨機(jī)選擇一個(gè)控件觸發(fā).其詳細(xì)的工作原理在下文中闡述.

本框架的程序入口會(huì)接收一個(gè)APK文件或者是已經(jīng)安裝好的APP的package名稱.框架在接受到包名以后會(huì)首先加載應(yīng)用,然后首先獲取初始的頁面,然后框架會(huì)獲取頁面的XML文件,通過APP狀態(tài)管理,對(duì)頁面進(jìn)行解析,抽象為頁面狀態(tài)的類.這個(gè)類包含了頁面的信息,狀態(tài)以及頁面所屬Activity名稱等.行為生成器在接收到這些信息后,會(huì)生成一次操作行為,然后再次會(huì)抓取XML文件,提供給狀態(tài)管理器進(jìn)行分析.并由UI相似度來區(qū)分是否是新的頁面狀態(tài).該測(cè)試行為會(huì)持續(xù)直到超過設(shè)定的測(cè)試時(shí)長(zhǎng)或者是測(cè)試的行為次數(shù)才會(huì)終止.

在運(yùn)行過程中,會(huì)有另外的線程負(fù)責(zé)進(jìn)行數(shù)據(jù)的采集,幀數(shù)的分析,以及攔截運(yùn)行時(shí)APP跳出的權(quán)限管理,以及阻止一部分會(huì)使得APP運(yùn)行過程中跳出的行為.

最終,日志分析模塊會(huì)對(duì)APP的操作行為和運(yùn)行時(shí)幀數(shù)的采集兩個(gè)日志進(jìn)行分析,輸出最終的報(bào)告作為結(jié)果.

本框架的整體遍歷邏輯流程圖如圖2所示.

2.1 UI相似判斷

該模塊負(fù)責(zé)對(duì)比一個(gè)Activity下兩個(gè)頁面是否為相似頁面.在相同的Activity中,可能存在多個(gè)不同狀態(tài)的頁面,以實(shí)現(xiàn)不同的功能.例如顯示了用戶新增的信息,或者是切換到了不同的選項(xiàng)卡.因此,單獨(dú)依賴Activity來區(qū)分APP的運(yùn)行狀態(tài)是不準(zhǔn)確的,一個(gè)Activity頁面可能有多個(gè)狀態(tài),而判斷兩個(gè)狀態(tài)是否相同并不能簡(jiǎn)單地通過比對(duì)UiAutomator提供的xml文件,而是要對(duì)xml文件做具體分析.本文提出的自動(dòng)化性能測(cè)試框架中的相似判斷,首先分析布局控件.若布局發(fā)生改變,則被判定為頁面不相似,即兩個(gè)狀態(tài)不同.布局的改變通常說明開發(fā)者在同一個(gè)Activity中,設(shè)有多個(gè)Fragment組件,以實(shí)現(xiàn)頁面不同的功能,亦或是新增了大量控件,實(shí)現(xiàn)了新的業(yè)務(wù)需求.當(dāng)布局沒有發(fā)現(xiàn)變化時(shí),控件數(shù)量成為了判定是否相似的第二個(gè)條件,本框架中通過計(jì)算相同的控件數(shù)和所有的控件數(shù)的比值,從控件相同數(shù)量上進(jìn)行區(qū)分,結(jié)合控件的位置信息,可以判定,兩個(gè)頁面是否相似.UI相似度的分析在該系統(tǒng)中有著重要的作用.其負(fù)責(zé)合并相同的頁面狀態(tài),降低遍歷的時(shí)間,同時(shí)促使框架能遍歷到更多的APP狀態(tài).

圖2 遍歷流程圖

當(dāng)一個(gè)頁面文件被作為輸入后,該模塊首先會(huì)對(duì)其進(jìn)行初始化.根據(jù)控件類型,劃分為滑動(dòng)組件,點(diǎn)擊組件,輸入框組件,以及不必要關(guān)注的組件.其次會(huì)分析布局的組件是否有相互覆蓋,相互重疊的部分,通過這個(gè)條件,我們經(jīng)過分析,可以獲取頁面可執(zhí)行的組件,并封裝在對(duì)應(yīng)的數(shù)據(jù)結(jié)構(gòu)中.在頁面相似的分析中,我們僅考慮經(jīng)過過濾之后的控件信息,這些行為的目的是盡可能從結(jié)構(gòu)上還原用戶的操作頁面.

2.2 遍歷策略

考慮到Android基于事件驅(qū)動(dòng)的運(yùn)行模式,本文采取優(yōu)化的隨機(jī)遍歷方法對(duì)Android的APP進(jìn)行遍歷.Monkey并沒有考慮到每個(gè)Activity的復(fù)雜度、深度以及歷史執(zhí)行情況.因此,本文提出了一種新型的隨機(jī)方法,以解決上述難題和挑戰(zhàn).

我們使用一個(gè)有向圖來表示一個(gè)APP在運(yùn)行過程當(dāng)中Activity的跳轉(zhuǎn)情況.針對(duì)一個(gè)Activity中的每一個(gè)UI狀態(tài),每個(gè)控件都抽象為四個(gè)狀態(tài),分別為操作次數(shù),操作后的狀態(tài),操作類型以及被觸發(fā)的概率值.概率值在頁面第一次生成時(shí),同一個(gè)頁面所有控件被觸發(fā)的概率值都是相同的.在隨機(jī)遍歷過程中,再次回到該頁面時(shí),每個(gè)控件被觸發(fā)的概率值會(huì)根據(jù)歷史測(cè)試行為和Activity的跳轉(zhuǎn)圖來更新為一個(gè)新的值.其目的是為了希望工具能找到更多的APP狀態(tài),遍歷業(yè)務(wù)邏輯復(fù)雜的模塊.其具體算法如下.

算法1.控件概率生成算法1)第一次生成頁面,統(tǒng)計(jì)控件數(shù),并對(duì)每個(gè)可操作的控件初始化狀態(tài).操作次數(shù)為0,操作后的狀態(tài)為null,以及被觸發(fā)的概率為1/可觸發(fā)控件總數(shù).2)當(dāng)?shù)诙畏祷仨撁鏁r(shí),判定是否每個(gè)控件都被觸發(fā)過,若每個(gè)控件都觸發(fā)過,則跳轉(zhuǎn)到3),否則跳轉(zhuǎn)到4).3)若每個(gè)控件都被觸發(fā)過時(shí),根據(jù)Activity跳轉(zhuǎn)的有向圖,分析每個(gè)控件操作后的狀態(tài),并對(duì)每個(gè)組件的后驅(qū)狀態(tài)的頁面控件數(shù)進(jìn)行排序,將后驅(qū)狀態(tài)更復(fù)雜的控件賦予更大的概率值.4)若還存在控件沒有被觸發(fā),則更新概率值,提高沒有被觸發(fā)過的控件被觸發(fā)的概率值.

在遍歷過程當(dāng)中,測(cè)試程序會(huì)根據(jù)每個(gè)控件狀態(tài),隨機(jī)產(chǎn)生行為,進(jìn)而嘗試去發(fā)現(xiàn)新的頁面狀態(tài),并把操作行為發(fā)送到手機(jī)端.

2.3 系統(tǒng)事件的觸發(fā)

Android手機(jī)的行為操作不僅限于用戶點(diǎn)擊、滑動(dòng)等操作,在該測(cè)試過程中,測(cè)試工具也會(huì)以恒定概率向手機(jī)發(fā)送一些系統(tǒng)事件,如,橫豎屏,音量改變.在AVD模式下,提供AndroidManifest.xml支持設(shè)置網(wǎng)絡(luò)變化,電量變化等虛擬操作.以測(cè)試在系統(tǒng)事件被觸發(fā)時(shí),被測(cè)App的行為是否會(huì)異常.

2.4 監(jiān)視器的設(shè)計(jì)

在整個(gè)測(cè)試過程中,監(jiān)視器主要負(fù)責(zé)如下工作.

(1)對(duì)每一步實(shí)現(xiàn)截圖,并在截圖上做出標(biāo)記,記錄每一步操作過程.

(2)實(shí)時(shí)監(jiān)控被測(cè)App是否處于Activity的棧頂.因測(cè)試過程一部分行為會(huì)導(dǎo)致被測(cè)App退出,則重啟APP,并阻止測(cè)試工具繼續(xù)進(jìn)行相同的行為.

(3)由于Android5.0之后授權(quán)方式的改變,運(yùn)行過程中有的APP經(jīng)常彈出授權(quán)按鈕.監(jiān)視器通過頁面分析,可以自動(dòng)授權(quán),使得遍歷程序繼續(xù)運(yùn)行.

2.5 日志分析

Android手機(jī)的屏幕刷新率現(xiàn)在是60 Hz,也就是在1000 ms內(nèi)需要生成60張圖像來保證頁面使用過程的流暢性.因此Android需要在16 ms就發(fā)出一次Vsync信號(hào),進(jìn)行圖像的繪制,否則就會(huì)導(dǎo)致使用過程中畫面不流暢.本框架通過對(duì)頁面的分析、聚合以獲得更多的APP運(yùn)行頁面和狀態(tài),在遍歷過程當(dāng)中,通過監(jiān)視器,監(jiān)控渲染時(shí)長(zhǎng),以16 ms為標(biāo)準(zhǔn),判斷頁面是否出現(xiàn)延遲.在遍歷過程中,我們通過對(duì)幀數(shù)的監(jiān)控,發(fā)現(xiàn)性能問題.

當(dāng)遍歷結(jié)束之后,會(huì)得到行為的記錄信息文件,記錄頁面幀數(shù)異常的文件,以及運(yùn)行操作時(shí)的運(yùn)行截圖,以及狀態(tài)信息.所有文件都以時(shí)間戳作為標(biāo)志,用于恢復(fù)運(yùn)行時(shí)的場(chǎng)景.其中頁面幀數(shù)異常的文件由xposed攔截的函數(shù)運(yùn)行時(shí)間戳分析得到.展現(xiàn)的是幀數(shù)異常的時(shí)間戳信息.將這個(gè)信息和行為信息結(jié)合在一起分析,即可以得到是哪些操作引起的異常.在運(yùn)行過程當(dāng)中,程序也會(huì)記錄在每個(gè)Activity中發(fā)現(xiàn)了多少狀態(tài),提供對(duì)測(cè)試效果的參考值.通過行為操作記錄,可以恢復(fù)出APP的狀態(tài),并可以獲取造成延遲問題操作的前驅(qū)操作和狀態(tài),提供更多的信息.

3 實(shí)驗(yàn)

我們實(shí)驗(yàn)環(huán)境使用的是MacBook Pro,CPU為i7-6700H,內(nèi)存大小16 G,硬盤為1 TB SSD.測(cè)試手機(jī)使用的是Samsung Galaxy NOTEⅡ,Android系統(tǒng)為4.1,預(yù)裝有Xposed框架.

我們?cè)O(shè)定每個(gè)APP的測(cè)試時(shí)間為15分鐘,測(cè)試次數(shù)為2次.隨機(jī)在F-Droid上抽取的50個(gè)APP作為樣本進(jìn)行實(shí)驗(yàn),同時(shí)也在github上獲取了對(duì)應(yīng)APP的源碼.以方便在測(cè)試到問題以后對(duì)源碼進(jìn)行分析.

在實(shí)驗(yàn)當(dāng)中,我們通過對(duì)日志的分析,總共發(fā)現(xiàn)有7個(gè)APP存在性能問題,詳細(xì)數(shù)據(jù)如表1所示.

表1 性能測(cè)試報(bào)告以及原因簡(jiǎn)析

在實(shí)驗(yàn)中,我們通過分析日志,發(fā)現(xiàn)異常信息后,對(duì)源碼進(jìn)行了查看.除了ccrama這個(gè)APP以外,我們均發(fā)現(xiàn)其余APP在主線程中執(zhí)行時(shí)間過長(zhǎng),同時(shí)在Xposed提供的日志中發(fā)現(xiàn)了信號(hào)超過16ms的情況,即在運(yùn)行過程中,頁面發(fā)生了不流暢的現(xiàn)象,存在性能問題,給用戶帶來不良的使用體驗(yàn).其中在ccrama的操作過程中,我們并沒有發(fā)現(xiàn)任何執(zhí)行時(shí)間過長(zhǎng)的問題,卻在VSync中發(fā)現(xiàn)了異常.根據(jù)對(duì)日志時(shí)間戳的進(jìn)一步分析,我們發(fā)現(xiàn)是在該APP滑動(dòng)的過程中,發(fā)生了頁面不流暢的問題,而并非是傳統(tǒng)的主線程異常.而在其他的APP中,我們同樣對(duì)源碼進(jìn)行了分析,確定了異常的原因,是主線程中大圖像加載導(dǎo)致的,或者是在主線程中的阻塞線程,以及不合理的多線程問題引起的.

在抽取的APP當(dāng)中,也有2個(gè)發(fā)生了無法進(jìn)行遍歷,正常執(zhí)行的情況.我們查看原因,發(fā)現(xiàn)這兩個(gè)APP并不是傳統(tǒng)的APP,而是使用了游戲引擎控件,導(dǎo)致我們無法通過UiAutomator抓取并分析頁面,因此無法獲取可以被點(diǎn)擊的控件,最終導(dǎo)致遍歷無法進(jìn)行,并在測(cè)試過程中一直停留在初始頁面.

通過實(shí)驗(yàn),可以體現(xiàn)本文提出的自動(dòng)化框架通過動(dòng)態(tài)執(zhí)行,可以遍歷到APP的各個(gè)狀態(tài),并通過Log日志分析,發(fā)現(xiàn)性能問題.具有良好的實(shí)用價(jià)值.

4 結(jié)語

本文提出了一個(gè)自動(dòng)化的Android應(yīng)用軟件的性能性能測(cè)試框架,既考慮到Android運(yùn)行狀態(tài)的多樣性,也考慮到系統(tǒng)事件的調(diào)用,使用了隨機(jī)遍歷的方式,相對(duì)于功能性測(cè)試,更側(cè)重遍歷頁面的狀態(tài),發(fā)現(xiàn)APP在運(yùn)行過程中產(chǎn)生不同的頁面狀態(tài).通過對(duì)運(yùn)行狀態(tài)的暫存,我們可以快速地從出現(xiàn)性能問題的狀態(tài)中實(shí)現(xiàn)場(chǎng)景恢復(fù),方便開發(fā)人員快速定位問題.

在實(shí)驗(yàn)過程中,我們發(fā)現(xiàn)了不能進(jìn)行遍歷的情況的APP,是由于無法被UiAutomator捕獲到正確的頁面,導(dǎo)致無法進(jìn)行頁面分析所引起的.在以后的工作中,我們可以考慮使用圖像識(shí)別,OCR技術(shù)等方式,嘗試在非傳統(tǒng)APP上對(duì)頁面進(jìn)行分析,然后抽象出對(duì)應(yīng)的頁面狀態(tài),用這種方法替換我們現(xiàn)在所依賴UiAutomator的方式,在該類APP上執(zhí)行遍歷行為.

本工具易于使用,僅需配置基本的Java環(huán)境和ADB環(huán)境即可使用,無需配置其他信息.本工具還支持多線程測(cè)試多臺(tái)實(shí)體機(jī),提高效率.從實(shí)驗(yàn)中可以看出我們有效的檢測(cè)到性能問題,同時(shí)結(jié)合了遍歷的策略,彌補(bǔ)了Monkey的不足,優(yōu)化現(xiàn)有動(dòng)態(tài)執(zhí)行工具不能自動(dòng)化的不足,具有良好的使用價(jià)值和工業(yè)用途.