行動端效能測試：不僅僅是“它快不快？”

全面指導如何解決實際應用中的電池耗電、記憶體洩漏、網路效率問題以及如何發現效能下降問題。

引言

提到“性能測試”，大多數人首先想到的是速度。應用程式啟動速度有多快？螢幕載入速度有多快？但對於行動應用來說，速度只是冰山一角。

你的應用程式可能不到一秒鐘就能啟動，但卻會在一小時內悄無聲息地消耗用戶 40% 的電量。它可能渲染出流暢無比的動畫，卻會不斷洩漏內存，直到被作業系統強制關閉。在 Wi-Fi 網路下，它可能運行速度極快，但在擁擠的地鐵網路下卻會完全無法使用。

行動效能測試是一項多維度的挑戰。在本文中，我們將超越載入時間，深入探討真正定義行動效能的四大支柱： 電池消耗、記憶體管理、網路效率 以及  迴歸檢測—所有內容均以真實世界場景為基礎。

1. 耗電大戶：悄無聲息的應用殺手

為什麼重要

電池續航力一直是智慧型手機用戶最關心的問題。無論功能多麼豐富，如果一款應用過度耗電，用戶最終都會卸載它。蘋果和谷歌都採取了積極的措施來懲罰耗電應用：安卓系統的「應用待機桶」功能限制後台活動，而iOS系統的「後台應用程式刷新」功能則可以被系統限製或停用。

什麼原因會導致電池過度耗電？

• 不必要的後台服務： Android 官方文件明確警告說，讓不必要的服務持續運行是應用程式可能犯的最糟糕的記憶體管理錯誤之一，而且它還會直接影響電池續航時間。
• 頻繁喚醒鎖定： 在不需要時保持 CPU 或螢幕喚醒狀態。
• 過度使用GPS： 採用持續位置輪詢而非使用位置變更 API。
• 未優化的網路呼叫： 使用頻繁輪詢代替推播通知或 WebSocket。
• 內存週轉和垃圾回收： 正如 Android 開發者指南中所述，頻繁的 GC 事件不僅會降低應用的運行速度，還會迅速耗盡電池電量。

如何檢測電池漏電

首先建立基準－測量應用空閒狀態下的電池消耗。然後，執行基於場景的測試，模擬常見的使用者操作流程，例如瀏覽、搜尋和串流媒體播放，同時測量能耗影響。別忘了測試應用在後台長時間運行（30、60 和 120 分鐘）的情況，並將結果與明確的預算目標進行比較，例如每小時活躍使用時的耗電量低於 5%。

在 Android 系統中，可以使用 Android Studio 中的 Energy Profiler 等工具。 dumpsys batterystats電池歷史記錄器和電池歷史記錄器都非常實用。在 iOS 上，Xcode 的「能源影響」儀錶板和 Instruments 中的「能源日誌」範本也能提供類似的資訊。

2. 記憶體洩漏：慢性毒藥

為什麼重要

行動裝置的記憶體有限。 Android 為每個應用程式設定了嚴格的堆疊記憶體大小限制，該限制因裝置而異——超過此限制就會出現問題。 OutOfMemoryError 崩潰。 iOS 的做法更加激進：它沒有交換文件，作業系統會在沒有任何警告的情況下終止佔用過多記憶體的應用程式。

記憶體洩漏的常見來源

• 對活動或上下文的靜態引用： Android 官方文件明確指出，這是導致記憶體洩漏的最常見原因。
• 未註冊的監聽器和回調函數： 從未被清理過的事件監聽器、廣播接收器或觀察器。
• 點陣圖和影像管理不善： 明明縮圖就夠了，卻載入全解析度影像。
• 保留的片段和視圖引用： 視圖銷毀後仍保留 UI 參考。
• 第三方庫臃腫： 正如 Android 官方指南所警告的那樣，外部程式庫程式碼通常不是為行動環境編寫的，效率可能很低。

如何測試記憶體洩漏

最有效的方法是 導航測試重複開啟和關閉同一螢幕 20 次或更多次，並驗證每次記憶體是否都恢復到基線水平。同時進行長時間運行測試，例如連續使用應用 30 分鐘以上，並執行各種操作，然後監控記憶體使用量的穩定成長。在 Android 系統上，旋轉測試（在複雜螢幕上快速旋轉裝置）非常適合檢測 Activity 記憶體洩漏。後台/前台循環測試（將應用程式切換至後台和前台 50 次以上）也可以發現被保留的物件。

