[譯] Performance testing of Flutter apps

原文連結：Performance testing of Flutter apps 作者：Filip Hracek (from Flutter team)

Flutter 在預設狀態下就能執行得非常快，這點非常棒! 但是否這就意味著你完全不需要考慮效能呢？

答案是否定的，編寫一個速度非常慢的 Flutter 應用是完全可能的。然而，另一方面你也可以充分利用這個框架，讓你的 app 不僅快速，高效，而且使用更少的 CPU 時間和電量。

這就是我們想要的！在一個有意義的指標上來比較兩個版本的應用在統計上明顯的差異

在 Flutter 中有一些效能優化的通用指導原則：

• 更新狀態時，影響範圍儘可能地少。
• 僅當必要時才更新狀態。
• 不要在 build 方法中進行密集型計算任務，理想的話，把這些操作放在 main isolate 之外。

你可能很難相信，對於大多數效能優化的問題來說，它們的答案統統指向了這句話——“它究竟取決於什麼？”。對於特定 Widget 是否值得進行特定優化，並付出維護成本？在特定情況下的特殊處理是否合理？

對於這些問題唯一有用答案是測試和測量。量化每個選擇對效能的影響，並根據該資料做出決定。

好訊息是 Flutter 提供了出色的效能分析工具，例如包含 Flutter Inspector 的 Dart DevTools（目前還處於預覽版），或是 Android Studio 中的 Flutter Inspector（安裝了 Flutter 外掛下）。你可以使用 Flutter Driver 操作應用，並在 Profile 模式下儲存效能資訊。

然而壞訊息是，現在的手機實在是太過智慧了。?

管理器的問題（Governors）

系統級守護程式需要根據當前負載調整 CPU 和 GPU 單元的速度，但是 iOS 和 Android 的管理器卻很難量化 Flutter 應用的效能。總的來說這還是一件好事，因為它確保了平穩的效能，同時也消耗盡可能少的電量。

然而缺點是你完全可以通過提高其效率以顯著加快應用的執行速度。

下面的例子中，你可以看到如何在應用中迴圈列印一些無意義的 print 語句，使得管理器切換到更高的檔位，從而讓應用執行更快速，效能更加可預測。

管理器的問題：在預設情況下，你無法相信這些數字。在上面這個盒子圖中，我們在 x 軸上進行單獨執行（用它們開始的確切時間標記），並在 y 軸上表示構建時間。正如你所看到那樣，當我們引入一些完全不必要的列印語句時，它竟然會縮短（而不是增加） build 時間。

在這個實驗中（上圖），更差的程式碼反而導致了更快的構建時間，更快的光柵化時間和更高的幀率。如果客觀上更差的程式碼會得到更好的效能，那麼你就不能遵循這些指標。

上面僅僅是為了解釋為何移動應用效能基準不直觀，以及測試困難的一個例子。

接下來，我將分享一些 Google I/O app 上 Flutter 的例子，Developer Quest。

基本建議

• 不要在 DEBUG 模式下測量效能。只有 profile 模式下才能測量其效能。
• 在真機上測試，不要在 Android 或者 iOS 模擬器上測試。雖然模擬器軟體非常適合開發使用，但是它們在效能表現上和真機差異非常大。Flutter 不允許在模擬器上以 profile 模式執行，因為這並沒有任何意義。這種方式收集的效能資料並不是實際的效能。
• 理想的情況下是使用相同物理裝置。讓它作為你專用的效能測試機，並不再用於其他用途。
• 學習 Flutter 效能分析工具

CPU / GPU 管理器

正如我們剛才所說的，現代作業系統根據負載和一些其他的啟發式調整每個 CPU 和 GPU 的頻率。（例如，觸控螢幕通常會讓 Android 手機將其優先順序置於更高的檔位。）

在 Android 上你能夠直接關掉這些管理器，我們稱之為“scale locking”。

• 編寫一個指令碼來 scale-lock 你的測試機效能。你可以在 Skia’s recipe 中找到靈感，也可以查閱 Unix CPU API。
• 除非你正在執行像 Skia 這樣的大型基準測試，通常情況下你可能想要一些更加輕量，不那麼通用的東西。來看看 Developer Quest 中針對某些方面的 shell 指令碼吧。 例如，下面這個將 CPU 管理器設為 userspace （唯一一個不會自動調整 CPU 頻率的管理器）。

#!/usr/bin/env bash
GOV="userspace"
echo "Setting CPU governor to: ${GOV}"
adb shell "echo ${GOV} > /sys/devices/system/cpu/cpu${CPU_NO}/cpufreq/scaling_governor"
ACTUAL_GOV=`adb shell "cat /sys/devices/system/cpu/cpu${CPU_NO}/cpufreq/scaling_governor"`
echo "- result: ${ACTUAL_GOV}"
複製程式碼

• 現在的目標並不是要模擬真實效能（沒有使用者 scale-lock 的裝置），而是獲取執行時可比較的效能指標。
• 最後你需要進行測試，並在裝置上執行 shell 指令碼。只有這樣才是有效的，在這之前的效能資料都在欺騙你。

Flutter Driver

Flutter Driver 能夠自動執行應用。你可以閱讀 flutter.dev 上效能分析的文章，瞭解如何使用它來分析應用。

