微网站做的比较好的,360建站平台,大连网络公司排名,php的网站怎么做的目录 1、客户端性能
1.1、客户端性能基础知识
2、客户端性能工具介绍与环境搭建
2.1.1、perfdog的使用
2.1.2、renderdoc的使用 1、客户端性能
1.1、客户端性能基础知识
客户端性能知识这里对2D和3D类游戏进行展开进行#xff0c;讲述的有内存、CPU、GPU、帧率这几个模块…目录 1、客户端性能
1.1、客户端性能基础知识
2、客户端性能工具介绍与环境搭建
2.1.1、perfdog的使用
2.1.2、renderdoc的使用 1、客户端性能
1.1、客户端性能基础知识
客户端性能知识这里对2D和3D类游戏进行展开进行讲述的有内存、CPU、GPU、帧率这几个模块内容。其中不管是2D还是3D类游戏都一定会包含有图片、字体、音频这些资源。2D类游戏主要的资源是图片所以对于渲染这块的内容核心在于CPU的draw call方面而3D类游戏包含的资源很多有模型、物理组件、光影效果、网格、shader、材质纹理等内容所以3D类游戏在渲染这块的内容核心包括CPU的draw call以及GPU的渲染计算方面。下面分别对影响内存、CPU、GPU性能方面进行讲解。
影响内存的因素
对于一款游戏基本的可以分为脚本和资源两部分而脚本通常会包括代码和导表数据。对于代码中没有及时回收的无用变量会占用了内存空间慢慢积累后也就是成了我们所说的内存泄漏。导表数据也是一个我们需要关注的点游戏里面有某些表格往往会比较大有的甚至达到几M的数据而在一个场景中可能要加载多个表格的数据这就需要将这些需要用到的表格都加载进入到内存当中但是实际上当前场景所有到的数据往往仅是数据表格的一小部分数据而已这就导致了有大量的表格数据在内存中是无用的但是又必须要加载进去。所以表格数据的优化也是一个比较重要的内容之一常规的表格优化策略有
通过功能数据放在独立的表格去除表格中未被使用的冗余字段对数据量大的表格进行分块处理使用中间文件做索引做到分块导表按需加载
而对于资源内容通用的资源有字体、音频、UI、纹理图片这通用资源里面其实已经包含了2D的了因为2D的资源也就是以上的这些内容。而3D的则还有网格、材质、着色器这些内容。下面针对这些影响因素逐个介绍。
字体一款游戏中使用到的字体往往有多种而一个字体小的有几兆大的甚至十几兆而游戏中加载字体都是全部加载进去且大部分是常驻内存的并且游戏在开发期时可能使用了多款字体但是实际上游戏中使用的没有么多导致字体在内存中占用了许多的内存。所以针对这点我这里也拿出来提及一下因为字体的加载大小几乎等同于字体实际的大小可以说是冗余的字体和多种字体既占包体量也占内存。
音频游戏音频也是会对内存造成一定的占用的这点也同样需要在性能测试过程需要考虑的。游戏里面常用的音频有ogg格式的mp3格式的wav格式的以及wwise音频引擎的使用bnk格式作为音频资源。对于游戏音频一种常规的优化策略是
对于长时间的音乐建议采用压缩格式的mp3对于短时间的音效建议采用非压缩给是wav
对于unity里面的音效设置刚开始的音源文件可能是1.4Mb如果采用的格式是加载时解压缩那么最后的音源在内存中的大小将高达10.2Mb。所以音源的加载策略也是一个很重要的影响因素。一般的加载方式有加载时解压缩、压缩内存、流式处理。这几种方式各有优缺点无非就是在速度与内存空间两个方面的取舍程度需要项目里面根据实际的需求选择合适自己项目的方式这里我就不给建议了。 UI游戏UI界面往往容易造成的性能问题是卡顿、界面打开慢等导致UI的过度绘制。在游戏中UI的销毁处理一般有三种情况一种是关闭UI后立即销毁不做任何的缓存一种是第一次打开UI后对UI先进行缓存处理关闭UI后不销毁UI下次打开速度快等到切换场景时才销毁第三种是关闭UI后不销毁UI直到内存达到预警值时再进行销毁对于我们测试来说需要了解UI在内存的处理方式后还需要关注该种模式下是否存在掉帧、卡顿的情况是否出现内存泄漏的情况。如果有那么我们需要定位出来是那些UI导致的掉帧、卡顿或者内存泄漏。常规的做法有
叫程序在客户端打印每个场景界面的UI列表log列出UI的 名字、尺寸、大小测试人员可以收集前后的UI数据定位出问题所在使用renderdoc查看某界面的资源加载情况确认哪个资源那一帧导致的掉帧、卡顿问题renderdoc的使用方法请参考renderdoc的使用使用prefdog等工具查看内存是否存在泄漏情况并确认是否是UI重复打开关闭导致的
纹理图片纹理对于内存的消耗是巨大的一个2048*2048的纹理采用32为颜色深度编码的话将消耗16M的内存一个1024*1024的纹理也需要消耗4M的内存大体计算方式大小*编码位数/8)即1024*1024*32/8)byte 1024*4kb 4Mb。 以上场景的纹理贴图中2048*2048规格的的图片占用内容会比较大这些纹理贴图需要美术优化。
需确认纹理在512*512、1024*1024、2048*2048几种大小以及在dds、tga两种格式下的内存占用情况目标如下 纹理的处理可以经过压缩不过压缩后效果可能不是很理想。一种做法是在原图的基础上将纹理的长宽分辨率比例放大一倍然后在保持原有的压缩格式这样压缩出来的结果还是要比原图要小一些。另外一种处理就是进行高低配分级处理先设置好分级针对中低档设备则进行纹理压缩针对高端档设备可以保持不压缩纹理。
3D类游戏的资源
网格需要能够确定出场景模型的网格占用情况对于unity3D类的模型中有些模型没有勾选【Rig】下的Optimize GameObject优化游戏对象选项这个选项可以把SceneManager中用于Skinning的节点都去掉从而节省场景节点树更新以及查询的CPU消耗。
与此同时网格文件Mesh里面会包含有大量的color数据normal数据tangent数据。这些数据也会对内存占用比较大。 材质贴图3D的材质贴图主要是纹理贴图纹理贴图中我们需要关注的有纹理格式纹理的尺寸、mipmap功能勾选了readwrite功能等。这些都会影响到游戏内存的。
对于纹理格式需要设备硬件支持不过目前为止基本大部分设备都支持了各种格式的纹理了不过可能还会遇到如下的两个问题 纹理的尺寸问题纹理的大小的计算和上面贴图所示的估算公式一致。
纹理的mipmap和readwrite功能可以在unity中的纹理属性中看到是否有勾选。一般情况下模型的mipmap建议勾选这对提高渲染效率尽管勾选后内存会增加1.33倍但是渲染效率大大提高还是值得的但是UI的纹理建议不要勾选了UI本身就渲染在屏幕上渲染提高不大反而会增加了内存然后readwrite选项建议不要勾选。 着色器shadershader作为能增强炫丽的渲染效果的脚本很多时候程序、TA为了增强效果加了好多shader这个可能会对内存有较大的开销。如下图是我自制的一个很小的单场景demo下shader所占用的内存空间就多大5.1Mb了。那在一款成型的3D类游戏中可能会有更多的shader内存了。 对于内存影响因素的内容这里就讲述上述的这几个当然还是有其他的影响因素但是相对没那么重要的核心的或者说常规的就是上面的这些因素如需了解其他的因素的话请自行去搜索学习下面讲CPU的性能影响因素。
影响CPU性能的因素
游戏中影响CPU性能除了本身游戏逻辑代码处理之外CPU对于渲染指令的处理也是影响其性能的主要原因之一。主要就是这两块影响的对于逻辑代码这块主要就是编程规范和算法设计的不合理导致CPU出现性能压力。同时CPU在对图形渲染这块的处理也是常常会出现性能瓶颈问题的。在渲染这块中draw call调用、Batches批次、UI调用、物理组件的处理以及GC调用都是比较影响CPU性能的所以这四块的内容优化会直接影响到CPU的性能。所以这里也主要针对这四块进行说明。
Draw call
Draw call是CPU对底层图形接口的调用是CPU提交数据 、指令、状态等内容给GPU的时候调用的但由于GPU的计算速度往往比CPU调用draw call的快如果CPU出现负载那么会造成卡顿掉帧。优化的做法就是对同类资源进行合批渲染静态资源看看能否进行合批从而较少draw call次数。一般建议的draw call在100以内。
Draw call可以的查看可以在unity的性能分析器里面看程序那边一般也都会在游戏中指令打印出来的也可以通过指令查看。 Batches批次是合批合批有静态合批与动态合批合批的目的是减少draw call的调用从而降低CPU的性能压力。静态合批是手动设置的1、通过设置游戏中需要合批的模型资源然后在游戏导出时在Player setting里面设置static batching这样设置后导出时unity就好帮我们合批了不过这样会增大包体大小但是会运行快一些2、在unity里面直接勾选static属性这样设置时物体是在加载过程才进行合批这样包体会更小但是运行会慢一些内存也会相应增大。动态合批是unity引擎自动帮我们合批的我们可以不用理会。不过动态合批有许多的限制
动态合批处理的物体顶点数量不超过900个包括shader里面的顶点设置如果GameObjects在Transform上包含镜像则不会对其进行动态合批处理使用不同的Material实例会导致GameObjects不能一起批处理即使它们基本相同带有光照贴图的GameObjects有额外的渲染器参数保存光照贴图的索引和偏移/缩放。一般来说动态光照贴图的GameObjects应指向完全相同的光照贴图位置才能被动态合批处理
静态合批有渲染上的优点但是也有缺点就是合批后在运行过程中会增加内存的消耗所以对于CPU与内存间的优化需要衡量两者间的短板所在择优而选而不能一昧的追求极端反而会影响到了其他方面的性能。 在Unity中的Frame Debugger也可以抓帧查看详细的渲染与合批过程在unity中因为有Batch的存在在一个Batch批次中可能会有出现合批了几十个甚至上百个Draw Call。也就是说Unity的Batch并不能实际减少Draw Call的数量但是合批次后性能会有较大的提升。原因是Batch合批次后尽管没有降低Draw Call的数量但是会将能够合批次的数据一次性提交了这样Draw Call里面的大头的数据被抽出来一次提交了剩余的Draw Call在CPU提交的时候带宽压力就会小很多。大致可以理解为假设一个Draw Call是一个1K大小的文件合批时将1千个1K大小文件里面90%大小的数据一次性提交了剩余的文件数量经过不变但是每个文件的数据量被抽减到了只剩下10%的数据也就是说处理器原本需要处理的1K大小的文件变成了只需要处理0.1K大小的数据压力自然就提升了。 UI调用也挺会增加CPU的负担的不合理的UI布局和调用会导致CPU过渡绘制和调用增加CPU性能压力。一般的优化策略有
同一个UI界面的图片尽量合到一张图集里面去减少draw call通用的图片放到一张共享图集里面去不同格式的图片放到不同的图集减少图片的尺寸合理使用UI层级在一个UI工程里面尽量不要使用复杂的UI结构动态UI与静态UI进行分离减少不必要的绘制透明UI要慎用可能会增加重绘
物理组件物理组件的大量使用也会增加CPU的计算压力对于物理组件的优化策略有
尽量不使用网格碰撞器选择使用合适的Fixed Timestep
这个设置在edit-项目设置-时间-固定的时间步进里面设置默认是0.02s也就是20ms。 GC调用尽管GC是用来处理优化内存的但是频繁的调用也是会增加CPU的逻辑处理开销因此对于CPU的优化那么减少GC的调用触发也是一个操作。
GC被触发的条件有
堆内存不足自动触发GC调用程序手动调用GC
问题一般会出现在程序手动频繁调用GC同时也是一些编程不够规范引发了垃圾数据是的系统堆内存过低而触发GC。
影响GPU性能的因素
对GPU性能的影响主要体现在渲染方面的压力导致的结果有游戏掉帧、耗电量过高等表现。我们可以大致了知道GPU的功能就是计算那么影响到GPU计算效率的无非就是两大方面一是面数过多像素计算复杂另一个是GPU显存带宽。
所以针对上面的这两点就可以有对应的优化策略。主要的优化策略有
减少顶点数量纹理图片尺寸不易过大使用LOD技术使用遮挡剔除使用合图图集大场景使用烘焙光影替代BPR光影移动端类游戏使用mobile版的shaderUI元素不使用mipmap设置合理使用mipmap
对于客户端性能的基础知识这里就可以讲这么多当然还有unity性能管线、Shader、纹理等方面的内容由于时间关系这里先不写了。
后面有空再写一篇关于如何定位、优化性能问题。
2、客户端性能工具介绍与环境搭建
2.1.1、perfdog的使用
腾讯旗下的perfdog可以用于检测客户端帧率、CPU甚至GPU等数据情况关于perfdog的使用请参考官网说明https://perfdog.qq.com/
这里可以讲一下关于perfdog的用例设计我给出几点总结
用例设计时尽量保持单一变量从而使得检测数据更具有说服力测试过程每个步骤尽量在ferfdog中的timeline时间轴上面的tag编写清除便于对比与定位问题收集录制的文件命名尽量用下划线拼接便于阅读如:小米6x_主线
2.1.2、renderdoc的使用
Renderdoc这个工具可以抓帧定位资源渲染加载过程的问题同时也可以找出被抓取的界面的的资源名字与大小用于定位一些资源、渲染速度、加载过程的性能问题。关于renderdoc的使用请参考附件
1.3客户端性能测试点
客户端性能的测试点不同项目功能不一样不过可以抛砖引玉的给出一些思路如下图所示给出一些常规的测试过程的几种情况。当然具体的用例设计还是要在围绕下面的几种情况的同时针对具体的功能进行细化。
