1)应用Streaming Mipmap后纹理内存没有降落的疑难
2)TCP网络传输大端/小端疑难
3)Texture Compression,Default和Override有什么关系
4)如何疾速革除Log
这是第299篇UWA技术常识分享的推送。明天咱们持续为大家精选了若干和开发、优化相干的问题,倡议浏览工夫10分钟,认真读完必有播种。
UWA 问答社区:answer.uwa4d.com
UWA QQ群2:793972859(原群已满员)
Texture
Q:为什么我在我的项目中应用了Streaming Mipmap然而在GOT报告中看纹理内存没有降落?是没有正确失效还是统计有问题?
A:之前做过相干测试,发现GOT Online是能够统计到被Streaming Mipmap影响的纹理的正确内存的,所以我揣测你遇到的状况大概率还是没有正确失效导致的。以下是对如何让一张纹理利用Streaming Mipmap的简略流程总结,其中会注明须要特地留神的一些条件(有些被官网文档收录,有些则文档中没有,但试验证实为必要):
- 在Project Settings-Quality中开启Texture Streaming选项。然而试验发现Editor中开启该选项而真机上却会生效的景象,导致所有纹理的Streaming Mipmap设置全副生效。所以为了确保失效,首先应该在代码中调用QualitySettings.streamingMipmapsActive API全局地开启这个选项,能力确保Streaming Mipmap可用。
- 调整1中设置的参数。比拟重要的参数是Memory Budget参数和Max Level Reduction参数。Memory Budget示意纹理资源的估算,默认值是512MB,但依据UWA的大量我的项目数据来看,中低端机上个别为200MB左右。它的数值代表的是所有纹理资源的估算——即,它既包含了非流式的纹理、又包含了咱们想要采纳流式的纹理——但这个“估算”并不代表纹理资源可占用的下限,只是Unity判断对于一个开启Streaming Mipmap的纹理到底采纳它的哪些Mipmap通道的参考值,非流式纹理可能轻易冲破这个估算。
Max Level Reduction则是代表着Unity通过流式存储最高能取到哪一级的Mipmap通道,这个参数的优先级比Memory Budget要高,也就会造成理论内存超过预算的状况。(比方该参数为2时,则最多剔除Mipmap0和1通道,即使抛弃当前还远超出预算值也不会进一步剔除。)
也就是说,如果Memory Budget值设置的远高于我的项目中纹理理论占用的内存,则Texture Streaming可能齐全不起效,所有开启Streaming Mipmap的纹理仍将保留它们的全副Mipmap通道。
设置开启Streaming Mipmap的纹理。1、2中提到的设置只对开启了Streaming Mipmap的纹理起效,而这只是官网文档的说法,从实际操作来看,Texture Streaming只对同时满足以下三个条件的纹理失效:
1)开启了Streaming Mipmap且开启了Generate Mipmap的纹理(这一点官网文档中没有提及,事实上开启Generate Mipmap才会生成Mipmap通道供Streaming Mipmap剔除);
2)被即时加载的纹理(如一开始就曾经在场景中被依赖的纹理,即使开启了Streaming Mipmap其内存也不会发生变化,通过AssetBundle加载和Res.Load()加载的纹理则能够),也即官网文档中这句话的理论含意:
如果是进行Android开发,还须要关上Build Setting,并将Compression Method设置为LZ4或LZ4HC。Unity须要应用其中一种压缩办法进行异步纹理加载,这是纹理串流零碎所必须的操作。
3)Gfx局部内存(这里指的是纹理资源开启Read/Write选项时,复制到CPU端的那一部分内存是不受Streaming Mipmap影响的);
- Streaming Mipmap剔除Mipmap通道的法则。它的机制其实和Texture Quality是相似的。咱们晓得,开启Mipmap的纹理之所以会变成原来的4/3倍,实际上是它各个通道所占用的内存之和。举例而言,一个具备11个Mipmap通道的原大小为1MB的纹理(10241024分辨率、ASTC44格局),其内存占用为1+1/4+1/16+…的11项等比数列之和,即约4/3。等比数列的各项就对应了Mipmap0、Mipmap1、Mipmap2…等各个Mipmap通道。那么,当Max Level Reduction参数设置为2时,其实际意义就是保留Mipmap2和后续所有更小的通道,而剔除Mipmap0和Mipmap1通道,此时的内存大小为4/3MB-1MB-1/4MB=85.33KB。这和我在Profiler或GOT Online中看到的数据基本一致。
- 对于采纳Streaming Mipmap计划的倡议。根据上述试验和剖析不难看出,Streaming Mipmap是的确具备一些长处的,对于对内存比拟敏感,尤其是纹理内存占用很大的我的项目,采纳Streaming Mipmap计划是十分正当和举荐的选项。与此同时,它的理论应用要求对我的项目中纹理资源的内存占用有相当的理解和布局——相干设置在Quality中,天经地义地应该思考到不同设施Lod分级时不同的设置。在中低端机中,设置尽量低的Memory Budget和尽量高的Max Level Reduction;在高端机上则恰恰相反,在内存可承受范畴内尽量开启最好的画面体现。除此之外,对于哪些纹理要开启Streaming Mipmap,个别是场景中3D物体的纹理,而UI模块采纳的纹理则尽量敞开。因为Mipmap的意义次要在于适应纹理在间隔镜头远近时的体现须要、防止失真等,而UI齐全不须要这些,开启只会白白浪费内存和计算工夫。
感激Faust@UWA问答社区提供了答复
Network
Q:网络协议规定对立应用大端数据传输,然而测试用小端数据发送,而后服务器收到间接返回给客户端,客户端能够正确解析。所以就有个疑难:数据传输不须要大小端转换?还是底层帮忙转了?
测试例子如下:音讯头部固定4个字节,值为body的长度。服务器没做任何解决收到音讯间接返回。客户端收到音讯先解析头部长度4个字节,拿到body长度再获取body具体数据。没有大小端转换然而解析都正确:
{ // 测试发送整数 var bodyMsg = "测试发送数据"; var bodyBytes = Encoding.UTF8.GetBytes(bodyMsg); // 发送头部长度,固定4个字节 int headLen = bodyBytes.Length; var headBytes = BitConverter.GetBytes(headLen); // 发送头部长度音讯 _sendSocketAsyncEventArgs.SetBuffer(headBytes, 0, 4); _socket.SendAsync(_sendSocketAsyncEventArgs); // 发送body音讯 _sendSocketAsyncEventArgs.SetBuffer(bodyBytes, 0, bodyBytes.Length); _socket.SendAsync(_sendSocketAsyncEventArgs);}
A:测试发送的数据只有在多字节数据处理时才须要思考字节序,如果是Protobuf,是不必思考字节序的。
底层不会主动进行大小端转换,须要写代码,所以个别都是我的项目初期就约定好。<br/>
另外,如果把服务器放到不同物理机则测试后果就是错掉的,正确做法是得把发送数据转为大端,比方下面音讯头要加上 if (BitConverter.IsLittleEndian) { Array.Reverse(headBytes); } ,而后在收到数据后再转为小端。
感激萧小俊@UWA问答社区提供了答复
Texture
Q:请问纹理的格局设置项,BuildSettings外面Texture Compression,Default和Override,这几个是什么关系?
A:纹理设置中Override For Android这一项的优先级最高;不勾选Override的状况下是Default中的格局。如果既没有勾选Override,也没有扭转Default标签下的格局设置,并且批改了Texture Compression选项,才会采纳Texture Compression的格局设置,并且也只对合乎上述条件的纹理失效。
感激宗卉轩@UWA问答社区提供了答复
Script
Q:咱们我的项目开发过程中应用Log还是比拟多的,测试的时候发现对性能影响比拟大、所以想在下版本中排除掉Log再看看性能数据。有没有比手动正文Log更好的办法?另外Release版本还会有Log吗?
A1:能够本人封装一个Log函数,Log函数外部再代用Debug.Log。能够在Void上加上[Conditional(“DEVELOPMENT_BUILD”),Conditional(“UNITY_EDITOR”)],这样只有Debug版本和Editor才会调用。
感激萧小俊@UWA问答社区提供了答复
A2:补充一下,较新版的Unity中提供了接口Debug.unityLogger.logEnabled = false,放在打Log的逻辑之前就能防止所有Debug类触发的所有Log了。另外Release版本是无奈革除Debug.Log的,还是要尝试用楼上或者API的形式去革除。
感激Faust@UWA问答社区提供了答复
封面图来源于网络
明天的分享就到这里。当然,生有涯而知无涯。在漫漫的开发周期中,您看到的这些问题兴许都只是冰山一角,咱们早已在UWA问答网站上筹备了更多的技术话题等你一起来摸索和分享。欢送酷爱提高的你退出,兴许你的办法恰能解他人的当务之急;而他山之“石”,也能攻你之“玉”。
官网:www.uwa4d.com
官网技术博客:blog.uwa4d.com
官网问答社区:answer.uwa4d.com
UWA学堂:edu.uwa4d.com
官网技术QQ群:793972859(原群已满员)