甘 佳 張茂凡 周志寰 任 想 潘 婭

(1.西南科技大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院 四川綿陽 621010；2.西南科技大學(xué)計(jì)算機(jī)應(yīng)用研究所 四川綿陽 621010)

在移動(dòng)互聯(lián)網(wǎng)的發(fā)展過程中，Android系統(tǒng)因其強(qiáng)大的可交互性和開源性，逐漸占領(lǐng)了移動(dòng)終端的市場。據(jù)調(diào)研機(jī)構(gòu)Gartner全球智能手機(jī)銷售報(bào)告顯示，2018年第一季度手機(jī)市場中，Android系統(tǒng)的市場份額高達(dá)85.9%[1]。但也因其開源性，Android終端應(yīng)用濫用手機(jī)硬件資源導(dǎo)致手機(jī)卡頓，影響用戶體驗(yàn)。由于Android系統(tǒng)碎片化嚴(yán)重，設(shè)備性能也參差不齊，給應(yīng)用的穩(wěn)定流暢運(yùn)行帶來了巨大挑戰(zhàn)。因此，在應(yīng)用正式上線前，應(yīng)對其進(jìn)行盡可能完善的性能測試。目前，針對手機(jī)應(yīng)用的性能測試點(diǎn)包括有CPU、內(nèi)存、流量、電量、網(wǎng)絡(luò)、啟動(dòng)耗時(shí)、過度繪制等。但是在啟動(dòng)耗時(shí)、過度繪制方面，通常只能獲取大致的性能數(shù)據(jù)，不能對問題分析進(jìn)行準(zhǔn)確定位。

國內(nèi)移動(dòng)互聯(lián)網(wǎng)公司針對Android應(yīng)用的性能測試，主要分為兩種方案：一是借助工具，實(shí)時(shí)采集手機(jī)性能數(shù)據(jù)；二是在測試APK中插入測試樁，獲取性能數(shù)據(jù)。第一種方案的主要代表有騰訊的GT 和訊飛的iTest 等。GT提供了兩套性能測試解決方案，其中一種是將其提供的SDK嵌入APK內(nèi)，從而達(dá)到開發(fā)調(diào)試的目的，另一種是提供測試工具的APK，與待測應(yīng)用一起安裝在手機(jī)上，操作待測應(yīng)用，實(shí)時(shí)展示性能測試結(jié)果。iTest工具與GT的后一套方案類似，也是提供測試工具APK，對待測應(yīng)用進(jìn)行實(shí)時(shí)測試及記錄。使用測試工具APK來進(jìn)行性能測試的方案雖然能夠?qū)崟r(shí)獲取手機(jī)性能數(shù)據(jù)，但發(fā)現(xiàn)問題后測試人員不能快速地進(jìn)行問題定位。為了更好地解決問題定位，Google為Android開發(fā)者提供了許多獲取性能數(shù)據(jù)的API，開發(fā)者只需在測試APK中調(diào)用API，便能進(jìn)行性能問題定位。但是這種方案缺點(diǎn)在于要在源碼中插入測試API調(diào)用代碼，而插入測試代碼的APK只能作為測試版本，不能發(fā)布到應(yīng)用商店。

本文提出一種性能自動(dòng)化測試方案，利用反編譯技術(shù)獲得應(yīng)用源碼，在源碼中插入測試樁函數(shù)，重新打包后進(jìn)行性能測試，從而獲取更精準(zhǔn)的性能測試數(shù)據(jù)文件，自動(dòng)解析后展示異常數(shù)據(jù)，能夠?qū)y試工作進(jìn)行有效輔助，提高測試效率。

1 自動(dòng)化測試方案設(shè)計(jì)

為了更好地定位性能問題，本文提出將反編譯技術(shù)應(yīng)用到測試過程中，測試設(shè)計(jì)流程如圖1所示。測試人員只要提供待測APK以及測試樁的Java代碼，然后運(yùn)行本框架，最后只需等待測試結(jié)果即可。

整個(gè)方案分為三部分：反編譯APK并插入代碼、運(yùn)行APK獲取并解析性能數(shù)據(jù)、展示數(shù)據(jù)及定位問題。其中，第一部分是本文的核心工作，主要利用反編譯技術(shù)獲得APK源碼，根據(jù)需要測試Activity名稱，將測試樁函數(shù)插入原APK中的對應(yīng)文件中，并重新編譯生成測試包。

圖1 方案設(shè)計(jì)流程圖Fig.1 Flow chart of the scheme design

2 關(guān)鍵部分實(shí)現(xiàn)

