評(píng)價(jià)一款游戲的性能好壞，我們通常會(huì)用到「幀率」（每秒鐘的渲染幀數(shù)）作為主要參考指標(biāo)。當(dāng)然，手游這塊功耗也是一個(gè)重要因素，但主要還是看幀率。像MOBA、FPS類的游戲，幀率肯定是越高越好，出于功耗與顯示設(shè)備的限制，一般跑滿也就在60fps左右。而像其他的棋牌、放置類游戲，幀率只要有30fps就足夠了。

一、Bandwidth

為什么會(huì)是帶寬呢？

這是因?yàn)槌鲇诳臻g的考慮，手機(jī)芯片的設(shè)計(jì)上采用了SoC架構(gòu)，因此內(nèi)存與顯存實(shí)際上是共享在一塊物理內(nèi)存上的，在OpenGL ES規(guī)范中，內(nèi)存與顯存中的數(shù)據(jù)卻不能共享。在有限帶寬的前提下，我們不妨計(jì)算一下，一臺(tái)分辨率為1920*1080的移動(dòng)設(shè)備，按60幀率來算，每秒鐘1次overdraw產(chǎn)生的數(shù)據(jù)量為：

1920 * 1080 * 32 * 60 / (1024 * 1024) = 3.7 Gb

如果遇到了大量的半透明物體或是粒子特效，那么數(shù)據(jù)量上可能會(huì)成倍的增長。

如此大量的數(shù)據(jù)存儲(chǔ)在顯存的FrameBuffer中，GPU要以高昂地代價(jià)頻繁地去顯存訪問FrameBuffer里的數(shù)據(jù)，這顯然是很難接受的。因此在移動(dòng)端的顯卡硬件上，想到了一種優(yōu)化方式，就是將FrameBuffer拆分成不同的小塊(tile)，每次可以先將這一小塊的數(shù)據(jù)放到訪問速度更快的On-Chip Memory中去，GPU會(huì)先從tile中一塊塊地去進(jìn)行渲染，等整體渲染完成之后，再將數(shù)據(jù)搬回顯存上。

我們將這種模式稱為 「TBR（Tile Base Rendering）」。

然而在TBR模式下，可能存在著這樣的一個(gè)問題，如果對(duì)于CPU每一次傳來的繪制命令都進(jìn)行渲染的話，那么GPU必定會(huì)頻繁、大量地對(duì)tile數(shù)據(jù)進(jìn)行搬遷操作，這顯然是不可接受的。為了解決這個(gè)問題，TBR一般的策略是：對(duì)于CPU提交的Draw Call請(qǐng)求，先只做頂點(diǎn)處理，將Vertex Shader計(jì)算的結(jié)果暫存到一個(gè)叫 「FrameData」 的地方。等到執(zhí)行 「Swap Buffer」 的時(shí)候，再對(duì)整個(gè)數(shù)據(jù)做光柵化，進(jìn)行繪制。

既然是等所有的FrameData數(shù)據(jù)處理好后一次性進(jìn)行繪制，GPU硬件上便進(jìn)一步做了些延遲渲染相關(guān)的優(yōu)化。例如iOS上的PowerVR，專門有一個(gè)叫 ISR 的硬件，會(huì)去處理FrameData中那些諸如深度測試、模板測試沒有通過的數(shù)據(jù)，盡可能地只去渲染那些最終影響FrameBuffer的物體。

我們將這種模式稱為 「TBDR（Tile Base Deffered Rendering）」。

• 使用壓縮的紋理格式，如ETC、PVR等

• 打開Mipmap（內(nèi)存與帶寬的權(quán)衡）

• 減少Shader中的采樣次數(shù)，盡量合并一些通道圖

• 控制總頂點(diǎn)數(shù)量

• 不要頻繁地切換FrameBuffer（后處理效果）

二、Drawcall

手機(jī)上CPU與GPU的關(guān)系，就好像客戶端與服務(wù)端的CS架構(gòu)。所謂Drawcall，可以理解為Client端的CPU向Server端的GPU發(fā)送的一次繪制命令，同時(shí)會(huì)傳遞需要被渲染的圖元列表?，F(xiàn)代GPU就為了「高并發(fā)」處理數(shù)據(jù)而生的，一般Drawcall的繪制數(shù)據(jù)計(jì)算起來應(yīng)該還是綽綽有余。但由于CPU傳遞的渲染數(shù)據(jù)得通過PCI-E總線才能傳到GPU顯存中的全局存儲(chǔ)區(qū)域，頻繁且大量地提交繪制相對(duì)簡單的繪制命令，會(huì)造成GPU端的 “ 產(chǎn)能過剩 ” ，CPU無法及時(shí)提供渲染數(shù)據(jù)而造成性能瓶頸。

