目前开始介入游戏测试了,由于时间问题，只能借助第三方测试平台来完成这部分操作了，并且只介绍其中几个重要参数以及概念

1、Draw Call实质

        DrawCall是CPU调用底层图形接口。比如有上千个物体，每一个的渲染都需要去调用一次底层接口，而每一次的调用CPU都需要做很多工作，那么CPU必然不堪重负。但是对于GPU来说，图形处理的工作量是一样的。所以对DrawCall的优化，主要就是为了尽量解放CPU在调用图形接口上的开销。所以针对drawcall我们主要的思路就是每个物体尽量减少渲染次数，多个物体最好一起渲染。

下面用张图来标识

        保证CPU和GPU可以并行工作的解决方法是：创建命令缓冲区（Command Buffer），CPU发布命令，GPU在完成上一次渲染任务之后会从中再取出命令并且执行，其中命令缓存区的命令有很多种，而DrawCall就是其中之一，其他命令有改变渲染方式、使用不同纹理等。由于GPU的多核性，因此GPU的执行速度很快，往往出现GPU执行完了命令缓冲区中的所有命令后等待CPU指示的情况。因此造成性能问题最主要的是CPU而非GPU。

（这里盗用别人一张图来解释）

图形引擎渲染画面的过程

Unity（或者说基本所有图形引擎）生成一帧画面的处理过程大致可以这样简化描述：

1. 可见性测试

     引擎首先经过简单的可见性测试，确定摄像机可以看到的物体

2. 准备好物体的数据

    然后把这些物体的顶点（包括本地位置、法线、UV等），索引（顶点如何组成三角形），变换（就是物体的位置、旋转、缩放、以及摄像机位置等），相关光源，纹理，渲染方式（由材质/Shader决定）等数据准备好

3. 通知图形API开始绘制

        然后通知图形API——或者就简单地看作是通知GPU——开始绘制，GPU基于这些数据，经过一系列运算，在屏幕上画出成千上万的三角形，最终构成一幅图像。

接下来我们的3个对象使用2个材质，A和B使用材质1，C使用材质2，这时候来看，应该是有2个DrawCall，或者3个DrawCall。应该是2个DrawCall啊，为什么会有3个DrawCall？？？而且是有时候2个，有时候3个。我们按照上面的DrawCall分析流程来分析一下：

1.渲染A，使用材质1 

2.渲染B，使用材质1 

3.渲染C，使用材质2

在这种情况下是2个DrawCall，在下面这种情况下，则是3个DrawCall

1.渲染A，使用材质1 

2.渲染C，使用材质2 

3.渲染B，使用材质1

因为我们没有控制好渲染顺序（或者说没有去特意控制），所以导致了额外的DrawCall，因为A和B不是一次性渲染完的，而是被C打断了，所以导致材质1被分为两次渲染

减少绘制的方式：

使用纹理图集（一张大贴图里包含了很多子贴图）来代替一系列单独的小贴图。它们可以更快地被加载，具有很少的状态转换，而且批处理更友好。

如果使用了纹理图集和共享材质，使用Renderer.sharedMaterial 来代替Renderer.material 。

使用光照纹理(lightmap)而非实时灯光。

使用LOD，好处就是对那些离得远，看不清的物体的细节可以忽略。

遮挡剔除（Occlusion culling）

使用mobile版的shader。因为简单。

2、三角形数量

    三角网格（Triangle Mesh），游戏开发者会使用三角形网格来建模。三角形是表面的分段线性逼近，如果用多条相连的线段分段逼近一个函数或曲线

从程序和性能的角度来看，面数是越少越好，少即意味着运算量变小，渲染速度会更快、耗电量都降低不少

为什么事三角形呢，请 参考文章：https://www.cnblogs.com/meteoric_cry/p/7929124.html

3、android内存主要有四种形式：VSS 、RSS 、PSS 、 USS

一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS

VSS：Virtual Set Size，虚拟耗用内存。它是一个进程能访问的所有内存空间地址的大小。这个大小包含了 

一些没有驻留在RAM中的内存，就像mallocs已经被分配，但还没有写入。VSS很少用来测量程序的实际使 

用内存。

RSS：Resident Set Size，实际使用物理内存。RSS是一个进程在RAM中实际持有的内存大小。RSS可能会 

产生误导，因为它包含了所有该进程使用的共享库所占用的内存，一个被加载到内存中的共享库可能有很 

多进程会使用它。RSS不是单个进程使用内存量的精确表示。

PSS：Proportional Set Size，实际使用的物理内存，它与RSS不同，它会按比例分配共享库所占用的内存。 

例如，如果有三个进程共享一个占30页内存控件的共享库，每个进程在计算PSS的时候，只会计算10页。 

PSS是一个非常有用的数值，如果系统中所有的进程的PSS相加，所得和即为系统占用内存的总和。当一个 

进程被杀死后，它所占用的共享库内存将会被其他仍然使用该共享库的进程所分担。在这种方式下，PSS 

也会带来误导，因为当一个进程被杀后，PSS并不代表系统回收的内存大小。

USS：Unique Set Size，进程独自占用的物理内存。这部分内存完全是该进程独享的。USS是一个非常有用 

的数值，因为它表明了运行一个特定进程所需的真正内存成本。当一个进程被杀死，USS就是所有系统回 

收的内存。USS是用来检查进程中是否有内存泄露的最好选择。

盗用别人的图一下，备注来源：https://www.cnblogs.com/JianXu/p/5685217.html

备注：手游在开发过程中可能会使用到共享库，所以个人觉得查看手游内存信息的时候使用pss作为内存指标比较合理