一、CPU性能

該游戲在CPU占用方面的性能非常不錯(cuò)，下圖為該游戲在紅米Note2 設(shè)備上按照劇情進(jìn)行游戲時(shí)的性能數(shù)據(jù)?？梢钥闯?#xff0c;在紅米Note2 上運(yùn)行的24979幀中，超過33ms的幀數(shù)占比為4.3%，超過50ms的幀數(shù)占比為1.2%?？紤]到切換場(chǎng)景時(shí)資源加載的開銷，一款游戲如果超過33ms的幀數(shù)占比低于10%，則說明該游戲在絕大多數(shù)時(shí)刻的運(yùn)行中都是非常流暢的。

通過進(jìn)一步統(tǒng)計(jì)，該游戲的CPU性能超過了84%的紅米Note2設(shè)備上的測(cè)試游戲，其能耗更是低于91%的同設(shè)備測(cè)試游戲。

其整體CPU性能的優(yōu)秀表現(xiàn)與其各個(gè)模塊的合理使用是分不開的。下面，我們就詳細(xì)講解一下其CPU性能方面的亮點(diǎn)之處。

1、渲染模塊

通過UWA性能測(cè)評(píng)報(bào)告，我們可以看到該游戲詳盡的渲染模塊性能開銷。該游戲在紅米Note2設(shè)備上運(yùn)行時(shí)的渲染模塊CPU開銷如下圖所示。通過統(tǒng)計(jì)，半透明物體渲染的CPU消耗均值為1.5 ms，主要集中在 0.7~2.7ms 范圍內(nèi)（5%~95%）。不透明物體渲染的CPU消耗均值為1.8 ms，主要集中在 0.2~4.6ms范圍內(nèi)（5%~95%）。

Draw Call峰值為340，雖然峰值較高，但僅在場(chǎng)景切換處出現(xiàn)，這是因?yàn)轫?xiàng)目在動(dòng)態(tài)加載后通過代碼調(diào)用StaticBatching的方式來合并Draw Call，所以可以看到Draw Call數(shù)量在進(jìn)入場(chǎng)景后迅速回落。同時(shí)，Draw Call數(shù)量主要集中在 48~179 范圍內(nèi)（5%~95%），屬于合理范圍之內(nèi)。

下圖為該游戲在紅米Note2上的具體CPU性能堆棧?？梢钥吹?#xff0c;該游戲在紅米Note2上無論是不透明開銷還是半透明開銷均處于較低水平，這得益于研發(fā)團(tuán)隊(duì)對(duì)于場(chǎng)景模型、蒙皮網(wǎng)格和UI的控制十分得當(dāng)。

美中不足的是Shader.SetPass稍高，這主要是渲染模塊中RenderState的切換較為頻繁所致，對(duì)此，建議大家對(duì)場(chǎng)景中的Material數(shù)量進(jìn)行控制，具體可以參考：《使用MaterialPropertyBlock來替換Material屬性操作》

2、UI模塊

該游戲在紅米Note2設(shè)備上運(yùn)行時(shí)的UI模塊CPU開銷如下圖所示。該游戲使用UGUI作為UI界面的解決方案。經(jīng)過統(tǒng)計(jì)，UI模塊總體的CPU占用均值為1.9ms，主要集中在0.1~3.6ms范圍內(nèi)（5%~95%），屬于合理范圍之內(nèi)。

其均值高于70%的行業(yè)數(shù)據(jù)，這是因?yàn)樵擁?xiàng)目使用的是Unity 4.7版本進(jìn)行開發(fā)，該Unity版本中，UGUI并沒有像Unity 5.3版本以后將部分拼合操作放到子線程中進(jìn)行。在這一點(diǎn)上，Unity 4.x的UGUI性能較之5.3+版本確實(shí)要多一些性能上的開銷。堆內(nèi)存平均每幀分配為5.5B，僅高于5%的行業(yè)項(xiàng)目，這說明該游戲UI界面的制作及UI重建的影響范圍非常合理。目前，UWA推薦UGUI模塊中，平均每幀堆內(nèi)存分配盡可能控制在2KB以下。

從下圖中可以看出，Canvas.SendWillRenderCanvases在不同的運(yùn)行時(shí)刻均出現(xiàn)CPU高值，但通過運(yùn)行截圖可以看到，其共同特點(diǎn)是CPU耗時(shí)高值均發(fā)生在畫面底層的UI選人界面出現(xiàn)時(shí)。因此，該UI界面的出現(xiàn)或相關(guān)操作極有可能是引發(fā)Canvas.SendWillRenderCanvases CPU過高的原因，建議研發(fā)團(tuán)隊(duì)對(duì)該界面進(jìn)行進(jìn)一步檢測(cè)。

