應用效能分析：指標、測試和監控

Informatec Digital »資源»應用效能分析：指標、測試與監控

要達到那種品質水平，僅僅「發布前進行少量測試」是不夠的。它需要結合持續監控（APM 和 RUM）、精心設計的效能測試、清晰的指標，以及能夠模擬從日常使用到極端流量高峰等各種情況的工具。此外，還必須採取策略性措施：衡量對業務真正重要的指標，並盡可能自動化，以避免不斷被動地應對問題。

應用效能：它的定義、重要性以及我們的衡量標準

我們談論應用程式效能時，指的是應用程式快速響應、保持穩定以及隨著用戶或資料量增加而擴展的能力，同時不會大幅增加資源消耗或影響用戶體驗。這適用於行動應用程式、Web 應用程式、桌面應用程式、API、微服務以及複雜的企業系統。

關鍵在於系統地衡量一系列應用程式效能指標 (KPI)，以便了解應用程式是否達到技術和業務目標，並在最終用戶注意到或生產環境中發出警報之前及時發現問題。

評估應用程式效能最常用的指標包括：

• CPU使用率：應用程式消耗多少處理器資源，以及是否存在峰值，表示存在過多的運算、設計不良的循環或阻塞回應的進程。
• 內存使用情況記憶體佔用量、記憶體洩漏、頁面錯誤或超頁面現象顯示系統花費在行動資料上的時間比執行業務邏輯的時間更多。
• 每分鐘請求數和每次請求位元組數這顯示了應用程式或 API 處理的請求數量以及每個請求處理的資料量。這有助於了解後端擴展能力以及每次調用的資料量是否合理。
• 延遲和回應時間：應用程式回應所需的時間，從使用者執行操作或用戶端發送請求到收到有效回應為止。
• 正常運作時間和可用性：服務正常運作的時間百分比，通常透過定期 ping 或合成檢查進行監控。
• 錯誤率：以錯誤（HTTP 4xx/5xx 代碼、未處理的異常、功能故障）結束的請求比例。
• Apdex評分和使用者滿意度：該指數以單一值概括了根據回應時間計算的滿意、容忍或不滿用戶的百分比。
• 垃圾回收效能（GC）在具有自動記憶體管理的平台（Java、.NET、Android）上，GC 花費了多少時間，並引入了多少暫停，以及這會對 CPU 使用率和流暢性產生怎樣的影響。
• 吞吐量或效能：單位時間內處理的交易或請求數量，在高並發系統中至關重要。

追蹤這些指標的目的不是為了收集圖表，而是為了了解應用程式的實際狀態，預測瓶頸，確定改進的優先級，並透過數據證明優化對用戶體驗和業務成果都有影響。

APM、RUM 和即時效能監控

在現代環境中，隨著分散式架構、容器、混合雲和微服務的出現，如果沒有良好的應用程式效能監控 (APM) 工具，結合真實用戶監控 (RUM) 技術以及日益先進的可觀測性元件，幾乎不可能控制效能。

APM/RUM 解決方案（例如 Elastic、Instana、Applications Manager、Turbonomic 等整合 APM 的解決方案）提供應用程式運作的端對端可見性：回應時間、分散式追蹤、資料庫查詢、外部呼叫、錯誤和異常，並與基礎架構指標整合。

真實使用者監測 (RUM)能夠捕捉真實使用者所看到的現象：螢幕載入時間、介面卡頓、瀏覽器或行動應用程式錯誤，以及不同地區和裝置上的感知延遲。這可以作為合成基準測試和實驗室測試的補充，後者固然重要，但不能取代真實世界的數據。

另一方面，現代APM平台提供以下功能：

• 實時監控 關鍵KPI：可用性、Apdex、錯誤率、傳輸速度 資源消耗.
• 分散式追蹤 追蹤跨多個微服務、佇列、資料庫和外部服務的事務，找出最慢的環節。
• 依賴關係圖 自動化工具可以顯示服務、資料庫、佇列和前端之間的關係，從而更容易檢測出故障的根本原因。
• 程式碼和線程分析 尋找消耗過多 CPU 或阻塞介面執行緒的方法、SQL 查詢或程式碼片段。
• 智慧警報和AIOps 結合機器學習和時間序列分析來偵測異常情況、減少誤報並確定關鍵事件的優先順序。

