App性能测试点系列三渲染趋势等含义的介绍

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

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作为内存指标比较合理

你可能感兴趣的:(App性能测试点系列三渲染趋势等含义的介绍)