與此同時(shí)，TBR架構(gòu)下優(yōu)化過的GPU，會(huì)先將頂點(diǎn)數(shù)據(jù)存儲(chǔ)到FrameData隊(duì)列，如果Drawcall數(shù)量過多，且頂點(diǎn)數(shù)量巨大，萬一FrameData承裝的內(nèi)存放不下了，就得先將數(shù)據(jù)移動(dòng)到別處，進(jìn)而大大降低了訪問速度。這也是我們需要控制DrawCall數(shù)量和頂點(diǎn)數(shù)的一個(gè)重要原因。

游戲開發(fā)中，常見的降低Drawcall的方式，無非以下幾種：

• 動(dòng)態(tài)合批

在每一幀都對(duì)需要的網(wǎng)格進(jìn)行合批處理，這樣的好處就是合批的物體仍然可以各自移動(dòng)，但是必須使用同一個(gè)材質(zhì)。當(dāng)所需合批的頂點(diǎn)數(shù)過多時(shí)，其實(shí)會(huì)對(duì)CPU產(chǎn)生額外的計(jì)算開銷。因此在做動(dòng)態(tài)合批的時(shí)候，通常會(huì)有頂點(diǎn)數(shù)的限制，需要根據(jù)實(shí)際需要做好取舍。

• 靜態(tài)合批

只進(jìn)行一次合批處理，生成一個(gè)大的網(wǎng)格，性能優(yōu)于動(dòng)態(tài)合批，但沒有動(dòng)態(tài)合批靈活（只能作用于靜態(tài)物體），并且會(huì)有較高的內(nèi)存占用。

• Shader LOD

根據(jù)機(jī)型或攝像機(jī)距離，使用不同的材質(zhì)shader，盡可能地降低細(xì)節(jié)表現(xiàn)，去除不必要的渲染Pass以及計(jì)算開銷。

• 遮擋剔除

三、Overdraw

GPU中跟Overdraw有關(guān)的指標(biāo)可以參考「像素填充率」，即每秒所能渲染的最大像素?cái)?shù)量。在確保帶寬沒有遇到性能瓶頸后（改用壓縮紋理格式），如果降低設(shè)備分辨率后，幀率一下子上去了，那么很可能就是像素填充率遇到了瓶頸。這時(shí)候就需要看看Overdraw是否在一個(gè)合理的范圍內(nèi)，是否有優(yōu)化的空間。

實(shí)際的游戲開發(fā)中，最常見的Overdraw大戶莫過于「粒子特效」了。美術(shù)同學(xué)在制作粒子特效的時(shí)候，往往會(huì)為了追求細(xì)節(jié)效果而忽略掉Overdraw的問題。大量的透明粒子相疊加，造成的性能開銷是十分可怖的。為此，我們最好在立項(xiàng)之初就設(shè)定好一些粒子特效的制作規(guī)范，或是一些建議要求來約束美術(shù)設(shè)計(jì)粒子效果。

• 一個(gè)復(fù)合粒子系統(tǒng)（如爆炸），子特效盡量不要超過5個(gè)（疊加過曝也應(yīng)考慮優(yōu)化）
• 粒子所占的屏幕面積盡量不要過大，可以考慮使用Mesh來替換

• 紋理中透明不可見的部分盡可能地少

為了照顧低端機(jī)型，我們可以對(duì)粒子特效采取分級(jí)的策略，等級(jí)越低，特效表現(xiàn)越簡單，同時(shí)也可以從粒子數(shù)量、運(yùn)算模塊來進(jìn)行精簡。如果還是不能滿足性能要求，也可以考慮改用幀動(dòng)畫來替代粒子特效。

本文轉(zhuǎn)自：愛丸游戲工作室 - 年糕爸爸豬，轉(zhuǎn)載此文目的在于傳遞更多信息，版權(quán)歸原作者所有，如有問題，請(qǐng)與我們聯(lián)系！