從零到一瞭解APP速度測評

作者 | 龍霸天

一、引言

GEEK TALK

為了知道「為什麼會打雷下雨」，我們拿起了手機，使用百度 APP 進行搜尋：

小小的一個搜尋訴求，卻需要經歷一個不短的互動過程。就跟去銀行辦業務一樣，只想改個銀行預留手機號，卻要：掃核酸碼進場，取號，等號，溝通，辦理，完成。

互動過程中的任何一個過長的等待，都可能會導致使用者流失，以下我們列舉了幾個常見的 APP 互動慢導致使用者流失的場景：

△啟動 APP 如果要好幾秒，使用者下一次可能會選擇直接使用原生瀏覽器

△ 點選搜尋好久才出搜尋結果，使用者下一次很可能會選擇競品搜尋引擎

△檢視一個內容，如果資源開啟緩慢，使用者下一次可能就去垂直 APP 找答案了

△你是不是也曾被開啟緩慢的健康碼困擾？

速度是影響使用者存留的關鍵因素。 BBC 發現他們的網站載入時間每增加一秒，就會失去 10% 的使用者；Pinterest 將感知等待時間減少了 40% 後，來自搜尋引擎的流量和註冊量增加了 15%；……

速度意味著提高轉化。 Lazada 將頁面 LCP 提升 3 倍後，轉化率提升了 16.9%；GYAO 將頁面 LCP 提升 3.1倍後，廣告點選率增加了 108%；……

（資料來源： http://web.dev/why-speed-matters/  ）

速度如此重要，所以我們經常需要對 APP 的關鍵場景進行速度評測，以實現兩個目的：

1. 防劣化 ：防止 APP 自己本身速度劣化，以持續給予使用者最好的互動體驗；

2. 看差距 ：努力提供比競品 APP 更好的效能體驗，以留存使用者，提高轉化。

需要注意的是：APP 速度評測，不關注互動過程中 APP 發起了多少後端請求，啟動了多少個程序，每一個任務處理耗時多久，CPU/記憶體損耗，渲染是否抖動，過程是否流暢，而只關注使用者同 APP 的互動速度，也就是使用者給 APP 一個輸入訊號，APP 的反饋響應速度。

而本文主要講述了三種 APP 速度評測的手法。

二、基於日誌打點的APP速度評測

GEEK TALK

手法概述： 在 APP 的關鍵節點進行「日誌打點」，再通過日誌資料統計分析，得到感興趣的速度指標。

以下，舉一個比較好的例子來說明下。

如圖所示，是百度貼吧智慧小程式的一次調起過程，從小程式開始載入（Loading）、到 APP 開始初步繪製小程式外框架（FP），到第一次內容呈現（FCP），再到整體頁面成型（FMP），最後達到可互動狀態（TTI）。

智慧小程式生態期望小程式開發者可以關注小程式效能，從而讓小程式擁有更好的使用者體驗，因此期望為各個小程式的開發者提供各頁面啟動場景的上屏時長，從而讓開發者瞭解現狀，助力其優化小程式效能體驗。

智慧小程式生態有數十萬小程式，一個一個幫開發者評測速度明顯不大現實，因此選擇了「基於日誌打點的評測手法」。

通過在小程式核心框架進行日誌打點得到「小程式啟動時間」及「小程式頁面內容超過一屏時刻」，並定義兩者時間間隔為小程式調起的上屏時長，通過日誌資料統計分析後提供給小程式開發者。

該手法的優點在於：

1. 成本較低

2. 容易實施

3. 結果基於線上日誌資料抽樣統計生成從而更貼近整體情況

但同時也存在一些問題：

1. 日誌打點僅能針對自家 APP，因此無法通過這種方式完成競品 APP 的速度評測，無法獲悉同競品 APP 的速度差距。

2. 受限於所評測業務場景的各種非同步資料請求動作，在各階段進行日誌打點以準確捕捉對應時刻在實際操作中並不容易，且為了防止對業務本身效能影響，大多時候只能做簡單採集，未必能得到最貼近使用者觀感的速度指標。

因此，為了能更好刻畫使用者直接觀感，我們往往會傾向於採用人工評測的手法。

三、人工手段的APP速度測評

GEEK TALK

手法概述：人工操作 APP，全程攝像頭錄屏，事後對錄屏做分幀處理，然後人工尋找關鍵節點幀，統計得出相應速度指標。

以下，繼續舉例子來說明。

如圖所示，是百度 APP 的一個搜尋過程，我們期望得到「點選搜尋」按鈕到「搜尋結果頁」完全渲染的過程時間。

點選搜尋按鈕到搜尋結果頁完成渲染的過程很短（百毫秒級），要人工觀測這個操作過程時長不大現實。

因此我們使用攝像頭對操作過程全程錄屏並把錄屏存到電腦。

△攝像頭全程錄屏

接著，我們使用影片分幀工具對錄屏按一定幀率進行分幀，然後人工尋找「點選搜尋按鈕」的那一幀及「結果頁完全渲染」那一幀，最後取兩個幀的時間間隔作為本次搜尋時間。