3、動(dòng)畫模塊

在UWA測(cè)評(píng)報(bào)告中，該游戲運(yùn)行時(shí)的動(dòng)畫模塊CPU開銷如下圖所示。

可以看出，除進(jìn)入場(chǎng)景時(shí)出現(xiàn)CPU高值外，其在戰(zhàn)斗副本中的CPU開銷均控制在較低水平。Animator.Update的CPU均值為1.8ms，主要集中在0.1~3.4ms區(qū)間內(nèi)，其性能較為優(yōu)秀，高于28%的行業(yè)項(xiàng)目。同時(shí)，MeshSkinning.Update的CPU均值為1.8ms，主要集中在0.1~3.4ms區(qū)間內(nèi)，高于21%的行業(yè)數(shù)據(jù)。

同時(shí)，經(jīng)過進(jìn)一步檢測(cè)發(fā)現(xiàn)，其進(jìn)入副本時(shí)的CPU高值均為lhAnimatorEvent.OnEventCallback回調(diào)函數(shù)所致，具體的CPU耗時(shí)堆棧如下圖所示。通過此堆?？芍?#xff0c;其耗時(shí)主要為UI界面的加載耗時(shí)，且進(jìn)一步通過資源管理信息可知其主要開銷為luaUI_PK(Clone)的Active操作和luaUI_Hall(Clone)的Deactive操作所致。因此，建議研發(fā)團(tuán)隊(duì)可進(jìn)一步檢測(cè)該UI的制作是否合理，并對(duì)其進(jìn)行完善。

4、GC調(diào)用

該研發(fā)團(tuán)隊(duì)對(duì)于GC調(diào)用頻率控制得非常出眾，游戲在運(yùn)行過程中，GC調(diào)用頻率為1921幀/次，優(yōu)于目前95%的行業(yè)內(nèi)游戲。

一般來說，如果一款項(xiàng)目的GC調(diào)用頻率可以控制在1000幀/次以上，就已經(jīng)相當(dāng)出眾了。該游戲的GC調(diào)用頻率如此優(yōu)秀，主要得益于研發(fā)團(tuán)隊(duì)對(duì)于項(xiàng)目代碼堆內(nèi)存的控制。下圖為游戲運(yùn)行25000幀的代碼堆內(nèi)存具體分配情況。對(duì)于使用UGUI的游戲來說，我們建議游戲運(yùn)行每1萬幀中，Top10函數(shù)的堆內(nèi)存分配總和小于30MB，而該游戲運(yùn)行25000幀，其Top10函數(shù)的堆內(nèi)存分配總和才26.91MB，足見該團(tuán)隊(duì)對(duì)于堆內(nèi)存分配的理解非常深刻。

---

二、內(nèi)存模塊

《戰(zhàn)地先鋒》在內(nèi)存上的表現(xiàn)如下圖所示?？們?nèi)存峰值達(dá)到249MB，Mono堆內(nèi)存峰值為32.5MB。243MB的總內(nèi)存分配相對(duì)來說略高，研發(fā)團(tuán)隊(duì)可嘗試在低端機(jī)器上對(duì)資源進(jìn)行進(jìn)一步控制，從而降低低端機(jī)器上的內(nèi)存占用。

1、Mono堆內(nèi)存

從上圖可知，該游戲的總體Mono堆內(nèi)存控制得很好，在25000幀中，Mono的堆內(nèi)存峰值僅為 32.5MB。該值屬于合理范圍之內(nèi)（<40MB）。

但是，從走勢(shì)上來看，其堆內(nèi)存的占用在游戲運(yùn)行過程中持續(xù)處于上升趨勢(shì)，對(duì)此，建議研發(fā)團(tuán)隊(duì)對(duì)緩存池進(jìn)行進(jìn)一步檢測(cè)，排查項(xiàng)目是否存在堆內(nèi)存泄露的隱患。

2、資源內(nèi)存

經(jīng)過統(tǒng)計(jì)，該游戲的紋理資源數(shù)量峰值為618個(gè)，內(nèi)存占用峰值119.5MB。紋理內(nèi)存占用較高，目前高于82%的行業(yè)項(xiàng)目。經(jīng)過統(tǒng)計(jì)，在內(nèi)存占用峰值處，ETC1格式紋理占有221個(gè)，Alpha8格式紋理占有5個(gè)，RGBA32和ARGB32格式紋理共占有120個(gè)，RGB24格式紋理占有87個(gè)，其余為RGBA16格式紋理。

