1）非2的幂次的ASTC纹理格式尺寸对带宽的影响
2）C#端如何处理xLua在执行DoString时候死循环
3）如何制定美术规范或者各个模块的指标
4）如何处理Lua的io.open出现中文路径
这是第348篇UWA技术知识分享的推送，精选了UWA社区的热门话题，涵盖了UWA问答、社区帖子等技术知识点，助力大家更全面地掌握和学习。
Texture
Q：有一张UI纹理尺寸1200x554，纹理格式ASTC 4x4，显示占用内存0.6MB，将MaxSize改为1024，占用内存476KB。
除了内存的降低外，想请问下对带宽或其他性能的影响大么？
纹理类型是Default，Advanced -> Non-Power of 2 -> ToNearest/... 选项，但是UI没有，UI是否也有必要自己实现ToNearest？
A：题主可以参考一下知乎的这个回答：
OpenGL支持非二次幂纹理的底层原理是什么？ - 知乎也可以参考：
Why are textures always square powers of two? What if they aren't? - Game Development Stack Exchange简单来说有如下几个信息：
- GPU的寻址是按块进行的，ASTC纹理的压缩也是按照块进行压缩的，因此贴图尺寸最好符合这个设定；
- 不满足的贴图通过补充额外空间来满足对应的需求，这里会有部分的空间浪费。
具体到题主的问题：
- 将MaxSize设置为1024，其实是减少了贴图尺寸，内存/显存占用变少是肯定的；
- 贴图尺寸降低，肯定是会减少带宽消耗，也有可能提升显存的采样命中率，包括加载方面因为文件大小变小都会有提升，但这些"好处"未必那么好量化，比较明显的应该是带宽降低。
- UI的贴图通常会做合图的操作，因此很多UI自身是不需要做尺寸上的要求的，但是如果不合图的话，整体上还是建议按照power of 2的尺寸在做设计，这种规范比较简洁清晰，容易执行。
感谢贾伟昊@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：在外部结束Lua虚拟机肯定是有很大崩溃风险的，我觉得有两个思路供参考：
- 建立一个完整的沙盒环境，类似Dock，这个环境内运行逻辑，外部可以把这个环境销毁掉，不会对外部造成任何影响，这个在Unity下可能难度比较大，要做逻辑和表现的分离，然后构建一个纯逻辑层的运行环境。
- 在Lua虚拟机内部监测死循环的情况，然后自主中断，抛出Error。这个是我们现在在用的方式，改造Lua虚拟机，监测一定时间内一直在执行某些字节码超过一定阈值就认为自己是在死循环把自己结束掉。当然还有一些别的条件，比如栈深度检测等等。这种自主中断并且抛错的方式其实更加完美。具体实现可以参考这个文章的思路：
检测 Lua 脚本中的死循环 - 链滴个人是比较推荐第二种方案的，也是很多项目验证过的，对于UGC类型的游戏，检测并能提醒用户编辑出来了死循环非常重要。
感谢贾伟昊@UWA问答社区提供了回答
Performance
Q：在UWA问答上看到了《项目初期如何确定美术规范》这个问题的回答，感觉还是不太理解，好像这个问题是不是只能凭经验，或者通过工具不断地去趋近那个指标，并没有一个指定规范，像是从面数什么之类的来计算？比如，我同屏10人，角色面数5000，渲染模块耗时不超过12ms之类的，有没有一定的公式去量化到美术的一个指标？感觉大部分好像不是根据经验来去做这个样的一个规范，或者是参考竞品之类，UWA给的项目测量好像也没有具体的计算方式，我感觉应该是定一个基准机型，然后再去做项目的各个模块的参考，然后才得出美术或者其他的指标。问下有没有更好的办法，最近看到有根据能耗来计算然后得到各个模块的指标，有大佬有了解过这方面的知识吗？
A：具体的信息在题主引用的问答里面已经有很多的讨论了，从我个人的经验来看，还没有什么更好的办法，主要原因在于性能结果受到的各个方面的影响因素特别多。
比如，同样机型上跑40w面的画面，Shader的复杂度差异就可能让一个GPU满负载而另外一个还有很大的空余量；再举一个例子，同样的一个画面，如果你的CPU很闲，也许你就可以用一些OC算法大大降低最终画面渲染的消耗，当然，GPU有富裕也可以用GPU-Driven这样的思路来做更加高效的剔除。
因此，不同的游戏类型，不同的人来做，都可能达到完全不同的性能结果。我们定义一个机型，给定一个经验值或者参考竞品的美术资产规范，往往是保证在使用相同引擎相似技术的情况下能够保证性能的底线。这个基于经验或者参考设定的规范和指标最大的意义在于告诉你可行性，如果最终游戏的性能没有达成到预期帧率，你可以参考其他游戏或者常规的优化方式来尽量接近可行结果，当然，你也可以通过修改引擎或者渲染管线，抑或其他Trick的方式来超越这个规范，这就取决于团队能力了。除此之外，规范也是要不断根据项目的实际情况进行调整的，而非完全的一成不变。
因此想根据一个公式，可以直接量化出一个规范，这个想法可能有些过于理想，这个公式里要考虑的因素太多，每个因素之间又有互相的影响，最终我们做性能优化的时候，也常常是在这些因素之前进行平衡------比如GPU Bound了就看看是否可以拿CPU换一些计算量出来，CPU Bound了是否可以用内存来换？
至于基于能耗来计算指标，我们往往是反向的，就是当一个优化做好之后，或者上了一个新Feature之后，我们会通过控制其他变量，单独开关这个Feature来查看它带来的能耗变化（我们的统计方式是基于电流表的，理论上比接口采集的数据更加符合实际情况）。而且在这个过程中能耗是波动的，不是稳定的，所以基本无法测量出增加一个面有多少能耗的增加，增加一个DrawCall有多少能耗的增加，更何况影响能耗最多的往往是带宽。
所以，整体上基于已有的经验来看，非常准确地量化消耗或者能耗，是一件很难的事情，不同设备可能会有不同，不同项目也可能会有不同，我个人是持悲观的观点。在实际工作中，主要基于经验和参考来制定一个大致的规范，然后在正式的资源与功能不断完成之后去迭代和完善这个规范。
如果题主探索出了可量化的路径，也欢迎分享~~
感谢贾伟昊@UWA问答社区提供了回答
Script
Q：关于Lua的io.open出现中文路径，有办法处理吗？
如以下的代码，不同版本Lua有不一样的结果，我的Lua 5.1会出现Invalid Argument，用5.4创建了一个乱码文件，因为有时候避免不了中文目录，像Windows平台下有人用了中文用户名，就会出现"C:/User/中文用户/AppData"之类的路径。
`local path = "C:\\新建文件夹\\test.txt"
local file, error_msg = io.open(path, "w")
if file then
file:write("这是一个示例文本文件。\n")
file:close()
print("文件创建成功。")
else
print("无法创建文件。", error_msg)
end
`A：网上搜到一篇文章，仅供参考：
lua io.open 中文路径-掘金另外就是如果文件内容并不是一定要在Lua中处理的，也可以让C#去做对应的文件操作。
感谢贾伟昊@UWA问答社区提供了回答
封面图来源于网络
今天的分享就到这里。生有涯而知无涯，在漫漫的开发周期中，我们遇到的问题只是冰山一角，UWA社区愿伴你同行，一起探索分享。欢迎更多的开发者加入UWA社区。
UWA官网：www.uwa4d.com
UWA社区：community.uwa4d.com