評價一款手機游戲的性能好壞，我們通常會用到「幀率」（每秒鐘的渲染幀數）作為主要參考指標。當然，手游這塊功耗也是一個重要因素，但主要還是看幀率。像MOBA、FPS類的游戲，幀率肯定是越高越好，出于功耗與顯示設備的限制，一般跑滿也就在60fps左右。而像其他的棋牌、放置類游戲，幀率只要有30fps就足夠了。
手機游戲開發要謹遵「二八原則」：20%的代碼影響80%的性能瓶頸。因此要合理地找出性能瓶頸所在，避免負優化。下面就三個比較常見的方面：「bandwidth」、「drawcall」、「overdraw」 來分別闡述渲染階段是如何造成性能瓶頸以及對應的解決辦法。
一、Bandwidth
移動端的GPU設計之初，優先注重的肯定是功耗問題，然而在實際渲染一幀圖像的時候，對功耗影響最大的因素就是「帶寬（bandwidth）」。
為什么會是帶寬呢？
這是因為出于空間的考慮，手機芯片的設計上采用了SoC架構，因此內存與顯存實際上是共享在一塊物理內存上的，在OpenGL ES規范中，內存與顯存中的數據卻不能共享。在有限帶寬的前提下，我們不妨計算一下，一臺分辨率為1920*1080的移動設備，按60幀率來算，每秒鐘1次overdraw產生的數據量為：
1920 * 1080 * 32 * 60 / (1024 * 1024) = 3.7 Gb
如果遇到了大量的半透明物體或是粒子特效，那么數據量上可能會成倍的增長。
如此大量的數據存儲在顯存的FrameBuffer中，GPU要以高昂地代價頻繁地去顯存訪問FrameBuffer里的數據，這顯然是很難接受的。因此在移動端的顯卡硬件上，想到了一種優化方式，就是將FrameBuffer拆分成不同的小塊(tile)，每次可以先將這一小塊的數據放到訪問速度更快的On-Chip Memory中去，GPU會先從tile中一塊塊地去進行渲染，等整體渲染完成之后，再將數據搬回顯存上。
我們將這種模式稱為 「TBR（Tile Base Rendering）」。
然而在TBR模式下，可能存在著這樣的一個問題，如果對于CPU每一次傳來的繪制命令都進行渲染的話，那么GPU必定會頻繁、大量地對tile數據進行搬遷操作，這顯然是不可接受的。為了解決這個問題，TBR一般的策略是：對于CPU提交的Draw Call請求，先只做頂點處理，將Vertex Shader計算的結果暫存到一個叫 「FrameData」 的地方。等到執行 「Swap Buffer」 的時候，再對整個數據做光柵化，進行繪制。
既然是等所有的FrameData數據處理好后一次性進行繪制，GPU硬件上便進一步做了些延遲渲染相關的優化。例如iOS上的PowerVR，專門有一個叫 ISR 的硬件，會去處理FrameData中那些諸如深度測試、模板測試沒有通過的數據，盡可能地只去渲染那些最終影響FrameBuffer的物體。
我們將這種模式稱為 「TBDR（Tile Base Deffered Rendering）」。
基于移動端GPU特有的架構模式，需要我們做哪些優化方面的事情或是注意事項呢？
使用壓縮的紋理格式，如ETC、PVR等
打開Mipmap（內存與帶寬的權衡）
減少Shader中的采樣次數，盡量合并一些通道圖
控制總頂點數量
不要頻繁地切換FrameBuffer（后處理效果）
二、Drawcall
手機上CPU與GPU的關系，就好像客戶端與服務端的CS架構。所謂Drawcall，可以理解為Client端的CPU向Server端的GPU發送的一次繪制命令，同時會傳遞需要被渲染的圖元列表。現代GPU就為了「高并發」處理數據而生的，一般Drawcall的繪制數據計算起來應該還是綽綽有余。但由于CPU傳遞的渲染數據得通過PCI-E總線才能傳到GPU顯存中的全局存儲區域，頻繁且大量地提交繪制相對簡單的繪制命令，會造成GPU端的 “ 產能過剩 ” ，CPU無法及時提供渲染數據而造成性能瓶頸。
與此同時，TBR架構下優化過的GPU，會先將頂點數據存儲到FrameData隊列，如果Drawcall數量過多，且頂點數量巨大，萬一FrameData承裝的內存放不下了，就得先將數據移動到別處，進而大大降低了訪問速度。這也是我們需要控制DrawCall數量和頂點數的一個重要原因。
游戲開發中，常見的降低Drawcall的方式，無非以下幾種：
動態合批
在每一幀都對需要的網格進行合批處理，這樣的好處就是合批的物體仍然可以各自移動，但是必須使用同一個材質。當所需合批的頂點數過多時，其實會對CPU產生額外的計算開銷。因此在做動態合批的時候，通常會有頂點數的限制，需要根據實際需要做好取舍。
靜態合批
只進行一次合批處理，生成一個大的網格，性能優于動態合批，但沒有動態合批靈活（只能作用于靜態物體），并且會有較高的內存占用。
Shader LOD
根據機型或攝像機距離，使用不同的材質shader，盡可能地降低細節表現，去除不必要的渲染Pass以及計算開銷。
遮擋剔除
常見于大世界場景的游戲中，對于攝像機可視范圍之外的物體可以進行視錐體剔除，但是可視范圍內的那些已經被遮擋住了的物體，可能仍然會去進行繪制，造成不必要的性能損耗。
三、Overdraw
對需要繪制的物體進行排序，是游戲引擎規避性能開銷的一種常見手段。非透明物體相對攝像機由近及遠地排序繪制，可以有效剔除那些深度測試不通過的片元。但對于那些未被遮擋（深度測試通過）的「透明物體」，由于需要開啟混合計算，因此在Early-Z階段也沒法剔除掉那些背后的圖元數據，這就造成了同一個像素的多次(過度)繪制，即我們常說的 「Overdraw」 。
GPU中跟Overdraw有關的指標可以參考「像素填充率」，即每秒所能渲染的最大像素數量。在確保帶寬沒有遇到性能瓶頸后（改用壓縮紋理格式），如果降低設備分辨率后，幀率一下子上去了，那么很可能就是像素填充率遇到了瓶頸。這時候就需要看看Overdraw是否在一個合理的范圍內，是否有優化的空間。
實際的游戲開發中，最常見的Overdraw大戶莫過于「粒子特效」了。美術同學在制作粒子特效的時候，往往會為了追求細節效果而忽略掉Overdraw的問題。大量的透明粒子相疊加，造成的性能開銷是十分可怖的。為此，我們最好在立項之初就設定好一些粒子特效的制作規范，或是一些建議要求來約束美術設計粒子效果。
一個復合粒子系統（如爆炸），子特效盡量不要超過5個（疊加過曝也應考慮優化）
粒子所占的屏幕面積盡量不要過大，可以考慮使用Mesh來替換
紋理中透明不可見的部分盡可能地少
為了照顧低端機型，我們可以對粒子特效采取分級的策略，等級越低，特效表現越簡單，同時也可以從粒子數量、運算模塊來進行精簡。如果還是不能滿足性能要求，也可以考慮改用幀動畫來替代粒子特效。