本文所提出的性能自動(dòng)化測試方案，在具體框架實(shí)現(xiàn)及應(yīng)用時(shí)有七大模塊，包括：

(1)反編譯APK；

(2)將Java代碼編譯為smali代碼；

(3)插入smali代碼后對APK重新打包、重簽名；

(4)編寫功能自動(dòng)化測試腳本；

(5)運(yùn)行APK獲取性能數(shù)據(jù)文件；

(6)解析性能數(shù)據(jù)文件；

(7)可視化性能數(shù)據(jù)定位問題。

反編譯APK并插入測試樁是本方案的關(guān)鍵部分，整個(gè)流程如圖2所示。

2.1 反編譯APK

在Android Studio等編譯器中，開發(fā)完成的Android應(yīng)用點(diǎn)擊運(yùn)行，編譯器會(huì)將應(yīng)用打包成一個(gè)后綴為.apk的文件。該文件可以在Android系統(tǒng)的手機(jī)或者平板電腦等終端上下載并安裝。一般情況下，Android應(yīng)用被打包成.apk文件之后，就無法逆向該文件得到應(yīng)用的源代碼以及資源文件。但在APK未加殼的情況下，通過一些開發(fā)者工具，還是可以將APK進(jìn)行反編譯并得到開發(fā)這個(gè)應(yīng)用時(shí)使用的資源文件(如圖片等) 、源代碼等。

圖2 反編譯APK插入測試樁流程圖Fig.2 Flow chart of the decompiled APK inserted intest stub

本文中要用到的反編譯工具是Google公司提供的ApkTool，將待測APK反編譯成 .smali文件。工具的使用方法可以參考官網(wǎng) ，方案中將ApkTool反編譯命令集成在框架中自動(dòng)執(zhí)行。在使用過程中需要注意以下問題：

(1)ApkTool盡量使用最新版本。ApkTool工具新老版本的執(zhí)行命令存在差異，并且舊版本ApkTool容易導(dǎo)致反編譯過程中出現(xiàn)報(bào)錯(cuò)“Exception in thread "main" brut.androlib.AndrolibException”。

(2)盡量使用未代碼混淆的APK進(jìn)行測試?；煜a后的APK，進(jìn)行反編譯后，不能完全復(fù)原其代碼，會(huì)對接下來的測試樁插入造成影響。

2.2 將Java測試樁代碼編譯為smali代碼

在前面的測試思路中也提到，本文需要測試人員提供Java測試樁代碼，再由框架自動(dòng)編譯為smali代碼插入到源碼中。在通過命令行編譯Android Java代碼文件過程中，如果Java文件引用到許多第三方庫文件，在命令編譯過程中就會(huì)報(bào)很多錯(cuò)誤。為了編譯順利通過，本文建議將測試樁代碼中所有引用到的Jar包都放在一個(gè)文件夾中，然后再編譯命令中引入該文件夾即可。

在本文方案中，Java文件編譯為smali文件需要通過以下3個(gè)步驟：

(1)通過“javac test.java”命令將 .java文件轉(zhuǎn)化為 .class文件；

(2)通過dx.jar工具命令“dx --dex --output=test.dextest.class”將 .class文件轉(zhuǎn)換為 .dex文件；

(3)通過baksmali.jar工具命令“java -jar baksmali.jar test.dex”將 .dex文件轉(zhuǎn)換成 .smali文件。

2.3 自動(dòng)化測試流程實(shí)現(xiàn)

前面的兩部分介紹了在本方案中是如何實(shí)現(xiàn)反編譯APK為Smali代碼以及將Java代碼編譯成smali代碼。在1.2節(jié)中的測試思路中也提及，本文提出的方案支持自動(dòng)化測試，能夠自動(dòng)化展示性能測試情況，便于定位問題。下面就本文如何實(shí)現(xiàn)自動(dòng)化測試進(jìn)行介紹。

首先，本框架整體使用Python語言編寫，提供配置文件供測試人員填寫，因此測試人員無需關(guān)心框架內(nèi)部實(shí)現(xiàn)細(xì)節(jié)，而框架只需要解析配置文件來獲得APK信息、Java測試樁代碼等，同時(shí)，在配置文件中也配置了代碼所要插入的Activity以及函數(shù)位置，這是實(shí)現(xiàn)自動(dòng)化測試的第一步，緊接著便可自動(dòng)化進(jìn)行反編譯、插樁等一系列活動(dòng)。配置文件內(nèi)容如圖3所示。

圖3 框架配置文件Fig.3 Configuration file of framework

