概要
Android Uiautomator的運(yùn)行速度一直很快, 但是在個(gè)別場(chǎng)合會(huì)發(fā)現(xiàn)執(zhí)行的非常緩慢. 本文就是這樣一個(gè)問(wèn)題的調(diào)查過(guò)程.
問(wèn)題
因?yàn)閼?yīng)用中需要登錄, 所以我們編寫(xiě)了響應(yīng)的測(cè)試用例. 因?yàn)榇嬖诘卿?非登錄這兩種情況, 而且有時(shí)候測(cè)試時(shí)并不知道當(dāng)前的登錄狀態(tài). 在不借助其他后端接口的前提下, 只能通過(guò)Ui進(jìn)行判斷. 經(jīng)過(guò)真機(jī)上的測(cè)試, 我們發(fā)現(xiàn)這個(gè)判斷登錄的用例常常需要數(shù)分鐘來(lái)執(zhí)行. 為什么這么慢呢?
調(diào)查
經(jīng)過(guò)實(shí)際的測(cè)試, 從UI判斷登錄狀態(tài)時(shí), 時(shí)間大部分消耗在了判斷一個(gè)UI widget是否存在的函數(shù)中. 也就是 UiObject的exists函數(shù). 但是查看了Android的文檔后,
public boolean exists ()
Check if view exists. This methods performs a [waitForExists(long)](http://developer.android.com/intl/zh-cn/reference/android/support/test/uiautomator/UiObject.html#waitForExists(long))
with zero timeout. This basically returns immediately whether the view represented by this UiObject exists or not. If you need to wait longer for this view, then see [waitForExists(long)](http://developer.android.com/intl/zh-cn/reference/android/support/test/uiautomator/UiObject.html#waitForExists(long))
.
我們可以發(fā)現(xiàn)按照文檔記載, 這個(gè)接口是可以 immediately 返回的. 雖然字面上可能會(huì)有偏差, 但是應(yīng)該不會(huì)有幾分鐘的延遲吧?
使用uiautomator的console出處看不出來(lái)太多問(wèn)題, 我們想到了logcat的輸出.
另開(kāi)啟一個(gè)終端, 記錄下測(cè)試運(yùn)行時(shí)的logcat輸出, 可以發(fā)現(xiàn)有幾段非常明顯的 timeout, 類似如下:
java.util.concurrent.TimeoutException: No idle state with idle timeout: 500 within global timeout: 10000
at android.app.UiAutomation.waitForIdle(UiAutomation.java:533)
at android.support.test.uiautomator.UiAutomatorBridge.waitForIdle(UiAutomatorBridge.java:112)
at android.support.test.uiautomator.UiAutomatorBridge.waitForIdle(UiAutomatorBridge.java:107)
at android.support.test.uiautomator.QueryController.findAccessibilityNodeInfo(QueryController.java:143)
at android.support.test.uiautomator.QueryController.findAccessibilityNodeInfo(QueryController.java:138)
at android.support.test.uiautomator.UiObject.findAccessibilityNodeInfo(UiObject.java:188)
at android.support.test.uiautomator.UiObject.waitForExists(UiObject.java:928)
at android.support.test.uiautomator.UiObject.exists(UiObject.java:979)
at com.milo.tests.UiTestCaseBase$6.checkForCondition(UiTestCaseBase.java:162)
at android.support.test.uiautomator.UiDevice.runWatchers(UiDevice.java:705)
at android.support.test.uiautomator.UiObject.findAccessibilityNodeInfo(UiObject.java:193)
at android.support.test.uiautomator.UiObject.waitForExists(UiObject.java:928)
at android.support.test.uiautomator.UiObject.exists(UiObject.java:979)
at com.milo.MyTest.IsLoggedin(MyTestPage.java:107)
at ...
從log上看久很明顯了, 在UiObject不存在的情況下, 框架會(huì)自動(dòng)調(diào)用runWatchers. 雖然這種機(jī)制會(huì)避免因?yàn)橐馔獾木嬖斐傻挠美\(yùn)行失敗, 但是會(huì)拖慢運(yùn)行. 每一次判斷widget是否存在的場(chǎng)合都會(huì)運(yùn)行所有的watcher
解決
因?yàn)槲覀兊挠美? 不得不有關(guān)于widget的邏輯分支判斷, 所以只能在這個(gè)用例的開(kāi)始處remove所有的watcher, 在用例執(zhí)行的后半段再次恢復(fù)register之前的watcher.
結(jié)論
- 自動(dòng)化用例的設(shè)計(jì)前提是避免邏輯分支. 但是我們目前的業(yè)務(wù)場(chǎng)景還沒(méi)有找到更好的辦法.
- 在用例不得不包含邏輯分支時(shí), 將邏輯分支的前后處理都變的更"輕".
- Uiautomator的使用上, 避免Watcher在不希望的場(chǎng)景下被自動(dòng)喚起.