啟動耗時是 App 的一項核心性能指標。知乎目前已有埋點數據可以作為參考，數據收集不需要人工干預，但這種測試方法的準確性一直被質疑，而且與用戶的真實感受有一定差距。在性能優化初期與競品橫向的對比上，知乎采用錄屏方式，即人工用視頻錄制軟件對手機屏幕進行錄制采集，然后用分幀工具進行分幀統計，這樣測試的結果符合用戶真實感受，但是測試成本極高。因此考慮在埋點數據作為縱向標準的基礎上，實現錄屏自動化測試方案作為輔助參考標準。
既然是把手工測試的過程自動化，那我們先捋一下手工測試的思路：手動錄屏 → 用分幀工具為視頻分幀 → 人工挑選出關鍵節點的圖片，記錄這一幀在視頻中的時間 → 計算啟動時長：結束節點時間–開始節點時間。如果要自動化整個過程，把每一步的自動化的方案組裝在一起即可。如何把人工識別關鍵節點圖片調整成通過機器學習模型自動識別，是關乎結果準確性的重要步驟。
整體思路如圖1啟動時間自動化測試流程所示，可分為四個部分。
訓練模型：收集圖片素材，訓練圖片識別模型，驗證模型準確率后，對識別不夠準確的場景進行樣本補充或調整，最終用準確率較高的模型進行識別。
屏幕錄制：通過腳本自動啟動 App ，并將手機的圖片幀序列保存到 PC 端。
數據處理：對圖片幀進行識別，準確識別出關鍵節點圖片，計算啟動時間。
閉環流程：數據持久化，建立 MR 準入機制。
圖 1 啟動時間自動化測試流程
選擇模型、訓練模型最終目的是：讓模型可以準確的識別出關鍵節點圖片。我們通過不斷調整、擴大訓練樣本，以便讓訓練后的模型能夠更加準確的識別關鍵節點的圖片。首先需要進行關鍵節點的樣本收集，然后選擇合適的模型并用樣本進行訓練，最后根據需要進行修正調整。
我們將啟動過程分為五個關鍵節點，分別為啟動開始、出現 logo 界面、出現廣告素材、首頁框架加載完成、首頁內容加載完成，對 App 啟動過程進行錄屏，并人工對圖片幀分類，分別保存圖片在五個關鍵節點文件夾中。如圖2啟動過程示意圖所示。
圖 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，可以接受。屏幕錄制和啟動是同時進行的，這里采用多線程的方式。
錄制步驟如下：
adb shell LD_LIBRARY_PATH=/data/local/tmp/minicap-devel /data/local/tmp/minicap-devel/minicap -P 1080x2340@1080x2340/0 -tadb forward tcp:1717 localabstract:minicap
nc localhost 1717App 啟動使用 adb 命令的方式，沒有手指按壓圖標以后，圖標顏色加深的效果，啟動節點計算只能根據第一個頁面在桌面不斷放大、出現的過程來計算這個過程也忽略了真實用戶手指按壓硬件處理的時間，統一通過 adb 命令下發時的時間戳，來作為開始啟動的時間。
整個啟動時間的計算都是根據時間戳來計算的，即第一張首頁出現圖片被保存的時間戳 - 啟動時間戳。
由于啟動過程包含廣告邏輯，出現廣告是難免的。在圖片識別過程，如果識別出現了廣告，則本次啟動時間不計入。
識別圖片的過程比較耗時，每張圖要 2s 左右，為了節省時間，每啟動一次便新建一個線程在后臺識別本次啟動存下的圖片，多個線程并發識別，啟動十次的話，整個流程下來大概要 12 分鐘。下圖為多個線程并發識別圖片的日志。
圖 5 識別過程 log
即便是保持機型、系統等變量都不變，同一臺手機啟動同一個包的啟動時間波動也是很大的，如何讓測試結果更可靠，工具能夠有效的反饋出問題，是我們在一直不斷優化的，目前所做的優化主要有以下幾點：
為了能盡早的發現代碼對啟動時間的影響，我們要在代碼合入前對啟動時間做到監控，因此將啟動時間錄屏自動化接入到 CI 中，每個 MR 打完包之后都會執行啟動時間測試，如果啟動時間高于歷史數據的平均值，會在 MR 上 @啟動時間負責人，對代碼進行排查。為了方便 dev 對問題排查，我們將啟動過程各個啟動項的啟動時間也記錄下來，方便查找是哪個啟動項影響了啟動時間。接入 CI 自動化的整體流程圖如下圖所示。
圖 6 閉環流程圖
下圖為測試數據數據存儲平臺的前端頁面展示。從頁面上可以查到每個 MR 打包之后的啟動數據，方便排查問題。
圖 7 數據展示圖
總體來說，啟動時間錄屏自動化測試，我們采用自動化錄屏加圖片模式識別進行自動化測試，并建全閉環流程讓啟動優化的結果得到持久保障。但是，我們注意到，目前測試中使用的模型還是最開始訓練得到的，后續計劃在每次測試結束后，都將關鍵幀圖片保存在樣本庫中，定時訓練，更新模型，這樣可以讓識別更加準確。
作者:楊洋
出處:https://zhuanlan.zhihu.com/p/70696324
1設置自動清理
系統安裝或者電腦用的時間久了，會產生大量的臨時文件和垃圾文件，使用存儲感知可以幫助刪除這些文件。
這么設置：
1. 桌面右鍵-顯示設置-存儲。
2. 點開存儲感知-配置存儲感知或立即運行。
02設置開機啟動項
電腦啟動時可能會同時運行很多應用程序，這些應用程序會降低電腦的速度。可以通過更改設置來禁用不需要的啟動項。
具體步驟：
1. 打開聯想電腦管家-在設備狀態欄中，找到開機用時
2. 進入開機用時-點擊不需要開機啟動的應用程序，然后選擇“禁用”。
03卸載不必要的軟件
電腦用的時間長了，往往會積累很多軟件，有一部分軟件現在沒用了，存著還會影響電腦的性能表現，建議選擇卸載它們。
這么設置：
1. 打開“控制面板”。
2. 點擊“程序-卸載程序”選項卡，找到你想卸載的程序。
3. 依次點擊軟件圖標，右鍵選擇“卸載”即可。
04清理不必要的大文件
聯想電腦管家有非常適合小白的C盤清理功能，所以也不用怕C盤爆紅時要怎么辦，到聯想電腦管家官網下載安裝，小白清理也能簡簡單單！
動應用的啟動時間，是 App 性能的重要衡量指標。啟動時間的快慢會直接影響用戶對一款應用的判斷和使用體驗。知乎 iOS App 包含非常多且復雜度高的業務模塊（如視頻等），也接入了很多第三方的組件，隨著業務需求的迭代，線上數據監控反映出來我們的啟動時間越來越慢。而啟動時間的快慢，本身是一個比較主觀的感受。因此，除了知乎 App 自己的啟動時間數據，還需要對啟動時間進行競品的橫向測試。我們會在這篇文章中介紹知乎測試團隊針對 iOS 競品啟動時間測試的一些實踐，并結合工程師啟動時間優化的結果，介紹持續監控啟動時間、主動發現啟動異常的測試方案。
常見的 iOS 啟動時長測試方法，主要有以下幾種
方法 1 可以精確獲取各個方法調用的耗時，需要 App 是 developer 證書簽名，否則無法執行測試；方法 2 可以精確獲取各個啟動項耗時，但和實際用戶體驗感受有一定出入，且需要拿到客戶端源碼，將工具嵌入客戶端中；方法 3 和用戶直觀感受一致，但分析截屏、視頻較麻煩，且發現問題時，無法定位到具體的啟動耗時項。目前對于競品啟動時長的對比測試，由于源碼和簽名的限制，方法 1 和 2 都不太合適。
錄屏測試方案通過記錄移動設備屏幕的變化，分析用戶從點擊 App 圖標到看到主體框架出現的時長，因此啟動時長的判斷必然會受到開屏廣告的影響。而各 App 在展示開屏廣告的過程中，可能會有其他啟動項在執行。因此去掉開屏廣告的啟動時長測試，會更有參考價值。在我們反復嘗試各 App 后，總結出以下兩個不展示開屏廣告的規律。
在 2016 年的 WWDC 《Optimizing App Startup Time》議題上，提到了啟動分為冷啟動和暖啟動兩種。暖啟動是指內存中包含 App 的相關數據，與我們日常提到的熱啟動不太一樣，連續殺掉 App 的啟動也可能是暖啟動。冷啟動是指系統的內核緩存區里沒有 App 相關數據。冷暖啟動的啟動時間會差異比較大，冷啟動的數據更能反映 App 真實的啟動時長。保證 App 是冷啟動的方法，就是通過重啟設備，清理系統內核緩存區。
Optimizing App Startup Time - Slide Page 126
因此我們的測試方案，需要分為冷啟動和暖啟動兩組場景，冷啟動提供更真實的啟動時長數據，暖啟動數據反映用戶日常使用的體驗感受（畢竟蘋果用戶不會經常重啟設備）。
錄屏工具我們選取了開源的工具 xrecord。設備連接上電腦后，通過 xrecord 工具將視頻文件錄制到本地。在每個設備每個 app 啟動測試一次，產生視頻一條。
視頻內容包含：桌面 → 被測 App 圖標變黑 → 展示知乎開屏 → 展示主體框架 → 首頁內容加載完成。由于首頁內容加載完成是異步實現的，因此我們選取分析的關鍵節點，是「被測 App 圖標變黑」和「展示主體框架」這兩個點。通過 FFmpeg 將視頻轉換成分幀后的圖像，剔除相似度較高的圖像后，再進行人工選取關鍵節點。
競品的選擇需要綜合考慮包體積、業務復雜度、業務類型等因素，選擇和知乎體量相當的 App 進行真實的同等機型測試。否則相差較大的應用，啟動時間的參考意義也不大。
經過實際測試后，我們發現：
詳細測試結果如下：
在知乎移動平臺 iOS 工程師的不懈努力下，經歷多個版本的迭代優化，最終知乎 iOS App 的啟動時長終于在同類競品中處于較快水平，優化效果非常明顯，
詳細測試結果如下：
業務的快速發展不可避免的會導致啟動時間逐步增長，如何「守住」工程師們辛苦「攻下」的優化成果呢？錄屏分幀測試雖然結果非常有說服力，但每個版本測試包含錄制、標注、整理報告等環節，且需要對同一個機型進行多組測試來減少誤差，需要耗費約 3 人/天的工作量。如果每個版本都進行一次測試，將會耗費大量測試人力。且這種測試方法只能給出整體啟動時長的報告，無法準確定位到啟動的異常。因此我們嘗試做了一些低成本、能快速反饋的自動化測試。
目前，知乎 iOS App 啟動項分為三種：
同步啟動項是決定啟動時長的關鍵因素，知乎移動平臺 iOS 工程師團隊在知乎自研的性能收集 APM SDK 中，加入了同步啟動項的耗時收集，并記錄在沙盒的數據庫中。通過這些數據，我們可以輕松的分析每次啟動時的耗時情況。
知乎的代碼是托管在 Gitlab 上，每一個需求的提測，都是對應到一個 Merge Request。我們希望針對 Merge Request 進行測試，確認代碼變動不會引入增加啟動耗時的風險，才能正常合入。 在 Merge Request 打出包后，通過 ios-deploy 工具，在真機上自動安裝知乎 App 并啟動 10 次。測試結束后，客戶端上報記錄的啟動時長數據到數據收集服務。數據收集服務進行匯總分析，并用前端圖表給出直觀的展示。整體測試在 Jenkins Pipeline 里完成，測試流程如下：
測試流程圖
測試報告主要提供平均啟動時長、啟動項數量、各個啟動項占用的時長等幾個維度，通過圖表展示，非常直觀的看到各個啟動項的時間占用。
對于新增啟動項或啟動時長遠超過平均值時，會給出對應的警告反饋，需要 Merge Request 的負責人跟進排查。
測試報告列表
測試報告詳細數據
通過這套自動化測試方案，能夠快速的找到新增啟動項和啟動明顯變慢的 Merge Request，更有效的幫助我們「守住」優化后的成果。
啟動速度優化是一個持續的工作，「攻」和「守」雙方面都要關注。除了分析 APM SDK 記錄的啟動項時間，我們也不會放棄錄屏分幀的測試方法，畢竟它是最直觀的用戶感受。后續我們也會嘗試使用機器學習領域的技術對圖像進行識別，訓練原來人工標注的視頻幀，自動識別出新錄制視頻里的啟動開始和結束的那兩幀，提高錄屏測試方法的標注效率。
作者:鐘離無糖
出處:https://zhuanlan.zhihu.com/p/48218035