起个名字好难啊

前言：无论是网上的攻略还是以前的经验来说，都说UGUI需要进行动静分离。也就是说同一个界面下的UI，可活动的元素放在一个Canvas下，不可活动的元素放在另一个Canvas下。虽然两个Canvas打断了合批，但是却减少了网格的重建时间，总体上是有优化的。究其原因，是因为在同一个Canvas下的某个元素发生变化时，同一Canvas下的所有元素都会进行网格重建（ReBatch）。而静态的元素在...

粒子系统Q1：粒子系统里面使用到的模型，是不是读写开关必须要打开，否则会崩溃？在Unity 5.3早期的版本中，我们确实收到过类似的反馈，在某些特效上使用了没有设置 Readable 的 Mesh 时就会触发崩溃，且在崩溃日志中会出现ParticleSystemRenderer::UpdateCachedMesh的堆栈。但目前我们在较新的版本上（例如4.7.2，5.3.5 等版

其他Q1：SkinnedMeshRenderer的Mesh是不是不能动态修改？属性里只开放了SharedMesh。如果需要动态修改 SkinnedMeshRender 对应的 Mesh，则可以通过读写 SharedMesh 来实现，类似于 MeshFilter.sharedMesh 的用法，参见：https://docs.unity3d.com/ScriptRefere

UI输入Q1：关于UI的Mask遮挡特效，能否提供一些解决思路呢？目前由于UI与粒子系统是两个相对独立的模块，因此两者的Mask遮挡并没有简单直接的方法。我们建议从以下几种方式来考虑实现：将粒子系统转为序列帧，通过纯UI的方式来实现；通过RenderTexture，添加一个相机来实现方形的“裁剪”；参考UI的内置Shader，编写一个受Stencil B

渲染优化Q1：在Android平台上，PlayerSettings里开启/关闭Multithreaded Rendering，在性能和稳定性上有多大的区别？ 一般是勾还是不勾？就我们目前深度优化过的项目而言，Android App中开启多线程渲染确实可以在渲染模块中带来较大的性能提升，但我们并没有详细地定量分析过，所以很难给出“到底能提升多少”的定量说明。对于稳定性来说，现

资源管理Q1：如下图，在UWA性能报告中，我们发现Camera.Render下CreateVBO的开销较高，请问这个是如何引起的？从图中可以看出，Mesh.CreateVBO是在半透明渲染的开销之下，说明这是半透明物体的渲染引起的。在我们目前测评过的项目中，仅使用NGUI的项目会在此处出现不同程度的CreateVBO的CPU开销。对此，建议研发团队首先确认其UI系统是否使用

UI Mesh 渲染Q1：在GPU分析器里面看到，同一个NGUI的图集被绘制了很多次。请问是否是由于各个界面Panel不一样导致的？这种情况下如何优化？图片中红框处的内容其实并不是同一个Atlas被多次渲染，而是拥有同一Atlas的不同Widgets在进行渲染。这些Widgets的Mesh是动态生成的，且在不同的Draw Call中，NGUI在生成它们时根据所使用的At

资源管理Q1：我们在做依赖打包改进，比如UIAtlas这种脚本，AssetBundle包里脚本没有做依赖，每个包里都有这个脚本，会导致Mono堆内存增大么？对于“脚本也是资产”这一点理解的不是很透彻。脚本在AssetBundle里是不会启动，但是会出现脚本丢失。本身没有做依赖打包的话脚本是冗余在AssetBundle中吧？首先，需要说明的是，脚本本身的内容是不会被打包到Asse

NGUI更新开销：NGUI进行自身的数据更新以及生成网格的过程中所产生的开销，目前UI部分的CPU耗时大部分都是这部分的开销；NGUI的更新开销几乎全部来源于UIPanel.LateUpdate中；一般超过3~4ms，说明这部分更新开销较高；UI更新的数量和频率通过合理的布局，可以把这部分的开销限制在很多小的范围里面；在关卡的切换或点击一些UI界面时，可以出现一些较高的峰值；但

