背景
啟動耗時是 App 的一項核心性能名額。知乎目前已有埋點資料可以作為參考，資料收集不需要人工幹預，但這種測試方法的準确性一直被質疑，而且與使用者的真實感受有一定差距。在性能優化初期與競品橫向的對比上，知乎采用錄屏方式，即人工用視訊錄制軟體對手機螢幕進行錄制采集，然後用分幀工具進行分幀統計，這樣測試的結果符合使用者真實感受，但是測試成本極高。是以考慮在埋點資料作為縱向标準的基礎上，實作錄屏自動化測試方案作為輔助參考标準。
思路
既然是把手工測試的過程自動化，那我們先捋一下手工測試的思路：手動錄屏 → 用分幀工具為視訊分幀 → 人工挑選出關鍵節點的圖檔，記錄這一幀在視訊中的時間 → 計算啟動時長：結束節點時間–開始節點時間。如果要自動化整個過程，把每一步的自動化的方案組裝在一起即可。如何把人工識别關鍵節點圖檔調整成通過機器學習模型自動識别，是關乎結果準确性的重要步驟。
整體思路如圖1啟動時間自動化測試流程所示，可分為四個部分。
訓練模型：收集圖檔素材，訓練圖檔識别模型，驗證模型準确率後，對識别不夠準确的場景進行樣本補充或調整，最終用準确率較高的模型進行識别。
螢幕錄制：通過腳本自動啟動 App ，并将手機的圖檔幀序列儲存到 PC 端。
資料處理：對圖檔幀進行識别，準确識别出關鍵節點圖檔，計算啟動時間。
閉環流程：資料持久化，建立 MR 準入機制。
圖 1 啟動時間自動化測試流程
訓練模型
選擇模型、訓練模型最終目的是：讓模型可以準确的識别出關鍵節點圖檔。我們通過不斷調整、擴大訓練樣本，以便讓訓練後的模型能夠更加準确的識别關鍵節點的圖檔。首先需要進行關鍵節點的樣本收集，然後選擇合适的模型并用樣本進行訓練，最後根據需要進行修正調整。
- 樣本收集
我們将啟動過程分為五個關鍵節點，分别為啟動開始、出現 logo 界面、出現廣告素材、首頁架構加載完成、首頁内容加載完成，對 App 啟動過程進行錄屏，并人工對圖檔幀分類，分别儲存圖檔在五個關鍵節點檔案夾中。如圖2啟動過程示意圖所示。
- 檔案夾命名為對應的節點的名稱。
- 每個檔案夾下存放 50 張截圖，包含 2 個機型的截圖，五個節點共計 250 張圖檔。
圖 2 啟動過程示意圖
- 模型的選擇與訓練
機器學習模型選擇了比較流行的 TensorFlow，主要原因是操作簡單，不必提取特征，訓練後識别準确度也很高。環境搭建流程可參考：https://www.tensorflow.org/hub/tutorials/image_retraining
搭好環境後開始訓練樣本，每個節點下的圖檔不能少于 20 張，不然會報錯。
學習後的模型儲存在 /tmp/output_graph.pb 中，五個關鍵節點的辨別即五個檔案夾的名稱。
- 測試模型準确率并對樣本進行調整
訓練完的模型我們并不能拿來就用，還要看它識别的準不準，如果不準要對素材進行補充或調整，直到能滿足需要。
當我們拿一張圖進行測試時，模型會告訴我們他認為這張圖為各個階段的機率。如圖3 所示，模型識别出其為 loading 階段的機率最高， 為98.35%，那我們可以認定它将這張圖識别為 loading 階段。而事實上這張圖檔确實處于 loading 階段。這個機率值越高，則說明模型越有把握，我們要盡量讓訓練後的模型可以胸有成竹的确認圖檔處于哪個節點。
圖 3 測試模型準确率樣例
接下來我們選取了 20 組新的截圖（共計 100 張圖），對訓練之後的模型進行測試。這 20 組截圖覆寫不同分辨率、不同機型。其中 MIN 為模型識别為這個節點的機率最小值。
圖 4 不同階段模型識别機率統計
由上圖我們可以看到，大部分圖檔的識别的準确率還是蠻高的。隻有「廣告-ad」階段部分圖檔的識别機率較低，甚至會錯識别成「啟動開始-start」，猜測可能是廣告頁與手機桌面相似度過高導緻，在增加了不同廣告的樣式到素材中繼續訓練後，果然識别準确率有所增加。
我們在代碼中設定了每個節點識别機率的門檻值，隻有識别機率超過門檻值才會認為比對成功。
螢幕錄制
錄屏工具選擇了 stf 提供的 minicap，在中等手機上截圖速率可達每秒 30、40 張。由于 minicap 傳輸速率極快，我們直接儲存二進制流為圖檔，通過圖檔儲存時的時間戳來計算啟動時間。此時關鍵節點最後一張圖檔的傳輸耗時為這種計算方式的誤內插補點，誤內插補點不超過 200ms，可以接受。螢幕錄制和啟動是同時進行的，這裡采用多線程的方式。
錄制步驟如下：
- 拿到 minicap 源碼後，我們需要對其手動編譯得到可執行檔案，但編譯後的可執行檔案會因 CPU 架構不同而不通用，好在官方文檔比較詳細，提供了 easy way 和 hard way，如果按照 easy way，把真機連在電腦上，運作官方腳本可直接編譯出真機需要的版本。安裝到用戶端上後，可以通過 adb 指令啟動 minicap，指令中 -P 參數可設定螢幕分辨率和圖檔壓縮比，适當的圖檔壓縮可以減少圖檔傳輸耗時和識别圖檔耗時。下面為啟動 minicap 的指令，加上 -t 可以檢查執行結果，出現 OK 即啟動成功。
adb shell LD_LIBRARY_PATH=/data/local/tmp/minicap-devel /data/local/tmp/minicap-devel/minicap -P 1080x2340@1080x2340/0 -t - minicap 啟動後，将裝置的TCP伺服器端口映射到本機的 1717 端口，在終端輸入「nc localhost 1717」可以看到 minicap 傳輸到 PC 的二進制資料流，看起來是亂碼，其實是圖檔流。
adb forward tcp:1717 localabstract:minicap
nc localhost 1717 - 本地建立 tcp client，監聽 1717 端口，把傳輸的二進制流儲存成圖檔，得到啟動過程截圖。
資料處理
App 啟動使用 adb 指令的方式，沒有手指按壓圖示以後，圖示顔色加深的效果，啟動節點計算隻能根據第一個頁面在桌面不斷放大、出現的過程來計算這個過程也忽略了真實使用者手指按壓硬體處理的時間，統一通過 adb 指令下發時的時間戳，來作為開始啟動的時間。
整個啟動時間的計算都是根據時間戳來計算的，即第一張首頁出現圖檔被儲存的時間戳 - 啟動時間戳。
由于啟動過程包含廣告邏輯，出現廣告是難免的。在圖檔識别過程，如果識别出現了廣告，則本次啟動時間不計入。
識别圖檔的過程比較耗時，每張圖要 2s 左右，為了節省時間，每啟動一次便建立一個線程在背景識别本次啟動存下的圖檔，多個線程并發識别，啟動十次的話，整個流程下來大概要 12 分鐘。下圖為多個線程并發識别圖檔的日志。
圖 5 識别過程 log
即便是保持機型、系統等變量都不變，同一台手機啟動同一個包的啟動時間波動也是很大的，如何讓測試結果更可靠，工具能夠有效的回報出問題，是我們在一直不斷優化的，目前所做的優化主要有以下幾點：
- 減少廣告的出現。由于啟動中出現廣告的資料會被廢棄，我們在 app 安裝後先做 10 次冷啟動，這樣後續測試資料中出現廣告的機率會減少。
- 找到合适的啟動次數。在一次測試任務中盡可能增加啟動次數，樣本資料越大準确性越高，但是由于圖檔識别是比較耗時的，啟動次數也不宜過多。
- 在資料統計上降低誤內插補點。拿到全部啟動時間後，我們會去掉其中的最大值和最小值，然後計算平均值。
閉環流程
為了能盡早的發現代碼對啟動時間的影響，我們要在代碼合入前對啟動時間做到監控，是以将啟動時間錄屏自動化接入到 CI 中，每個 MR 打完包之後都會執行啟動時間測試，如果啟動時間高于曆史資料的平均值，會在 MR 上 @啟動時間負責人，對代碼進行排查。為了友善 dev 對問題排查，我們将啟動過程各個啟動項的啟動時間也記錄下來，友善查找是哪個啟動項影響了啟動時間。接入 CI 自動化的整體流程圖如下圖所示。
圖 6 閉環流程圖
下圖為測試資料資料存儲平台的前端頁面展示。從頁面上可以查到每個 MR 打包之後的啟動資料，友善排查問題。
圖 7 資料展示圖
展望
總體來說，啟動時間錄屏自動化測試，我們采用自動化錄屏加圖檔模式識别進行自動化測試，并建全閉環流程讓啟動優化的結果得到持久保障。但是，我們注意到，目前測試中使用的模型還是最開始訓練得到的，後續計劃在每次測試結束後，都将關鍵幀圖檔儲存在樣本庫中，定時訓練，更新模型，這樣可以讓識别更加準确。
作者:楊洋
出處:https://zhuanlan.zhihu.com/p/70696324