Linear Rendering在移动设备上的支持率

这是第135篇UWA技术知识分享的推送。今天我们继续为大家精选了若干和开发、优化相关的问题，建议阅读时间10分钟，认真读完必有收获。

UWA 问答社区：answer.uwa4d.com

UWA QQ群：465082844（仅限技术交流）

渲染

Q1：在 此篇博客 里，有提到Linear Space Color这个特性在安卓机上的支持率是61%，在苹果机上是71%。

不过这个数据是2016年的数据，已经不适用于现在了，我们希望能知道Linear Rendering这个特性在现在安卓机和苹果机上的支持率，当然，如果能区分地区（例如大中华区和东南亚各自的支持率）和更加细节（例如OpenGL ES 2和OpenGL ES3占有率、Vulkan支持率、iOS Metal的支持率等）就更好了。

另外，如果我们在Gamma颜色空间下，使用PBR流程制作手机游戏想要有更好的表现效果，有什么好的策略和方法吗？现在我们使用的是Metal-Roughness贴图，Shader是参考下面 这篇 博客，修改Standard的Shader代码写成的：

占有率这个东西，不同的统计渠道可以得出不同的统计结果，我这里没有具体的数据，只能提供个人的建议——2019年上市的3D游戏，除非特别小型，在国内市场，我个人认为是不用去考虑OpenGL ES 2.0的设备了。三四年前的千元机已经支持OpenGL ES 3.0了（比如红米Note2、小米2A），何必为了这点市场份额而额外增加那么多限制呢？（Alpha通道拆分、自己在Shader中做线性空间处理、Shader要注意贴图采样数量限制等等）

另外大致看了下题主贴的文章，其实是在Gamma的设置下自己在Shader中实现Linear Space的计算过程而已，这种方式有两个小问题：

1）增加GPU额外计算量，比基于硬件的方式消耗更大一点点；

2）最终的从线性空间转换到伽马空间的过程，注意最理想的是在最后一步来进行，如果有多个Pass，这里的计算过程在效果上可能有错误（单个Pass，没有后处理的情况下看上去是一致的）。当一个Pass输出的颜色会作为下一个Pass的输入时，也要将颜色转换回线性空间来计算才正确。

还有就是不仅仅albedo贴图，所有是颜色的贴图/通道都需要做这样的计算才是正确的。

使用链接中的方式可以实现线性空间的效果，比较老的游戏也通常是这样做的，但是我个人会倾向于直接使用Unity内置好的功能，性能上和便利性上都会更好一些。

另外，个人观点，基于PBR流程的话，在做好基准效果之后，程序能做的事情不多，毕竟都是物理计算的，后面的效果大都依赖于美术对于PBR的理解以及制作经验了。

感谢贾伟昊@UWA问答社区提供了回答

最近项目刚切到线性空间去，查了些资料，Linear Rendering需要支持OpenGL ES 3.0 ，Android版本参考4.3, 以下是一份Android版本参考数据，参考版本数据大致可以推出占比 ：

https://blog.csdn.net/qq_29428215/article/details/80847211

iOS参考iOS 7的iPhone 5s。

经过我查看的资料和调研，我跟楼上观点一致，直接切线性空间。

感谢赵林@UWA问答社区提供了回答

逻辑代码

Q2：控制 Lua 逻辑代码产生的内存，如何回收才能避免内存峰值过大？

C#和Lua都可以在回收的时候被标记为null，从UWA报告中的曲线可以看出，C#的回收机制是一段时间自行回收，Lua却没有，可以理解在堆内存管理上是有区别的？如果避免这样的内存泄露问题，控制内存暴涨，有什么更好的回收方法？

补充理解：
手动回收内存：Lua内存回收调用Collect，C#调用GC；
自动回收内存：C#申请的内存置空或Clear可以回收掉，而Lua描述中也是置空可以让其自动回收，但是下面的Lua变化曲线没有锯齿线的变化，这有点不明白了，是否我理解错了？

自动回收的说法可能有点问题，Clear或者置空只能认为是解除对对象的引用，并没有回收对象的内存。

回收的时间点总是发生在GC时的，只是有些是手动调用的，有的是自动触发的。上面C#和Lua的曲线不同，应该只是GC触发的规则和时间点不同（C#的频率高，而且每次是全量的GC，一次性回收；Lua的规则会复杂些，而且还可能是分代的）。

然后也可能是C#层的堆内存分配的比较快，量比较大，所以看上去GC就比较频繁了。

调用Collect是可以触发回收的，通过lua_gc的第二个参数还能控制是否分步进行。不过从曲线上看，Lua部分的内存有泄漏的风险，才会出现峰值越来越高的现象，所以建议还是先尝试定位下泄漏问题。

该回答由UWA提供

避免内存峰值过大，如果只是交给自动GC很难满足。