UGUI和NGUI的区别：使用率：NGUI占大多数，NGUI和UGUI的使用占比为81% : 19%；易用性：NGUI占一定优势，UGUI仍在慢慢改善；性能：如果都合理搭配，UGUI在性能上还是有一点优势的，在Unity5.2、5.3之后UGUI有一部分网格合并的操作是放在多线程中进行，相对来讲，性能有一定的提升；但NGUI的优化相对更简单一些，主要是因为NGUI的Drawca

资源管理Q1：怎么去掉Mesh中的Colors属性？我把FBX里的LayerElementColor字段都删了，这个Colors还是存在。默认情况下，在3d建模软件中并不会导出Color属性。以3ds max为例，Color通常是通过modifier添加的，因此只需要在导出前将其删除即可。另外也可以通过fbx sdk来直接对文件进行处理，但这种做法就需要查看官方的文档了。

图形渲染Q1：以前端游时代，材质根据Pass不同、光照环境不同可以离线预编译成ShaderCache，运行时并不需要拼材质再实时编译，只要加载二进制代码就好了。那Unity有没有做这件事呢？我们是根据平台和环境预编译的Shader。对于支持 Binary Shader 加载的设备，在首次编译某个 Shader 的时候是会生成其对应的 Binary Shader Cache ，生

资源管理Q1：关于定位游戏中冗余资源引用的问题。UWA的报告中能定位到具体的引用代码么？ 在Profiler只能看到ManagedStaticReferences但是具体不到引用的位置。比如Static ClassA引用一个ClassB，ClassB上引用了一个资源，就定位不出这个引用的过程。请问这种情况下有没有比较好的方法找到引用关系呢？该问题在Unity 5.3 之前的版本

Q1：Unity UI图集不是正方形，使用PVRTC格式的话，会出现问题么？比如是512x1024的原始比例。如果纹理尺寸长宽不相等，那么即便是2的幂次，也不会被压缩成PVRTC格式纹理。建议在iOS平台中，尽可能保证纹理尺寸为2的幂次且长宽相等。

物理Q1：请问Physics.Processing的占用过大一般是因为什么原因导致的？影响物理系统耗时的因素主要为Contacts数量（碰撞对数量）、Rigidbody API的使用情况和每帧的调用次数。第一种情况是最为常见的引发物理模块耗时较大的原因，因此，我们在UWA性能报告中对其进行了详细的分析，如果你的报告中Contacts数量较高，切记要验证其

性能优化Q1：Draw Call和Setpass Call，这两个指标主要是看哪一个？关于这点众说纷纭，很多地方都是说看SetPass Call，但是在UWA的性能测试中，还是把Draw Call当成唯一指标。在 Unity 5.x 中，SetPass Call与 Draw Call相比，SetPass Call的指标与性能相关性更大（比如Static Batching

NGUI：如何定位：UIRect.Update：UIWidget很多的时候，开销比较高；（UI模块或屏幕进行缓存，当缓存时，有大量UI在屏幕外边，虽然降低了UIPanel.LateUpdate，但UIRect.Update（下面有UIWidget）每帧都会更新位置，这个开销非常高）UIRect.Update一般是非常低，否则说明UI缓存非常多； 如何定位

Animator.ApplyOnAnimatorMove：调用次数太多说明场景中角色数量太多了；Animator.ProcessAnimationJob：关于AnimationClip的采样和读取；WaitingForJob：Unity5.X已经将其放入了子线程，等待子线程的处理；角色的多少和AnimationClip的复杂程度影响耗时；Animators.FireAnimatio

CPU均值：物理引擎每帧的平均CPU耗时。对于Unity引擎而言，其4.X版本所使用的物理引擎为NVIDIA PhysX2.8，报告中统计的是Physics.Simulate的CPU耗时；其5.X版本所使用的物理引擎为NVIDIA PhysX3.3，报告中统计的是Physics.Simulate和Physics.Processing的CPU耗时总和。推荐值：主体范围：0~3ms; 

资源管理Q1：我们项目做AssetBundle打包时，发现如果资源所依赖的C#Script的Public成员变量有变化时，用新代码加载旧的AssetBundle就会不兼容。有没有什么方法能判断这些Script在变化时是否需要重新打AssetBundle呢？目前我们使用.CS文件的MD5来判断是否需要重新打包，但其实这样应该有很多不必要的重复打包，对吗？该问题的本质原因是新代码的

