看了很多关于NGUI drawCall的文章，见得比较多的一个观点是：一个 Atlas 对应一个Drawcall。
好奇心下做了个demo，两个panel中只用到一个Atlas，却产生了10个drawCall，百思不得其解。寻觅已久终于找到三篇文章：
一、/forum/read.php?tid=14653
减少NGUI 3的DrawCall数量
刚升级到NGUI3， 这下不打紧，DrawCall数由5个增长到了十七八个，想想应该不会是NGUI的问题吧。后来整理了一下，发现有两点：&&& & & &1）对于同一Atlas，DrawCall数取决于Panel的数量（实际上是UIPanel这个脚本的数量）。比如说，我有两个Sprite，这两个Sprite属于同一Atlas，但是位于不同的Panel下，这时候DrawCall 数是2， NGUI 2中则是1。使用建议就是只使用一个Panel。&&& & & &2）对于不同Atlas，同一Panel下的Sprite，可通过Depth调节显示层级，Z值不管用，这点跟NGUI 2中刚好相反。还有就是不同Atlas的Sprite 的Depth值尽量不要来回穿插。比如Atlas A中有两个Sprite a 和 aa，Depth分别为1，3；Atlas B中有两个Sprite b 和 bb， Depth分别为2，4， 则DrawCall 总数为4而不是2。（在NGUI 3中，你可以点击Panel ，在Inspector面板中看到每一个DrawCall的调用细节 ）&&& & & &简单的说就是DrawCall的数量不只跟Atlas的数量有关，还跟Atlas调用顺序有关，使用的时候最好只用一个Panel， 不同Atlas的Sprite Depth尽量不穿插。
二、http://blog.csdn.net/monzart7an/article/details/
前置说明一：
Unity中的drawcall定义：
每次引擎准备数据并通知GPU的过程称为一次Draw Call。
Unity（或者说基本所有图形引擎）生成一帧画面的处理过程大致可以这样简化描述：引擎首先经过简单的可见性测试，确定摄像机可以看到的物体，然后把这些物体的顶点（包括本地位置、法线、UV等），（顶点如何组成三角形），变换（就是物体的位置、旋转、缩放、以及摄像机位置等），相关光源，纹理，渲染方式（由材质/Shader决定）等数据准备好，然后通知图形API&&或者就简单地看作是通知GPU&&开始绘制，GPU基于这些数据，经过一系列运算，在屏幕上画出成千上万的三角形，最终构成一幅图像。
前置说明二：
NGUI中的UIWidget(窗口小部件)的显示顺序：
每一个UIWidget的显示顺序由depth值决定，跟z轴没关系，而这个depth值是由两部分组成的，一个是UIWidget所在的UIPanel的depth和UIwidget自身的depth值进行加权计算。
并且，UIPanel的权重非常大，可以认为，UIPanel的depth大的所有UIWidget比UIPanel的depth小的所有UIWidget比最后计算的depth一定大。举个例子：
UIPanel1 & &depth &x & & & & & & & & & & &UIPanel2 & &depth &y
UIWidget1 &depth &m & & & & & & & & & & &UIWidget2 &depth &n
只要 x & y，那么不管m和n的大小，UIWidget1最后的depth一定大于UIWidget2。
减少drawcall的规则：
1、同一个UIPanel下的texture（图，纹理，材质）和font（字体）尽量放在同一个altals下。也表达了另外一个意思，使用同一个altals（图集）的元素尽量放在同一个UIPanel下面。
2、如果一个UIPanel下面使用了多个altals，那么尽量让使用相同altals的元素连续，尽量避免altals交叉。
规则1的前半部分好理解。后半部分，参照前面显示顺序问题可以知道。如果使用同一个altals的元素在两个不同的UIPanel下面，这就必然导致它们的drawcall分离。所以即使调整它们的depth一致，也无法合并成一个drawcall.
规则2的意思，举个例子就明白了：
同一个UIPanel下有4个UIWidget，w1，w2，w3，w4。
其中 W1和W2引用altals1。
其中 W3和W4引用altals2。
如果它们的depth顺序为 &w1 : 1，w2 ：2，w3 : 3，w4 : 4。
那么整个渲染需要2个drawcall，因为渲染顺序为&w1，w2，w3，w4。
而w1和w2公用一个altals，所以可以合并成一个drawcall，同理w3和w4可以合并成一个drawcall。
而如果它们的depth顺序为：&w1 : 1，w2 ：3，w3 : 2，w4 : 4。
那么整个渲染需要4个drawcall，因为渲染顺序为&w1，w3，w2，w4。
因为w1和w3不是公用一个altals，所以只能分开渲染。同理w3和w2，w2和w4也只能分开渲染。
三、/thread--1.html
楼主自学Unity不久，有纰漏的地方请大神指正。正文如下：
NGUI为了减少GPU状态切换的消耗（比如切换material），把相同material的widget合并，减少DrawCall的数量。下文描述了NGUI如何对widget归类，以及减少DrawCall需要注意的地方。
归类widget的代码在UIPanel中的FillAllDrawCalls()里，代码如下
void FillAllDrawCalls &&&& ()
& & & &&&& & {
& & & &&&& & & & & & for (int i = 0; i & drawCalls. &&&& ++i)
& & & &&&& & & & & & & & & & &&&& UIDrawCall.Destroy(drawCalls.buffer[i]);
& & & &&&& & & & & & drawCalls.Clear();
& & & &&&& & & & & & Material mat =
& & & &&&& & & & & & Texture tex =
& & & &&&& & & & & & Shader sdr =
& & & &&&& & & & & & UIDrawCall dc =
& & & &&&& & & & & & if (mSortWidgets) SortWidgets();
& & & &&&& & & & & & for (int i = 0; i & widgets. &&&& ++i)
& & & &&&& & & & & & {
& & & &&&& & & & & & & & & & UIWidget w &&&& = widgets.buffer[i];
& & & &&&& & & & & & & & & & if &&&& (w.isVisible && w.hasVertices)
& & & &&&& & & & & & & & & & {
& & & &&&& & & & & & & & & & & &&&& & & & Material mt = w.
& & & &&&& & & & & & & & & & & &&&& & & & Texture tx = w.mainT
& & & &&&& & & & & & & & & & & &&&& & & & Shader sd = w.
& & & &&&& & & & & & & & & & & &&&& & & & if (mat != mt || tex != tx || sdr != sd)
& & & &&&& & & & & & & & & & & &&&& & & & {
& & & &&&& & & & & & & & & & & &&&& & & & & & & & if (mVerts.size != 0)
& & & &&&& & & & & & & & & & & &&&& & & & & & & & {
& & & &&&& & & & & & & & & & & &&&& & & & & & & & & & & &&&& & SubmitDrawCall(dc);
& & & &&&& & & & & & & & & & & &&&& & & & & & & & & & & &&&& & dc =
& & & &&&& & & & & & & & & & & &&&& & & & & & & & }
& & & &&&& & & & & & & & & & & &&&& & & & & & & & mat =
& & & &&&& & & & & & & & & & & &&&& & & & & & & & tex =
& & & &&&& & & & & & & & & & & &&&& & & & & & & & sdr =
& & & &&&& & & & & & & & & & & &&&& & & & }
& & & &&&& & & & & & & & & & & &&&& & & & if (mat != null || sdr != null || tex != null)
& & & &&&& & & & & & & & & & & &&&& & & & {
& & & &&&& & & & & & & & & & & &&&& & & & & & & & if (dc == null)
& & & &&&& & & & & & & & & & & &&&& & & & & & & & {
& & & &&&& & & & & & & & & & & &&&& & & & & & & & & & & &&&& & dc = UIDrawCall.Create(this, mat, tex, sdr);
& & & &&&& & & & & & & & & & & &&&& & & & & & & & & & & &&&& & dc.depthStart = w.
& & & &&&& & & & & & & & & & & &&&& & & & & & & & & & & &&&& & dc.depthEnd = dc.depthS
& & & &&&& & & & & & & & & & & &&&& & & & & & & & & & & &&&& & dc.panel =
& & & &&&& & & & & & & & & & & &&&& & & & & & & & }
& & & &&&& & & & & & & & & & & &&&& & & & & & & & else
& & & &&&& & & & & & & & & & & &&&& & & & & & & & {
& & & &&&& & & & & & & & & & & &&&& & & & & & & & & & & &&&& & int rd = w.
& & & &&&& & & & & & & & & & & &&&& & & & & & & & & & & &&&& & if (rd & dc.depthStart) dc.depthStart =
& & & &&&& & & & & & & & & & & &&&& & & & & & & & & & & &&&& & if (rd & dc.depthEnd) dc.depthEnd =
& & & &&&& & & & & & & & & & & &&&& & & & & & & & }
& & & &&&& & & & & & & & & & & &&&& & & & & & & & w.drawCall =
& & & &&&& & & & & & & & & & & &&&& & & & & & & & if (generateNormals) &&&& w.WriteToBuffers(mVerts, mUvs, mCols, mNorms, mTans);
& & & &&&& & & & & & & & & & & &&&& & & & & & & & else &&&& w.WriteToBuffers(mVerts, mUvs, mCols, null, null);
& & & &&&& & & & & & & & & & & &&&& & & & }
& & & &&&& & & & & & & & & & }
& & & &&&& & & & & & & & & & else &&&& w.drawCall =
& & & &&&& & & & & & }
& & & &&&& & & & & & if (mVerts.size != 0) &&&& SubmitDrawCall(dc);
& & & &&&& & }
算法描述如下
先把UIPanel中的Widget按depth从小到大排序，如果depth相同那按照material的ID来排序。然后遍历每个元素，把material相同的Widget归类到同一个drawCall。合并之后的结果如下图
最后生成了3个DrawCall，并按顺序提交GPU绘制。
为何要采用这个算法呢？因为NGUI的Material是透明材质，不会写入深度缓存（但是会进行深度测试，以保证与非透明物体的层次正确），我们可以看NGUI材质所使用的Unlit/Transparent Colored这个Shader，里面有一句ZWrite Off。所以widget的前后关系与z坐标是没有关系的，而是与DrawCall的绘制顺序有关。所以如果要按照上图的depth来显示widget，必然只能分成3个DrawCall，并且按顺序绘制。
Unity（或者说基本所有图形引擎）生成一帧画面的处理过程大致可以这样简化描述：引擎首先经过简单的可见性测试，确定摄像机可以看到的物体，然后把这些物体的顶点（包括本地位置、法线、UV等），索引（顶点如何组成三角形），变换（就是物体的位置、旋转、缩放、以及摄像机位置等），相关光源，纹理，渲染方式（由材质/Shader决定）等数据准备好，然后通知图形API&&或者就简单地看作是通知GPU&&开始绘制，GPU基于这些数据，经过一系列运算，在屏幕上画出成千上万的三角形，最终构成一幅图像。
在Unity中，每次引擎准备数据并通知GPU的过程称为一次Draw Call。这一过程是逐个物体进行的，对于每个物体，不只GPU的渲染，引擎重新设置材质/Shader也是一项非常耗时的操作。因此每帧的Draw Call次数是一项非常重要的性能指标，对于iOS来说应尽量控制在20次以内，这个值可以在编辑器的Statistic窗口看到。
Unity内置了技术，从名字就可以看出，它的主要目标就是在一次Draw Call中批量处理多个物体。只要物体的变换和材质相同，GPU就可以按完全相同的方式进行处理，即可以把它们放在一个Draw Call中。Draw Call Batching技术的核心就是在可见性测试之后，检查所有要绘制的物体的材质，把相同材质的分为一组（一个Batch），然后把它们组合成一个物体（统一变换），这样就可以在一个Draw Call中处理多个物体了（实际上是组合后的一个物体）。
但Draw Call Batching存在一个缺陷，就是它需要把一个Batch中的所有物体组合到一起，相当于创建了一个与这些物体加起来一样大的物体，与此同时就需要分配相应大小的内存。这不仅会消耗更多内存，还需要消耗CPU时间。特别是对于移动的物体，每一帧都得重新进行组合，这就需要进行一些权衡，否则得不偿失。但对于静止不动的物体来说，只需要进行一次组合，之后就可以一直使用，效率要高得多。
Unity提供了Dynamic Batching和Static Batching两种方式。Dynamic Batching是完全自动进行的，不需要也无法进行任何干预，对于顶点数在300以内的可移动物体，只要使用相同的材质，就会组成Batch。Static Batching则需要把静止的物体标记为Static，然后无论大小，都会组成Batch。如前文所说，Static Batching显然比Dynamic Batching要高效得多，于是，Static Batching功能是收费的&&
要有效利用Draw Call Batching，首先是尽量减少场景中使用的材质数量，即尽量共享材质，对于仅纹理不同的材质可以把纹理组合到一张更大的纹理中（称为Texture Atlasing）。然后是把不会移动的物体标记为Static。此外还可以通过CombineChildren脚本（Standard Assets/Scripts/Unity Scripts/CombineChildren）手动把物体组合在一起，但这个脚本会影响可见性测试，因为组合在一起的物体始终会被看作一个物体，从而会增加GPU要处理的几何体数量，因此要小心使用。
对于复杂的静态场景，还可以考虑自行设计遮挡剔除算法，减少可见的物体数量同时也可以减少Draw Call。
总之，理解Draw Call和Draw Call Batching原理，根据场景特点设计相应的方案来尽量减少Draw Call次数才是王道，其它方面亦然。
在最近，使用U3D开发的游戏核心部分功能即将完成，中间由于各种历史原因，导致项目存在比较大的问题，这些问题在最后，恐怕只能通过一次彻底的重构来解决
现在的游戏跑起来会有接近130-170个左右的DrawCall，游戏运行起来明显感觉到卡，而经过一天的优化，DrawCall成功缩减到30-70个，这个效果是非常显著的，并且这个优化并没有通过将现有的资源打包图集来实现，图集都是原有的图集，如果从全局的角度对图集再进行一次优化，那么DrawCall还可以再减少十几个
本次优化的重点包括：层级关系和特效
对于U3D，我是一个菜鸟，对于U3D的一些东西是一知半解，例如DrawCall，我得到的是一些并不完全正确的信息，例如将N个纹理打包成一个图集，这个图集就只会产生一个DrawCall，如果不打成图集，那么就会有N个DrawCall，这个观点在很多人的认识里都是正确的，因为可以通过简单的操作来验证，但严格来说，这个观点是错误的，因为它还受层级关系影响！
U3D的渲染是有顺序的，U3D的渲染顺序是由我们控制的，控制好U3D的渲染顺序，你才能控制好DrawCall
一个DrawCall，表示U3D使用这个材质/纹理，来进行一次渲染，那么这次渲染假设有3个对象，那么当3个对象都使用这一个材质/纹理的时候，就会产生一次DrawCall，可以理解为一次将纹理输送到屏幕上的过程，（实际上引擎大多会使用如双缓冲，缓存这类的手段来优化这个过程，但在这里我们只需要这样子认识就可以了），假设3个对象使用不同的材质/纹理，那么无疑会产生3个DrawCall
接下来我们的3个对象使用2个材质，A和B使用材质1，C使用材质2，这时候来看，应该是有2个DrawCall，或者3个DrawCall。应该是2个DrawCall啊，为什么会有3个DrawCall？？？而且是有时候2个，有时候3个。我们按照上面的DrawCall分析流程来分析一下：
1.渲染A，使用材质12.渲染B，使用材质13.渲染C，使用材质2
在这种情况下是2个DrawCall，在下面这种情况下，则是3个DrawCall
1.渲染A，使用材质12.渲染C，使用材质23.渲染B，使用材质1
因为我们没有控制好渲染顺序（或者说没有去特意控制），所以导致了额外的DrawCall，因为A和B不是一次性渲染完的，而是被C打断了，所以导致材质1被分为两次渲染
那么是什么在控制这个渲染顺序呢？首先在多个相机的情况下，U3D会根据相机的深度顺序进行渲染，在每个相机中，它会根据你距离相机的距离，由远到近进行渲染，在UI相机中，还会根据你UI对象的深度进行渲染
那么我们要做的就是，对要渲染的对象进行一次规划，正确地排列好它们，规则是，按照Z轴或者深度，对空间进行划分，然后确定好每个对象的Z轴和深度，让使用同一个材质的东西，尽量保持在这个空间内，不要让其他材质的对象进入这个空间，否则就会打断这个空间的渲染顺序
在这个基础上，更细的规则有：
场景中的东西，我们使用Z轴来进行空间的划分，例如背景层，特效层1，人物层，特效层2
NGUI中的东西，我们统一使用Depth来进行空间的划分
人物模型，当人物模型只是用一个材质，DrawCall只有1，但是用了2个以上的材质，DrawCall就会暴增（或许对材质的RenderQueue进行规划也可以使DrawCall只有2个，但这个要拆分好才行），3D人物处于复杂3D场景中的时候，我们的空间规则难免被破坏，这只能在设计的时候尽量去避免这种情况了
使用了多个材质的特效，在动画的过程中，往往会引起DrawCall的波动，在视觉效果可以接受的范围内，可以将特效也进行空间划分，假设这个特效是2D显示，那么可以使用Z轴来划分空间
每个材质/纹理的渲染一定是会产生DrawCall的，这个DrawCall只能通过打包图集来进行优化
制作图集一般遵循几个规则：
从功能角度进行划分，例如UI可以划分为公共部分，以及每个具体的界面，功能上，显示上密切相关的图片打包到一起
不要一股脑把所有东西打包到一个图集里，特别是那些不可能同时出现的东西，它们就不应该在一个图集里，这样的图集意义不大，减少不了DrawCall，并且一个你不需要显示的图片，会一直占用你的内存，这让我非常不爽
注意控制图集的大小，不要让图集太大，一个超级大图集的DrawCall消耗或许顶的上十几个小图集的消耗
字符图集，在使用BMFont或者其他工具生成图片字的时候，我们往往是直接导入一大串文字，然后直接生成图片，但实际上这上面的操作也有优化空间，例如BMFont生成的图片大小，是可以设置的，有两个规则，一个规则是导出的图片尽量小，另一个是导出的图片尽量少，默认的大小应该是512x512，假设你生成的图片256x256就可以容纳，那么多做一个操作你可以节省这么多空间，另外当你输入多几个字，就导致增加一张图片时，例如1024变成2048，那么你可以考虑使用3张512的图片，这样也会节省空间
经过精心划分的图集在加上精心规划的渲染顺序，DrawCall会有一个质的优化
U3D提供了非常便捷的方法让我们很轻易地使用美术给过来的特效，懒惰的U3D程序猿会直接放入U3D，甚至不去看这是个什么特效，我们的特效一般都是一瞬间的事情，例如技能特效，或者其他什么特效，那么特效播放完，这个特效我们就看不到了，但假设这个特效在播放结束的时候，没有将自身的Active属性设置为false，那么它就会继续占用你的DrawCall，消耗你设备的计算能力，所以程序需要保证当一个特效播放完之后，能够被消耗，或者设置为非激活的状态，可以使用一些公共方法来完成特效播放完之后的清理工作（自己实现2个静态函数，一个播放完销毁，一个播放完设置未激活）
阅读(...) 评论()unity 怎么看drawcall_百度知道如何降低Unity程序的Drawcall_百度知道Unity在5.4 Beta版本中引入了一种新的Draw Call Batching方式——GPU Instancing。当场景中有大量使用相同材质和网格的物体时，通过GPU Instancing可以大幅降低Draw Call数量。本文将由Unity官方开发工程师蔡元星，为大家简单介绍GPU Instancing的原理并引导读者修改已有的Shader来开启Instancing。
什么是GPU InstancingGPU Instancing是指由GPU和图形API支持的，用一个Draw Call同时绘制多个Geometry相同的物体的技术。
上图中的场景有数千块陨石，但只有三种陨石模型，这种情况下使用Instancing之后只需要数十个Draw Call。&在D3D11中，Instanced Draw Call API如下所示：
注意前两个参数：IndexCountPerInstance和InstanceCount，这是不同于一般Draw Call API的地方。你需要告诉D3D每个Instance用到多少个顶点索引以及这个Draw Call要画多少个Instances。&那么如何做到像上图中那样每块石头都有不同的位置、旋转和大小呢？在使用Instancing时，我们一般会把世界矩阵这种每个Instance独有的数据放到一个额外的Buffer中以供Shader访问，可以是第二个Vertex
Buffer，也可以是Constant Buffer。
Instancing的应用场景Instancing并不是总能提高性能，所以有必要明白Instancing技术可以做什么、不能做什么。&
Instancing能做什么：
通过减少Draw Call数量来降低CPU开销。
Instancing不能做什么：
减少GPU的负载。实际上，Instancing还会在GPU上带来一些额外的开销。
&具体来说，如果你的场景具备以下条件，使用Instancing可能会给你带来性能提升：
有大量使用相同材质和相同网格的物体
性能受制于过多的Draw Call (图形驱动在CPU上负载过大)
&在实际的游戏项目中，最合适使用Instancing来优化的是植被系统。因为通常植被系统需要绘制大量相同的树木和草，使用Instancing之后Draw Call的消耗会大幅降低。
在Unity 5.4中使用Instancing在Unity 5.4中使用Instancing需要注意：
类似于Static / Dynamic Batching，Instancing是一种新的合并Draw Call的方式
适用于MeshRenderer组件和Graphics.DrawMesh()
需要使用相同的Material和Mesh
需要把Shader改成Instanced的版本
当所有前提条件都满足时，Instancing是自动进行的，并且比Static/Dynamic Batching有更高的优先级
Instancing的实现
Instancing的实现步骤如下：
将Per-Instance Data（世界矩阵、颜色等自定义属性）打包成Uniform Array，存储在Instance Constant Buffers中
对于可以使用Instancing的Batch，调用各平台图形API的Instanced Draw Call，这样会为每一个Instance生成一个不同的SV_InstanceID
在Shader中使用SV_InstanceID作为Uniform Array的索引获取当前Instance的Per-Instance Data
如何修改Shader以支持Instancing1自定义Vertex /
Fragment Shader 下面的代码片段展示了如何把一个简单的Unlit Shader修改为支持Instancing的版本。红色字体的部分是在已有Shader基础上需要添加或修改的地方。
下面我们来逐一解释每一处的修改是什么意思。&#pragma multi_compile_instancing
“multi_compile_instancing”会使你的Shader生成两个Variant，其中一个定义了Shader关键字INSTANCING_ON，另外一个没有定义此关键字。&除了这个#pragma指令，下面所列其他的修改都是使用了在UnityInstancing.cginc里定义的宏（此cginc文件位于Unity_Install_Dir\Editor\Data\CGIncludes）。取决于关键字INSTANCING_ON是否被定义，这些宏将展开为不同的代码。&UNITY_INSTANCE_ID
用于在Vertex Shader输入 / 输出结构中定义一个语义为SV_InstanceID的元素。&UNITY_INSTANCING_CBUFFER_START(name) / UNITY_INSTANCING_CBUFFER_END
每个Instance独有的属性必须定义在一个遵循特殊命名规则的Constant Buffer中。使用这对宏来定义这些Constant Buffer。“name”参数可以是任意字符串。&UNITY_DEFINE_INSTANCED_PROP(float4, _Color)
定义一个具有特定类型和名字的每个Instance独有的Shader属性。这个宏实际会定义一个Uniform数组。&UNITY_SETUP_INSTANCE_ID(v)
这个宏必须在Vertex Shader的最开始调用，如果你需要在Fragment Shader里访问Instanced属性，则需要在Fragment Shader的开始也用一下。这个宏的目的在于让Instance ID在Shader函数里也能够被访问到。&UNITY_TRANSFER_INSTANCE_ID(v,
在Vertex Shader中把Instance ID从输入结构拷贝至输出结构中。只有当你需要在Fragment Shader中访问每个Instance独有的属性时才需要写这个宏。&UNITY_ACCESS_INSTANCED_PROP(_Color)
访问每个Instance独有的属性。这个宏会使用Instance ID作为索引到Uniform数组中去取当前Instance对应的数据。&最后我们需要提一下UnityObjectToClipPos：
在写Instanced Shader时，通常情况下你并不用在意顶点空间转换，因为所有内建的矩阵名字在Instanced Shader中都是被重定义过的。比如unity_ObjectToWorld实际上会变成unity_ObjectToWorldArray[unity_InstanceID]；UNITY_MATRIX_MVP会变成mul(UNITY_MATRIX_VP, unity_ObjectToWorldArray[unity_InstanceID])。注意到如果直接使用UNITY_MATRIX_MVP，我们会引入一个额外的矩阵乘法运算，所以推荐使用UnityObjectToClipPos
/ UnityObjectToViewPos函数，它们会把这一次额外的矩阵乘法优化为向量-矩阵乘法。&2Surface
Shader 如果想把一个Surface Shader改写成支持Instancing的版本，你只需要加上“#pragma multi_compile_instancing” 就可以了。设置Instance ID的代码会自动生成。定义或访问每个Instance独有属性的方法同Custom Vertex / Fragment Shader。&另外，你可以在Project窗口右键单击，选择Create-&Shader-&Standard
Surface Shader (Instanced)来创建一个示例Shader。
使用Instancing的限制下列情况不能使用Instancing：
使用Lightmap的物体
受不同Light Probe / Reflection Probe影响的物体
使用包含多个Pass的Shader的物体，只有第一个Pass可以Instancing
前向渲染时，受多个光源影响的物体只有Base Pass可以instancing，Add Passes不行
另外，由于Constant Buffer的尺寸限制，一个Instanced Draw Call能画的物体数量是有上限的（参见UnityInstancing.cginc中的UNITY_MAX_INSTANCE_COUNT）
最后需要再次强调的是，Instancing在Shader上有额外的开销，并不是总能提高帧率。永远要以实际Profiling的结果为准！
摘自：http://mp./s?__biz=MjM5NjE1MTkwMg==&mid=&idx=1&sn=f47686dba250bdf708c2e1d0b1ac8162&scene=23&srcid=0513pnXKHTE7zvzfeTV31cUo#rd
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：300次
排名：千里之外draw call是openGL的描绘次数（directX没怎么研究，但原理应该差不多）一个简单的openGL的绘图次序是：设置颜色&绘图方式&顶点座标&绘制&结束。每帧都会重复以上的步骤。这就是一次draw call如果有两个model，那么需要&&设置颜色&绘图方式&顶点座标A&绘制&结束。设置颜色&绘图方式&顶点座标B&绘制&结束。两次也就是说在openGl绘制前，如果色彩通道(color filter)，绘图方式(shader)，顶点座标（model）不同的情况下draw calls就会增加。对openGl来说绘制参数（状态值）的变更要比绘制大量的顶点更耗费cpu。所谓高速绘图就是，在尽量不改变openGl状态值的情况下，用一次draw call完成所有绘制。比如上面的例子：设置颜色&绘图方式&顶点座标A＋顶点座标B&绘制&结束。就要更加有效率。个人估计unity3d的dynamic batch,static batch都是通过一定的方法使不同的object的顶点座标能够结合成一个整体，达到减少draw calls的效果。但是有一定的要求限制，比如material要相同，mesh要相同并在300个面以内等等，这些都是为了保证openGl的状态值不改变。
Unity在 Player Setting 里的两个功能选项 Static Batching 与 Dynamic Batching。功能描述如下：
Static Batching 是将标明为 Static 的静态物件，如果在使用相同材质球的条件下，Unity 会自动帮你把这两个物件合并成一个 Batch，送往 GPU 来处理。这功能对效能上非常的有帮助，所以是需要付费才有的。
Dynamic Batching 是在物件小于300面的条件下(不论物件是否为静态或动态)，在使用相同材质球下，Unity就会自动帮你合合并成一个 Batch 送往 GPU 来处理。
在屏幕上渲染物体，引擎需要发出一个绘制调用来访问图形API（iOS系统中为OpenGL ES）。每个绘制调用需要进行大量的工作来访问图形API，从而导致了CPU方面显著的性能开销。
Unity在运行时可以将一些物体进行合并，从而用一个绘制调用来渲染他们。这一操作，我们称之为&批处理&。一般来说，Unity批处理的物体越多，你就会得到越好的渲染性能。
Unity中内建的批处理机制所达到的效果要明显强于使用几何建模工具（或使用Standard Assets包中的CombineChildren脚本）的批处理效果。这是因为，Unity引擎的批处理操作是在物体的可视裁剪操作之后进行的。Unity先对每个物体进行裁剪，然后再进行批处理，这样可以使渲染的几何总量在批处理前后保持不变。但是，使用几何建模工具来拼合物体，会妨碍引擎对其进行有效的裁剪操作，从而导致引擎需要渲染更多的几何面片。
只有拥有相同材质的物体才可以进行批处理。因此，如果你想要得到良好的批处理效果，你需要在程序中尽可能地复用材质和物体。
如果你的两个材质仅仅是纹理不同，那么你可以通过 纹理拼合 操作来将这两张纹理拼合成一张大的纹理。一旦纹理拼合在一起，你就可以使用这个单一材质来替代之前的两个材质了。
如果你需要通过脚本来访问复用材质属性，那么值得注意的是改变Renderer.material将会造成一份材质的拷贝。因此，你应该使用Renderer.sharedMaterial来保证材质的共享状态。
动态批处理
如果动态物体共用着相同的材质，那么Unity会自动对这些物体进行批处理。
动态批处理操作是自动完成的，并不需要你进行额外的操作。
1、 批处理动态物体需要在每个顶点上进行一定的开销，所以动态批处理仅支持小于900顶点的网格物体。
2、 如果你的着色器使用顶点位置，法线和UV值三种属性，那么你只能批处理300顶点以下的物体；如果你的着色器需要使用顶点位置，法线，UV0，UV1和切向量，那你只能批处理180顶点以下的物体。
3、请注意：属性数量的限制可能会在将来进行改变。
4、 不要使用缩放尺度（scale）。分别拥有缩放尺度(1,1,1)和(2,2,2)的两个物体将不会进行批处理。
5、 统一缩放尺度的物体不会与非统一缩放尺度的物体进行批处理。
使用缩放尺度(1,1,1)和 (1,2,1)的两个物体将不会进行批处理，但是使用缩放尺度(1,2,1)和(1,3,1)的两个物体将可以进行批处理。
6、 使用不同材质的实例化物体（instance）将会导致批处理失败。
7、拥有lightmap的物体含有额外（隐藏）的材质属性，比如：lightmap的偏移和缩放系数等。所以，拥有lightmap的物体将不会进行批处理（除非他们指向lightmap的同一部分）。
8、 多通道的shader会妨碍批处理操作。比如，几乎unity中所有的着色器在前向渲染中都支持多个光源，并为它们有效地开辟多个通道。
9、预设体的实例会自动地使用相同的网格模型和材质。
静态批处理
相对而言，静态批处理操作允许引擎对任意大小的几何物体进行批处理操作来降低绘制调用（只要这些物体不移动，并且拥有相同的材质）。因此，静态批处理比动态批处理更加有效，你应该尽量低使用它，因为它需要更少的CPU开销。
为了更好地使用静态批处理，你需要明确指出哪些物体是静止的，并且在游戏中永远不会移动、旋转和缩放。想完成这一步，你只需要在检测器（Inspector）中将Static复选框打勾即可，如下图所示：
使用静态批处理操作需要额外的内存开销来储存合并后的几何数据。在静态批处理之前，如果一些物体共用了同样的几何数据，那么引擎会在编辑以及运行状态对每个物体创建一个几何数据的备份。这并不总是一个好的想法，因为有时候，你将不得不牺牲一点渲染性能来防止一些物体的静态批处理，从而保持较少的内存开销。比如，将浓密森里中树设为Static，会导致严重的内存开销。
静态批处理目前只支持Unity iOS Advanced。
nity（或者说基本所有图形引擎）生成一帧画面的处理过程大致可以这样简化描述：引擎首先经过简单的可见性测试，确定摄像机可以看到的物体，然后把这些物体的顶点（包括本地位置、法线、UV等），索引（顶点如何组成三角形），变换（就是物体的位置、旋转、缩放、以及摄像机位置等），相关光源，纹理，渲染方式（由材质/Shader决定）等数据准备好，然后通知图形API&&或者就简单地看作是通知GPU&&开始绘制，GPU基于这些数据，经过一系列运算，在屏幕上画出成千上万的三角形，最终构成一幅图像。
在Unity中，每次引擎准备数据并通知GPU的过程称为一次Draw Call。这一过程是逐个物体进行的，对于每个物体，不只GPU的渲染，引擎重新设置材质/Shader也是一项非常耗时的操作。因此每帧的Draw Call次数是一项非常重要的性能指标，对于iOS来说应尽量控制在20次以内，这个值可以在编辑器的Statistic窗口看到。
Unity内置了技术，从名字就可以看出，它的主要目标就是在一次Draw Call中批量处理多个物体。只要物体的变换和材质相同，GPU就可以按完全相同的方式进行处理，即可以把它们放在一个Draw Call中。Draw Call Batching技术的核心就是在可见性测试之后，检查所有要绘制的物体的材质，把相同材质的分为一组（一个Batch），然后把它们组合成一个物体（统一变换），这样就可以在一个Draw Call中处理多个物体了（实际上是组合后的一个物体）。
但Draw Call Batching存在一个缺陷，就是它需要把一个Batch中的所有物体组合到一起，相当于创建了一个与这些物体加起来一样大的物体，与此同时就需要分配相应大小的内存。这不仅会消耗更多内存，还需要消耗CPU时间。特别是对于移动的物体，每一帧都得重新进行组合，这就需要进行一些权衡，否则得不偿失。但对于静止不动的物体来说，只需要进行一次组合，之后就可以一直使用，效率要高得多。
Unity提供了Dynamic Batching和Static Batching两种方式。Dynamic Batching是完全自动进行的，不需要也无法进行任何干预，对于顶点数在300以内的可移动物体，只要使用相同的材质，就会组成Batch。Static Batching则需要把静止的物体标记为Static，然后无论大小，都会组成Batch。如前文所说，Static Batching显然比Dynamic Batching要高效得多，于是，Static Batching功能是收费的&&
要有效利用Draw Call Batching，首先是尽量减少场景中使用的材质数量，即尽量共享材质，对于仅纹理不同的材质可以把纹理组合到一张更大的纹理中（称为Texture Atlasing）。然后是把不会移动的物体标记为Static。此外还可以通过CombineChildren脚本（Standard Assets/Scripts/Unity Scripts/CombineChildren）手动把物体组合在一起，但这个脚本会影响可见性测试，因为组合在一起的物体始终会被看作一个物体，从而会增加GPU要处理的几何体数量，因此要小心使用。
对于复杂的静态场景，还可以考虑自行设计遮挡剔除算法，减少可见的物体数量同时也可以减少Draw Call。
总之，理解Draw Call和Draw Call Batching原理，根据场景特点设计相应的方案来尽量减少Draw Call次数才是王道，其它方面亦然。
/ybgame/p/3588795.html
在最近，使用U3D开发的游戏核心部分功能即将完成，中间由于各种历史原因，导致项目存在比较大的问题，这些问题在最后，恐怕只能通过一次彻底的重构来解决
现在的游戏跑起来会有接近130-170个左右的DrawCall，游戏运行起来明显感觉到卡，而经过一天的优化，DrawCall成功缩减到30-70个，这个效果是非常显著的，并且这个优化并没有通过将现有的资源打包图集来实现，图集都是原有的图集，如果从全局的角度对图集再进行一次优化，那么DrawCall还可以再减少十几个
本次优化的重点包括：层级关系和特效
对于U3D，我是一个菜鸟，对于U3D的一些东西是一知半解，例如DrawCall，我得到的是一些并不完全正确的信息，例如将N个纹理打包成一个图集，这个图集就只会产生一个DrawCall，如果不打成图集，那么就会有N个DrawCall，这个观点在很多人的认识里都是正确的，因为可以通过简单的操作来验证，但严格来说，这个观点是错误的，因为它还受层级关系影响！
U3D的渲染是有顺序的，U3D的渲染顺序是由我们控制的，控制好U3D的渲染顺序，你才能控制好DrawCall
一个DrawCall，表示U3D使用这个材质/纹理，来进行一次渲染，那么这次渲染假设有3个对象，那么当3个对象都使用这一个材质/纹理的时候，就会产生一次DrawCall，可以理解为一次将纹理输送到屏幕上的过程，（实际上引擎大多会使用如双缓冲，缓存这类的手段来优化这个过程，但在这里我们只需要这样子认识就可以了），假设3个对象使用不同的材质/纹理，那么无疑会产生3个DrawCall
接下来我们的3个对象使用2个材质，A和B使用材质1，C使用材质2，这时候来看，应该是有2个DrawCall，或者3个DrawCall。应该是2个DrawCall啊，为什么会有3个DrawCall？？？而且是有时候2个，有时候3个。我们按照上面的DrawCall分析流程来分析一下：
1.渲染A，使用材质12.渲染B，使用材质13.渲染C，使用材质2
在这种情况下是2个DrawCall，在下面这种情况下，则是3个DrawCall
1.渲染A，使用材质12.渲染C，使用材质23.渲染B，使用材质1
因为我们没有控制好渲染顺序（或者说没有去特意控制），所以导致了额外的DrawCall，因为A和B不是一次性渲染完的，而是被C打断了，所以导致材质1被分为两次渲染
那么是什么在控制这个渲染顺序呢？首先在多个相机的情况下，U3D会根据相机的深度顺序进行渲染，在每个相机中，它会根据你距离相机的距离，由远到近进行渲染，在UI相机中，还会根据你UI对象的深度进行渲染
那么我们要做的就是，对要渲染的对象进行一次规划，正确地排列好它们，规则是，按照Z轴或者深度，对空间进行划分，然后确定好每个对象的Z轴和深度，让使用同一个材质的东西，尽量保持在这个空间内，不要让其他材质的对象进入这个空间，否则就会打断这个空间的渲染顺序
在这个基础上，更细的规则有：
场景中的东西，我们使用Z轴来进行空间的划分，例如背景层，特效层1，人物层，特效层2
NGUI中的东西，我们统一使用Depth来进行空间的划分
人物模型，当人物模型只是用一个材质，DrawCall只有1，但是用了2个以上的材质，DrawCall就会暴增（或许对材质的RenderQueue进行规划也可以使DrawCall只有2个，但这个要拆分好才行），3D人物处于复杂3D场景中的时候，我们的空间规则难免被破坏，这只能在设计的时候尽量去避免这种情况了
使用了多个材质的特效，在动画的过程中，往往会引起DrawCall的波动，在视觉效果可以接受的范围内，可以将特效也进行空间划分，假设这个特效是2D显示，那么可以使用Z轴来划分空间
每个材质/纹理的渲染一定是会产生DrawCall的，这个DrawCall只能通过打包图集来进行优化
制作图集一般遵循几个规则：
从功能角度进行划分，例如UI可以划分为公共部分，以及每个具体的界面，功能上，显示上密切相关的图片打包到一起
不要一股脑把所有东西打包到一个图集里，特别是那些不可能同时出现的东西，它们就不应该在一个图集里，这样的图集意义不大，减少不了DrawCall，并且一个你不需要显示的图片，会一直占用你的内存，这让我非常不爽
注意控制图集的大小，不要让图集太大，一个超级大图集的DrawCall消耗或许顶的上十几个小图集的消耗
字符图集，在使用BMFont或者其他工具生成图片字的时候，我们往往是直接导入一大串文字，然后直接生成图片，但实际上这上面的操作也有优化空间，例如BMFont生成的图片大小，是可以设置的，有两个规则，一个规则是导出的图片尽量小，另一个是导出的图片尽量少，默认的大小应该是512x512，假设你生成的图片256x256就可以容纳，那么多做一个操作你可以节省这么多空间，另外当你输入多几个字，就导致增加一张图片时，例如1024变成2048，那么你可以考虑使用3张512的图片，这样也会节省空间
经过精心划分的图集在加上精心规划的渲染顺序，DrawCall会有一个质的优化
U3D提供了非常便捷的方法让我们很轻易地使用美术给过来的特效，懒惰的U3D程序猿会直接放入U3D，甚至不去看这是个什么特效，我们的特效一般都是一瞬间的事情，例如技能特效，或者其他什么特效，那么特效播放完，这个特效我们就看不到了，但假设这个特效在播放结束的时候，没有将自身的Active属性设置为false，那么它就会继续占用你的DrawCall，消耗你设备的计算能力，所以程序需要保证当一个特效播放完之后，能够被消耗，或者设置为非激活的状态，可以使用一些公共方法来完成特效播放完之后的清理工作（自己实现2个静态函数，一个播放完销毁，一个播放完设置未激活）
完成DrawCall的优化之后，接下来就是内存的优化了，（内存优化手记 待续）
阅读(...) 评论()