使用ScriptableObject代替部分配置表的坑点

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:之前的项目曾经用过这种方式做配置表,但是随着表格和配置的增加,会出现许多问题,比如以下几个:

  1. 内存:内存要比普通的加载、解析二进制文件要大不少,大概有8倍。
  2. 加载速度:加载速度比普通的解析二进制要慢十倍以上,也是个大概值,毕竟是三年前做的项目了。
  3. 卡顿:ScriptableObject的加载和解析都在主线程,会卡主线程,而自己实现的二进制可以自己写个子线程去解析,就算在主线程解析起来也很快。这块大概也是十倍的量级。
  4. 硬盘:如果二进制不压缩,其实硬盘上差距不那么大,但是稍微用zip压缩一下,就有十倍的差距了。
  5. 策划:如果面对大量的数据,Excel显然更能帮助策划高效地配置,比如现在需要配置100个道具,如果用ScriptableObject比较复杂。
  6. Runtime:Runtime修改虽然做不到,但是热重载是可以做到的,效率也不差多少。
  7. 资源可拖拽:这个功能你调查过策划是否喜欢了吗?
  8. 热更新:如果项目使用的语言是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:解答第一个问题:

  1. 可以针对重复数据进行剔除,尤其是一些字符串的配置。在配置导出时把这样的数据提取一份,其他用到的地方只是引用,会节省不少。
  2. 数据类型要合理。
  3. 可以使用类似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,就能在模拟器上显示正常,但手机上就颜色太亮了,如下图:

使用ScriptableObject代替部分配置表的坑点_第1张图片

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(原群已满员)

你可能感兴趣的:(script,rendering,editor,resource)