您所在的位置： &
Android图形子系统详解
Android图形子系统详解
Android的图形系统发展经历了通过CPU模拟图形操作，和GPU专门进行图形处理的阶段，因为这方面硬件技术发展很快，因此Android图形系统也在不断调整，以期提供更加快速流畅的UI体验。
图形操作可以有两种方式实现：一是利用通用CPU模拟图形操作；二是利用GPU专门做图形操作。前者会增加CPU的负担，在现在高分辨率已经是普遍现象的时候，让通用处理器来完成大量的图形计算已经不现实。Android图形系统的发展过程也验证了这一观点。
为了达到高效的图形处理效果，是必须紧密结合软件和硬件的。这篇文章主要介绍跟Android的图形子系统。以后可能会对这些主题进行更加深入的探讨。
Android图形系统的软件构成
下面的示意图，展示了Android上负责图形处理的软件模块。
498)this.width=498;' onmousewheel = 'javascript:return big(this)' width="394" height="434" border="0" src="/files/uploadimg/9410.png" alt="AndroigGFX2-273x300" title="AndroigGFX2-273x300" style="background-image: border-width: 0 border-style: border-color: -moz-use-text- padding-left: 0 padding-right: 0 display: padding-top: 0 cursor:" />
一个典型Android应用中各个图形系统组件的关系图
GPU专门设计用于加速图形操作。GPU不同于CPU，它的一个设计目的就是高度的并行化，并行化是大部分图形计算的共同特征。
Android 刚刚问世的时候，GPU还是可选的，最近发布的版本中，GPU已经是一个必配硬件。如果系统中没有GPU，系统使用的OpenGL
ES就包含了libagl和pixelflinger，通过软件实现OpenGL
ES协议接口，有时也有硬件支持的CopyBit。但是不幸的是，Android通过软件模拟OpenGL，并不支持OpenGL ES
2.0。现在，Android系统中的不少组件使用了OpenGL ES
2.0，比如HWUI、Renderscript、SurfaceTexture。平板电脑都有很高的分辨率，纯软件的模拟支持并不能保证图形的填充需 求，也就不能为用户提供流畅的UI体验。厂商如果想制造基于ICS或者更高版本Android系统的设备，就必须具有支持OpenGL ES 2.0
画布是应用程序用来绘制Widget或图形等元素的地 方。Froyo和Gingerbread上，画布通过Skia来绘制。Honeycomb及以后的版本，HWUI被加入了进来，提供了GPU加速支持。在 Ice Cream Sandwich及以后的版本上，HWUI缺省用于图形的绘制。
Skia是一组2D绘图的API，它完全通过软件实现。由于性能方面的原因，Skia逐渐被HWUI所替代。
HWUI 可以使UI组件使用GPU加速。HWUI是在Honeycomb中引入进来的，目的是使交互更加快速，及时响应，流畅。在大分辨率的平板电脑上，通过 Skia来绘制动画，会占用很高的CPU资源，进而拖慢整个系统。HWUI需要支持OpenGL ES 2.0的GPU，不能通过软件模拟。
Renderscript
Renderscript 同样也是Honeycomb引入的新的API，它的设计为了同时解决移植和性能问题。应用程序员用Renderscript（基于C99）编写代码，然后 一个LLVM的交叉编译器把它编译为机器独立的bit
code，应用程序员再将其打包到apk中。当用户下载apk时，设备上的编译器（基于LLVM，位于/system/lib/libbcc.so）将 bit code编译为目标机器上的指令。
Renderscript在Froyo和Gingerbread上也存在，但是不是公开的API。只有Android的一些wallpaper使用了它。那时它的实现也非常粗糙，功能有限。
一 个Surface对应一个屏幕外缓冲区，应用程序用来渲染窗口内容。一个游戏程序，它可能使用OpenGL在Surface上绘制3D对象，一个普通应用 程序，它可能使用Skia来绘制Widget或者文本，它也可能使用HWUI库来启用GPU加速。从ICS开始，Surface通过一个后端的 SurfaceTexture实现，这就意味着Surface对应的不再是一个缓冲区，而是一个纹理（texture）。
498)this.width=498;' onmousewheel = 'javascript:return big(this)' width="456" height="440" border="0" src="/files/uploadimg/9411.png" alt="AndroigGFX1-300x290" title="AndroigGFX1-300x290" style="background-image: border-width: 0 border-style: border-color: -moz-use-text- padding-left: 0 padding-right: 0 display: padding-top: 0 cursor:" />
Android平台的图形栈
SurfaceFlinger:
SurfaceFlinger是一个合成器，它管理来自于不同应用的Surface。比如，可能有许多应用同时存在，与此对应的，存在许多独立的Surface需要被渲染。SurfaceFlinger决定屏幕上显示的内容，那些需要被覆盖，进行裁剪。
SurfaceFlinger使用的是OpenGL ES 1.1标准中的函数。为什么呢？如果使用OpenGL ES 2.0，就必须需要支持OpenGL ES 2.0的硬件GPU，这会使系统的启动更加复杂，也会使模拟器的实现更加困难。
HW Composer:
硬件合成器是Honeycomb引入的一个HAL，SurfaceFlinger使用它，利用硬件资源来加速Surface的合成，比如3D GPU和2D的图形引擎。
CopyBit也是一个HAL。它允许使用特殊硬件来加速一些图形操作，比如复制（blitting）。它设计的初衷是在没有3D GPU的系统上加速软件的渲染过程。CopyBit在ICS中被删除了，因为GPU已经成为一个必备硬件，没有必要专门设计一个加速部件。
Libagl/PixelFlinger:
libagl 是一个通过软件实现了OpenGL ES
1.0和1.1版本API的组件。它使用PixelFlinger来实现OpenGL调用。为了加速使用PixelFlinger的渲染过程，JIT被引 入了进来，称为CodeFling。CodeFling生成机器代码，它急剧加速了许多类型的像素操作。
可以看出，Android的图形系统在不断的调整，目的是为了提供更加快速流畅的UI体验。这就是Android版本中图形相关代码变动很大的原因。【编辑推荐】【责任编辑： TEL：（010）】
关于&&&&&&的更多文章
从整体上来看，一款Android产品分为设计、编码和测试三个阶段。
网友评论TOP5
既然强大的Android Studio来了，有什么理由不去用呢？
本视频教程为51CTO独家AppCan系列视频教程的第一部分
传统意义上，电视是大众传播媒介。传统电视媒体，传播
本系列视频教程由正益无线与51CTO共同推出，目的是让
本书描述的是在逆向与反逆向之间展开的一场旷日持久的拉锯战。作者Eldad Eilam以一个解说人的身份为我们详尽地评述了双方使用的
Windows Phone专家
Android开发专家
51CTO旗下网站为什么android、ios同样的配置但android远不及ios流畅？
苹果iOS系统为什么远比谷歌安卓更流畅？
不少人都反应苹果iPhone要比一般Android手机流畅，这是一个现象要说是大问题谈不上，毕竟两者是完全两个不同的系统所以严格来说放在一起对比是不公平的。不过因为Android以及iOS是
当下两大主流操作系统，对比抗衡之类的说法自然难以避免。今天我们就来谈谈为什么iOS产品在使用过程中会让人觉得更加流畅一些，而为何一些Android手机则容易出现卡顿延迟的情况。
iOS手机为什么比安卓流畅
优先级别不同：iOS最先响应屏幕
当我们使用iOS或者是Android手机时，第一步就是滑屏解锁找到相应程序点击进入。而这个时候往往是所有操控开始的第一步骤，iOS系统产品就表现出来了流畅的一面，但Android产品却给
人一种卡顿的现象，更别说后续深入玩游戏或者进行其它操控了。这是为什么?
其实这与两个系统的优先级有关，iOS对屏幕反应的优先级是最高的，它的响应顺序依次为Touch&Media&Service&Core架构，换句话说当用户只要触摸接触了屏幕之后，系统就会最优先去
处理屏幕显示也就是Touch这个层级，然后才是媒体(Media)，服务(Service)以及Core架构。而Android系统的优先级响应层级则是Application&Framework&Library&Kernal架构，和显示相
关的图形图像处理这一部分属于Library，你可以看到到第三位才是它，当你触摸屏幕之后Android系统首先会激活应用，框架然后才是屏幕最后是核心架构。
iOS系统优先处理Touch层级
可以看到优先级的不同导致了iOS产品以及Android手机在操控过程中的表现差异，当你滑动屏幕进行操控的时候，iOS系统会优先处理Touch层级，而Android系统则是第三个才响应Library层
级，这是造成它们流畅度不同的因素之一。不过优先级对系统流畅性有有影响不假，但并不是最绝对的，造成两系统之间流畅性不一的现象还有其它因素，我们可以接着往下看。
硬件工作配置不同：iOS基于GPU加速
目前智能手机硬件装备竞赛当中，其实处理器等配置已经达到了一个瓶颈期，各大旗舰产品在硬件比拼当中基本上没有太大的区别，而这时候GPU就成为了一个凸显差异的重要因素。一些大型
软件像是3D游戏对GPU性能要求都会比较高，苹果iPhone产品采用的Power&VR&SGX系列GPU在当下来说非常的主流，跑分测试数据证明了它并不会比一些旗舰级别的Android产品差劲。
A6处理器集成了Power&VR&SGX543显示芯片
而iOS系统对图形的各种特效处理基本上正好都是基于GPU硬件进行加速的，它可以不用完全借助CPU或者程序本身，而是通过GPU进行渲染以达到更流畅的操控表现。但是Android系统产品则并
非如此，因为Android需要适应不同的手机硬件，需要满足各种差异配置，所以很多图形特效大多都要靠程序本身进行加速和渲染，并严重依赖CPU运算的操作自然会加大处理器的负荷，从而
出现卡顿的问题。虽然Android&4.0以及4.1等更高版本中进行了改进将硬件加速设为默认开启，但依旧无法做到所有特效全部都靠GPU进行加速。在很多Android手机里面都自带有“是否开启
GPU渲染”这个功能选项，不过开启之后的改善也是微乎其微。
iOS图形特效基于GPU加速渲染屏幕最先响应的优先级关系，再加上iSO本身GPU加速程序的特性，使得大家在操控过程中感觉iOS手机拥有着不错的流畅性。因为它本身的整个流程都是在为最大化的流畅做服务，不管是第一
印象的滑动接触屏幕，还是你进一步使用程序之后的更深层操作都是如此。而GPU加速这点特性，应该是它优于Android系统流畅性的又一个因素。
开发机制不同：安卓机制效率低
Android的编程语言是JAVA，而iOS的则为Objective-C，不过要是说Android系统之所以有些卡顿是因为JAVA开发语言的关系，或者是拿它和Objective-C对比肯定会有人提出质疑。
Objective-C的优势是效率高但比较“唯一”，而JAVA的优势则是跨平台不过运行效率相对偏低，其实这两个编程语言所带来的机制不同，就已经造成了各自系统之间的流畅性差异化。
Android系统架构
iOS的Objective-C，编译器gcc，而这个gcc编译出来的代码又被苹果专为iOS架构优化到了极致，运行过程中也不需要虚拟机在中间插手，执行效率自然很高&引自网络。这一段话应该是iOS
系统本身运行程序的执行过程，而Android是通过JAVA虚拟机来执行，并且系统需要占用大量内存来换取执行速度，再加上不定期的内存自动回收机制，从而直接导致了卡顿现象的出现。iOS系统架构有着不错的运行效率
Android的JAVA编程本身运行效率比Objective-C低一些，而且再加上内存自动回收的机制，所以造成了一些卡顿不流畅的现象出现。但根据技术人员讲解，现代的JAVA虚拟机效率已经不再是
最大的瓶颈，Android&4.0系统版本之后的卡顿现象明显得到了改善，所以这也是有用户并没有发现自己新买的Android手机出现太多卡顿现象的原因。看来编程语言和机制已经被Android进行
了改善，这同样也不是造成它与iOS流畅性偏差的唯一因素，不过影响却是实实在在存在着。
系统设计不同：安卓APP无法统一
有了优先级的关系，有了GPU加加速的影响，还有两个系统各自编程以及机制的问题，似乎已经可以说明为什么iOS相比Android更为流畅的原因。但最终还有一个问题是就是应用程序，很显然
用户觉得卡顿都是在运行软件的过程中产生，毕竟没有安装任何应用的初始出厂手机基本上都不存在不流畅或者延迟等现象，而且一款智能手机不安装任何应用程序那也不符合用户的购买初
衷和使用行为。所以归根结底，Android相比iOS的应用程序，到底出了什么问题?
App&Store是苹果和iOS的另一个标志
因为iOS产品的封闭性，所以所有的APP运行对象都比较单一，因为每个应用程序都是被运行在iPhone，iPad等iOS产品当中，它们有着很高的硬件利用效率。因为iOS系统的配件供应商只有那
么几家，CPU也是一年换一次，这点不像Android终端年年变月月变，开发者很难遇见未来终端分辨率会包含多少种，GPU驱动会包含哪些等等，所以相对来说Android应用开发成本较高且收益
较慢。而iOS应用开发则因为软硬件垂直整合而受益，这样一来苹果自然就保证了应用本身其与硬件产品之间的完美结合程度。
其实Android和iOS两大系统APP开发情况的不同，也正是它们开发和不开放的特性所造成的。如果要是拿旗舰Android手机加上一个专为这款旗舰产品设计的游戏，来和苹果iPhone&5运行对比
的话，你真的不会遇到Android旗舰机出现卡顿延迟的问题，为什么因为这款游戏针对这款手机设计，在软硬等方面都达到了最大化的兼容和优化，自然就不会出现停滞的现象。
Android&App虽然奋力追赶在但数量和质量上并未超越iOS
而Android系统程序要被安装在各种符合要求的手机上面，开发者也不可能针对所有的机器型号进行开发，只能在比较主流的机器上进行测试并保证运行效果，所以他们为了兼顾整个产品线只
能不得不降低游戏体验以达到高中低产品可以共用的效果。最后那些占据了Android终端份额的大量大众用户们由于自己的手机不是旗舰产品而得不到流畅的使用体验，自然而然就会产生
Android产品不如iOS流畅的抱怨。
写在最后：
不管是iOS产品感觉比Android流畅还是真的比它流畅，其实说到底原因很简单。苹果会花费一年甚至两年的时间去开发一个桌面icon，一种字体，并去测试屏幕点位，而Android终端中除了
Nexus系列之外似乎没有太多产品可以做到用这么长的时间去做这么细致的事情。有网友说得好，Android做的更多的是“让系统跑起来”，而iOS拥有着苹果做的更多的则是“让系统以最高的
效率跑起来”，或许这就是iOS产品比Android更流畅的原因吧。但更好的一面的是随着谷歌对Android的持续升级以及各厂商对自家产品的循序改进，使得越来越多的Android终端正在摆脱卡
顿不流畅的束缚，未来安卓用户的期待同样有望得到更好的满足。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。Unity3D - 图形性能优化 - 推酷
Unity3D - 图形性能优化
Unity官方文档中有一篇是讲图形性能优化的，这篇文章
是指导Unity开发优化的最佳文章。Unity圣典曾翻译过
，但是太老旧了，跟最新的文档差别很大。我试着翻译一下最新的文档，
Optimizing Graphics Performance &
图形性能优化
Good performance is critical to the success of many games. Below are some simple guidelines for maximizing the speed of your game’s graphical rendering.
良好的性能是很多游戏成功的关键。以下是一些最大化提高游戏图形渲染速度的简单指导。
Where are the graphics costs &
图形开销在哪里
The graphical parts of your game can primarily cost on two systems of the computer: the GPU or the CPU. The first rule of any optimization is to find
where the performance problem is
because strategies for optimizing for GPU vs. CPU are quite different (and can even be opposite - it’s quite common to make GPU do more work while optimizing for CPU, and vice versa).
游戏的图形显示部分主要消耗计算器的两个系统：GPU和CPU。任何优化的第一规则都是查明性能瓶颈在哪里，因为优化GPU和优化CPU的策略常常是不同的（甚至常常是相互对立的——常常为了优化CPU而把它的一些工作交给GPU，反之亦然）。
Typical bottlenecks and ways to check for them:
典型的瓶颈和检查方法：
GPU is often limited by&
&or memory bandwidth.
GPU常常受限于
和存储器带宽。
Does running the game at lower display resolution make it faster? If so, you’re most likely limited by fillrate on the GPU.
如果游戏在较低的显示分辨率上运行更快，则很可能是受限于GPU的填充率。
o&CPU is often limited by the number of things that need to be rendered, also known as “
draw calls
o CPU常常受限于需要渲染的物品数量，我们通常叫它“
draw calls
”（绘制调用，一般用专业术语“draw call”）
Check “draw calls” in&
& if it’s more than several thousand (for PCs) or several hundred (for mobile), then you might want to optimize the object count.
o 在Rendering Statistics窗口查看“draw calls
”，如果在PC上它常常多达几千个，或者在移动设备上多达几百个，那么你可能需要优化物体的数量。
Of course, these are onl the bottleneck could as well be somewhere else. Less typical bottlenecks:
当然，这只是根据经验的主要开销点，而瓶颈也可能在别处。不那么典型的瓶颈有：
Rendering is not a problem, neither on the GPU nor the CPU! For example, your scripts or physics might be the actual problem. Use&
&to figure this out.
o GPU和CPU在渲染方面都没有问题！比如，你的脚本或者物理可能是真正的问题所在，使用Unity的Profiler查明问题。
GPU has too many vertices to process. How many vertices are “ok” depends on the GPU and the complexity of vertex shaders. Typical figures are “not more than 100 thousand” on mobile, and “not more than several million” on PC.
o GPU处理太多的顶点。到底多少个顶点是ok的，依赖于具体的GPU设备和顶点着色器的复杂度。典型的数字是，在移动设备上“不要超过10万个”，在PC上“不要超过数百万个”。
CPU has too many vertices to process, for things that do vertex processing on the CPU. This could be skinned meshes, cloth simulation, particles etc.
o CPU处理太多的顶点 —— 针对CPU处理顶点的情况。这可能是蒙皮网格、衣服模拟、粒子等。
CPU optimization - draw call count &
CPU优化：draw call数量
In order to render any object on the screen, the CPU has some work to do - things like figuring out which lights affect that object, setting up the shader & shader parameters, sending drawing commands to the graphics driver, which then prepares the commands to be sent off to the graphics card. All this “per object” CPU cost is not very cheap, so if you have lots of visible objects, it can add up.
为了渲染一个
到屏幕上，CPU需要做一些工作——比如，哪些灯光影响
，建立着色器和着色器参数，给显卡驱动发送绘制命令，然后准备发送给显卡的命令。单个
的CPU开销并不昂贵，但是如果有很多可见
So for example, if you have a thousand triangles, it will be much, much cheaper if they are all in one mesh, instead of having a thousand individual meshes one triangle each. The cost of both scenarios on the GPU will be very similar, but the work done by the CPU to render a thousand objects (instead of one) will be significant.
所以，举例来说，比如你有1000个三角形，相比每个三角形一个独立的网格，它们都在一个网格中对CPU
要低得多。这两种方案对于GPU来说差别不大，但是CPU渲染1000个
（代替1个）的
In order to make CPU do less work, it’s good to reduce the visible object count:
为了让CPU做更少的工作，减少可见对象的数量是很有效的：
Combine close objects together, either manually or using Unity’s&
o 合并接近的物体。可以手工合并，也可以利用Unity的draw call batching（批量draw call）。
Use less materials in your objects, by putting separate textures into a larger texture atlas and so on.
o 在物体中使用更少的材质。可以把独立的纹理合并成一个更大的纹理图集。
Use less things that cause objects to be rendered multiple times (reflections, shadows, per-pixel lights etc., see below).
o 避免使用导致物体被渲染多次的效果（比如反射、阴影、像素光照等，见下面）。
Combine objects together so that each mesh has at least several hundred triangles and uses only one
for the entire mesh. It is important to understand that combining two objects which don’t share a material does not give you any performance increase at all. The most common reason for having multiple materials is that two meshes don’t share the same textures, so to optimize CPU performance, you should ensure that any objects you combine share the same textures.
合并物体使每个网格有至少几百个三角形，
整个网格只使用一种
。合并两个不
同一材质的物体并不会提升性能，
理解这一点
很重要。拥有多个材质的最常见原因是两个网格不
相同的纹理，所以为了优化CPU性能，你要确保合并的物体共用相同的纹理。
However, when using many pixel lights in the
, there are situations where combining objects may not make sense, as explained below.
然而，如果在正向渲染路径下使用很多像素光照，有一些情况下合并物体并没有效果，下面解释。
GPU: Optimizing Model Geometry &
GPU：优化模型几何
When optimizing the geometry of a model, there are two basic rules:
有两个优化模型几何的
基本原则：
Don’t use any more triangles than necessary
o 不用使用任何非必要的多余三角形
Try to keep the number of UV mapping seams and hard edges (doubled-up vertices) as low as possible
o 尽可能减少UV贴图接缝和硬边（顶点增多了一倍）的数量。
Note that the actual number of vertices that graphics hardware has to process is usually not the same as the number reported by a 3D application. Modeling applications usually display the geometric vertex count, i.e. the number of distinct corner points that make up a model. For a graphics card, however, some geometric vertices will need to be split into two or more logical vertices for rendering purposes. A vertex must be split if it has multiple normals, UV coordinates or vertex colors. Consequently, the vertex count in Unity is invariably higher than the count given by the 3D application.
注意，图形硬件处理的顶点实际数量常常跟3D应用程序报告的不一致。建模应用常常显示几何顶点数量，即构成模型的不同角点的数量。然而，图形显卡为了渲染目的可能会把一些几何顶点拆分成两个或者更多个逻辑顶点。如果一个顶点有多个法线、UV坐标或者顶点颜色，那么必须把它拆分。因此，Unity中的顶点数量一定会比3D应用程序给的定点数多。
While the amount of geometry in the models is mostly relevant for the GPU, some features in Unity also process models on the CPU, for example mesh skinning.
模型的几何数量主要对GPU有意义，Unity中的一些特性也在CPU上处理模型，比如网格蒙皮。
Lighting Performance &
Lighting which is not computed at all is always the fastest! Use
to “bake” static lighting just once, instead of computing it each frame. The process of generating a lightmapped environment takes only a little longer than just placing a light in the scene in Unity,&
不需要计算的光照是最快的。使用光照贴图烘焙静态光，只需要一次，代替了每帧计算。生成光照贴图环境，比在Unity的场景中放一个光源消耗的时间仅仅多一点，
It is going to run a lot faster (2–3 times for 2 per-pixel lights)
o 它的运行速度要快很多（对于2个逐像素光照，快2-3倍）
And it will look a lot better since you can bake global illumination and the lightmapper can smooth the results
o 并且，因为可以烘焙全局光照，并且lightmapper（光照贴图工具）可以让烘焙的结果更平滑，所以
它看起来效果也好很多
In a lot of cases there can be simple tricks possible in shaders and content, instead of adding more lights all over the place. For example, instead of adding a light that shines straight into the camera to get “rim lighting” effect, consider adding a dedicated “rim lighting” computation into your shaders directly.
许多情况下，有一些着色器和内容的简单技巧，而不是在所有地方添加更多的光源。比如，为了获得“边缘光照”效果，可以直接在着色器中添加一次“边缘光照”计算，而不是添加一个直射相机的灯。
Lights in&
正向渲染中的光照
Per-pixel dynamic lighting will add significant rendering overhead to every affected pixel and can lead to objects being rendered in multiple passes. On less powerful devices, like mobile or low-end PC GPUs, avoid having more than one
Pixel Light
illuminating any single object, and use lightmaps to light static objects instead of having their lighting calculated every frame. Per-vertex dynamic lighting can add significant cost to vertex transformations. Try to avoid situations where multiple lights illuminate any given object.
对每一个受到影响的像素，逐像素动态光会累加可观的渲染耗费，并且会导致物体在多个通道被渲染。在性能比较差的设备上，比如移动设备或者低端PC的GPU，避免使用多于一个的像素灯照射任何单个物体，并且使用光照贴图来照亮静态物体而不是每帧计算光照。逐顶点动态光照会在顶点转换上累加客观的消耗。努力避免多个灯光照射任何给定物体的情况。
If you use pixel lighting then each mesh has to be rendered as many times as there are pixel lights illuminating it. If you combine two meshes that are very far apart, it will increase the effective size of the combined object. All pixel lights that illuminate any part of this combined object will be taken into account during rendering, so the number of rendering passes that need to be made could be increased. Generally, the number of passes that must be made to render the combined object is the sum of the number of passes for each of the separate objects, and so nothing is gained by combining. For this reason, you should not combine meshes that are far enough apart to be affected by different sets of pixel lights.
如果你使用像素光照，对于每一个网格，像素光照射它多少次，它将被渲染多少次。如果你合并两个相距较远的网格，将会增大合并物体的有效大小。渲染的时候，照射到合并物体任一部位的所有的像素光都会被计算，所以，需要渲染通道数量会增加。一般地，渲染合并物体的通道数量等于分别渲染独立物体的通道数量之和，所以，合并没有作用。因此，你不应该合并足够远以至于受不同像素光影响的网格。
During rendering, Unity finds all lights surrounding a mesh and calculates which of those lights affect it most. The
are used to modify how many of the lights end up as pixel lights and how many as vertex lights. Each light calculates its importance based on how far away it is from the mesh and how intense its illumination is. Furthermore, some lights are more important than others purely from the game context. For this reason, every light has a&
Render Mode
setting which can be set to&
Not Important
lights marked as&
Not Important
will typically have a lower rendering overhead.
渲染的时候，Unity查找所有网格周围所有的光，并计算哪一个对网格影响最大。Quality &Settings（质量设置）可以修改最终多少个光是像素光，多少个是顶点光。每一个光基于距离网格的距离计算它的权重和光照强度。此外，取决于游戏内容，有些光比别的光更重要。因此，每个光源有
设置，可以把它设置为
的光一般有更低的渲染开销。
As an example, consider a driving game where the player’s car is driving in the dark with headlights switched on. The headlights are likely to be the most visually significant light sources in the game, so their Render Mode would probably be set to
. On the other hand, there may be other lights in the game that are less important (other cars’ rear lights, say) and which don’t improve the visual effect much by being pixel lights. The Render Mode for such lights can safely be set to&
Not Important
so as to avoid wasting rendering capacity in places where it will give little benefit.
举例来说，考虑一个赛车游戏，玩家的车开着车头灯，在黑夜中行驶。车头灯是游戏中最重要的可见光，所以它们的渲染模式可能要设置为
。另一方面，可能游戏里的其它灯光没那么重要（比如其它汽车的尾灯），
对这些灯光来说，
使用像素光照
可视效果作用不大，可以把它们设置为
，避免在只能获得较少效果的地方浪费渲染性能。
Optimizing per-pixel lighting saves both CPU and the GPU: the CPU has less draw calls to do, and the GPU has less vertices to process and pixels to rasterize for all these additional object renders.
对于CPU和GPU来说，
优化逐像素光照都可以减少开销：CPU需要处理的draw call少了，GPU需要处理的顶点和
所有这些额外对象的
像素少了。
GPU: Texture Compression and Mipmaps &
GPU：纹理压缩和多重纹理
will decrease the size of your textures (resulting in faster load times and smaller memory footprint) and can also dramatically increase rendering performance. Compressed textures use only a fraction of the memory bandwidth needed for uncompressed 32bit RGBA textures.
使用压缩纹理会减少纹理大小（结果是更快的加载速度和更小的内存占用）并且大幅提高渲染性能。压缩纹理占用的存储带宽只有未压缩的32位RGBA纹理的一小部分。
Use Texture Mip Maps &
使用多重纹理
As a rule of thumb, always have
enabled for textures used in a 3D scene. In the same way Texture Compression can help limit the amount of texture data transfered when the GPU is rendering, a mip mapped texture will enable the GPU to use a lower-resolution texture for smaller triangles.
作为经验，在3D场景中使用的纹理总是启用生成多重纹理。以同样的方式，GPU渲染时，纹理压缩可以帮助限制传输的纹理数据量，因为对于较小的三角形，多重纹理允许GPU使用较低分辨率的纹理。
The only exception to this rule is when a texel (texture pixel) is known to map 1:1 to the rendered screen pixel, as with UI elements or in a 2D game.
这条规则的例外是，知道texel（纹理像素）是1:1映射到渲染的屏幕像素，比如UI元素或者在2D游戏中。
LOD and Per-Layer Cull Distances &
LOD(多细节层次)和每层剔除距离
In some games, it may be appropriate to cull small objects more aggressively than large ones, in order to reduce both the CPU and GPU load. For example, small rocks and debris could be made invisible at long distances while large buildings would still be visible.
在一些游戏中，为了减少CPU和GPU负担，可以
剔除小物体。比如，远距离的小石头和碎片可以设为不可见，而大的建筑物是可见的。
This can be either achieved by
system, or by setting manual per-layer culling distances on the camera. You could put small objects into a&
and setup per-layer cull distances using the&
script function.
可以使用LOD系统，或者在相机上设置
每层剔除距离，来做剔除。你可以把小物体放入一个独立的层，然后使用Camera.layerCullDistance脚本函数设置每层的剔除距离。
Realtime Shadows &
Realtime shadows are nice, but they can cost quite a lot of performance, both in terms of extra draw calls for the CPU, and extra processing on the GPU. For further details, see the
实时阴影效果很好，但是会消耗很多的性能，包括CPU额外的draw call和GPU
的处理。更多细节，看文档的
GPU: Tips for writing high-performance shaders &
GPU：写高性能着色器的提示
A high-end PC GPU and a low-end mobile GPU can be literally hundreds of times performance difference apart. Same is true even on a single platform. On a PC, a fast GPU is dozens of times faster than a slow integrated GPU; and on mobile platforms you can see just as large difference in GPUs.
毫不夸张的说，高端PC和低端移动设备的GPU性能可能相差几百倍，甚至在同一个平台上也相差这么大。在PC上，一个快的GPU几十倍速于低端集成GPU；在移动设备上，也是如此。
So keep in mind that GPU performance on mobile platforms and low-end PCs will be much lower than on your development machines. Typically, shaders will need to be hand optimized to reduce calculations and texture reads in order to get good performance. For example, some built-in Unity shaders have their “mobile” equivalents that are much faster (but have some limitations or approximations - that’s what makes them faster).
所以，请记住，在移动设备和低端PC上的GPU性能，可能比你的开发机器低得多。典型地，为了良好的性能，着色器需要手工优化来减少计算和纹理读取。例如，一些内置的Unity着色器有
等价的“移动”版本（但是有些限制或者是近似值 - 就是这些使得更快）。
Below are some guidelines that are most important for mobile and low-end PC graphics cards:
下面是一些针对移动设备或者低端PC显卡的指南：
Complex mathematical operations &
复杂的数学运算
Transcendental mathematical functions (such as
, etc) are quite expensive, so a good rule of thumb is to have no more than one such operation per pixel. Consider using lookup textures as an alternative where applicable.
复杂的数学函数（比如pow、exp、log、cos、sin、tan等）开销很大，所以一个好的经验是不要在每个像素上使用这些函数。如果可以，考虑使用查找纹理作为替换。
It is not advisable to attempt to write your own
inversesqrt
operations, however. If you use the built-in ones then the driver will generate much better code for you.
不建议自己实现
normalize、dot、inversesqrt
使用内置的函数，
驱动会生成更好的代码。
Keep in mind that alpha test (
) operation will make your fragments slower.
记住，alpha测试（
）操作会使你的片段更慢。
Floating point operations &
You should always specify the precision of floating point variables when writing custom shaders. It is
to pick the smallest possible floating point format in order to get the best performance. Precision of operations is completely ignored on many desktop GPUs, but is critical for performance on many mobile GPUs.
写自定义的着色器时，应该指定浮点数精度。为了获得更好的性能，选用最小的可行浮点数格式是很
在很多台式机GPU上完全被忽略，但是在移动设备GPU上，它对于性能很关键。
If the shader is written in Cg/HLSL then precision is specified as follows:
如果着色器是Cg/HLSL写的，精度如下：
&- full 32-bit floating point format, suitable for vertex transformations but has the slowest performance.
- 32位浮点数格式，适合用于顶点变换，但是性能最慢。
&- reduced 16-bit floating point format, suitable for texture UV coordinates and roughly twice as fast as&
- 减半的16位浮点数格式，适合用于纹理UV坐标，性能大约是
&- 10-bit fixed point format, suitable for colors, lighting calculation and other high-performance operations and roughly four times faster than&
- 10位顶点格式，适合用于颜色、光照计算和其它高性能操作，比
大约快4倍。
If the shader is written in GLSL ES then the floating point precision is specified specified as
respectively.
如果着色器用GLSL ES写的，浮点数格式分别是：
For further details about shader performance, please read the
了解着色器性能的更多细节，请阅读文档
Simple Checklist to make Your Game Faster &
让你的游戏更快的简要清单
Keep vertex count below 200K..3M per frame when targetting PCs, depending on the target GPU
&如果目标设备是PC，保持顶点数低于20万-300万，依赖于目标GPU。
If you’re using built-in shaders, pick ones from Mobile or Unlit category. They work on non-mobi but are simplified and approximated versions of the more complex shaders.
&如果你使用内置着色器，选用Mobile或Unlit种类的。它们
在非移动平台良好工作，是复杂着色器的简化或者近似值版本。
Keep the number of different materials per scene low - share as many materials between different objects as possible.
&保持每次场景不同材质的数量 —— 不同物体尽可能共享材质。
&property on a non-moving objects to allow internal optimizations like&
&对于不移动的物体，设置
属性，允许像静态批处理这样的内部优化。
Do not use&
Pixel Lights
&when it is not necessary - choose to have only a single (preferably directional) pixel light affecting your geometry.
&除非必要，不要使用像素光 —— 只选用一个（尽可能平行光）像素光影响你的几何体。
Do not use dynamic lights when it is not necessary - choose to bake lighting instead.
&除非必要，不要使用动态光 —— 选择烘焙光照来代替。
Use compressed texture formats when possible, otherwise prefer 16bit textures over 32bit.
&如果可以，尽量使用压缩纹理格式；否则，16位格式纹理性能好于32位的。
Do not use fog when it is not necessary.
&除非必要，不要使用雾效果。
Learn benefits of&
&and use it to reduce amount of visible geometry and draw-calls in case of complex static scenes with lots of occlusion. Plan your levels to benefit from occlusion culling.
&学习遮挡剔除的好处，然后使用它来降低可见几何体和有许多遮挡的复杂静态场景draw call的
数量。设计你准备从遮挡剔除获得好处的等级。
Use skyboxes to “fake” distant geometry.
&使用天空盒“冒充”远距离的几何体。
Use pixel shaders or texture combiners to mix several textures instead of a multi-pass approach.
&使用像素着色器或纹理合并来混合几个纹理，而不是多通道逼近。
If writing custom shaders, always use smallest possible floating point format:
&如果写自定义着色器，使用
尽可能小的浮点数格式：
&- for colors, lighting information and normals,
&- 用于颜色、光照信息和法线，
&- for texture UV coordinates,
&- 用于纹理UV坐标，
&- avoid in pixel shaders, fine to use in vertex shader for position calculations.
&- 避免在像素着色器中使用，用于顶点着色器的位置计算比较好。
Minimize use of complex mathematical operations such as&
&etc. in pixel shaders.
&在像素着色器中，尽可能少用复杂的数学函数，比如
Choose to use less textures per fragment.
&每个片段使用较少的纹理。
已发表评论数()
&&登&&&陆&&
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见