Q1：当关闭预渲染GI时会出现IndirectResolution,这个参数有什么用，为什么调大了以后会大大增加渲染时间，但是烘培出来却没有什么效果。
该值主要控制的是GI的烘焙密度，数值越大，表示每个单位距离内的Texel越多，即烘焙得越精致，自然烘焙的时间也越长。
该值并非越大越好，场景越小建议该值越低。该值为1时，对于多数场景，其烘焙效果已经足够了，升高该值，其效果也不会有明显提升。
Q2：请问Unity引擎中使用什么贴图压缩格式，可以保证在占用内存相对较小的情况下True Color效果和原图相当？同时在iOS和Android平台上图片的压缩格式分别用什么比较合适？有什么需要注意的地方吗?
目前来讲，并不存在一个所有GPU平台都支持硬件解压的压缩格式。 ETC1 和 PVRTC 分别是Android和iOS上我们最推荐的格式。 但对于透明纹理，ETC1不支持，而 PVRTC 则可能有较大失真，因此更推荐使用 RGBA 16。
一般来说建议直接使用 Unity 默认的压缩格式（即选择 Compressed 即可，不需要做特殊设置），Unity 会做如下处理：
1.Android 上不带Alpha通道的图片采用 ETC1，带Alpha通道的图片采用True Color中的RGB16，TrueColor中的 RGBA16 会>比 RGBA32 更节省空间，但图像的显示质量会差一些；
2.iOS 上使用 PVRTC，但PVRTC格式要求纹理的长宽相等，且都是2的幂次（即POT，在ImportSettings中可以将NPOT的纹理自动转换成POT）。
另外，针对Android 上的带Alpha通道的图片，还有一种常见的做法，即把Alpha通道独立出来作为另一张纹理，从而将 RGB 部分和 Alpha 部分分别采用 ETC1来压缩，但渲染时就需要自定义的 Shader来处理。
同时，我们不建议直接使用 RGBA32 格式的纹理，因为它占用了很大的内存。一般建议使用 RGBA16 和 ETC 格式的纹理来进行加载。 如果转换到 RGBA16 格式时出现了类似“色阶”的颜色问题，则建议尽可能避免大量的过渡色使用。
Q3: 在Unity开发中，大规模使用粒子特效会有什么问题 ?如何去针对性的优化？
普遍来说，会造成Draw call高、渲染开销大、CPU高等问题。下图就是UWA性能诊断系统对粒子系统检测的几个注意点。
Q4：在游戏中，有些Mesh在编辑时候是接收Lightmap的，出于某些原因我们合并了相同的Mesh（材质也相同）。但是发现原先的Lightmap不再影响合并后的Mesh，请问怎么才能实现让合并后的Mesh也接收原先的Lightmap？
如果Lightmap不止一个的话，手动合并Mesh是会出现问题的，因为合并的Mesh烘焙信息很可能出现在不同的Lightmap中，但合并之后的Mesh在渲染时只能使用一个Lightmap，这样uv2读取到Lightmap信息就会出现问题，进而出现这种现象。其实，对于材质相同的Static物体并不需要手动对其Mesh进行combine，因为Unity的Static Batching会自行完成。而如果由于某种特定需求一定要将Mesh进行合并的话，那么也要将其所需要的Lightmap也一并合并，同时改变相应的uv2。不仅如此，Shader中Lightmap也需要进行相应修改，这是比较复杂的，所以并不建议这样的做法，因为可能会花掉开发团队大量的开发时间。
Q3：我在shader里这么写的代码
o.texcoord1 = vec2(mod(v.texcoord.x,1.0),mod(v.texcoord.y,1.0));
但是报错 undeclared identifier 'mod' at line 106 (on d3d11)，请问是什么原因导致的呢？
报错表明mod在d3d11的Shader中是未定义的，如果开发团队无需在d3d11的平台上使用该 Shader，则可以添加以下预编译指令：
#pragma exclude_renderers d3d11
如果Shader依旧无法正常显示，那可能是因为在Editor中使用的是 DX11（可以从标题栏中看出）。 可以尝试修改DX9的参数 ：Build Settings -> 点击 PC, Mac ... -> Player Settings（不需要点击 Switch Platform） -> 去掉 Auto Graphics API for Windows 的勾选，只保留 Direct3D9。同时，开发团队也可以直接使用 fmod 替换 mod，理论上 fmod 在各个平台都是支持的。
Q4：当关闭预渲染GI时会出现IndirectResolution，这个参数有什么用，为什么调大了以后会大大增加渲染时间，但是烘培出来没有啥效果。
简单来说，该值主要控制的是GI的烘焙密度，数值越大，表示每个单位距离内的texel越多，即烘焙得越精致，自然烘焙的时间也越长。该值并不需要越大越好，场景越小，建议该值越低。该值为1时，对于多数场景，其烘焙效果已经足够了，升高该值，其效果也不会有明显提升。
开发者也可以参考Unity官方的说明文档：
http://docs.unity3d.com/Manual/GlobalIllumination.html
Q5：关于抗锯齿和BLOOM，有什么好的优化方案或者优秀插件推荐？
A：通常在中低端的设备上，抗锯齿并没有比较高效的方案；而对于中高端的设备，可尝试直接使用 Unity 内置的 MSAA 功能，但也只推荐使用 2x。
关于Bloom效果，以下是适用于移动端，且评价较好的一款插件：BloomPro
Q6：我们这种英雄UI，里面嵌了一个类似场景的Prefab，开了实时光照之后内存就特别高。这种不属于场景，又没有办法烘培，有没有什么好的建议呢？
A：首先，理论上开实时光对内存是没什么影响的。
开发团队可以尝试烘焙，因为Unity 5.x 中也是有办法进行动态加载Lightmap 的，只是需要通过脚本将烘焙时每个物件的Lightmapindex和Lightmapscaleoffset记录下，并在运行时动态加载后设置回去的方式来实现。因为目前Lightmapindex和Lightmapscaleoffset信息是和场景绑定在一起，储存在Lightmapsnap.assets 中，发布时也是放在场景信息中，因此不会记录在Prefab 上。
Q7：在Unity 4.x的版本中，所有UI贴图使用ETC2格式，即使目标设备不支持该格式，也会解压成RGBA32使用。 而在目前使用的Unity 5.3.4版本中，iOS平台无法设置ETC2格式。如果压缩只能使用PVRTC格式，那么PVRTC存在显示效果比较差，并且图片必须为正方形，但如果用RGBA32格式，贴图占用的内存和存储又都过大，请问目前版本的Unity在iOS平台上应该如何设置UI贴图的压缩格式？
我们建议可以先尝试其他的压缩格式看是否可以达到类似的效果，如ASTC格式。ASTC 在 iOS 的高端机上是被支持的，因此理论上在 Editor 下不会强制把 ASTC 转为 RGBA32，建议尝试设置为 ASTC 后打包，从 Editor.log 中或者直接从包体大小上可以看出是否确实使用了 ASTC。
一般来说，如果 RGBA16 的效果可以接受的话，建议使用 RGBA16，虽然打包时相对大一些，但是内存中相比 RGBA32 能够减半，但使用 ASTC 的话，虽然打包时比较小，但是在普通机型上会被处理成 RGBA32，导致过大的内存开销。
Q8：如下图所示，第一张显示的是没有烘培Lightmap的场景效果，里面有一盏点光源；第二张显示的是烘培Lightmap后的场景效果。请问为什么同一盏点光源照亮的效果差别那么大？(图略)
简单来说，这就是实时的直接光照和全局光照的差别。
在渲染时前者只能处理光源和单个物件之间的直接光照，而后者在烘焙时是通过光线跟踪或者辐射度等复杂算法，计算出所有物体各个表面之间相互反射的光照信息，这也是烘焙Lightmap需要较久的时间的原因 。可以发现在全局光照下，即使是物体的背面也会因为其它表面的反射而被照亮，这在直接光线下就无法实现这样的效果。
Q9：以前端游时代，材质根据Pass不同、光照环境不同可以离线预编译成ShaderCache，运行时并不需要拼材质再实时编译，只要加载二进制代码就好了。那Unity有没有做这件事呢？我们是根据平台和环境预编译的Shader。
对于支持 Binary Shader 加载的设备，在首次编译某个 Shader 的时候是会生成其对应的 Binary Shader Cache ，生成的 Binary 文件位于和 Application.persistantPath 并列的Cache 目录下。
Q10：相同效果前提下，就性能而言，Shader 是用 V&F 还是Surface好？
Surface生成的V&F比较庞杂，分支较多，如果不注意 #pragma surface 参数的选择，容易出现不必要的开销。举例来说，如果直接用 Unity 5.x 中默认创建的 Surface Shader （默认参数为 #pragma surface surf Standard fullforwardshadows），那么 Shader 是会做 Physically based Standard Lighting 的，而这在移动端开销非常大，且并非必要
