目前開始介入游戲測(cè)試了,由于時(shí)間問題，只能借助第三方測(cè)試平臺(tái)來完成這部分操作了，并且只介紹其中幾個(gè)重要參數(shù)以及概念

1、Draw Call實(shí)質(zhì)

????????DrawCall是CPU調(diào)用底層圖形接口。比如有上千個(gè)物體，每一個(gè)的渲染都需要去調(diào)用一次底層接口，而每一次的調(diào)用CPU都需要做很多工作，那么CPU必然不堪重負(fù)。但是對(duì)于GPU來說，圖形處理的工作量是一樣的。所以對(duì)DrawCall的優(yōu)化，主要就是為了盡量解放CPU在調(diào)用圖形接口上的開銷。所以針對(duì)drawcall我們主要的思路就是每個(gè)物體盡量減少渲染次數(shù)，多個(gè)物體最好一起渲染。

下面用張圖來標(biāo)識(shí)

????????保證CPU和GPU可以并行工作的解決方法是：創(chuàng)建命令緩沖區(qū)（Command Buffer），CPU發(fā)布命令，GPU在完成上一次渲染任務(wù)之后會(huì)從中再取出命令并且執(zhí)行，其中命令緩存區(qū)的命令有很多種，而DrawCall就是其中之一，其他命令有改變渲染方式、使用不同紋理等。由于GPU的多核性，因此GPU的執(zhí)行速度很快，往往出現(xiàn)GPU執(zhí)行完了命令緩沖區(qū)中的所有命令后等待CPU指示的情況。因此造成性能問題最主要的是CPU而非GPU。

（這里盜用別人一張圖來解釋）

圖形引擎渲染畫面的過程

Unity（或者說基本所有圖形引擎）生成一幀畫面的處理過程大致可以這樣簡(jiǎn)化描述：

1. 可見性測(cè)試

?????引擎首先經(jīng)過簡(jiǎn)單的可見性測(cè)試，確定攝像機(jī)可以看到的物體

2. 準(zhǔn)備好物體的數(shù)據(jù)

????然后把這些物體的頂點(diǎn)（包括本地位置、法線、UV等），索引（頂點(diǎn)如何組成三角形），變換（就是物體的位置、旋轉(zhuǎn)、縮放、以及攝像機(jī)位置等），相關(guān)光源，紋理，渲染方式（由材質(zhì)/Shader決定）等數(shù)據(jù)準(zhǔn)備好

3. 通知圖形API開始繪制

????????然后通知圖形API——或者就簡(jiǎn)單地看作是通知GPU——開始繪制，GPU基于這些數(shù)據(jù)，經(jīng)過一系列運(yùn)算，在屏幕上畫出成千上萬(wàn)的三角形，最終構(gòu)成一幅圖像。

接下來我們的3個(gè)對(duì)象使用2個(gè)材質(zhì)，A和B使用材質(zhì)1，C使用材質(zhì)2，這時(shí)候來看，應(yīng)該是有2個(gè)DrawCall，或者3個(gè)DrawCall。應(yīng)該是2個(gè)DrawCall啊，為什么會(huì)有3個(gè)DrawCall？？？而且是有時(shí)候2個(gè)，有時(shí)候3個(gè)。我們按照上面的DrawCall分析流程來分析一下：

1.渲染A，使用材質(zhì)1?

2.渲染B，使用材質(zhì)1?

3.渲染C，使用材質(zhì)2

在這種情況下是2個(gè)DrawCall，在下面這種情況下，則是3個(gè)DrawCall

1.渲染A，使用材質(zhì)1?

2.渲染C，使用材質(zhì)2?

3.渲染B，使用材質(zhì)1

因?yàn)槲覀儧]有控制好渲染順序（或者說沒有去特意控制），所以導(dǎo)致了額外的DrawCall，因?yàn)锳和B不是一次性渲染完的，而是被C打斷了，所以導(dǎo)致材質(zhì)1被分為兩次渲染

減少繪制的方式：

使用紋理圖集（一張大貼圖里包含了很多子貼圖）來代替一系列單獨(dú)的小貼圖。它們可以更快地被加載，具有很少的狀態(tài)轉(zhuǎn)換，而且批處理更友好。