• 不要在效能測試時手動操作你的應用。始終使用 Flutter Driver 確保你的比較具有意義。
• 編寫你的 Flutter Driver 程式碼，以便能夠讓其執行你真正想要測試的內容。如果你正在進行常規程式效能測試，請嘗試遍歷全部應用，並執行使用者會做的操作。
• 如果你的應用具有偶然性（隨機網路事件等），請使用 mock 資料，並且保證它們儘可能相似。
• 如果需要的話，還可以使用 Timeline 的 startSync() 方法 和 finishSync() 方法，來新增自定義時間軸事件。例如，當你想要測試特定方法的效能時，這很有用。將 startSync() 放在它的開頭，並在方法結束時使用 finishSync()。
• 對於各個不同版本的應用，需要進行多次測試。在 Developer Quest 時我彙總了 100 次。當你測量一些比如像“第 99 位百分數”這樣繁雜的東西時，你得執行更多次才行。而對於基於 POSIX 的系統來說，只需要執行下面這樣：

for i in {1..100}; do flutter drive --target=test_driver/perf.dart --profile; done
複製程式碼

時間軸（Timeline）

時間軸是你執行 profile 模式下輸出的原始資料。Flutter 將此資訊轉儲到可被 chrome://tracing 載入的 JSON 檔案中。

• 瞭解如何在 Chrome 的 tracing timeline 中開啟完整的 timeline。你只需要開啟 Chrome 瀏覽器的 chrome://tracing，然後點選“Load”，選擇那個 JSON 檔案。你可以在這篇 簡短指導 中獲得關於它的更多資訊。（同樣有 Flutter Timeline tooling，但目前還處於 tech preview 階段。因為在 Flutter 的 timeline tooling 準備就緒之前，Developer Quest 專案就已經開始了，所以我還沒用過那個。）
• 使用 WSAD 鍵在 chrome://tracing 的 timeline 中移動，以及使用 1234 來更改操作模式。
• 首次設定效能測試時，考慮是否使用 Flutter Driver 執行完整的 Android systrace。這使您可以更深入地瞭解裝置中實際發生的情況，包括 CPU 縮放資訊。但是，不要使用完全開啟的 systrace 測量您的應用程式，因為它會讓一切變得非常慢而且更加不可預測。
• 那麼，應該如何使用 Flutter Driver 執行完整的 Android systrace 呢？首先，你得從 /path/to/your/android/sdk/platform-tools/systrace/systrace.py --atrace-categories=gfx,input,view,webview,wm,am,sm,audio,video,camera,hal,app,res,dalvik,rs,bionic,power,pm,ss,database,network,adb,pdx,sched,irq,freq,idle,disk,load,workq,memreclaim,regulators,binder_driver,binder_lock 開啟 Android systrace。 然後通過 flutter run test_driver/perf.dart --profile --trace-systrace 執行 app。最後，通過 flutter drive --driver=test_driver/perf_test.dart --use-existing-app=http://127.0.0.1:NNNNN/ 啟動 Flutter Driver（其中 NNNNN 是 Flutter run 上執行的埠給你的）。

度量

最好能看盡可能多的指標，但我發現一些相比其他更有用的指標。

• build 的時間 和 光柵化的時間 僅在真正嚴格的效能測試中才有用（預設情況下提供的度量標準是 TimelineSummary），這些測試除了 UI 之外不會包含太多其他內容。

• 不要把 TimelineSummary.frameCount 看作計算每秒幀數（FPS）的方法。Flutter 的配置檔案工具不能給你提供真實的幀速率資訊。TimelineSummary 雖然提供了 countFrames() 方法，但它只會計算已完成的幀構建了多少次。一個優化良好的應用可以限制不必要的重建，每秒的幀數比經常重建的未經優化的應用程式少很多。

• 我個人獲得的最有用的資料是通過測量執行 Dart 程式碼所花費的總 CPU 時間得到的。這會算上 build 方法和外部執行的程式碼。假設你在 scale-locked 的裝置上執行配置檔案測試，總 CPU 時間可以很好地估算你的應用程式將消耗更多還是更少的電。

• 要找出 Dart 程式碼執行所花費的總 CPU 時間，最簡單的方法是看 timeline 中 MessageLoop:FlushTasks 事件的範圍。在製作 Developer Quest 的時候，我編寫了一個 Dart 工具來提取它們。
• 要檢測 jank （即跳過的幀），請尋找極端情況。例如，對於 Developer Quest 的特定情況以及我們用於測試的裝置來說，觀察 95% 的 build 時間很有幫助。（90% 的 build 時間都很相似，即使是在比較效率水平差距非常大的程式碼也是一樣，而 99% 往往又過於亂了。但你的情況可能會有所不同。）

• 正如我之前所提到的那樣，對於你的每個版本的應用都演算它上百次， 然後使用有些許誤差的平均值或百分位資料。如果使用箱形圖就更好了！

結論

當這些都設定好了之後，你就能夠自信地比較提交和實驗。下面，你可以看到一個很常見困境的答案：“這種優化值得維護開銷嗎？”

我認為對於這個情況來說，答案是肯定的。只需幾行程式碼，我們應用的每個自動測試平均可以減少 12% 的 CPU 時間。

然而，本文的主要內容是，不同的測量方式可能會反映處非常不同的東西。嘗試過於寬泛地推斷效能測量也許十分符合直覺，但卻是錯誤的。

換句話說：“它究竟取決於什麼”。我們應該信奉這句話。

以上便是翻譯的全部內容，我認為這篇文章對我們構建高效的 Flutter 應用具有很大的指導意義，所以便翻譯出來分享給大家。

如若有譯誤還請指出。