⑴ 夏季SoC發熱深度對比：麒麟9000與驍龍888誰更「冷酷」
轉眼時間就到了年中，手機界各種晶元之間的性能對比相信大家已經看得很多了，尤其是麒麟9000與驍龍888這一對安卓陣營頂級晶元之間，各種維度的比較都很多。不過，由於季節是從冬春季步入夏季，相信大家有一個感覺會逐漸被放大——手機發熱甚至是發燙，尤其是在打 游戲 的時候。那麼問題來了：夏季高溫情況下，手機功耗與發熱多大程度上會被高溫影響？筆者就來專門測一測，看看麒麟9000與驍龍888在夏季高溫的時候，誰的功耗上升慢，誰的發熱控制好，誰更適合在夏季使用。
為了讓測試具有實際參考性，筆者分別進行了室外高溫+常溫極限 兩個測試環境。使用的機型則是兩款萬元高端機，華為Mate40 RS保時捷設計與三星S21 Ultra，測試 游戲 分別是《王者榮耀》、《和平精英》、《原神》三款 游戲 ，覆蓋小型、中型與大型 游戲 三個檔位，對性能與功耗的要求逐步升級。
簡單看下兩款處理器。麒麟9000使用了台積電的5nm工藝，搭載三檔八核CPU，GPU首發24核Mali G78，NPU是達芬奇架構2.0，標配巴龍5G基帶，性能直接拉滿的同時能效比大幅提升，堪稱是史上最強麒麟。
驍龍888使用了三星5nm工藝，CPU也是三擋八核架構，GPU升級Adreno 660，DSP升級Hexagon 780，標配X60 5G基帶，性能飆升，是高通最強SOC。
除了SoC的配置，再來看看移動端晶元綜合性能排行，麒麟9000綜合得分126.4，驍龍888得分118.6，麒麟超過驍龍成為安卓移動晶元第一。綜合性能有所差別，又差別在哪裡，實際體驗怎麼樣？下面進入測試。
為了測試的准確，筆者分別對三款 游戲 都分別進行了空載功耗測試，來排除屏幕這個耗電大戶對功耗的影響，最大還原玩 游戲 中處理器尤其是GPU的功耗情況。
實測兩款手機空載功耗如上：
通過空載功耗可以看到，兩款手機的屏幕耗電差距並不明顯。下面正式進入今天的主題，麒麟9000與驍龍888的性能+功耗+發熱PK。
20分鍾不間斷測試，PerfDog監測的數據結果如下：
（提示：有四次幀率低谷，均是因王者結束重開導致）
先看幀率，兩款手機都保持在了60幀左右的高水平，除了結束一局重開中間的四次載入掉幀（華為Mate40 RS開了3局，三星S21 Ultra開了一局 ），玩王者都毫無壓力。
再看功耗，去掉空載功耗並簡單計算功耗差值，麒麟9000比驍龍888低862-709=153 mWh， 計算得到驍龍888比麒麟9000的功耗高153 709=19.4%。意味著驍龍888每玩80分鍾的王者，麒麟9000就可以玩將近100分鍾，這個功耗差對續航的影響比意料之中的要大。
發熱方面，麒麟9000玩20分鍾後最高溫達到了39.7 ，驍龍888達到了40.9 ，溫度差達有1.2 ，屬於溫熱到微燙的一個手感程度，夏天還可以接受。
小結：玩王者榮耀，麒麟9000與驍龍888性能不相上下，但麒麟9000功耗有20%多的優勢，同時溫度更低。
30分鍾不間斷 測試，PerfDog監測的數據結果如下：
（提示：有三次幀率低谷，均是因和平精英結束重開導致）
先看幀率，華為Mate40 RS比三星S21 Ultra低了 39.6-39.2= 0.4幀，原因並不是麒麟9000性能不足，而是因為有一局快速成盒子了，導致多一次，與上面測試王者遇到了一樣的問題。簡單來說玩吃雞，麒麟9000與驍龍888也沒什麼壓力。
再看麒麟9000與驍龍888的功耗差值，達到了1479-1047=432 mWh，計算 得到 麒麟9000功耗比驍龍888低 432 1047= 41 .3 %，這個差距嚇到我了，畢竟這次對比的對象不是7nm的驍龍865+ 。
為什麼驍龍888功耗會更高？或許發熱能說明一些問題。麒麟9000玩和平精英30分鍾最高溫40.2 ，只是比王者榮耀高了0.5 ，說實話這個發熱還是蠻出乎意料的。而驍龍888溫度則同比升高了1.1 ，從溫熱變為了輕度燙手的42 ，尤其是邊框會更加明顯，驍龍開始「上火」了。
小結：在中度性能與持續發熱的影響下，麒麟9000在能效比上把驍龍888甩開了，省電優勢繼續拉大。
由於三星S21Ultra原神會鎖幀到40，所以都選擇了同一標準的30幀測試，PerfDog的監測數據如下：
（提示：原神不會因為死亡重開，所以圖中幀率波動均是處理器真實性能反饋）
先看幀率，這次沒了 游戲 打完一局重新開始的影響，紫色線的麒麟9000平均幀率比綠色線的驍龍888高了 29.9-27.6= 2. 3 幀，雖這個領先並不多，但是細看幀率波動線就可以發現，麒麟9000幾乎沒有過大的幀率波動，甚至幀率方差Var是0，但驍龍888卻一直有很大的波動，幀率方差Var達到了16.6， 游戲 中會很多次感受到明顯的掉幀。
再看功耗，玩原神的功耗差值變為了 1342-1037= 305mWh，驍龍888在原神上功耗比麒麟9000高 305 1037= 29.4%，相比和平精英的41%大幅降低，是不是意味著這才是驍龍的真實實力？別著急先表態，下面還有 發熱 數據。
發熱方面，麒麟9000溫度升到了41.8 ，玩 游戲 會明顯感到燙手了。驍龍888溫度則是升到了43.2 ，雖只比麒麟高了1.4 ，但卻第一次攀升到了43 以上，玩 游戲 會感到更明顯的燙手，驍龍888功耗下降的原因也找到了——發熱降頻，導致功耗下降，算是一個有失有得的結果。
小結：通過王者、和平精英、原神三款 游戲 的一個高溫環境測試，發現Mate40 RS確實比三星S21 Ultra體驗優勢明顯，在高溫天麒麟9000的性能輸出更加持久、穩定，CPU+GPU高能效比進一步凸顯， 游戲 發熱更低、功耗更低。驍龍888則像是一個反面，雖性能強勁，但能效比低與可能的調度問題，遇到中高性能需求時會快速升溫，導致要麼是功耗大幅增加，要麼是為了降發熱而卡頓 掉幀 。
為了進一步證實以上的猜測，筆者又用和平精英與原神兩款 游戲 做了更進一步的測試。
在戶外通風環境下，和平精英選擇了90分鍾連續不間斷的實測，PerfDog監測的數據結果如下：
（提示：有七次幀率低谷，華為重開4次，三星重開3次）
幀率波動圖如上，使用麒麟9000的華為Mate40RS很不幸地又比使用驍龍888的三星S21 Ultra多重開了一局，導致幀率驍龍888比麒麟9000高39.6-39.3=0.3幀。兩款手機的幀率波動除了重開的大幅下降，和平精英連續玩中並沒有出現明顯波動，都擁有良好的 游戲 幀率表現。
在功耗上差值上，驍龍888比麒麟9000多了3177-2615=462mWh，整體功耗驍龍比麒麟高462 2615=17.7%，兩款處理器的功耗差繼續變小了，這種變化的原因是什麼，咱們接著看發熱，或許能告訴我們為什麼。
溫度上，麒麟9000從上一次和平精英測得40.2 上升到了42 ，升溫1.8 ，麒麟也進入了燙手階段。驍龍888則是從42 直接上升到了44 ，升溫2 ，從火熱升級到「火燙」階段。
這樣一對比，或許就能明白麒麟9000功耗從比驍龍888低41%升到低17.7%的原因了，即使麒麟9000的能效比高與發熱低，但是長時間的 游戲 也會讓發熱累積到一個高度，導致處理器能效比降低，進而功耗就升高了。
帶著探究的精神，進行了原神最後30分鍾的測試，華為三星兩款手機全開60幀+最高特效，即使三星鎖幀40，也要看看到底會有什麼結果。PerfDog監測數據結果如下：
這一次先看功耗，麒麟9000功耗比驍龍888高了 2035-1851= 184mWh，也就是高了 184 1851= 9.9%，這是驍龍888功耗首次戰勝麒麟。對比第一部分內容中的原神30幀 的功耗 測試結果，麒麟9000同比增加了96.2%，驍龍888同比增加了37.9%，看來 降低用戶體驗的 鎖幀對於驍龍888來說確實一個省電的好辦法。
（提示：原神不會因為死亡重開，圖中幀率波動均是處理器真實性能反饋）
再看幀率，在三星鎖幀40幀的情況下，華為Mate40 RS平均比三星S21 Ultra高56.2-38.7=17.5幀，計算得到華為幀率比三星高17.5 38.7=45%，幀率上這一次華為跑原神擁有碾壓之勢。同時從幀率曲線圖上也可以看到，華為與三星這次都很吃力，兩者都有明顯的大幅度掉幀。
結合幀率與功耗，也就是說在功耗高9.9%的情況下，麒麟9000最高實現了比驍龍888高45%左右的性能輸出，當然這么換算可能不準確，但依然具有一定可參考價值。
最後再來看看性能跑滿的情況下，發熱會如何，由於兩款手機的極限溫度都出乎意料，因此這次正反面的發熱都記錄了。
華為Mate40 RS正面最高溫度45.1 ，背面最高溫度44.9 ，已經達到了很燙手的地步，這也是筆者第一次把華為Mate40 RS玩到這個溫度，可以稱得上是「烤機了」。
三星S21 Ultra正面最高溫度46.5 ，背面最高溫度47.2 ，手感溫度已經到了一個感覺會boom的地步，「火龍」正式露出了真面目。要知道這還是驍龍888鎖幀40幀的結果，如果不鎖幀突破50 大關也不是沒有可能。當然，如此高溫也可能與三星的散熱優化不足有關，這也是一個重要影響因素。
結合功耗、幀率與發熱溫度三者可以發現，雖麒麟9000跑滿原神會功耗大幅增加，同時溫度大幅升高、幀率波動增大，但整體的功耗水平、發熱水平都依然比驍龍888低，不得不說這已經不是一個可以用能效比、性能來簡單解讀的了，會涉及到更深層次的晶元設計、晶元製造的製程工藝、晶元封裝工藝、晶元性能調度機制、晶元與手機的深度耦合適配、以及類似於GPU Turbo等底層軟體技術等，用一個個的前沿技術，才能把麒麟9000打磨的超出行業表現。
通過兩輪使用情形的對比，可以發現麒麟9000相比驍龍888在持續的高性能輸出、高能效比、低發熱上有著明顯的優勢。對於 游戲 黨來說，可能驍龍888與麒麟9000在王者這類小 游戲 體驗不會有太明顯的差別，都是安卓陣營最頂尖的存在。但當面對高溫天氣+原神這種大型 游戲 的時，麒麟9000的高性能+高能效比+低發熱優勢就凸顯出來了，同比更低溫+長續航。至於網友們會怎麼選擇或者有什麼看法，相信看完這篇深度對比已經有了答案。
⑵ iqoo9怎麼連接perfdog
1.顯示連接的設備
2.選擇需要測試的app
3.device tab下顯示設備的基本信息，setting設置參數，about裡面有perfdog的官方介紹
4.FPS 刷新的次數
5.cpu cou使用率
6.流量
7.若想要測試其他指標，可以7中勾選，這里簡單介紹幾個常用的
screenshot 圖形模式（數據線模式下使用）
Fps 刷新次數
Frame time 計算繪制每個圖形的時間
cpu usage cpu使用率
memory uasge 內存
cpu temperature cpu溫度
network 流量
battery 電量（wifi模式下）
8.開始記錄數據
9.從左到右，為每個階段打上標簽，本地存儲位置，web雲存儲數據
iQOO 9是iQOO於2022年1月5日發布的手機產品，於1月12日正式上市。
iQOO 9採用6.78英寸AMOLED（E5柔性）屏幕；高度約164.55毫米，寬度約76.7毫米，厚度約8.37毫米，重量約206.1克；配有傳奇版、賽道版、鋒芒三種顏色。
iQOO 9搭載高通驍龍8 Gen1八核處理器；後置5000萬像素主鏡頭+1300萬像素廣角鏡頭+1200萬像素人像鏡頭三攝，支持2倍光學變焦、20倍數字變焦等拍照功能，前置1600萬像素攝像頭；搭載4700毫安時容量電池。
⑶ APP頁面掉幀卡頓原因及Perfdog性能測試之FPS
最近在做APP性能專項測試，視頻剪輯過程中出現多次卡頓掉幀的問題，為了更好地了解出現掉幀卡頓的原因，去查閱了資料並記錄下該文章
了解卡頓原因之前，先了解下視圖渲染過程如下圖：
1、CPU計算顯示的內容（如文本繪制，UI布局計算，視圖創建，圖片解碼等等），然後把計算好的內容提交給GPU
2、GPU 渲染（變換，圖層合成，紋理渲染等）完成後，將渲染結果放入幀緩沖區
3、視頻控制器會按照 VSync 信號逐行讀取幀緩沖區的數據，經過可能的數模轉換傳遞給顯示器顯示
備註：
1、顯示器上的所有圖像都是一線一線的掃描上去的（從左到右，從上到下刷新），如下圖：
3、水平同步可能會出現畫面撕裂的現象（如下圖）。因為畫面的渲染不是整個畫面一起渲染的，是逐行逐列渲染。如果沒有開啟垂直同步，設備配置不夠，則畫面在高速移動中會出現一行還沒刷新完成就出現下一行，進而出現撕裂情況
4、垂直同步就是為了解決畫面撕裂的問題，當開啟垂直同步後，GPU 會等待顯示器的 VSync 信號發出後，才進行新的一幀渲染和緩沖區更新。這樣能解決畫面撕裂現象，也增加了畫面流暢度，但需要消費更多的計算資源，也會帶來部分延遲。
5、目前，iOS設備使用雙緩存，並開啟垂直同步，Android是三緩存，並開啟垂直同步（緩存之間怎麼切換的呢？？？）
首先，先了解下基礎的知識：假定設備的刷新率是60HZ，如果頁面的滑動流暢率為60fps，也就是一秒更新60張圖片，人眼上看就是流暢的效果，也就是每隔16.7ms（1/60）就要產生一幀的畫面，即：每隔16.7ms發出V-SYNC信號，觸發對UI進行渲染，這一幀的畫面需要由CPU和GPU共同協同完成顯示（詳見上面的視圖渲染過程）
卡頓掉幀原因：
如果在一個 VSync 時間內，CPU花費的時間比較長，留給GPU的時間就比較少，GPU+CPU總時間就可能超過16.7ms，下一幀到來前，沒准備好當下幀的畫面，這時候顯示器還是顯示上一幀的畫面，就出現掉幀，就出現滑動卡頓；
同理，如果GPU花費的時間比較長，總時長也可能超過16.7ms
所以，CPU 和 GPU 不論哪個阻礙了顯示流程，都會造成掉幀現象
經過上面的分析，為了優化掉幀卡頓問題，我們就需要對CPU和GPU的處理過程進行優化
先講下以下的幾個參數：
Frames Per Second；應用界面平均每秒刷新次數，
Jank ：1s內卡頓次數
BigJank :1s內嚴重卡頓次數
PerfDog Jank計算方法：
1. 同時滿足以下兩條件，則認為是一次卡頓 Jank.
a) 當前幀耗時>前三幀平均耗時2倍。
b) 當前幀耗時>兩幀電影幀耗時(1000ms/24 2=84ms)。
2. 同時滿足兩條件，則認為是一次嚴重卡頓 BigJank .
a) 當前幀耗時>前三幀平均耗時2倍。
b) 當前幀耗時>三幀電影幀耗時(1000ms/24 3=125ms)。
測試過程中，卡頓時長的佔比。即Stutter(卡頓率)=卡頓時長/總時長
卡頓時長計算：基於Jank的基礎上，一次Jank卡頓，會有一次卡頓時間Jank time。測試過程中可能有多次Jank卡頓，即有多次卡頓時間Jank time。卡頓時長即為多次卡頓時間的和
上下幀畫面顯示時間間隔，也可簡單認為單幀渲染耗時
Avg(FTime):平均幀耗時
1、流暢度不等於FPS，需要多維度衡量，考慮FPS，Jank，Stutter
2、APP需要關注FPS、Jank及卡頓率。只是需要區分使用場景，如：
（1）、靜態頁面窗口
只需關注FPS，理論FPS應該為0，否則，說明有冗餘刷新，容易引起手機發熱及耗電。
（2） 有滾動動畫頁面窗口
只需關注FPS，FPS處於合適值即可，無需高頻刷新。
（3）快速滑動頁面窗口。
需要關注FPS、Jank及卡頓率。手機交互靈敏度就是來源於此，一般滑動狀態下，幀率越高越好，Jank越小越好。
（4） 播放視頻頁面窗口。
需要關注FPS、Jank及卡頓率，視頻卡頓直接影響用戶。視頻一般幀率18-24幀，Jank=0。比如微信播放視頻、視頻播放器等。
⑷ perfDog 筆記1：基本使用
IOS/Android性能測試、分析工具平台。快速定位分析性能問題。
支持移動端所有應用程序（游戲、app應用、瀏覽器、小程序、小游戲、H5、後台系統進程等）、Android模擬器、雲真機等性能測試。
支持APP多進程測試
PerfDog桌面應用程序版本都支持對IOS和Android設備進行測試。PerfDog多開,支持單PC同時測試多台手機
登錄PerfDog官網 https://perfdog.qq.com/
ios: 若檢測不到連接手機，先安裝itunes確保手機能連上PC
Android: 非安裝模式和安裝模式
註：手機一開啟USB調試模式，並允許USB應用安裝
a. 非安裝模式：即插即用，無需配置安裝；但手機上無實時性能數據顯示
b. 安裝模式：手機上自動安裝PerfDog.apk，手機上顯示實時性能數據
以華為手機為例，
USB模式： USB連線後，在設備列表選擇USB圖標設備進行USB模式測試
WIFI模式： 只能在WIFI模式測試功率等信息。USB連線後，在設備列表選擇WIFI圖標，進行WIFI模式測試。WIFI檢測連接成功後，拔掉USB連接線
註：
1. PC和phone連接同一WiFi,檢測成功後，按照提示拔出USB連接線
2. USB模式下phone充電，測試功率無意義
android已安裝PerfDog後，左上角顯示實時性能數據
⑸ perfdog會泄露用戶信息嗎
最近QC同學在跑游戲的過程中發現玩的時間久了游戲會發生閃退，經過搜集信息後排除了功能性bug的
一.判斷是否是內存泄露
拿到真機，USB連接，殺掉多餘後台進程，打開Perfdog，接下來一頓操作猛如虎，Perfdog具體操作不在贅述，有關perfdog怎麼使用的教程可以參考
Perfdog使用教程
拿到內存趨勢圖
使用手機
此圖一出，基本就可以斷定內存泄露了，這是正常玩游戲，游戲運行了30分鍾的內存趨勢圖；
結論：，內存持續上升，存在內存泄露。
一個優秀的游戲通常情況內存是有上升有回落，多次運行同一個功能也不會導致內存功能持續上升；
呈現出起伏狀態，比如：
知道了存在內存泄露，下面就要開始分析有可能是哪裡導致的內存泄露；
二.分析泄露原因
一般針對unity游戲來說，內存瓶頸是資源和Mono堆內存，兩部分；
以下是unity游戲程序在運行時的內存分配概況
先簡單介紹下Mono，unity使用Mono機制來完成跨平台的操作，就好像JAVA使用虛擬機來完成跨平台操作一樣，Mono也是一種跨平台的實現。跨平台其實現原理在於使用了叫CIL（Common Intermediate Language通用中間語言，也叫做MSIL微軟中間語言）的一種代碼指令集，CIL可以在任何支持CLI（通用語言基礎結構）的環境中運行，就像.NET是微軟對這一標準的實現，Mono則是對CLI的又一實現。由於CIL能運行在所有支持CLI的環境中，例如剛剛提到的.NET運行時以及Mono運行時，也就是說和具體的平台或者CPU無關。
一般對於unity開發的游戲來說，內存的開銷都是圍繞下面的三個方面：
1.資源內存的佔用；
2.引擎模塊自身內存佔用；
3.託管堆內存佔用。
Mono通過垃圾回收機制（GarbageCollect，簡稱GC）對內存進行管理，可以自動地改變堆的大小來適應你所需要的內存，並且是可以適時地調用垃圾回收（GarbageCollection）操作來釋放已經不需要的內存。也就是說Mono會自動釋放一些內存，但要注意的是GC釋放的內存只會留給mono使用，並不會交還給操作系統，因此mono堆內存是只增不減的。
這里簡單介紹下Mono回收原理：
Mono會跟蹤每次內存分配的動作，並維護一個分配對象表，當GC的時候，以全局數據區和當前寄存器中的對象為根節點，按照引用關系進行遍歷，對於遍歷到的每一個對象，將其標記為活的（alive）。所有對象的被標記意味著該對象可以通過全局對象或者當前上下文訪問到，而沒有被標記的對象則意味著該對象無法通過任何途徑訪問到，即該對象「失聯」了，GC最終會將所有「失聯」的對象內存進行回收。
內存泄露定義
我們把對象已經不再需要使用卻沒有被GC回收的情況稱為mono內存泄漏。Mono內存泄漏會使空閑內存減少，GC頻繁，mono堆不斷擴充，最終導致游戲內存佔用的升高。最終導致內存過高，進程被操作系統Kill或者崩潰。簡單來說，也就是一些對象被實例化出來後沒有被釋放掉，一種保存在內存中，新的對象又需要申請新的內存空間，導致內存不斷上升。
重點關注點
配置文件的使用、紋理、網格、RenderTexture和粒子系統；
比如頻繁的創建銷毀對象是否使用對象池，或者粒子，紋理等資源顯示過後是否被及時從內存中釋放，等等；
三.測試手段
1.首先通跑測試，確定問題確定原因，比如我上面通過通跑游戲確定存在內存泄露；
2.縮小范圍，由於一個游戲在運行的過程中場景比較復雜，上面的同跑並不能准確定位問題，所以我們要劃分場景測試，例如我在上面的通跑游戲過程中包括以下場景，打開關閉UI界面，戰斗場景，切換地圖，升級武器等，如果沒有比較明顯的數據，那就要分別針對以下場景進行測試。比如UI場景可以反復打開關閉UI界面，戰斗場景可以持續戰斗掛機，反復切換地圖等等，總之是把游戲內進行的行為減少，細化要檢測的場景；
3.定位問題
如果某個場景發生內存泄露，邊定位到那個場景運行游戲，而在游戲運行時，相應的引擎也有一些工具可以查看具體的代碼使用情況，比如unity的Profiler。
如果多個場景都出現內存泄露，那就要查找這些場景所交叉的部分，比如通信框架等；而本次經過多個場景的測試發現都存在泄露，最後經過排查發現是使用的通信框架存在泄露問題。
四，Perfdog內存相關簡介
通常情況下安卓可以輕松獲取到的內存有4種數據，我們也可以通過ADB來獲取，
VSS - Virtual Set Size 虛擬耗用內存（包含共享庫佔用的內存）
RSS - Resident Set Size 實際使用物理內存（包含共享庫佔用的內存）
PSS - Proportional Set Size 實際使用的物理內存（比例分配共享庫佔用的內存）
USS - Unique Set Size 進程獨自佔用的物理內存（不包含共享庫佔用的內存）
一般來說內存佔用大小有如下規律：VSS >= RSS >= PSS >= USS
而Perfog的Memory也就是 Android PSS Memory，也是我們通常來用作代表內存的數據，是實際使用的物理內存大小。
Swap Memory (Swap Memory，部分設備支持Swap功能，在啟用Swap功能後，系統會對PSS內存進行壓縮，Swap增加，PSS會相應減少，由於壓縮會佔用CPU資源，同時相應會導致FPS降低)
Virtual Memory(VSS) 虛擬內存是計算機系統內存管理的一種技術。它使得應用程序認為它擁有連續的可用的內存（一個連續完整的地址空間），而實際上它通常是被分隔成多個物理內存碎片，還有部分暫時存儲在外部磁碟存儲器上，在需要時進行數據交換。
五、Perfdog新功能初探
PerfDog 3.5版本剛剛推出，新增一個最新的數值，CPU Usage(Normalized)：規范化CPU利用率
官方給出的解釋為：
傳統計算方法：當前時刻CPU頻率下，CPU Usage = CPU執行時間/CPU總時間。
由於移動設備CPU頻率時刻變化，用傳統CPU利用率計算方法，假定在低頻率時刻計算出CPU利用率=30%，和在CPU高頻時刻計算出CPU利用率=30%。同樣都是30%但性能消耗是完全不樣的，明顯高頻消耗更高。傳統CPU利用率已無法真實反映性能消耗。
所以我們需要一種規范化(可量化)的統計方式。將頻率因素考慮進去。
CPU Usage(Normalized)= (CPU執行時間/CPU總時間) * (當前時刻所有CPU頻率之和/所有CPU頻率最大值之和)。
PerfDog兩種統計方式都有。CPU Usage默認為規范化CPU利用率。建議使用規范化CPU利用率作為衡量性能指標。
具體的描述可以看這里：規范化CPU利用率
嘗鮮體驗以下。測試使用過程和之前的一樣。來看看新增的數據對比
title：
CPU Usage趨勢圖對比：
CPU Core Usage趨勢圖對比：
從趨勢圖來看的話，實際上兩種演算法並無太大差異，但是精確到具體幀的使用率，差異會比較明顯，單純從性能的角度來說，傳統CPU利用率僅能從數值的角度體現手機的CPU使用程度，但是無法從性能使用程度的角度表達手機的CPU使用效率，就像前文所說，低頻率時刻計算出CPU利用率=30%，和在CPU高頻時刻計算出CPU利用率=30%。同樣都是30%但性能消耗是完全不樣的。規范化CPU利用率數值可以彌補這一缺點。目前的測試行業良莠不齊，規范指標較少，如果真的可以做到統一行業標准不失為一件好事。