前言

在我之前寫的一篇文章Android App響應(yīng)時間測試方法研究提到一種比較通用的測試啟動時間或者響應(yīng)時間的方案，即利用Monkeyrunner的圖片對比接口進行截圖比較。但是由于MonkeyRunner的sameAs接口耗時1秒左右，再加上Android的截圖工具耗時也需要2秒左右。這些耗時帶來的誤差對測試結(jié)果的影響非常大。因此，我們通過minicap和圖像算法對該方案進行了優(yōu)化。下面介紹一下優(yōu)化方案。

minicap

minicap是一個工具組件，提供一個socket接口實時傳輸Android設(shè)備的屏幕截圖數(shù)據(jù)流。STF使用minicap工具將設(shè)備的屏幕截圖數(shù)據(jù)流通過nodejs服務(wù)實時渲染到web頁面，從而達到遠程屏幕的效果。研究了minicap的原理后，發(fā)現(xiàn)它是通過高頻率截圖的方式，形成視頻流的效果。經(jīng)過計算，發(fā)現(xiàn)minicap的截圖速度可以達到30ms以下。于是，我想到利用minicap的方式來替代Android的截圖API，從而減少截圖帶來的誤差。由于minicap提供的是不間斷的屏幕截圖數(shù)據(jù)流，因此，我們需要分析出每張截圖在流中的起終點，并截取生成圖片。關(guān)于如何使用minicap的原理介紹以及如何將二進制數(shù)據(jù)流轉(zhuǎn)成截圖，可以參考Q博士的博文STF框架之minicap工具。

圖像相似度算法

之前方案中另一個帶來誤差的地方在于monkeyrunner的圖像比對接口。也是在網(wǎng)上找了一大堆的圖像比較算法，比如智能算法尺度不變特征轉(zhuǎn)換(Scale-invariant feature transform或SIFT)。這些算法一般都是對圖像進行精確對比，算法都比較復(fù)雜，效率也不高?；仡櫸覀兊男枨?，其實是為了確認一個場景切換到另一個場景是否完成。在App交互中，兩個發(fā)生切換后，比如從啟動頁面進入首頁，界面還是會發(fā)生非常大的變化。而我們只需要檢測到這些比較明顯的差異即可。那么圖像比較算法其實沒必要那么精確，最簡單的做法，我們只要比較整張圖片的RGB分布值即可。同時，我們設(shè)置一個閾值，如果兩張的圖片RGB分布超過20%不同，則可以認為場景發(fā)生了變化。這樣一個算法的耗時可以降低到200ms左右。關(guān)鍵代碼可以參考下面

public static boolean sameAs(BufferedImage myImage,BufferedImage otherImage, double percent){       
        if (otherImage.getWidth() != myImage.getWidth()) {
            return false;
        }
        if (otherImage.getHeight() != myImage.getHeight()) {
            return false;
        }       
        int width = myImage.getWidth();
        int height = myImage.getHeight();
        int numDiffPixels = 0;
        for(int y = 0; y < height; y++){
            for(int x = 0; x < width; x++){
                if(myImage.getRGB(x, y) != otherImage.getRGB(x, y)){
                    numDiffPixels++;
                }
            }
        }
        double numberPixels = height * width;
        double diffPercent = numDiffPixels / numberPixels;
        System.out.println(diffPercent);
        return percent > 1.0D - diffPercent;
    }

新方案實現(xiàn)

有了前面提到的minicap截圖以及圖像比較算法的調(diào)研，我們就可以開始研究下新方案的實現(xiàn)。從下圖可以看到，我們一共開啟了三個線程。線程一負責(zé)收集minicap的發(fā)送的二進制流，線程二負責(zé)將二進制流轉(zhuǎn)換成圖片，線程三負責(zé)比較前后兩張圖片的相似度。

方案流程圖

這里最關(guān)鍵的是截圖比較線程，我們可以在線程開始的時候，啟動App或者加載初始截圖，然后對比前后截圖的相似度，當(dāng)相似度>0.9即停止測試，代碼可以參考下面：

class ImageCompare implements Runnable {
        
        @Override
        public void run() {
            while(isRunning){
                if (imageQueue.size() <= 2) {
                    // LOG.info("數(shù)據(jù)隊列為空");
                    continue;
                }
                ImageInfo imageinfo1 = imageQueue.poll();
                ImageInfo imageinfo2 = imageQueue.poll();
                if(ImageTools.sameAs(imageinfo1.getImage(), imageinfo2.getImage(), 0.9) || (System.currentTimeMillis()-startTime) > 20000){
                    loadingTime = imageinfo2.getTimestamp()-startTime;
                    isRunning = false;
                }
            }
        }
        
    }

誤差分析

下圖是在樂視手機實測的日志結(jié)果，可以看出相似度分析的耗時在200ms左右，截圖的耗時在100ms左右。因此，通過該方式進行響應(yīng)時間的測試，誤差可以控制在300ms以內(nèi)。

日志

總結(jié)

上面的優(yōu)化方法，相比之前的方案，誤差從3秒減少到了300ms。這樣一個誤差范圍，如果用于啟動時間的測試，是可以接受的。對于頁面響應(yīng)時間的測試，300ms的誤差還是有點大。如果對精確度要求比較高，建議還是通過代碼插樁的方式比較好。