透過結合應用程式效能管理 (APM)、運行環境管理 (RUM) 和綜合監控，您可以獲得360 度全方位的效能視覺性：包括使用者所見、應用程式內部運作以及底層基礎架構的回應。這使得 DevOps 和 ITOps 團隊能夠快速回應突發事件，甚至更好地預防它們的發生。

行動和 Web 應用的關鍵效能指標

在行動和網頁應用中，某些效能指標尤其重要，因為它們直接影響使用者感知和產品成功與否。密切監控這些指標，決定著一款應用程式是能吸引用戶，還是在第二次使用後就被卸載。

行動應用程式的關鍵點之一是應用程式啟動延遲，也就是從使用者點擊圖示（或通知）到螢幕上顯示有用資訊所經過的時間。應用程式啟動延遲可以分為以下幾種類型：

• 冷啟動該應用程式不在記憶體中；系統必須建立一個進程，載入程式碼，初始化庫，並顯示第一個畫面。
• 半熱啟動該過程仍然存在，但該活動被重新建立或恢復到某種狀態。
• 熱啟動您只需重新調整視圖或恢復活動，無需額外付出太多努力。

作為參考，強烈建議將冷啟動時間控制在 500 毫秒以下，這可以使 p95 和 p99 延遲（最高百分位數）接近中位數。如果部分使用者需要等待幾秒鐘才能開啟應用，而其他使用者只需半秒即可完成，則表示系統存在不平衡。

另一個關鍵問題是滾動和介面卡頓。在動態螢幕（例如資訊流、清單、圖庫）上，使用者期望獲得流暢的體驗。當系統無法以裝置的刷新率（60Hz、90Hz 甚至 120Hz）產生幀時，就會出現卡頓和延遲。當應用程式渲染內容的時間超過一幀的持續時間（例如，在 60 FPS 下超過 16,7 毫秒）時，就會出現這種「卡頓」。

除了流暢性之外，螢幕切換也必須仔細監控。切換標籤頁、從清單中開啟詳細資訊或顯示對話方塊都應該幾乎瞬間完成，動畫流暢，不能出現閃爍或長時間的黑屏。

在後台，電池消耗和能源效率同樣重要。不必要的任務、大量的記憶體分配和高強度的 CPU 使用都會縮短電池續航時間並導致設備過熱。 Android Runtime (ART) 提高了能源效率，但如果您的應用程式內部循環每秒創建數千個新對象，那麼記憶體分配和垃圾回收的成本將非常明顯。

識別和糾正效能問題的工作流程

為了避免依賴運氣，建立一套系統的效能分析工作流程非常有幫助，該流程將實驗室中詳細的手動測試與生產環境中匯總指標的收集相結合。典型的流程包括以下步驟：

首先，需要確定關鍵使用者旅程，即對使用者體驗和業務影響最大的流程：

• 頻繁啟動應用程式（圖示、通知、深度連結）。
• 螢幕上會持續捲動顯示大量資料。
• 視圖和活動之間的關鍵轉換。
• 長時間操作流程，例如瀏覽、音訊/視訊播放、結帳等。

一旦確定了目標，就可以使用Perfetto 或 Systrace 等分析和追蹤工具對其進行檢測和分析，以微秒級的精度查看設備正在做什麼；使用內存分析生成器來檢測洩漏和分配熱點；或者使用 Simpleperf 等工具來找出哪些函數消耗的 CPU 最多。

需要強調的是，詳細的效能分析需要調試這些路由的每一次運行，並在可控的環境下重現問題。分析匯總資料對於發現模式和迴歸問題很有價值，但它並不能取代對特定追蹤資料的深入分析。

