[TOC]
前后端性能指標
性能測試的定義和分類
定義：
觀察系統(tǒng)在一個給定的環(huán)境和場景中的性能表現(xiàn)是否與預期目標一致焰情，評判系統(tǒng)是否存在性能缺陷内舟，并根據(jù)測試結(jié)果識別性能瓶頸初橘，改善系統(tǒng)性能的完整的過程。
分類：
- 基準測試：單用戶耕蝉，發(fā)單次請求赔硫，產(chǎn)出基準性能數(shù)據(jù)
- 負載測試：多用戶盐肃，用戶數(shù)漸增砸王，持續(xù)同時發(fā)同一業(yè)務請求，產(chǎn)出最大TPS
- 壓力測試：多用戶耘成，資源使用飽和瘪菌，持續(xù)同時發(fā)同一業(yè)務請求，產(chǎn)出系統(tǒng)瓶頸或使用極限
- 混合場景測試：多用戶诵肛，資源使用不飽和默穴，持續(xù)同時發(fā)不同業(yè)務請求蓄诽，驗證系統(tǒng)穩(wěn)定性
性能測試的指標
前后端的性能測試關(guān)注點和指標是不一樣的。
前端關(guān)注點
- 響應時間：用戶從客戶端發(fā)出請求乙埃，并得到響應锯岖，以及展示出來的整個過程的時間嚎莉。
- 加載速度：通俗的理解為頁面內(nèi)容顯示的快慢。
- 電量：APP的耗電量赃额。
- 流量：APP所消耗的流量
1跳芳、加載速度
通俗的理解竹勉，可以將加載速度視為頁面內(nèi)容顯示的快慢飞盆。拿Google搜索的例子來說吓歇，從用戶輸入搜索內(nèi)容按下enter鍵城看，到看到搜索出來的內(nèi)容杏慰，這個過程的快慢就是加載速度炼鞠。假設選中一個內(nèi)容點擊谒主，跳轉(zhuǎn)到一個網(wǎng)頁瘩将，網(wǎng)頁的內(nèi)容顯示出來能讓用戶看見的過程凹耙，也是加載速度肖抱。
早些年Amazon曾經(jīng)做過一個統(tǒng)計：網(wǎng)頁加載時間每延長1秒鐘意述，一年將減少16億美元的營收吮蛹。
一般有哪些方式可以改善加載速度帶來的用戶體驗呢？
-
減少HTTP重復請求
性能黃金法則：只有
10%~20%的最終用戶響應時間花在了下載HTML文檔上术荤，其余的80%~90%時間花在了下載頁面中的所有組件上瓣戚。因此焦读，改善響應時間最簡單的途徑就是減少HTTP請求的數(shù)量矗晃，并且去除不必要的重復請求张症。
-
使用CDN
HTTP請求和響應的時間會受到離 web 服務器距離的影響。如果用戶離應用程序的web服務器離用戶更近浑彰，那么多個HTTP請求的響應時間將縮短拯辙。
CDN（內(nèi)容發(fā)布網(wǎng)絡）是一組分布在多個不同地理位置的Web服務器，可以選擇網(wǎng)絡階躍數(shù)最小的服務器周伦，或者具有最短響應時間的服務器未荒，用于更加有效地向用戶發(fā)布內(nèi)容。
-
減少下載的資源
比如通過壓縮圖片的方式寨腔，減少圖片的大小迫卢，縮短下載的時間冶共。另外可以通過比對客戶端與服務端差異的方式，快速展示本地的緩存資源家卖，減少同樣內(nèi)容的重復下載上荡。
2馒闷、電量
Android的很多特性都比較耗電(屏幕、GPS沛善、喚醒機制塞祈、CPU议薪、連網(wǎng)等的使用)斯议。
3、流量
目前的網(wǎng)絡類型包含2G\3G\4G\wifi坯临，其中還有不同運營商的區(qū)分。APP 使用過程中赶促，常見的網(wǎng)絡流量嚴重消耗的原因主要有鸥滨，調(diào)用響應慢谤祖，調(diào)用失敗等各種情況粥喜。
通常從哪些指標去衡量流量消耗的狀態(tài)是否正常呢容客？
- 應用首次啟動流量提示缩挑；
- 應用處于后臺供置，連續(xù)運行2小時的靜默流量芥丧；
- 應用處于前臺坊罢，高負荷運行時的流量峰值活孩。
一般有哪些原因?qū)е铝髁勘淮罅肯哪兀?/strong>
- 資源太多
- 圖片太大
- 重復請求
- 日志上傳
- 埋點數(shù)據(jù)
4、Crash和ANR
Crash的原因一般有：空指針询兴、內(nèi)存泄漏诗舰、數(shù)組越界训裆、調(diào)用了高版本的API。
Android應用程序蝙茶，如果主線程(即UI線程)在超時間內(nèi)對用戶輸入時間沒有處理完畢隆夯，就會出現(xiàn)Application Not Responding彈出框别伏，用戶需要選擇等待或者強制關(guān)閉來殺死進程厘肮。
5类茂、FPS
就是動畫幀率巩检。幀就是指動畫或視頻的“畫面”领舰，1幅畫就叫做“1幀”冲秽，幀數(shù)就是在1秒鐘時間里傳輸?shù)膱D片的量矩父，也可以理解為圖形處理器每秒鐘能夠刷新幾次窍株，通常用FPS（Frames Per Second）表示杉武。
每一幀都是靜止的圖象辙售，快速連續(xù)地顯示幀便形成了運動的假象旦部，高的幀率可以得到更流暢和逼真的動畫较店，因此每秒鐘幀數(shù) (FPS) 越多，顯示出來的動作就越流暢容燕。
那么什么是合理的FPS呢梁呈？
幀率達到60FPS以上，人眼主觀就感受不到差別了蘸秘。所以一般以60FPS作為衡量標準官卡，即要求每一幀刷新的時間小于16ms，這樣才能保證滑動中平滑的流暢度醋虏。
后端關(guān)注點
- 響應時間：接口從請求到響應寻咒、返回的時間。
- 并發(fā)用戶數(shù)：同一時間點請求服務器的用戶數(shù)颈嚼，支持的最大并發(fā)數(shù)毛秘。
- 內(nèi)存占用：APP的內(nèi)存開銷。
- 吞吐量（TPS）：Transaction Per Second, 每秒事務數(shù)阻课。在沒有遇到性能瓶頸時：TPS=并發(fā)用戶數(shù)*事務數(shù)/響應時間。
- 錯誤率：失敗的事務數(shù)/事務總數(shù)适秩。
- 資源使用率：CPU占用率抚官、內(nèi)存使用率、磁盤I/O、網(wǎng)絡I/O卒煞。
1扮饶、響應時間
指的是客戶發(fā)出請求到得到響應的整個過程的時間。在某些工具中占键，請求響應時間通常會被稱為TTLB（Time to laster byte）翩概，意思是從發(fā)起一個請求開始，到客戶端收到最后一個字節(jié)的響應所耗費的時間难述。所以也可以理解成，響應時間＝網(wǎng)絡響應時間+應用程序響應時間。
因此在大部分公司的項目實際運作中，會把性能測試分為兩部分年鸳，APP 前端的響應時間、后端接口請求和返回的時間滥酥，即分別是系統(tǒng)級性能測試和接口級性能測試宇葱。
- 網(wǎng)絡傳輸時間：T3+T4+T5+T6
- 應用服務器處理時間：T5+T7+T8
- 數(shù)據(jù)庫服務器處理時間：T7+T8
<span style="color:#ff0000;">響應時間 </span>= N1+N2+T3+T4+T5+T6+T7+T8
那么什么是合理的響應時間呢？
- 互聯(lián)網(wǎng)上對于用戶響應時間，有一個普遍的標準，2－5－10原則
詳細來說，就是：
- 2秒之內(nèi)得到響應，會認為系統(tǒng)響應的很快
- 5秒之內(nèi)得到響應，會認為系統(tǒng)響應的速度還不錯
- 10秒之內(nèi)得到響應膳沽，會認為系統(tǒng)響應的速度很糟糕
- 超過10秒還未得到響應，會認為系統(tǒng)是沒有響應的
2、CPU
在Linux系統(tǒng)下糜工，CPU利用率分為用戶態(tài)刨裆、系統(tǒng)態(tài)窍帝、空閑態(tài)贴膘，分別表示CPU處于用戶態(tài)執(zhí)行的時間玄柠，系統(tǒng)內(nèi)核執(zhí)行的時間这弧，和空閑系統(tǒng)進程執(zhí)行的時間。平時所說的CPU利用率是指：CPU執(zhí)行非系統(tǒng)空閑進程的時間 / CPU總的執(zhí)行時間。
CPU可能出現(xiàn)的問題是尊浓，持續(xù)CPU占用較高、設備發(fā)熱谷丸、使用非常卡頓、程序卡死樟凄。
什么情況下會消耗CPU 呢挂谍？
-
就是大量的運算
比如某個Activity或者方法有一直不停的運算消耗CPU（比如：不停止的while 或者for 循環(huán)）
一般從哪些指標監(jiān)控CPU情況呢？
- 設備的應用在空閑時間萨醒，CPU的占用情況
- 應用使用時，CPU的占用走勢涣仿，持續(xù)變化
- CPU的占用峰值**
**
3丈探、內(nèi)存占用
Android系統(tǒng)中类嗤，每個APP進程除了同其他進程共享(shared dirty)外精偿，還獨用私有內(nèi)存(private dirty)笔咽，通常使用PSS(=私有內(nèi)存+比例分配共享內(nèi)存)來衡量一個APP的內(nèi)存開銷甩十。
移動設備的內(nèi)存資源有限橄霉，因此為每個APP進程分配的私有內(nèi)存也是有限制的造虏。APP 的內(nèi)存常見問題有內(nèi)存占用過高、內(nèi)存泄露渠啤，以及內(nèi)存溢出狐肢。
- 內(nèi)存泄漏：程序在向系統(tǒng)申請內(nèi)存分配后，使用后未釋放沥曹。
- 內(nèi)存溢出：程序向系統(tǒng)申請的內(nèi)存空間超出了系統(tǒng)本身的內(nèi)存份名，會出現(xiàn)崩潰，也就是客戶端的carsh妓美。
上面主要講了性能的指標僵腺，具體各個性能指標的測試工具及方法，分別見其他文章壶栋。
本文由mdnice多平臺發(fā)布