Android Studio 的記憶體分析器和 LeakCanary（Square 開發的自動化記憶體洩漏偵測函式庫）是必不可少的工具。在 iOS 上，Xcode 的 Instruments 及其記憶體洩漏和分配模板，以及記憶體圖調試器，也能起到相同的作用。

3. 網路效率：面向現實世界的設計

為什麼重要

實驗室測試通常在快速且穩定的 Wi-Fi 網路下進行。但您的用戶可能身處擁擠的 LTE 基地台、偏遠地區的 3G 網絡，或是行駛列車上訊號不穩定的 Wi-Fi 網路。谷歌的研究表明，如果頁面加載時間超過 3 秒，53% 的行動網站訪客會放棄訪問。同樣的道理也適用於原生應用。

實際網路環境測試

不要只考慮「連接」和「斷開連接」。你需要測試各種情況：快速 Wi-Fi、良好的 LTE（約 20 Mbps，延遲 30 毫秒）、較差的 3G（750 Kbps，延遲 200 毫秒）、擁塞的網路（500 Kbps，延遲 500 毫秒，且有丟包）、接近離線狀態（50 Kbps，延遲 2 秒）。

測試什麼

• 超時處理： 該應用程式能否優雅地處理耗時超過 30 秒的請求？
• 重試邏輯： 該應用程式是否會使用指數退避演算法重試失敗的請求？
• 有效載荷大小： 您是否在傳輸不必要的資料？圖片是否已優化？
• 緩存： 該應用程式是否使用了正確的HTTP快取來避免重複下載？
• 離線模式： 用戶在沒有網路連線的情況下是否仍可存取核心功能？
• 網路轉換： 用戶在請求過程中從 Wi-Fi 切換到行動網路會發生什麼事？

如何模擬網路狀況

在 iOS 系統中，蘋果提供了網路連結調節器（可透過 Xcode 開發者設定存取），其中包含針對 3G、Edge、LTE、Wi-Fi 和 100% 丟包場景的預置設定檔。在 Android 系統中，您可以使用 Charles Proxy 或 Toxiproxy 等工具來控製網路流量。這些工具可讓您引入人為的延遲、頻寬限制和丟包，從而在自動化測試運行期間模擬真實網路環境。

4. 低階設備測試：被遺忘的大多數

為什麼重要

根據Counterpoint Research的數據，全球智慧型手機的平均售價低於300美元。您的使用者群體中有相當一部分人使用的裝置僅配備2-3GB記憶體、較舊的處理器和有限的儲存空間。如果您只在旗艦機型上進行測試，就無法了解大多數使用者的使用體驗。

低端設備的主要區別

低端設備的記憶體較小，這意味著作業系統會更頻繁地關閉後台應用程式。較慢的CPU會導致動畫卡頓和運算時間延長。儲存空間不足可能導致應用程式安裝和更新失敗。較舊的作業系統版本可能缺少某些API，而低解析度螢幕可能會出現佈局和渲染問題。

低端設備的測試策略

除了旗艦機型外，還要維護一個包含至少兩到三台入門設備的測試實驗室。設定分級效能預算：例如，旗艦機型應用啟動時間低於 1 秒，中階機型低於 2 秒，低階機型低於 3 秒。在 CI/CD 管線的所有層級上運行完整的回歸測試套件，並專門針對受限裝置分析記憶體和 CPU 使用情況。

5. 建立性能回歸框架

我們的目標

性能問題往往悄無聲息地出現，逐漸累積。每次發布 50 毫秒的效能下降可能不會引起注意，但 10 次發布後，應用程式的運行速度就會慢 500 毫秒。解決方案是將自動化效能回歸測試整合到 CI/CD 管線中。

運作原理

架構非常簡單：您的 CI/CD 系統（例如 Jenkins）觸發測試運行器（例如 Appium），該運行器在真實裝置或模擬器上執行效能測試場景。測試運行器收集指標（例如啟動時間、記憶體使用情況、電池消耗、幀速率、網路負載大小），並將它們推送到 Prometheus 等指標儲存庫。 Grafana 儀表板視覺化指標隨時間變化的趨勢，並在指標超過閾值時透過 Slack 或電子郵件通知團隊。

要追蹤哪些指標