同時，建議在自動化測試環境和生產環境中設定持續的指標收集：啟動時間、阻塞率、幀指標（例如，透過 Android 上的 FrameMetricsAggregator）、Play 控制台欄位指標、滾動巨集基準測試等。這些指標可以幫助您了解裝置、作業系統版本和網路條件之間的真實差異。

用於精確測量的應用程式和系統設置

最常見的陷阱之一是在不切實際的條件下測試性能。為了使結果有效，必須仔細配置APK 和系統，確保測試環境盡可能接近生產環境，同時控制干擾因素。

在應用層面，切記不要使用偵錯版本進行效能測試。偵錯版本會新增檢查、日誌和標誌，這些都會顯著改變執行時間環境。在 Android 10 及更高版本中，您可以使用清單檔案中的`profileable android:shell="true"`屬性來啟用針對發布版本的效能測試，從而保持接近真實應用程式的效能表現。

此外，建議使用生產程式碼精簡工具（例如 ProGuard、R8 等），因為程式碼大小和組織結構對效能有顯著影響。但是，您應該仔細閱讀相關規則：某些配置可能會移除一些對效能測量至關重要的追蹤點，因此需要在測試版本中進行相應的調整。

關於編譯，最好將應用預熱到已知狀態，通常是速度模式或速度設定檔模式。這兩種模式都能減少 DeX 解釋執行的程式碼量，並降低後台 JIT 編譯的需求，進而穩定結果。速度設定檔模式力求更接近實際生產環境的行為，但這需要「預熱」應用並管理設定檔（例如，基線設定檔）。

從系統角度來看，當需要非常高精度的測量（微基準測試）時，通常會對裝置進行校準：在同一終端和作業系統版本上執行 A/B 測試，設定 CPU/GPU 頻率，使用 lockClocks 等腳本停用小核心或熱限制等。這並不能代表真實世界的情況，但可以降低特定場景下的噪音。

對於更接近用戶體驗的測量（啟動、電池消耗、UI崩潰），建議使用Macrobenchmark等測試框架，這些框架可以自動執行許多步驟，避免細微但關鍵的配置錯誤。

典型的效能問題模式

幾乎所有經過徹底分析的應用程式中都會出現某些反覆出現的問題模式，這些模式值得了解，因為如果及時發現，通常會有非常明確的解決方案。

最常見的問題之一是由於跳轉 Activity 導致的啟動緩慢。這種情況發生在啟動 Intent（圖示、通知、深度連結）之後，會先啟動一個不繪製任何影格的中間 Activity，然後再啟動「真正的」Activity。在追蹤日誌中，這表現為兩個連續的 `activityStart` 事件，中間沒有任何視覺效果。這種「跳轉」會增加啟動延遲，卻沒有任何實際意義。解決方案通常是將初始化程式碼重構為一個可重複使用的元件，或將其直接整合到主 Activity 中。

另一個經典的例子是不必要的記憶體分配觸發垃圾回收。如果 Systrace 或記憶體分析顯示，在長時間運行的操作期間，每隔幾秒鐘就會執行一次垃圾回收，那麼很可能是程式碼在密集型循環中反覆不斷地分配物件。解決方案並非移除每個新分配的對象，而是解決記憶體熱點問題，在適當的時候重複使用結構體或應用物件池機制。

圖形管線中也常會遇到阻塞畫面。在正常的追蹤中，對 `Choreographer.doFrame()` 的呼叫會以固定的節奏發生（例如，每 16,7 毫秒一次）。放大查看具有這種節奏的區域可以發現開銷較大的視圖、過於複雜的佈局、在 UI 執行緒上執行的 I/O 操作或配置錯誤的 RecyclerView。

RecyclerView 正是諸多問題的根源：例如，當只有少數元素發生更改時，卻使用 `notifyDataSetChanged()` 使整個資料集失效；嵌套 RecyclerView 中回收視圖池配置不當；以及到達列表末尾時資料預取不足。所有這些都會導致渲染開銷過大、滾動跳動以及使用者明顯的等待時間。

效能測試：類型、步驟和最佳實踐