其次，在本框架下進(jìn)行性能測試時(shí)直接運(yùn)行自動(dòng)化測試腳本。經(jīng)過實(shí)踐本框架支持任意性能自動(dòng)化測試框架，如UIautomator，monkey，QT4A等，保證了性能測試的自動(dòng)化執(zhí)行，無需人工干預(yù)。隨著性能測試的不斷深入，數(shù)據(jù)也在不斷積累，最終本框架將獲取到的兩類性能數(shù)據(jù)自動(dòng)進(jìn)行數(shù)據(jù)可視化，呈現(xiàn)在Web頁面上。

綜上所述，本框架在測試過程中不需要進(jìn)行人工干預(yù)，能夠?qū)崿F(xiàn)自動(dòng)化測試并展示結(jié)果。

3 方案應(yīng)用及結(jié)果

為了驗(yàn)證本文提出的方案能夠?qū)Χㄎ恍阅軉栴}及優(yōu)化提供幫助，本文針對啟動(dòng)耗時(shí)、過度繪制兩個(gè)專項(xiàng)測試點(diǎn)，選擇開源游戲應(yīng)用《2048》進(jìn)行實(shí)驗(yàn)。下面首先介紹測試點(diǎn)的測試基本原理再闡述具體的實(shí)驗(yàn)過程和結(jié)果。方案如圖4所示。

圖4 實(shí)驗(yàn)方案設(shè)計(jì)Fig. 4 Experiment scheme design

3.1 測試原理

(1)啟動(dòng)耗時(shí)測試

啟動(dòng)耗時(shí)是指在Android應(yīng)用中從零開始到頁面Activity加載完成的時(shí)間。Google官方文檔中給出兩種測試方法：第一種是使用命令“adb shell am start-w packagename/activity”來啟動(dòng)耗時(shí)相關(guān)參考值，如圖5所示。該命令獲取的信息中，各字段及解釋如表1所示。

圖5 adb獲取頁面啟動(dòng)耗時(shí)結(jié)果Fig.5 Results of starting time consumption via adb

該方法雖然能夠獲取到應(yīng)用的啟動(dòng)耗時(shí)等信息，但對應(yīng)用啟動(dòng)耗時(shí)問題定位沒有幫助。第二種是函數(shù)耗時(shí)的分析方法：在APK源代碼中，通過插入測試樁函數(shù)，輸出一個(gè)后綴為 .trace的二進(jìn)制文件，該文件記錄了函數(shù)的耗時(shí)、調(diào)用次數(shù)、隸屬線程等信息；同時(shí)，借助Android SDK提供的dmtracedump工具，將 .trace二進(jìn)制文件解析成可讀的編碼格式，從可讀文件提取出關(guān)鍵字來獲得函數(shù)耗時(shí)等信息。

表1 APK啟動(dòng)耗時(shí)字段及含義Table1 Explanation fields of APK starting time consumption

(2)過度繪制測試

過度繪制(Overdraw)描述的是手機(jī)和平板等移動(dòng)終端屏幕上同一個(gè)像素在同一幀的時(shí)間內(nèi)被繪制了多次。在一個(gè)多層次重疊的UI結(jié)構(gòu)中，如果用戶不可見的界面也存在繪制的行為，一些像素區(qū)域會(huì)被多次繪制，因此會(huì)造成CPU和GPU硬件資源不必要的浪費(fèi)。在 Android 系統(tǒng)的開發(fā)者模式中，有調(diào)試 GPU 過度繪制的開關(guān)，打開該開關(guān)后Android手機(jī)屏幕會(huì)有藍(lán)色、綠色等顏色的色塊，不同顏色色塊代表過度繪制嚴(yán)重程度的不同。在Android系統(tǒng)中沒有直接提供接口獲取屏幕過度繪制計(jì)數(shù)，但Framework/base/core/Java/android/view/HardwareRender.java中的GLRenderer內(nèi)部類提供了drawOverDrawCounter方法(如圖6所示)，調(diào)用該方法可以在手機(jī)屏幕左下角顯示出當(dāng)前UI界面過度繪制次數(shù)(即overdraw參數(shù)的值)，因此獲取overdraw參數(shù)的值即可知道過度繪制的次數(shù)。

圖6 HardwareRender類關(guān)鍵代碼Fig.6 The key codes in HarwareRender class

綜上所述，在應(yīng)用本方案進(jìn)行測試時(shí)，我們將按照這樣的基本測試原理來編寫測試樁函數(shù)，進(jìn)行實(shí)驗(yàn)驗(yàn)證。

3.2 實(shí)驗(yàn)過程