一般来说，是结合手动触发GC，甚至设置合理的步进。在一些特定的场景，比如说战斗场景，在内存准许的情况下还可能采用的策略是停掉自动GC以防止自动GC引起卡顿，然后出来场景做一次手动全回收并且开启GC。

防止内存泄露同样是要特别注意的问题，比如说Local不小心处理成了Global无法释放，被table表强引用等情况导致无法释放，导致内存占用越来越大。

感谢赵林@UWA问答社区提供了回答

虚幻&粒子系统

Q3：求助虚幻4大佬们的帮助：

1）有可能在蓝图中或者C++中对粒子系统的Mesh进行修改吗？

2）或者说有可能把蓝图创建的Procedural Mesh赋值给粒子系统的Mesh吗？

http://orfeasel.com/creating-procedural-meshes

回答如下：

1）首先，题主要先确定需要Runtime修改的是单个ParticleSystemComponent实例的Mesh还是整个ParticleSystem（资源模板）的Mesh。两者都比较容易达成，引擎在渲染动态对象的时候，会每帧通过PrimitveSceneProxy的GetDynamicMeshElements收集实际的MeshBatch，ParticleSystem会根据Emitter的实际Instance类型，调用对应类型的GetDynamicData获取需要的数据。所以只需要给ParticleSystemComponent添加接口暴露给蓝图，用来设置新的StaticMesh，并且在接口实现中，传递给实际的FParticleEmitterInstance，FParticleEmitterInstance基类中新增SetMesh的接口，什么都不做，在继承类FParticleMeshEmitterInstance中，增加UStaticMesh*类型的成员变量，作为PerInstance的override用的Mesh数据，重载基类的SetMesh接口中把传入的Mesh复制给自己的Override用的Mesh，并在FParticleMeshEmitterInstance::GetDyanmicData接口最后NewEmitterData->Init的第三个参数改成 EmitterInstanceMeshOverride ? EmitterInstanceMeshOverride : MeshTypeData->Mesh。至于要改整个ParticleSystem模板的Mesh就更简单了，直接在SetMesh接口中换掉自己MeshTypeData->Mesh就行了。要做的完整需要对resourcesize，getmaterials以及计算bounds的相应接口做一些简单的调整。

2）用ProceduralMesh会比较麻烦，当然也不是不行，但这里有一些概念题主需要清楚：普通的StaticMesh是Assets，而实际的Component可以看成是使用某种Assets的实例。所以在Mesh Data中设置的其实是资源，在实际生成实例的时候，会利用资源的数据来生成对应的数据。而ProceduralMesh比较特殊，并不存在资源，只存在实例，如果想实现需求，需要把ProceduralMesh的各种stream（position，normal，tangent，vertexcolor等）转成Particle的FMeshParticleVertexFactory中的实际数据格式，参考FMeshParticleVertexFactory::FDataType和ProceduralMesh中对应的数据的结构关系。

内存

Q4：请教个问题，内存快速增长该如何确定是哪些导致的？我们的UWA测评报告中显示切场景的时候多了差不多两百兆。

UWA：这个是PSS内存增长，这块内存的进一步定位有两种方式：第一种是在UWA GOT Assets模式中，查看主流资源（纹理、网格、RenderTexture等）的增幅情况；第二种是传到UWA网站，进行线上深度测评，通过线上报告除主流资源外，可以进一步看到此处的提升是Unity自身增长，还是Gfx增长，如果是前者，则根据AssetBundle加载相关，如果是后者，则跟Texture、Mesh、ShaderLab相关，这样就可以比较清晰地定位了。

但是，需要注意的是，PSS的内存增幅要快于Unity引擎的实际内存增幅，即App中加载一个4MB的纹理，引擎增加的记录是4MB，而PSS可能增加6MB、8MB甚至更多，这个是由其OS和Driver来决定的。

内存

Q5：Unity 5.6.6版本下，在PlayerSetting中改变了Logo和背景，如图一直在内存中 ，请问该如何处理呢？

UWA：恰好整过一样的问题，当时绕过的方法是在首场景中添加一个脚本，然后把splashimage挂上去，在这个脚本的 Start 中通过 Resources.UnloadAsset() 把 splashimage 卸载掉，后续应该就不会再出现了。题主也可以一试。

今天的分享就到这里。当然，生有涯而知无涯。在漫漫的开发周期中，您看到的这些问题也许都只是冰山一角，我们早已在UWA问答网站上准备了更多的技术话题等你一起来探索和分享。欢迎热爱进步的你加入，也许你的方法恰能解别人的燃眉之急；而他山之“石”，也能攻你之“玉”。

官网：www.uwa4d.com

官方技术博客：blog.uwa4d.com

官方问答社区：answer.uwa4d.com

官方技术QQ群：465082844（仅限技术交流）