从Gamma空间改为Linear空间会导致性能下降吗
1）从Gamma空间改为Linear空间会导致性能下降吗
2）如何处理没有使用Unity Ads却收到了GooglePlay平台的警告
3）C#端如何处理xLua在执行DoString时候死循环
4）Texture2DArray相关
这是第350篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。
Rendering
Q：Linear性能比Gamma差吗？我们项目从之前使用的是Unity 2020.2.7f1版本，选择的是Gamma。目前升级到2021.3.21f1，切换为Linear空间，Shader和图片都进行过修改，性能也优化过。
但是总体测试下来性能不如之前的Gamma，帧率没有以前高，帧率掉了很多，经过优化，还是不太令人满意，总感觉会卡顿，不知道是不是从Gamma升级到Linear的原因？
A1：应该和换颜色空间没关系。如果没有特殊功能，Gamma和Linear的主要区别就是最后输出到显示器时要不要做颜色的修正，根据你的描述应该和修改Shader有关。
感谢李伟@UWA问答社区提供了回答
A2：在硬件支持的设备上，不应当有明显的性能差异。
在硬件不支持的情况下（比如OpenGL ES 2.0），如果是基于Shader中的模拟转换来实现Linear Space的效果，会有一定的GPU消耗。但是如果感受上是卡顿，而非持续的低帧率，那也不像是这种情况，建议从具体的性能Profile数据入手来进行排查。
这里有一个相关的讨论，搜索performance关键词可以看到一些人做的实验：
Gamma vs Linear Space - Unity Forum部分结论引用如下：
“I have just done a stress test of Gamma vs Linear color spaces with transparencies and Gamma is indeed a liiiitle faster than Linear, but the difference is so minimal it doesn't even matter. (2 to 3 frames per second more on a stress test that was overdrawing 8 transparent planes one over the other for the full screen space.)
On any GPU that handles GLES3 there is no performance reason to use Gamma space over Linear.Gamma space is legacy now and is only useful for legacy GLES2 GPUs (because linear requires GLES3)”
不同的游戏测试结果可能略有差异，但原理上应该是没有可观测的性能差异的，题主可以参考一下。
感谢贾伟昊@UWA问答社区提供了回答
Script
Q：我没有使用Unity Ads，但仍然收到了GooglePlay平台的警告：
您的“xxxxxxx”应用（版本代码：8）包含“com.unity3d.ads:unity-ads”SDK 或您的某个代码库所依赖的SDK，该SDK会收集个人数据或敏感数据，这些数据包括但可能不仅限于Advertising ID，Android ID标识符。根据用户数据政策的相关规定，应用不得将永久性设备标识符与其他个人数据、敏感的用户数据或可重置的设备标识符相关联。
自世界协调时间（UTC）2023年1月11日午夜起，如果新应用版本包含SDK版本且不符合用户数据政策，则可能无法发布。您可以考虑将该SDK升级至不含违规代码的合规版SDK（若有），或者从您的应用内移除该SDK。
根据您的SDK提供方的情况，您可以考虑升级到4.0.1，并/或联系您的SDK提供方，看看是否有合适的更高版本可用。Google无法推荐任何第三方软件，也无法为这类软件提供任何背书。
A1：建议检查下SystemInfo的引用。
感谢Knight-132872@UWA问答社区提供了回答
A2：提供几个思路：
1、确认Package下有没有com.unity.ads包
2、如果使用的是Unity中国版，可以切换为以下版本或同版本国际版
感谢bo@UWA问答社区提供了回答
A3：亲测，用对应的国际版本就行了，解包发现，中国版不论是否导入Ads，打的包里面都会有Ads内容，国际版本不会有这个问题，今天提交谷歌商店验证过了。
解包后在smali\com\unity3d目录下，splash文件夹，首先要在工程里移除Ads，再打包测试，我用2020.3.38f1和2018.4.36f1测试都没问题。
感谢TimWang@UWA问答社区提供了回答
Script
Q：我使用xLua作为游戏的内嵌脚本语言，允许玩家自定义脚本。
现在有个玩家在脚本里面写了一个死循环，当我用DoString去加载这个脚本时候会直接卡死，于是我在外面加入了一个Task：
var isSucceed = false;
var task = Task.Run(() => {
isSucceed = sandbox.DoString(xxxx)//这里简化一下.核心就是加载这个脚本执行DoString
});
bool isCompletedSuccessfully = task.Wait(TimeSpan.FromMilliseconds(1500)); //1.5s timeout
if (!isCompletedSuccessfully)
{
CELog.LogError("加载脚本超时");
isSucceed = false;
luaEnv.Dispose(); //Kill掉当前的Evn
return; //不再加载后续脚本
}
现在是只要调用‘luaEnv.Dispose()’编辑器就直接闪退，无论是这里Timeout了调用，还是等几秒以后。
我感觉是因为Task的Timeout只是在超时后回调，但是此时Lua还在死锁中，所以我无法Dispose。
官方的FAQ提了一句：
调用LuaEnv.Dispose崩溃，很可能是这个Dispose操作是由lua那驱动执行，相当于在lua执行的过程中把lua虚拟机给释放了，改为只由C#执行即可。
我感觉和我这个情况是一样的，应该如何处理？
A：Update一下目前研究的进展：
这是找xLua求教的结果，目前满足我自己的需求：
xlua DoString时候死循环 C#端如何处理 · Issue #1077 · Tencent/xLua · GitHub
如果以上方法不满足，还搞不定底层，可以尝试以下几个方向：
MoonSharp
MoonSharpMoonSharp是纯用C#写的Lua，不过已经不更新了。Discord还有活跃，问的问题都会解答。
https://gist.github.com/xanathar/2c777a79937398834ad4
用Hook的方式可以实现以上的需求。
优点就是纯C#的，相对来说好操作。不过就是性能弱，但是如果和我一样Lua只是用于玩家的Mod。其实还好，因为Lua端的逻辑会很弱。
nLua
Using Debug Hooks crashes Lua execution · Issue #56 · NLua/NLua · GitHub
nLua的DebugHook是直接被集成好的，xLua的Hook大佬没给暴露出来，要自己搞。
uLua
Lua Modding Framework | Utilities Tools | Unity Asset Store
Assetstore上面的资源，近期还在更新。
感谢题主Eran@UWA问答社区提供了回答
Texture
Q：从Texture arrays文档（Unity - Manual: Texture arrays）上来看，GLES3 Metal 已经可以支持了。
最容易想到的就是地形的Splat层，如果是四层Splat，那么就可以用一个Texture2DArray来代替，好处是减少了Bind消耗。其中根据龚大（为什么要强调Texture2DArray在地形上的应用？ - 知乎）的意思来看，似乎还可以减少Splat采样次数，但根据自己的测试和理解来看并不行，因为Texture2DArray的Slice之间并不会Blending，不知是不是我理解问题。
我使用一个Texture2DArray来代替4层的Splat地形，从xCode上看开销，并没有任何的减小，那目前来看这么做地形的意义就不是很大了。AssetStore上有一个插件叫MegaSplat就是使用Texture2DArray来达到很多层混合。
目前想到的Texture2DArray还有一个可以利用的地方是场景贴图。比如场景用到了多张 1024的贴图，或者多张Lightmap，原来由于贴图不同导致StaticBatching无法合并，现在就可以使用Texture2DArray来做了。
还有比如UI上的Icon之类的，可以合并到一个Texture2DArray来达到DrawCall的合并。
目前Texture2DArray最不好的地方是，只能通过代码来创建，没有编辑器的支持。如果要离线制作Texture2DArray，就需要为不同的平台准备多份资源了。
请问大家有没有Texture2DArray的经验可以分享呢，已经使用或者有计划使用的?
A1：研究了一下Texture2DArray，看起来它是将多个2D的Texture组合起来变成一个对象，所以在使用的时候只需要绑定一次，就可以采样多个2D Texture。的确如题主所说，采样的时候还是一次只能采样一个指定的Slice，Blend也需要另外的Shader代码来完成。
题主说了：其中根据龚大的意思来看，似乎还可以减少splat采样次数，但根据自己的测试和理解来看并不行。
我感觉他的意思可能是：并不是每次采样必须把所有的Slice都采了，而是可以只采其中一部分。估计原本想表达的是一次采样只采一个Slice。
我使用一个Texture2DArray来代替4层的Splat地形，从xcode上看开销，并没有任何的减小，那目前来看这么做地形的意义就不是很大了。
如果单从性能上看，Texture2DArray比Texture2D的确只是减少纹理绑定的开销，然后在游戏引擎中可能会对合批产生影响。其他的做法跟普通Texture2D是一样的。Texture2DArray比Texture3D在LOD处理上不同，Texture3D会减少Slice，这并不是渲染Terrain时想要的。然后Texture2DArray在Filter的时候只会在u，v上做，而Texture3D还会在d上做，所以这部分Texture2DArray也比Texture3D性能更好。综合这些因素可能就是推荐渲染Terrain使用Texture2DArray的原因。题主通过实验说明Texture2DArray渲染地形没有减少开销，也有可能是因为一般一个场景就一个地形，从绑4张纹理变成绑1张就少了几毫秒，而且也不是每帧都绑，所以从整体效果上看表现的不明显。
--- 更新 2018.2.22
做了个简单实验验证了一下，下图分别是用Texture2D和Texture2DArray渲染地形结果和GLES API调用。实验设备为三星s6。
Texture2D：
Texture2DArray：
其中，GLES API调用图中红色框表示纹理绑定的API调用，绿色框表示渲染API调用。WT表示了该API调用的耗时，单位为纳秒。从Texture2D图中可知一共有5次纹理绑定，分别对应于材质中的5张纹理绑定，而Texture2DArray图中只有两次调用，分别是Splat纹理和四层混合纹理的绑定。从图中可知一次glBindTexture的耗时大约为1000~10000ns，即最多0.01ms。因此，三次glBindTexture加上三次glActiveTexture也最多0.06ms。所以看不出来。
感谢ZFK@UWA问答社区提供了回答
A2：假如地形需要16张图片，制作上确保同一位置最多受4张图影响，是否可行？若可行是否可以理解为使用Texture2DArray比不使用节省了16-(4+1)=11次Sample，与相应的Bind？（这个4也可能2或者10看需求，+1是因为要分别存索引跟权重，具体要不要+1视实际情况决定。）不使用Array时减少Sample次数也能用if判定但对GPU并行影响更大。
感谢[email protected]@UWA问答社区提供了回答
今天的分享就到这里。生有涯而知无涯，在漫漫的开发周期中，我们遇到的问题只是冰山一角，UWA社区愿伴你同行，一起探索分享。欢迎更多的开发者加入UWA社区。
UWA官网：www.uwa4d.com
UWA社区：community.uwa4d.com