引擎系统设计思路 - 用户态与系统态隔离

为何要做隔离：

        1. 核心实现目标不一样。就如国防力量守住国门，百姓则安居乐业。

        2. 利用的资源不一样。

        3. 如果实现了隔离，两方可以按照各自的习惯与特性自由生长。

用户态与系统态隔离：

        从用户的角度看系统:  得到我想要的结果，系统能给我什么？，我又该给系统准备好什么？

        从系统的角度看用户:  你向我要的东西我，我立刻以某种形式给你。你准备要给我需要的东西，我用的时候自取。

        a. 外部用户侧的对象或者逻辑，在外部创建使用。内部系统侧的对象或者逻辑，在内部创建使用。

        b. 用户状态下对内部系统的操作要立即响应，但是具体如何实际执行系统内部的机制，则是异步并行的。因为有异步，也可以或者提供保留同步机制。

        c. 用户态与系统态之间不会建立直接的依赖关系他们的关系是异步并行的。前者负责面向用户行为，后者负责面向引擎内部系统的管理行为(包括资源管控，算力使用，渲染机制的动态生成与调度等等)。总体来讲，前者是数据和行为约束的提供方，而后者会依据实际策略具体使用这些数据和实现预期的行为结果。

        d. 用户态的正确执行，并不会受到系统态的限制。反之亦然。

        情景类比说明：银行客户需要处理一个账户上的事情(此银行的相关业务)，他将此事交给银行的一个客服。在处理过程中(不管是否此事已经在处理中)，此客户持续告诉客服各种可能的调整。最终账户事宜处理完成，符合银行的需求进而正常接入相关财务事宜。这里的客户，可以看做是用户态。而客服以及银行则是系统态。整个事情的推进中，双方保持信息同步但是异步并行(信息或者数据或者叫结果一致/同步，才是我们真正关心的，而不是操作)。

说大一点，虚拟机这种机制，就是典型的例子。

        误区：

                1. 将客户(业务)实现强关联到系统内，甚至在系统内去实现。这么做看似可行，实则可怕。可能有人会说因为敏捷需要而为之，实际上是不愿分析思考而且不顾及成本投入。一步错、步步错，就是这么来的。要防止极端情况下有的产品，需求做完，产品作废，企业做跪。出现这种结果，说白了，是经营管理能力问题，是技术产品认知问题，没啥好说的。不过，记住好事多磨，就事论事，莫动气啊(哈哈哈)。

                2. 也有人觉得这样一个好的系统实现，需要巨大的投入。恰恰相反，这只是需要一个"自律"的迭代过程，边开发边迭代是一起进行的。因为隔离，所以容易迭代，而迭代又促进了隔离。就如健身和减肥一样。明知道健康和身材是关键要素，所以注意健身就是日常，而不是等到健康和身材都成为难题了，才来关注和处理。重要的事情要持续关注和协调，而非靠感觉选择性无视。奇迹和神迹都是有严苛条件的，不可随意向往。魔鬼藏在细节中。圣人老子很早很早就说过，天下大事必作于细，天下难事必作于易， 可反过来行吗？

达到的目的：

        1. 使用的时候，各司其职，保持高效。

        2. 运行的时候, 各司其职，保持高效。

        3. 升级迭代的时候，各司其职，保持高效。

        4. 将相对复杂和重要的工作交给系统接管，而不需要用户负责。

        6. 将复杂而广泛的应用形式交给用户实现，尽量不干扰用户的使用自由度。

        7. 用户态边界内，随时创建，随时销毁。

其他相关:

        1. 引擎系统设计思路 - 支撑高效能3D虚拟视觉系统的七个维度-CSDN博客

        2. 3D系统中可渲染实体容器(Renderable Entity Container)-CSDN博客