需要監控的關鍵指標包括應用冷啟動和熱啟動時間、螢幕切換時間、穩定狀態和長時間使用後的記憶體佔用、每小時活躍使用時的電池消耗、每個螢幕的網路負載大小、丟幀率和崩潰率。每個指標都應設定明確的閾值，例如冷啟動時間低於 2 秒（95% 分位值）、穩定狀態下記憶體佔用低於 150 MB 以及每小時活躍使用時的電池消耗低於 8%。

關注趨勢，而非絕對值

迴歸分析框架的真正威力在於追蹤趨勢。單一資料點可能看起來正常，但如果過去六個版本中每次發布的記憶體使用量都成長了 5%，那就表示存在問題。 Grafana 儀表板結合歷史數據，能夠清楚地展現這些趨勢，並使其可控。

6. 綜合分析：一個真實案例

我們來看一個實際的例子。假設你正在測試一款外送應用程式。

場景： 週五晚上人很多，一位用戶下了訂單。

條件： 一台預算有限的三星 Galaxy A14（4 GB RAM，Android 13），LTE 網路擁塞（下載速度 2 Mbps，延遲 500ms），電池剩餘 30%。

使用者流程： 開啟應用程式 → 瀏覽餐廳 → 查看菜單 → 將商品加入購物車 → 結帳 → 追蹤訂單。

每一步，你都要測量不同的指標。例如，應用啟動時的冷啟動時間；瀏覽時的列表渲染時間和圖片延遲加載性能；查看菜單時的內存使用情況；添加商品時的 UI 響應速度（丟幀）；結帳時在網絡速度較慢的情況下 API 的響應時間和重試行為；訂單跟踪 15 分鐘期間的電池消耗和 WebSocket 重連行為以及返回主屏幕後是否恢復主屏幕。

這類測試的失敗報告極具參考價值。它不會像「應用程式運行緩慢」那樣籠統，而是提供精確的數據：冷啟動性能比上一個版本下降了 40%，結帳時內存佔用超過 200 MB，且導航後內存佔用未能恢復到基線水平——這表明存在內存洩漏。同時，電池消耗、重試邏輯、離線購物車持久化以及幀率等測試均通過。這種訊號能夠幫助工程團隊快速定位並修復問題。

7.如何 Digital.ai 測試可以提供幫助

本文介紹的方法——CPU、記憶體和電池效能分析、網路模擬和回歸追蹤——功能強大，但要大規模實施，需要大量的工具投入。這就是… Digital.ai 測試開始了。

Digital.ai 測試XXXXXXX 專為幫助團隊交付在實際環境中完美運行的應用程式而打造。 Digital.ai您可以在真實的 iOS 和 Android 裝置上測量 CPU、記憶體、電池和網路使用情況，以便及早發現效能瓶頸，避免影響使用者。

主要功能包括：

📱 在真實設備上記錄和回放性能交易 — 確保您的測試反映真實的用戶旅程

📊 追蹤每個流程的 CPU、記憶體和電池消耗情況 — 讓您能夠逐屏查看，從而精確定位回歸問題

🌐 類比限速網路狀況 — 偵測僅在網路速度慢或擁塞時才會顯現的隱藏瓶頸

無論您是在測試原生應用程式、混合應用程式還是行動 Web 應用， Digital.ai 為您的整個測試套件提供全面的性能覆蓋——無縫整合到您的 CI/CD 管道中。

👉 了解更多信息 digital.ai/移動性能測試

關鍵要點

1. 速度只是一個維度。 電池、記憶體、網路和裝置多樣性都同樣重要。
2. 在實際條件下進行測試。 網路速度慢、設備低階、電池電量低等問題會暴露出實驗室測試永遠無法發現的問題。
3. 自動化並追蹤。 使用 Appium、Prometheus 和 Grafana 等工具將效能指標建置到您的 CI/CD 管道中。
4. 設定預算，而不僅僅是設定目標。 為不同設備層級定義各項指標的閾值。
5. 關注趨勢，而不僅僅是絕對值。 每次釋放導致5%的衰減，化合物迅速累積。
6. 使用官方的個人資料分析工具。 Android Studio Profiler、Xcode Instruments 和 LeakCanary 是你的好幫手。

資源中心

• Android：管理應用程式記憶體 — Android 官方記憶體管理文檔
• 蘋果：提升應用效能 — 蘋果公司效能優化指南
• Android 耗能分析器 — Android Studio 中的電池分析
• 金絲雀洩密— Android 自動記憶體洩漏偵測
• Appium 文件— 行動測試自動化框架

本書是為行動測試工程師、QA主管以及任何認為性能不僅僅是秒錶上的數字的人而寫。