除了生產環境監控之外，任何切實可行的策略都需要在受控環境中製定完善的應用效能測試計劃。這種測試能夠幫助您在向用戶開放變更或新版本之前，請驗證應用程式的容量、穩定性和可擴展性。

測試有好幾種類型，每種類型都有其特定的目的：

• 負載測試他們會在預測的用戶或交易負載下評估應用程式的行為，測量回應時間、吞吐量和資源消耗，以便在部署前發現瓶頸。
• 壓力測試他們將系統推向極限，以測試其承受能力、故障表現和恢復能力。他們對於產能規劃和應對類似「黑色星期五」的購物高峰至關重要。
• 耐久性/浸泡測試他們會持續負載數小時或數天，以發現緩慢退化、記憶體洩漏或資源耗盡等問題。
• 峰值測試他們模擬負載的突然和反覆增加（例如，活動、功能發布、直播），以驗證應用程式和基礎設施能否應對突發變化。
• 容量測試他們分析當用戶數量顯著增加時應用程式的運行情況。 數據量 （資料庫大小、檔案、訊息），驗證回應時間、儲存可靠性和資料遺失情況。
• 可擴展性測試他們會檢查應用程式在負載逐漸增加時的反應情況，以及水平或垂直擴展是否能帶來預期的效能提升。

典型的效能測試流程包含幾個不同的階段。首先是需求分析階段：了解業務可接受的回應時間、吞吐量、可用性等級和錯誤限制。然後是規劃和策略階段，在此階段，需要定義測試範圍、測試環境、測試工具以及要監控的指標。

接下來，設計測試案例以涵蓋不同的負載場景、網路條件和資料量；配置測試環境（硬體、軟體、網路、負載注入和監控工具）；運行測試，仔細收集效能資料。

關鍵階段是監控與分析：將回應時間與 CPU 使用率、網路延遲與錯誤率、流量高峰與資料庫過載等進行關聯分析。在將發現結果以清晰的報告形式記錄下來並提交給利害關係人後，流程將進入最佳化和重新測試階段：調整程式碼、配置或資源，並重複測試，直到改進效果得到驗證。

性能測試的工具和框架

要將上述內容付諸實踐，需要依賴特定的效能測試工具，包括開源和商業工具，這些工具應涵蓋自動化、負載產生、監控和分析。一些相關的類別包括：

• 開源工具諸如 Apache JMeter、Gatling、k6、Locust、Taurus、nGrinder 等項目，以及擴展了效能場景的單元和功能測試框架（JUnit、XCTest、Appium），可以建立功能強大的測試套件，且授權成本低廉。
• 商業負載測試和APM工具WebLOAD、LoadNinja、NeoLoad、LoadView、BlazeMeter、Rational Performance Tester、Silk Performer、Eggplant、CloudTest 或 Parasoft 等解決方案提供整合環境，具有基於雲端的負載產生、進階報告和專業支援。
• 專業化且可觀察的解決方案Applications Manager、Instana、Dynatrace、IBM Turbonomic 等產品，以及 SolarWinds 等網路監控平台，都專注於持續監控、異常偵測以及應用程式效能、基礎架構和使用者體驗之間的關聯。
• 平台特定工具例如，對於 Android 系統，Perfetto、系統追蹤、Android Studio 記憶體分析器、Simpleperf、Systrace 或 Play Console 幀指標等工具可以對系統級行為進行非常精細的分析。

在選擇其中一種工具時，建議考慮易用性、對協議和技術的支援、可擴展性、與持續整合/持續交付 (CI/CD) 的整合、許可模式、可擴展性以及支援品質（社區支援或商業支援）等因素。此外，結合使用多種工具也很常見：一種用於負載生成，一種用於應用效能管理 (APM)，另一種用於基礎設施可觀測性。

簡而言之，分析和監控應用程式效能需要結合精心選擇的指標、合適的工具和嚴格的測試流程，但結果絕對值得：更快、更穩定、更有效率的應用程序，更滿意的用戶，更少的生產事故，當然，還會對品牌聲譽和收入產生直接的積極影響。