资源管理Q1：我的游戏运行一段时间之后，已经切换到一个空场景了，然后手动调用了System.GC.Collect(); Resources.UnloadUnusedAssets();为什么还是会有这么多贴图资源被引用呢。我猜可能是由于一些脚本中的静态变量引用导致，请问有办法查出来是哪些静态变量吗？很大可能是这些资源直接或间接被其他Container缓存了，这种情况在我们进行内存

动画Q1：我在Profiler中看到Animator.Initialize这个耗时很大，这个有什么建议么?Animator.Instance 是因为Animator过多造成的吗？由图中可知，Animator.Initialize主要是在Instantiate实例化时引起（实际上，GameObject.Active操作也会引起Animator.Initialize），而其具体的耗时原

性能Q1：在整体的性能消耗上，CPU和GPU各占一半合理吗？如果不是，各占多少为好？还是说需要根据机型来看？其次，我如何知道游戏在手机上的GPU消耗？Profiler是看不到的，有工具推荐吗？首先，CPU和GPU是并行的，也就是CPU在运算的时候GPU也在运算，一帧的结束时间是两者中比较晚结束的那个。因此，一般我们在考虑这个问题的时候，经常会说是CPU bound还是GPU

内存管理Q1：有没有办法可以减少游戏中Mono内存占用的大小？我现在读完游戏表以后就占用了60MB，我看其他游戏读完配置表也才10MB左右，这个是怎么做到的呀？如果刚进入游戏后，Mono堆内存就达到了60MB，那么你的游戏项目极有可能在一开始加载了一个非常大的配置表。对此，我们建议出现该问题的研发团队对配置文件的初始加载进行详细检测，查看是否可以精简配置文件信息。如果不行，则尝试将

UI 输入Q1：UWA的直播里说的“将UI的Layer设置为不可见，从而将UI屏蔽”的方式具体是怎么实现的？为什么我在NGUI下直接设置UI元素的Layer不会生效呢？在NGUI中使用修改Layer的方式隐藏界面，必须以UIPanel为单位，即直接修改UIPanel所在的GameObject的Layer才会生效。因为对于UISprite或者UILabel，都会在运行时被强制修改为与

资源加载/卸载Q1：如下图，通过纹理图片通过文件流形式加载到内存，这样的资源还可以使用Resources.UnloadUnusedAssets()和Resources.UnloadAsset(m_Asset)进行资源卸载吗？如果是自己载入内存并初始化为Unity的Texture2D，则还是要重点查看Texture2D对象的创建方式。一般来说，会用new Textur

性能优化Q1：请问怎么优化下图这两者的GC Alloc？每次AddComponent 都会有这么多的开销。图中的两项GC Alloc是在进行AddComponent时不可避免的，因此只能通过尽量减少AddComponent的调用次数来进行优化。

图形渲染Q1：我们的游戏中有一些静止的建筑，会和整个场景一起烘焙（包括了每个建筑在地表的阴影）。现在希望这些建筑是逐步开放的，比如玩家1级的时候只有建筑A开放，2级的时候建筑B开放，现在的问题是当建筑未开放时（SetActive(false)）地表的相关阴影还在。这种问题一般是怎么处理的？这种问题是因为研发团队将整个场景烘焙成一张Lightmap所致。如果地图中的建筑是固定

UIQ1：能否在NGUI多分辨率适应方面提供一些解决方案或者思路？多分辨率适应涉及到以下几个方面：布局。通常可以通过 NGUI 中的 Anchor 组件来实现，能够保证 UI 到屏幕上指定锚点的距离；UI 背景图比例。通常我们建议将背景图的长宽比放大，以适配不同长宽比的屏幕，但要注意两边需要留空，或者保留可被裁掉的元素；UI 的整体缩放。可以通过 UIR

资源管理Q1：我在UGUI里更改了Image的Color属性，那么Canvas是否会重建？我只想借用它的Color做Animation里的变化量。如果修改的是Image组件上的Color属性，其原理是修改顶点色，因此是会引起网格的Rebuild的（即Canvas.BuildBatch操作，同时也会有Canvas.SendWillRenderCanvases的开销）。而通过修改顶

