1）应用ScriptableObject代替局部配置表的坑点
2）加载配置内存过大问题
3）URP的UI在Android模型器下比在真机上暗
4）Unity在Windows上第一次运行Play启动很慢
5）如何正确卸载UnityWebRequest下载的图片资源
这是第231篇UWA技术常识分享的推送。明天咱们持续为大家精选了若干和开发、优化相干的问题，倡议浏览工夫10分钟，认真读完必有播种。
UWA 问答社区：answer.uwa4d.com
UWA QQ群2：793972859（原群已满员）
Script
Q：ScriptableObject能够通过Runtime批改，资源能够拖拽配置。这些都是Excel无奈做到的劣势。
所以筹备尝试用ScriptableObject代替局部Excel的配置用在我的项目里。想晓得，ScriptableObject这样用，大家有没有遇到过比较严重的坑点？例如这样的Asset的加载、解析的空间或工夫上的开销是否可承受等等。
补充一下，比方配备是成组的，对每组配备做一个ScriptableObject对应的Asset拖一组配备Prefab援用，而后由内部持有ScriptableObject Asset的门路即可。像这种局部资源相干的配置走这套，粒度更细，一个Asset中蕴含的资源自身就是应该被同时加载的。这种状况是不是没有这种冗余加载的问题？
A1：之前的我的项目已经用过这种形式做配置表，然而随着表格和配置的减少，会呈现许多问题，比方以下几个：
- 内存：内存要比一般的加载、解析二进制文件要大不少，大略有8倍。
- 加载速度：加载速度比一般的解析二进制要慢十倍以上，也是个大略值，毕竟是三年前做的我的项目了。
- 卡顿：ScriptableObject的加载和解析都在主线程，会卡主线程，而本人实现的二进制能够本人写个子线程去解析，就算在主线程解析起来也很快。这块大略也是十倍的量级。
- 硬盘：如果二进制不压缩，其实硬盘上差距不那么大，然而略微用zip压缩一下，就有十倍的差距了。
- 策动：如果面对大量的数据，Excel显然更能帮忙策动高效地配置，比方当初须要配置100个道具，如果用ScriptableObject比较复杂。
- Runtime：Runtime批改尽管做不到，然而热重载是能够做到的，效率也不差多少。
- 资源可拖拽：这个性能你考察过策动是否喜爱了吗？
- 热更新：如果我的项目应用的语言是Lua，ScriptableObject会妨碍新增字段的更新，毕竟是C#申明的字段（或者后续有表格热更新增字段、表格的需要）。
以上状况如果都能承受，那么用ScriptableObject是能够的。据我所知，还是有一些上线我的项目是用这套计划的，并且也稳固经营了3年以上。
感激xiaobai@UWA问答社区提供了答复
A2：举个例子，比方一个配备表关联上百个配备模型。加载间接拖上去的ScriptableObject就得同时加载这上百个配备模型。如果不必拖拽援用，这个的可编辑性远远不如Excel。
感激欧月松@UWA问答社区提供了答复
A3：个别这种资源援用，能够思考应用一个可加载的门路或者地址来代替，防止间接援用带来的同时加载问题。
感激静风霁@UWA问答社区提供了答复
A4：ScriptableObject大部分时候还是没有Excel好用的，比方在公式和索引上，也无奈疾速定位配置谬误，然而大多数Editor的编辑器性能须要用到ScriptableObject。咱们我的项目的计划是Excel转Protobuf + ScriptableObject转Protobuf，运行时只加载Protobuf的二进制文件即可。
感激萧小俊@UWA问答社区提供了答复
Script
Q：配置表太多占用内存过大时，除了采纳Sqlite，还有什么好的解决办法吗？FlatBuffer不必全副进内存吗？如果不全副进内存，访问速度如何呢？
A1：解答第一个问题：
- 能够针对反复数据进行剔除，尤其是一些字符串的配置。在配置导出时把这样的数据提取一份，其余用到的中央只是援用，会节俭不少。
- 数据类型要正当。
- 能够应用相似FlatBuffer/ZeroFormatter的提早加载的思路，在真正应用时再去反序列化。一次游戏过程中理论用到的配置量比拟无限，应用这种策略能够尽可能地缩小不必要数据的加载（这一条可能次要实用于C#层去读配置的，如果你们是存成Lua这条就不肯定实用了）。
解答第二个问题：
咱们上个我的项目也是到前期优化时遇到相似问题，只是参考了这种思路，并没有进行齐全替换。在打包时，会对配置以行为单位，进行Offset和Length的计算；在Runtime阶段，初始加载只会加载每行的ID，对应的这一行的Offset和Length，而后后续逻辑调用配置表接口拿数据的时候，如果发现没有反序列化过，就依据Offset和Length再去构建一下相应的数据提供给下层。访问速度必定没有开始间接全副加载的好，但咱们测下来影响不大。
感激范君@UWA问答社区提供了答复
A2：字符串吃内存，尽量少用或者复用。
表格中比拟多的会是哪种？攻打-1000、进攻-2000、血量-3000，每个Int都是4个字节，数量多了会顶不住。这种能够思考用一个int32/int64/uint32/uint64去存多个数值。
感激萧小俊@UWA问答社区提供了答复
Rendering
Q：URP的UI在很多Android模型器下的显著比在手机上要暗很多。确认模拟器用的Gles3.0+ 反对Linear色调空间，看上去就像是模拟器对UI进行了一次额定的GammaToLinearSpace，如果在导入UI图片时把sRGB勾掉，或者进行一次LinearToGamma，就能在模拟器上显示失常，但手机上就色彩太亮了，如下图：
A1：最新进展：之前用2019.3.5f1，更新到2019.4.10f1就没有这个问题了。
感激题主loy_liu@UWA问答社区提供了答复
A2：Unity论坛有很多人反馈SRP + OPENGL ES + Linear Color Space在Android下面有渲染Bug。看下Player Settings->Android->Resolution and Presentation->Blit Type设置成Auto是否解决问题呢？
感激范君@UWA问答社区提供了答复
A3：2019.3.6f1的Release Note里有说到这个是Bug。
[Mobile: [Android] [Gles3] [URP] Darker UI when using Gles3, Linear and URP]
感激Xuan@UWA问答社区提供了答复
Editor
Q：Unity在Windows上第一次运行Play启动很慢，但在Mac上没有这个问题。该如何进行排查呢？
A1：Mac没问题，有可能是Play启动游戏的时候在扫描各种资源文件导致，能够排查下AssetPostprocessor相干的，比方OnPostprocessAllAssets是不是每次启动的时候都在遍历。
感激Kenji@UWA问答社区提供了答复
A2：如果是Editor的问题能够试一下Unity官网提供的编辑器耗时剖析工具Performance Tracking（2019.4+），低版本从Profiler中看看能不能定位到耗时。Performance Tracking
ScriptableObject导致的相似的问题
感激羽飞@UWA问答社区提供了答复
Resource
Q：通过UnityWebRequest和DownloadHandlerTexture下载的Texture资源，下载实现后赋值到RawImage组件，如何正确卸载UnityWebRequest下载的图片资源？
A：咱们上个我的项目此类Texture都会被专门的Manager治理起来，确保没有被其余GameObject援用后，应用Object.DestroyImmediate来销毁掉，尽管这个接口官网不举荐应用。或者能够尝试下确保没有援用后应用Object.Destroy卸载或期待下次调用Resources.UnloadUnusedAssets时来卸载。
感激范君@UWA问答社区提供了答复
封面图来自网络
明天的分享就到这里。当然，生有涯而知无涯。在漫漫的开发周期中，您看到的这些问题兴许都只是冰山一角，咱们早已在UWA问答网站上筹备了更多的技术话题等你一起来摸索和分享。欢送酷爱提高的你退出，兴许你的办法恰能解他人的当务之急；而他山之“石”，也能攻你之“玉”。
官网：www.uwa4d.com
官网技术博客：blog.uwa4d.com
官网问答社区：answer.uwa4d.com
UWA学堂：edu.uwa4d.com
官网技术QQ群：793972859（原群已满员）