如果使用了紋理圖集和共享材質(zhì)，使用Renderer.sharedMaterial?來代替Renderer.material?。

使用光照紋理(lightmap)而非實(shí)時(shí)燈光。

使用LOD，好處就是對(duì)那些離得遠(yuǎn)，看不清的物體的細(xì)節(jié)可以忽略。

遮擋剔除（Occlusion culling）

使用mobile版的shader。因?yàn)楹?jiǎn)單。

2、三角形數(shù)量

????三角網(wǎng)格（Triangle Mesh），游戲開發(fā)者會(huì)使用三角形網(wǎng)格來建模。三角形是表面的分段線性逼近，如果用多條相連的線段分段逼近一個(gè)函數(shù)或曲線

從程序和性能的角度來看，面數(shù)是越少越好，少即意味著運(yùn)算量變小，渲染速度會(huì)更快、耗電量都降低不少

為什么事三角形呢，請(qǐng) 參考文章：https://www.cnblogs.com/meteoric_cry/p/7929124.html

3、android內(nèi)存主要有四種形式：VSS 、RSS 、PSS 、 USS

一般來說內(nèi)存占用大小有如下規(guī)律：VSS >= RSS >= PSS >= USS

VSS：Virtual Set Size，虛擬耗用內(nèi)存。它是一個(gè)進(jìn)程能訪問的所有內(nèi)存空間地址的大小。這個(gè)大小包含了?

一些沒有駐留在RAM中的內(nèi)存，就像mallocs已經(jīng)被分配，但還沒有寫入。VSS很少用來測(cè)量程序的實(shí)際使?

用內(nèi)存。

RSS：Resident Set Size，實(shí)際使用物理內(nèi)存。RSS是一個(gè)進(jìn)程在RAM中實(shí)際持有的內(nèi)存大小。RSS可能會(huì)?

產(chǎn)生誤導(dǎo)，因?yàn)樗怂性撨M(jìn)程使用的共享庫(kù)所占用的內(nèi)存，一個(gè)被加載到內(nèi)存中的共享庫(kù)可能有很?

多進(jìn)程會(huì)使用它。RSS不是單個(gè)進(jìn)程使用內(nèi)存量的精確表示。

PSS：Proportional Set Size，實(shí)際使用的物理內(nèi)存，它與RSS不同，它會(huì)按比例分配共享庫(kù)所占用的內(nèi)存。?

例如，如果有三個(gè)進(jìn)程共享一個(gè)占30頁(yè)內(nèi)存控件的共享庫(kù)，每個(gè)進(jìn)程在計(jì)算PSS的時(shí)候，只會(huì)計(jì)算10頁(yè)。?

PSS是一個(gè)非常有用的數(shù)值，如果系統(tǒng)中所有的進(jìn)程的PSS相加，所得和即為系統(tǒng)占用內(nèi)存的總和。當(dāng)一個(gè)?

進(jìn)程被殺死后，它所占用的共享庫(kù)內(nèi)存將會(huì)被其他仍然使用該共享庫(kù)的進(jìn)程所分擔(dān)。在這種方式下，PSS?

也會(huì)帶來誤導(dǎo)，因?yàn)楫?dāng)一個(gè)進(jìn)程被殺后，PSS并不代表系統(tǒng)回收的內(nèi)存大小。

USS：Unique Set Size，進(jìn)程獨(dú)自占用的物理內(nèi)存。這部分內(nèi)存完全是該進(jìn)程獨(dú)享的。USS是一個(gè)非常有用?

的數(shù)值，因?yàn)樗砻髁诉\(yùn)行一個(gè)特定進(jìn)程所需的真正內(nèi)存成本。當(dāng)一個(gè)進(jìn)程被殺死，USS就是所有系統(tǒng)回?

收的內(nèi)存。USS是用來檢查進(jìn)程中是否有內(nèi)存泄露的最好選擇。

盜用別人的圖一下，備注來源：https://www.cnblogs.com/JianXu/p/5685217.html

備注：手游在開發(fā)過程中可能會(huì)使用到共享庫(kù)，所以個(gè)人覺得查看手游內(nèi)存信息的時(shí)候使用pss作為內(nèi)存指標(biāo)比較合理