對(duì)于RGBA32、ARGB32的紋理，我們建議在視覺效果可以保證的情況下，盡可能使用ETC1格式紋理（Android平臺(tái)）進(jìn)行替換，不僅可以達(dá)到更小的內(nèi)存占用，同時(shí)可以獲得更快的加載效率。而對(duì)于無法進(jìn)行硬件壓縮的紋理，可以通過Dither方法嘗試將其轉(zhuǎn)換成RGBA16格式的紋理，具體做法可以參考此篇文章。

其他資源的內(nèi)存占用情況如下：

Mesh資源：

內(nèi)存峰值高于41%的項(xiàng)目

AnimationClip資源：

內(nèi)存峰值高于40%的項(xiàng)目

AudoClip資源：

內(nèi)存峰值高于73%的項(xiàng)目

AudioClip的內(nèi)存占用較高，高于73%的行業(yè)項(xiàng)目。對(duì)此，研發(fā)團(tuán)隊(duì)可嘗試將內(nèi)存占用較高的音頻資源通過Stream的方式來進(jìn)行加載，該方式可極大降低AudioClip資源的內(nèi)存占用。

以上則為《戰(zhàn)地先鋒》游戲在CPU性能和內(nèi)存管理方面的具體使用情況。優(yōu)秀的CPU性能、非常少的堆內(nèi)存分配以及引擎模塊間的合理使用，足以看出該研發(fā)團(tuán)隊(duì)非常深厚的技術(shù)功底和對(duì)于引擎相當(dāng)優(yōu)秀的把控能力。

---

三、性能優(yōu)化、進(jìn)無止境

該游戲在Shader加載和GameObject Active/Deactive方面仍有一定的提升空間。在此，我們對(duì)其進(jìn)行羅列，希望同樣可以幫助到大家的研發(fā)項(xiàng)目。

1、Shader加載

目前，游戲副本切換時(shí)存在較高的Shader解析（Shader.Parse)開銷，如下圖所示。通過具體資源信息中的Shader資源分析，可以定位是如下幾個(gè)Shader的加載耗時(shí)，對(duì)此，建議研發(fā)團(tuán)隊(duì)嘗試對(duì)頻繁使用的Shader進(jìn)行預(yù)加載并常駐內(nèi)存，從而減少不必要的Shader重復(fù)加載耗時(shí)。

2、GameObject Active/Deactive調(diào)用次數(shù)過高

該游戲在運(yùn)行過程中，GameObject Active/Deactive的調(diào)用次數(shù)過高，在游戲運(yùn)行的25000幀中，Active調(diào)用268952次，Deactive調(diào)用393490次。其調(diào)用的具體次數(shù)如下圖所示（下圖為游戲運(yùn)行每10幀進(jìn)行一次Sample，而每個(gè)Sample的數(shù)值為前10幀中Active/Deactive調(diào)用次數(shù)的總和。

其中，GameObject的Active/Deactive Top10資源信息具體如下所示，因此，研發(fā)團(tuán)隊(duì)可通過下表直接對(duì)頻繁進(jìn)行Active的GameObject進(jìn)行完善。Deactive的完善亦然。

頻繁的Active/Deactive操作不僅會(huì)造成CPU的浪費(fèi)，同時(shí)，它還很可能間接造成更大的CPU耗時(shí)，比如Animator.Initialize耗時(shí)。該游戲的Animator.Initialize調(diào)用較為頻繁，且耗時(shí)較高，如下圖所示，而這就是頻繁的Active/Deactive操作所造成的結(jié)果。因此，對(duì)于GameObject不必要的Active和Deactive操作進(jìn)行控制，是非常有必要的。

最后，非常感謝《戰(zhàn)地先鋒》研發(fā)團(tuán)隊(duì)對(duì) UWA 的認(rèn)可和支持。感謝他們樂于將項(xiàng)目性能數(shù)據(jù)與大家一起分享，讓更多的研發(fā)團(tuán)隊(duì)了解到一款性能優(yōu)秀的3D移動(dòng)游戲在各個(gè)模塊上可以做到怎樣的程度。同時(shí)，也歡迎更多的開發(fā)團(tuán)隊(duì)可以與我們一起來分享你們的性能數(shù)據(jù)，讓更多的游戲開發(fā)者受益！

PS：安利這款FPS手游，在TapTap上已經(jīng)獲得了8.6的高分，并將于9月7日在14個(gè)安卓渠道同時(shí)開啟付費(fèi)刪檔測(cè)試，歡迎大家來預(yù)約！

原文出處：侑虎科技
本文作者：admin
轉(zhuǎn)載請(qǐng)與作者聯(lián)系，同時(shí)請(qǐng)務(wù)必標(biāo)明文章原始出處和原文鏈接及本聲明。

總結(jié)

以上是生活随笔為你收集整理的FPS手游《战地先锋》性能案例精讲的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。