共计 3583 个字符，预计需要花费 9 分钟才能阅读完成。
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（原群已满员）
