[TOC]
前後端性能名額
性能測試的定義和分類
定義：
觀察系統在一個給定的環境和場景中的性能表現是否與預期目标一緻，評判系統是否存在性能缺陷，并根據測試結果識别性能瓶頸，改善系統性能的完整的過程。
分類：
- 基準測試：單使用者，發單次請求，産出基準性能資料
- 負載測試：多使用者，使用者數漸增，持續同時發同一業務請求，産出最大TPS
- 壓力測試：多使用者，資源使用飽和，持續同時發同一業務請求，産出系統瓶頸或使用極限
- 混合場景測試：多使用者，資源使用不飽和，持續同時發不同業務請求，驗證系統穩定性
性能測試的名額
前後端的性能測試關注點和名額是不一樣的。
前端關注點
- **響應時間：**使用者從用戶端送出請求，并得到響應，以及展示出來的整個過程的時間。
- **加載速度：**通俗的了解為頁面内容顯示的快慢。
- **電量：**APP的耗電量。
- **流量：**APP所消耗的流量
1、加載速度
通俗的了解，可以**将加載速度視為頁面内容顯示的快慢。**拿Google搜尋的例子來說，從使用者輸入搜尋内容按下enter鍵，到看到搜尋出來的内容，這個過程的快慢就是加載速度。假設選中一個内容點選，跳轉到一個網頁，網頁的内容顯示出來能讓使用者看見的過程，也是加載速度。
早些年Amazon曾經做過一個統計：網頁加載時間每延長1秒鐘，一年将減少16億美元的營收。
一般有哪些方式可以改善加載速度帶來的使用者體驗呢？
-
減少HTTP重複請求
性能黃金法則：隻有
10%~20%
-
使用CDN
HTTP請求和響應的時間會受到離 web 伺服器距離的影響。如果使用者離應用程式的web伺服器離使用者更近，那麼多個HTTP請求的響應時間将縮短。
CDN（内容釋出網絡）是一組分布在多個不同地理位置的Web伺服器，可以選擇網絡階躍數最小的伺服器，或者具有最短響應時間的伺服器，用于更加有效地向使用者釋出内容。
-
減少下載下傳的資源
比如通過壓縮圖檔的方式，減少圖檔的大小，縮短下載下傳的時間。另外可以通過比對用戶端與服務端差異的方式，快速展示本地的緩存資源，減少同樣内容的重複下載下傳。
2、電量
Android的很多特性都比較耗電(螢幕、GPS、喚醒機制、CPU、連網等的使用)。
3、流量
目前的網絡類型包含2G\3G\4G\wifi，其中還有不同營運商的區分。APP 使用過程中，常見的網絡流量嚴重消耗的原因主要有，調用響應慢，調用失敗等各種情況。
通常從哪些名額去衡量流量消耗的狀态是否正常呢？
- 應用首次啟動流量提示；
- 應用處于背景，連續運作2小時的靜默流量；
- 應用處于前台，高負荷運作時的流量峰值。
一般有哪些原因導緻流量被大量消耗呢？
- 資源太多
- 圖檔太大
- 重複請求
- 日志上傳
- 埋點資料
4、Crash和ANR
Crash的原因一般有：空指針、記憶體洩漏、數組越界、調用了高版本的API。
Android應用程式，如果主線程(即UI線程)在逾時間内對使用者輸入時間沒有處理完畢，就會出現Application Not Responding彈出框，使用者需要選擇等待或者強制關閉來殺死程序。
5、FPS
就是動畫幀率。幀就是指動畫或視訊的“畫面”，1幅畫就叫做“1幀”，幀數就是在1秒鐘時間裡傳輸的圖檔的量，也可以了解為**圖形處理器每秒鐘能夠重新整理幾次，**通常用FPS（Frames Per Second）表示。
每一幀都是靜止的圖象，快速連續地顯示幀便形成了運動的假象，高的幀率可以得到更流暢和逼真的動畫，是以每秒鐘幀數 (FPS) 越多，顯示出來的動作就越流暢。
那麼什麼是合理的FPS呢？
幀率達到60FPS以上，人眼主觀就感受不到差别了。是以一般以60FPS作為衡量标準，即要求每一幀重新整理的時間小于16ms，這樣才能保證滑動中平滑的流暢度。
後端關注點
- **響應時間：**接口從請求到響應、傳回的時間。
- **并發使用者數：**同一時間點請求伺服器的使用者數，支援的最大并發數。
- **記憶體占用：**APP的記憶體開銷。
- **吞吐量（TPS）：**Transaction Per Second, 每秒事務數。在沒有遇到性能瓶頸時：TPS=并發使用者數*事務數/響應時間。
- **錯誤率：**失敗的事務數/事務總數。
- **資源使用率：**CPU占用率、記憶體使用率、磁盤I/O、網絡I/O。
1、響應時間
指的是**客戶送出請求到得到響應的整個過程的時間。**在某些工具中，請求響應時間通常會被稱為TTLB（Time to laster byte），意思是從發起一個請求開始，到用戶端收到最後一個位元組的響應所耗費的時間。是以也可以了解成，響應時間＝網絡響應時間+應用程式響應時間。
是以在大部分公司的項目實際運作中，會把性能測試分為兩部分，APP 前端的響應時間、後端接口請求和傳回的時間，即分别是系統級性能測試和接口級性能測試。
- 網絡傳輸時間：T3+T4+T5+T6
- 應用伺服器處理時間：T5+T7+T8
- 資料庫伺服器處理時間：T7+T8
響應時間 = N1+N2+T3+T4+T5+T6+T7+T8
那麼什麼是合理的響應時間呢？
- 網際網路上對于使用者響應時間，有一個普遍的标準，2－5－10原則
詳細來說，就是：
- 2秒之内得到響應，會認為系統響應的很快
- 5秒之内得到響應，會認為系統響應的速度還不錯
- 10秒之内得到響應，會認為系統響應的速度很糟糕
- 超過10秒還未得到響應，會認為系統是沒有響應的
2、CPU
在Linux系統下，CPU使用率分為使用者态、系統态、空閑态，分别表示CPU處于使用者态執行的時間，系統核心執行的時間，和空閑系統程序執行的時間。平時所說的CPU使用率是指：CPU執行非系統空閑程序的時間 / CPU總的執行時間。
CPU可能出現的問題是，持續CPU占用較高、裝置發熱、使用非常卡頓、程式卡死。
什麼情況下會消耗CPU 呢？
-
就是大量的運算
比如某個Activity或者方法有一直不停的運算消耗CPU（比如：不停止的while 或者for 循環）
一般從哪些名額監控CPU情況呢？
- 裝置的應用在空閑時間，CPU的占用情況
- 應用使用時，CPU的占用走勢，持續變化
-
CPU的占用峰值**
**
3、記憶體占用
Android系統中，每個APP程序除了同其他程序共享(shared dirty)外，還獨用私有記憶體(private dirty)，通常使用PSS(=私有記憶體+比例配置設定共享記憶體)來衡量一個APP的記憶體開銷。
移動裝置的記憶體資源有限，是以為每個APP程序配置設定的私有記憶體也是有限制的。APP 的記憶體常見問題有記憶體占用過高、記憶體洩露，以及記憶體溢出。
- 記憶體洩漏：程式在向系統申請記憶體配置設定後，使用後未釋放。
- 記憶體溢出：程式向系統申請的記憶體空間超出了系統本身的記憶體，會出現崩潰，也就是用戶端的carsh。