按照實(shí)驗(yàn)方案設(shè)計(jì)，實(shí)驗(yàn)按照以下步驟進(jìn)行：

(1)編寫功能自動(dòng)化腳本運(yùn)行應(yīng)用，通過本方案能夠展現(xiàn)應(yīng)用啟動(dòng)耗時(shí)的情況，結(jié)果如圖7所示。從圖中可以直觀看出調(diào)用函數(shù)com.demo.game2048publish.SplashActivity.waitTime()消耗6 734 us，遠(yuǎn)高于其它函數(shù)，導(dǎo)致應(yīng)用啟動(dòng)耗時(shí)較長；

圖7 《2048》測試結(jié)果Fig.7 Test result of 2048

(2)通過測試發(fā)現(xiàn)的問題，開發(fā)人員可以根據(jù)函數(shù)名定位到應(yīng)用源碼函數(shù)調(diào)用的位置，進(jìn)而發(fā)現(xiàn)該函數(shù)在啟動(dòng)頁面的onCreate()方法中被循環(huán)調(diào)用了1 000次。

(3)在應(yīng)用源碼中修復(fù)該問題，這里將源碼中的循環(huán)調(diào)用刪除，改成只調(diào)用一次waitTime()函數(shù)。

(4)修改應(yīng)用源碼后重新打包生成 .apk文件，使用同樣的運(yùn)行腳本再進(jìn)行一次性能數(shù)據(jù)的獲取，得到的啟動(dòng)耗時(shí)結(jié)果如圖8所示，可以看到較優(yōu)化前，該函數(shù)的調(diào)用耗時(shí)有明顯下降，約為優(yōu)化前耗時(shí)的1/1000。

為了更好地說明應(yīng)用的啟動(dòng)耗時(shí)在優(yōu)化前后的變化，實(shí)驗(yàn)在同一部測試機(jī)上使用adb命令的方法3次獲取應(yīng)用的啟動(dòng)耗時(shí)TotalTime值，結(jié)果如表2所示。

圖8 《2048》應(yīng)用啟動(dòng)耗時(shí)優(yōu)化后結(jié)果Fig. 8 Result of 2048 starting time consumption after optimization

測試次數(shù)啟動(dòng)耗時(shí)優(yōu)化前/ms啟動(dòng)耗時(shí)優(yōu)化后/ms第一次265257第二次266255第三次265258

從表2可以看出，《2048》應(yīng)用的啟動(dòng)耗時(shí)從優(yōu)化前的265.3 ms降低為優(yōu)化后的256.6 ms，啟動(dòng)耗時(shí)優(yōu)化后降低了8.7 ms。

以上實(shí)驗(yàn)表明，本文提出的啟動(dòng)耗時(shí)測試方案能夠發(fā)現(xiàn)并準(zhǔn)確定位到應(yīng)用的啟動(dòng)耗時(shí)問題，問題修復(fù)后得到的啟動(dòng)耗時(shí)數(shù)據(jù)有明顯下降進(jìn)一步說明定位的有效性。

同理，對過度繪制問題的定位，在本方案下進(jìn)行測試后可以清楚看到哪個(gè)函數(shù)過度繪制問題嚴(yán)重(如圖9所示)，可以方便開發(fā)人員準(zhǔn)確定位。

圖9 過度繪制可視化圖Fig. 9 Visualization of overdrawing

4 總結(jié)

本文針對Android應(yīng)用性能測試過程中不易定位的問題現(xiàn)狀，提出了一套自動(dòng)化測試方案，基于反編譯技術(shù)，向APK源碼中插入測試樁函數(shù)，并重新生成測試包，輔助測試人員進(jìn)行性能測試。以啟動(dòng)耗時(shí)、過度繪制為例，應(yīng)用本方案進(jìn)行性能測試。通過在某兩款應(yīng)用上進(jìn)行實(shí)驗(yàn)，表明相較傳統(tǒng)的方法，該方案能夠更為精準(zhǔn)地發(fā)現(xiàn)并定位啟動(dòng)耗時(shí)和過度繪制的問題。在編譯APK包時(shí)，可同時(shí)生成測試包和正式包，規(guī)避了測試樁函數(shù)人工插入的成本問題，也能解決單獨(dú)編譯測試包的耗時(shí)問題。該方案目前雖只在啟動(dòng)耗時(shí)、過度繪制兩點(diǎn)上進(jìn)行應(yīng)用，但反編譯源碼插入測試樁函數(shù)測試同樣也適用于其它專項(xiàng)測試，稍作調(diào)整后具備一定的通用性。