△ 多 APP 混合評測得到對比結果

該手法的優點在於：

1. 可以採集到最貼近使用者觀感的速度指標

2. 可以做競品對比

但同時也存在一些問題：

1. 整個過程充斥著大量重複而又枯燥的過程，極其耗時、極其耗費精力，非常低效。參考既有人效資料：人工評測一個簡單場景就要耗費
   3 天，複雜場景可以達到半個月，而如果想要做到更精確的多地域多使用者覆蓋的話，週期可以長達兩個月。

2. 人工評測過程得到的數值會受評測時網路、裝置狀態等影響，且取樣數量非常有限，故不能使用絕對值作為直接結果，而只能用於競品對比或者版本間對比

如果一件事情做起來成本較高，即使它對產品有所增益，考慮價效比，我們也會選擇不做或者少做。

低效的手段讓大部分業務望而卻步，因此常將效能評測週期延長到一個季度甚至半年一次。

為了降低人工評測成本，自動化評測應運而生。

四、自動化驅動APP速度評測

GEEK TALK

手法概述：通過自動化手段操作 APP 並全程錄屏，事後對路徑進行分幀並經演算法找到目標關鍵幀，最後通過統計學手法計算相應速度指標。

回顧整個人工評測過程，其實也就三個步驟：

1. 操作 APP 完成互動同時全程錄屏（有時也會直接採用手機的系統錄屏工具直接錄屏）

2. 對錄屏進行分幀處理，並在分幀里人工找尋首尾幀

3. 重複 n 次，按一定統計學手法取均值

拆解後，可以發現，只要三個核心能力，便能實現自動化：

1. 自動化操控手機的能力

2. 全程錄屏的能力

3. 自動化找尋首尾幀的能力

自動化操控手機完成互動的開源工具有很多，比如：Appium、Adb、WDA、Uiautomator2、Tidevice 等。

自動化進行手機錄屏的開源工具也有：scrcpy、minicap 等。

值得一提的是，自動化找尋首尾幀在市面上並沒有現成通用的工具，需要根據互動場景的不同及現實限制性條件去設計，一般來說都需要動用到計算機視覺相關演算法。為了方便大家理解，這裡舉幾個例子：

例子1： 我們在 Android 裝置上開啟了「顯示指標位置」，這樣當我們操作手機的時候，都會在手機上留下一個「十字錨點」。如此，針對於 Android 裝置以某個點選動作為開始的互動場景，我們就可以把「找尋首幀」問題轉換成找尋帶有「十字錨點」幀的問題。接著使用計算機視覺演算法找尋十字錨點幀，便能實現首幀自動識別。

△Android 裝置開啟「顯示指標位置」，將找尋首幀問題轉換成找尋十字錨點幀

例子2： 我們想要取得「搜尋結果頁」自點選搜尋到第一個影片卡片的影片啟動播放的過程耗時。影片啟動播放的標識是左下角出現一個「開啟聲音的 icon」，因此我們只要使用計算機視覺演算法找尋對應 icon 圖標出現幀，便能實現該互動場景的尾幀自動識別。

△通過使用特定影象作為錨定物，將找尋尾幀問題轉換成影象查詢問題。

自動化評測手法相比於人工評測優點在於：

1. 極大降低了人力消耗

2. 極大提升了評測效率

我們期望通過自動化來降低評測成本，但自動化本身也帶來了額外的成本和問題：

1. 自動化用例編寫的難易度、上手成本及可持續性等

2. 自動化執行的穩定性及置信度

3. 首尾幀識別演算法的定製化開發成本及準確率問題

因此，我們開發了一個名為 LazyPerf 的 APP 速度評測工具，期望能夠通過一體化的解決方案讓整體評測成本有質變的下降。

五、APP速度評測工具LazyPerft

GEEK TALK

整個工具核心圍繞兩個方面提升評測效率：

• 降低自動化用例的編寫成本

• 降低首尾幀校準的人工成本

5.1 降低自動化用例的編寫成本

核心點1： 我們採用了「基於真機操作錄製用例」的手法來編寫自動化用例。

好處是：使用者只需在手機上輕鬆一點，便能完成一個自動化用例步驟的錄製，上手成本非常低，用例格式統一帶來了較好的可持續性，讓使用者可以將主要精力放在用例的整體設計上。

缺點是：相比於基於指令碼程式碼編寫用例，犧牲了用例編寫的靈活性，原本腳本里一個 For 迴圈就能解決的問題，可能就需要工具花費大量精力去設計較為友好的用例編寫方式。

核心點2： 引入了基於佈局的控制元件定址方式，降低 UI 區域性變動對自動化用例的影響，同時支援按照「模式」來定址。

頁面結構樹往往層級深而冗長，導致基於 XPATH 的控制元件定址時常受 UI 區域性內容變動影響較大，進而導致用例執行的不穩定，從而要重新錄製用例。

因此，我們基於 UI 控制元件佈局關係對頁面結構樹進行了重塑，重新定義了新的控制元件定址方式並通過 LazyPerf 來進行組織，以期降低變動帶來的影響。

