背景:遊戲項目採用敏捷開發,版本開發迭代很快,基本1-2周一個版本
性能問題在整個項目的階段數量
性能問題不是一開始就有的,也不是某一天突然出現的,而是隨著我們的開發進度不斷累積產生的;到後來我們希望用幾天的時間去解決幾個月甚至幾年的問題,而實際上結果往往不會盡如人意。而且相同的問題,相同的人,在不同的時間去處理所花費的經歷與時間完全不同。所以說性能問題看上去是研發團隊的技術問題,但本質上其實是研發團隊的開發流程問題
如果我們可以規範流程,做到每一個版本皆有一份數據展示,一旦發現問題,及時處理,那麼可以大大減少以後的優化時間;而人力每個版本做性能又比較雞肋,所以完全可以採用自動化的方式處理,那麼自動化的操作究竟會不會對我們得到的性能數據產生影響,下面我們來探索下;
測試背景:1.打開Perfdog,記錄手動跑功能和自動化跑功能的性能數據2.本次所使用自動化功能為Airtest
測試用例:1.未開啟Airtest IDE連接,手動跑功能2.開啟Airtest IDE連接,手動跑功能3.開啟Airtest IDE連接,使用自動化腳本跑功能4.斷開Airtest IDE連接5.關閉Airtest IDE進程
自動化腳本:只會運行一個戰鬥小功能,很短的時間
下面測試用例的斷開連接是指:
先來看看FPS
很明顯我們發現是否採用自動化的方式跑遊戲功能對比FPS的影響幾乎沒有
再來看看內存
發現自動化對內存也沒有影響,開不開自動化對於內存幾乎都一樣
再來看看CPU
我們發現在開啟airtest的IDE連接時,Total cpu的使用率顯著上升,在跑自動化腳本時Total cpu的使用率也在上升。而app的cpu使用率幾乎是沒有影響的。這是因為在開啟airtest ide的連接時,ide要使用minicap服務獲取手機的屏幕截圖,所以會對cpu的整體使用率有影響,而在運行腳本時airtest要進行圖像搜索匹配,所以也要佔用cpu。但是對於app的使用率則不會有影響。
本次測試不適用自動化腳本,單獨對比ide的影響
測試用例:1.靜止頁面不連接airtest ide2.靜止頁面連接airtest ide3.靜止頁面斷開airtest ide連接不退出ide4.靜止頁面斷開airtest ide連接退出ide
FPS數據
是否開啟IDE對應用的fps絲毫不影響
內存
內存也沒什麼影響
CPU使用率
和第一組的結論一樣,也是開啟ide會對total cpu使用率造成影響,需要注意的是斷開IDE與手機的連接後性能消耗還在,因為mincap服務實際沒有被中斷,要退出關閉IDE cpu才會恢復正常。
所選則是手機APP,非遊戲
FPS
內存
CPU
我們發現結論和上面相同
為什麼推薦這個值作為CPU使用率的衡量標準呢,因為發現還是規範化比較適合自動化,更為準確一些,關於規範化利用率的文檔:規範化利用率介紹
完全可以使用自動化的方式獲取應用的性能數據啦,這是因為我們所獲取的數據都是針對單個應用,所以自動化的操作不會算法該應用之內,不過接入自動化sdk的就要另外考慮了,SDK所消耗的資源會被算在應用頭上。