资源管理Q1: 我使用Shader.WarmupAllShaders操作，在后续加载资源还是有CreateGPUProgram出现。(Shader都在一个AssetBundle文件中，都是常驻内存的，不会删掉)是必须使用ShaderVariantCollection来加载Shader吗？A：以上这种问题的较大可能是：Shader被打包到不同AssetBundle中了，WarmupA

Q1：如果我有一个Prefab，它的Dependencies都在Resources文件夹中，那么，当我在AssetBundle打包时，只打包这个Prefab（不指定BuildAssetBundleOptions.CompleteAssets和BuildAssetBundleOptionsCollectDependencies）的话，这个Prefab能够正确实例化吗？这是不能正确实例化的

版本BugQ1：在把Unity升级到5.3之后，项目中缓存的粒子特效无法正常播放了（只能播放一次），是否还需要修改粒子的设置呢？这个问题是Unity的Bug，5.4.0B3 release note 为：Particles: Fixed particle system only playing once.（会在新版本5.4修复）目前我们推荐通过另一种方法可以暂

Q1：Lightmap在PC上显示正常，但是转到Android平台上存在色差，颜色普遍偏暗。一般来讲，有两种情况可能会导致色偏和亮度差异。1.Unity烘焙的Lightmap是32bit的HDR图，而移动设备通常不支持HDR图(32bit per channel)，会按照LDR图(8bit per channel)的形式进行处理，因此会出现色偏问题。因此我们建议：在

运行性能Q1：如下图，我们发现WaitingForJob这个函数消耗过高导致了卡顿，请问该卡顿是否由于渲染压力过大导致？从图中看，该线程最后是在等待 Canvas.sortjob，而这是 UI 排序造成的开销（自Unity5.2版本开始，UGUI的部分计算已经移出了主线程）。详情参考：http://blogs.unity3d.com/2015/09/07/mak

内存管理Q1：如图，在Editor中查看Profiler里的内存详细信息，发现Used Total中有个“Unity”，请问是什么意思？为什么会特别大？在Editor中运行时，“Unity”大是正常的，因为在Editor中运行项目时，引擎包含了所有的资源占用的内存（除了部分纹理和Mesh是在GFX中），同时自身会进行很多的辅助操作来记录各种游戏运行信息。一般来说，在查看

资源加载Q1：怎样动态加载Navmesh？目前Navmesh不支持动态加载，只能随场景一起加载， 因此可以考虑将带有Navmesh的场景打包成AssetBundle，然后使用LoadLevel加载AssetBundle中的场景。Navmesh的动态加载已经在Unity的Roadmap中。而当前，Navmesh是和场景绑定的，也就是说目前只能通过LoadLevel（不支持Lo

NGUIQ1：NGUI变形，如下图走样了，请问是不是图片压缩导致的？当UI纹理在设备上的显示分辨率低于原始分辨率时，会因为出现aliasing现象，导致UI局部变形。通常对于粗线条、块状的UI图素，变形通常是不明显的，但对于细线条的UI图素，则可能非常明显。通常该问题可以考虑三种方式来改善：在NGUI中将UIRoot的Scaling

MOBA移动游戏性能分析报告：渲染、UI和逻辑代码是性能头号杀手！UWA曾经发布过MMORPG 和 ARPG 的Unity手游性能测评报告，延续该系列，最近UWA对提交测试（登陆www.uwa4d.com）的所有MOBA手游进行了客观的分析和汇总，并将其具有属性特征的几大性能模块数据在此分享，希望能给相关行业的研发人员一些更为明确和建设性的意见。◆◆◆总体性能

ParticleSystem.Update：严格控制粒子系统Active的数量，数量越多，Update越高，无论粒子系统是否在视锥体内；优化：1：视锥体外，距离比较远时，关闭粒子系统；2：计算UV，往屏幕上做投影，在屏幕外侧时，关闭粒子系统；推荐文章链接：如何读懂UWA性能报告？—粒子系统篇