最近 DOTS 玩的比较多, 也来凑合几句. 首先针对高赞回答中的一些言论正一下试听:
是也不是, 准确来说, 能解决性能问题的技术是 JobSystem 和 Burst, ECS 只是专注于 Unity 应用长期以来缺乏的架构问题, 只不过 ECS 架构所特有的 Data-Orient 特性能更容易地解决 JobSystem 和 Burst 所需良好结构数据的问题.
能接近 Free Performance 的技术是 Burst, 唯一需要做的就是使用新的 Unity.Mathematics 来编写程序, 当然目前也有不少的限制(比如必须要blittable数据, 不支持 Class等), 同时也会有许多莫名其妙的 Bug (我甚至遇到过运行时内存数据被污染), 因此建议在开发阶段可以完全把 Burst 关掉.
Unity 目前在ECS上的动作是希望利用 ECS 的编译器将 JobSystem 也变为 Free Performance, 比如下面的代码就已经是 Jobify 过的代码, 不过用户可以几乎无感:
对比一下没有 Jobify 的写法:
与此同时, 使用 ECS 的另一个好处(或坏处)是, 你之前关于 Unity 专有的许多性能优化知识都没用了, 什么 Object Poolling, Instancing, Scene Streaming, Caching Components , GameObject.Find 等等都永远说再见了.
恰恰相反, 因为面向数据设计的初衷就是为了解耦合, 你见过谁在设计数据库时出现"耦合度"问题吗?实际上 ECS 的编码过程就是设计数据的过程, 用好数据库的第一第二范式就能设计出相对良好的程序结构, ECS world 里的数据也可以完全和副作用说拜拜.
至于策划? 可以看看我翻译的基于 Game Object Conversion 和 SubScene 的 DOTS 开发工作流 你就能明白为何结论也是恰恰相反: DOTS 让两者的角色更加清晰分离, 策划你就别插手代码了. 什么? 你还是想改? Visual Scripting 了解一下.
很简单, 因为 H5 运行的环境恰恰是性能低下的 Mobile 平台, 性能这东西就像钱, 钱多就能买多点, 钱少买的少点, 并不是说我需要渲染上百万个对象才需要性能, 而是到处都需要性能, 这也是为啥 Unity 的口号是 Performance By Default. 而不是 Performance By 高工资程序员.
毫无必要的争论, 说这话的人知道 unsafe 关键字吗? 事实上, 不是 Unity 不在业务层面用Cpp, 而是 Unity 压根就不想用C++, 因此把整个引擎都逐渐转向 C# 了, 原有 C++ 的 Runtime Core 会越来越小, 新出的 Package 都是 C# based 的, 为啥? 因为 C# 开发体验好, Burst 和 JobSystem 又可以直接榨干 CPU , 两全其美.
不不不, 一点都不难, 之所以你觉得难, 是因为你没有转变过来 Data-Orient Design 的思想, 满脑子都还是继承一个 Person 类得到 Woman类, 这完全是两种处理问题的思路, 脑子转不过弯来当然觉得难了.
很简单, DOTS 现阶段在完成度上就是接近废品的残次品, 我在这里说到过现阶段的DOTS, 粘过来给你们看看.
非常遗憾, 经过了 Unity 长达近三年的宣传, DOTS到今天完成度依然极低, 基本上处于不可用的状态, 一款游戏引擎必不可少的部分可简单列为下面八个, 接下来我分开说说在 DOTS 技术栈里他们的现状
所以, 要怪就怪 Unity 的营销部门, 吹太过了, 步子太大扯到了蛋, 整个社区里弥漫着这样的气氛:
是的, 看起来是挺好的, 总的来讲 DOTS 肯定是未来, 现在是算是学习 DOTS 的不错时间, 最近正在写一个关于 DOTS Sample 的系列文章, 我会尽我所能将 DOTS Sample 所折射的 DOTS 的现阶段的优缺点和开发过程都理出来, 有兴趣的同学可以关注一下.