△頁面結構樹往往層級深而冗長

此外，我們還遇到了一些場景，是沒辦法通過 XPATH 進行控制元件定址的。

舉個例子，我們期望在百度 APP 的推薦欄目下找尋「百度動態型別卡片」，通過點選這型別卡片看「百度動態頁」的啟動速度。

遇到的問題是，咱們每次開啟百度 APP，推薦欄目的內容是會變化的，百度動態型別卡片出現在 Feed 流的第幾屏、第幾個是不確定的，卡片的內容也是不確定的。

這種情況，我們該怎麼進行定址？

因此，我們在新型的控制元件定址方式上追加設計了一種「基於模式的控制元件定址方式」，每一個非葉子控制元件都會通過子控制元件的 UI 佈局資訊生成一個模式屬性，由此同種型別的 Feed 卡片便會擁有一樣的模式屬性，這樣我們便能通過模式輕鬆定址到我們所需的特定型別卡片。

△通過「基於模式的定址」在多屏內輕鬆找到「百度動態型別卡片」

核心點3： 設計了基於 UI 控制元件結構樹的控制元件定址方式，解決部分場景無法通過系統工具完成控制元件定址的問題。

在實踐過程中，我們發現有一些 APP 頁面會因為內容過於豐富，而沒有辦法通過 Uiautomator2/WDA 等工具取得控制元件樹，進而使得自動化用例無法編寫。

因此我們設計了基於 UI 控制元件結構樹的控制元件定址方式，使用視覺演算法基於手機截圖生成 UI 控制元件結構樹供使用者編寫用例。

同時也支援使用者在截圖上自定義圈定控制元件，然後通過OCR/影象查詢/相似度比對等系列演算法組合實現定址。

5.2 降低收尾幀校準的人工成本

核心點1： 整合各型別場景首尾幀識別演算法，讓首尾幀識別自動化。

我們採用了傳統 CV 及深度學習方案，抽象了 8 套模板，適配 20+ 場景，能夠快速滿足使用者場景需求，這是效能評測降耗的核心所在。雖然大部分場景我們可以實現 5 幀差內準確率 90%+，但是仍然有很多複雜場景是難以實現自動化的，比如「搜尋結果頁的劃屏起播場景」，我們想要獲得在划動頁面的時候，上一個影片停止播放到下一個影片自動播放的時間間隔，因為不好界定錨點所以較難通過演算法實現自動識別。

核心點2： 支援單錄屏多場景標註。

往往多個場景存在連續性關係。

舉個例子：為了在「搜尋結果頁」中點選「影片卡片」取得「影片落地頁」啟動速度，我們需要冷啟百度 APP、點選搜尋框、輸入 Query、點選搜尋按鈕，最後找尋「影片卡片」並點選。

整個過程至少包含了 3 個互動場景，與其分開執行自動化後進行校準，不如直接利用一次自動化錄屏進行分場景校準。

核心點3： 十幀校準模式。

在螢幕固定情況下，一個頁面展示的幀數越多，幀圖片的可見度就越低，在 13.3 英寸 Macbook 屏上我們發現 10 幀的展示恰到好處。

在 10 幀展示的基礎上，我們發現，如果演算法自動校準的幀能夠在展示的 10 幀內找到，那麼人工校準成本在 10s，如果左右滑動 10 幀可以找到則需 20s，滑動超過 10 幀則需 30s+。

因此，如果演算法能實現 5 幀差（演算法校準幀離目標幀不超過 5 幀以確保在首屏 10 幀內找到）準確率 100%，那麼單次校準的人耗就能維持在 10s（較低成本）。

由此，校準成本的持續降低就能夠精確轉換為自動校準演算法 5 幀差準確率的持續提升。

六、問題與展望

GEEK TALK

由於我們是通過一些系統級的開源工具實現的裝置的自動化操控，所以不可避免的，這些工具本身會帶來對裝置的效能損耗，進而影響評測結果。

雖然我們可以通過控制變數，以巡迴執行形式實現對比測試、疊加統計學手法來將影響降低，但是影響終究存在。

與此同時，這些開源工具本身也時常受到裝置型號、作業系統版本影響而產生各種可用性問題，且部分工具已無人維護。

這些都為自動化評測的可持續性帶來了較大的隱患。

但好在這些問題不是不可解決的，業界已經逐步誕生出一些通過物理方式進行裝置自動化操控的手段，所以我們設想，下一代的自動化評測方式可以是這樣的：電腦本地 APP 驅動用例錄製及執行；通過單目攝像頭感知場景，指導自動化執行，同時全程錄屏；雙軸導軌確定座標，豎向點觸頭操作螢幕……

----------  END  ----------

推薦閱讀【技術加油站】系列：

百度工程師教你玩轉設計模式（工廠模式）

揭祕百度智慧測試在測試分析領域實踐

百度使用者產品流批一體的實時數倉實踐

ffplay影片播放原理分析

百度工程師眼中的雲原生可觀測性追蹤技術

使用百度開發者工具 4.0 搭建專屬的小程式 IDE

一鍵三連，好運連連，bug不見 :point_down: