Developer/FlowScope

Fork 0

Files

$JSD\13999$ JSD\13999 491eb27cd2 提交文档

2026-06-18 15:11:42 +08:00

12 KiB

Raw Permalink Blame History

Loxodon Framework Core 分析

分析对象：https://github.com/vovgou/loxodon-framework/tree/master/Loxodon.Framework/Assets/LoxodonFramework

分析日期：2026-06-12

结论

Loxodon Framework 的 Core 本质上是一个 Unity MVVM + DataBinding 运行时核心，而不是覆盖完整游戏生命周期的游戏框架内核。

它的核心价值集中在：

用 Context 和 ServiceContainer 提供全局/局部上下文与轻量服务注册。
用 BindingServiceBundle 装配 DataBinding 所需的 Parser、Converter、SourceProxy、TargetProxy、Binder。
用 ViewModelBase、ObservableObject、Observable Collection 支撑 ViewModel 状态变化。
用 UIView、Window、WindowManager 提供 UI 视图、窗口状态和转场管理。
用 Messenger、Command、Async、Prefs、Localization 等模块补齐 MVVM UI 开发所需的基础设施。

因此，Loxodon 更适合作为 FlowScope 的 UI / Binding / ServiceBundle 外围模块参考，不适合作为 FlowScope Kernel 的边界模板。

Core 模块拆解

Context

源码位置：

Context 维护静态 ApplicationContext 和按 key 注册的多个 Context，每个 Context 内部有：

IServiceContainer
属性字典
可级联查询的 parent context

ApplicationContext 在 Context 基础上补了：

IMainLoopExecutor
Global Preferences
User Preferences

这个设计方便应用层快速拿到全局能力，但也说明 Loxodon 的 Core 并不是纯机制内核。它把主线程执行器和 Prefs 这类应用级能力直接放进了全局上下文。

ServiceContainer

源码位置：

ServiceContainer 是轻量服务定位器，支持：

按 Type 注册对象或 factory。
按 string name 注册对象或 factory。
Resolve<T>() / Resolve(string) 解析服务。
Unregister<T>() / Unregister(string) 注销服务。

ServiceBundle 是模块装配入口：

public interface IServiceBundle
{
    void Start();
    void Stop();
}

AbstractServiceBundle 把容器传给 OnStart / OnStop，由具体 bundle 负责注册和注销一组服务。

这个模式对 FlowScope 有参考价值：模块可以用显式 Start/Stop 完成能力注册，避免散落的静态初始化。

Binding

源码位置：

Binding 是 Loxodon Core 最厚、最核心的部分。

BindingServiceBundle 会装配：

PathParser
ExpressionPathFinder
ConverterRegistry
ObjectSourceProxyFactory
SourceProxyFactory
TargetProxyFactory
BindingFactory
StandardBinder

然后注册：

IBinder
IBindingFactory
IConverterRegistry
IExpressionPathFinder
IPathParser
INodeProxyFactory
ISourceProxyFactory
ITargetProxyFactory

这说明 Loxodon 的 Binding 不是简单的反射赋值，而是一条可扩展管线：

BindingDescription
  -> Path / Expression
  -> SourceProxy
  -> Converter
  -> TargetProxy
  -> Binding

README 也强调该框架围绕 DataBinding 做了性能优化：减少装箱、降低 GC、通过动态委托或静态织入降低反射成本。

ViewModel / Observable

源码位置：

ViewModelBase 继承 ObservableObject，核心职责是：

封装属性变更。
触发 PropertyChanged。
可选通过 IMessenger 广播 PropertyChangedMessage<T>。

典型路径是：

ViewModel property set
  -> Set<T>
  -> field updated
  -> RaisePropertyChanged
  -> optional Messenger.Publish(PropertyChangedMessage<T>)
  -> Binding updates target UI

这是标准 MVVM 的数据驱动 UI 模型。

View / Window

源码位置：

UIView 负责 Unity UI 基础行为：

RectTransform
CanvasGroup
Visibility
Enter / Exit Animation
Enable / Disable event

Window 在 UIView 基础上增加：

WindowType
windowPriority
WindowState
activated / dismissed / visibility changed event
state broadcast

WindowManager 管理窗口集合、当前窗口、可见窗口和转场执行。

这部分是 UI 框架能力，不是游戏 Feature 生命周期管理。

Messaging / Command / Async / Prefs

源码位置：

这些模块服务于 MVVM/UI 工程化：

Messenger：按消息类型和 channel 做发布订阅。
RelayCommand：给 UI 事件绑定命令。
AsyncResult / ProgressResult / CoroutineTask：把异步、协程、进度结果统一成可等待对象。
Preferences：默认基于 PlayerPrefs，支持全局和用户偏好。

这些能力有实用价值，但它们放在 Core 中会让 Core 变厚。对 FlowScope 来说，应当拆成独立模块或适配层，而不是进入 Kernel。

架构优点

1. MVVM UI 工程化成熟

Binding、ViewModel、Command、Window、Messenger 形成了完整闭环。对于 UI 重、状态同步复杂、需要数据绑定的 Unity 项目，Loxodon 能显著减少手写 UI 刷新代码。

2. Binding 管线拆得足够细

SourceProxy、TargetProxy、Converter、PathParser、Binder 的拆分使绑定系统具备较强扩展性。不同 UI 系统或不同数据源可以通过 proxy/factory 接入，而不是改主流程。

3. ServiceBundle 模式简单可控

Start/Stop 注册/注销一组服务，适合插件化装配。相比全局静态初始化，这种方式更容易表达模块边界。

4. 有性能意识

README 中明确强调减少 value type 装箱、减少 GC、优化绑定性能。这说明 Loxodon 的设计目标不是单纯追求抽象，而是面向 Unity UI 高频更新场景。

架构局限

1. Core 边界偏厚

ApplicationContext 直接提供主线程执行器和 Preferences，Preferences 默认落到 PlayerPrefs，Messenger.Default 也带有全局静态倾向。

这些设计让使用更方便，但会让 Core 逐步吸收平台、存储、消息、UI 等应用级能力。

2. 不是完整游戏框架内核

Loxodon Core 没有把以下能力作为主轴：

游戏 Feature 生命周期
模块启动顺序
资源后端边界
配置表加载边界
存档版本迁移
热更新策略
场景/流程切换策略

它的插件生态里有 Addressable、Data、XLua、ILRuntime 等扩展，但 Core 本体的主轴仍然是 MVVM/DataBinding。

3. 对小团队很省事，对强边界内核有侵蚀风险

如果项目目标是快速做 UI 驱动业务，Loxodon 的全局上下文和内置 Prefs 会很方便。

但如果目标是 FlowScope 这种机制型内核，直接照搬会让 Kernel 同时承担 UI、Prefs、Messaging、Async、Binding 等职责，边界会变得越来越难控。

对 FlowScope 的借鉴建议

可以借鉴

ServiceBundle 的模块装配方式

FlowScope 的 P1/P2 模块可以采用类似显式装配模式：

ModuleBundle.Start(container)
  -> register contracts
  -> register default implementations
  -> register adapters

ModuleBundle.Stop(container)
  -> unregister contracts
  -> release module-owned state

Binding 管线的分层思想

如果 FlowScope 后续需要 UI Binding 或 Editor Binding，可以参考 Loxodon 的拆分：
```
Source
Target
Path
Converter
Binder
BindingContext
```
但这应该作为 UI 扩展模块，而不是 Kernel 机制。
ViewModelBase 的属性变更封装

Set<T> 模式可以降低 ViewModel 代码重复，也能统一 PropertyChanged 和消息广播策略。
Window 状态模型

Window / WindowManager 对弹窗、页面、转场、可见性和激活状态有参考价值，可用于 FlowScope UI 模块设计。

不建议照搬

不要把 Prefs 放进 Kernel

FlowScope 的 Save / Prefs / PlayerPrefs 应保持在 Save 模块或 Unity Adapter 中。
不要把 Messenger 作为 Kernel 默认通信机制

消息总线容易变成隐式耦合通道。Kernel 应保持 Feature 生命周期和 Slot/Policy 机制清晰，事件系统应作为 P1/P2 模块单独设计。
不要把 UI Window 放进 Kernel

UI 是 Feature/Module 的外围能力。Kernel 只需要管理 Feature 的启动、替换、停止策略，不应知道 Window 栈。
不要用全局 ApplicationContext 承载所有能力

FlowScope 更适合显式 Bootstrap + Container + FeatureContext。全局上下文可以作为上层便利入口，但不应成为 Kernel 的事实中心。

与 FlowScope Kernel 边界的关系

FlowScope 当前更适合保持：

Kernel
  -> Container
  -> AppKernel
  -> StartupPipeline
  -> FeatureHost
  -> FeatureInstance
  -> FeatureContext
  -> FeatureLifetime
  -> FeatureSlot
  -> FeaturePolicy

Loxodon 的能力更适合放在：

FlowScope.UI
  -> ViewModel
  -> Binding
  -> Window / Panel
  -> Command

FlowScope.Events
  -> Messenger / EventBus

FlowScope.Save.Unity
  -> PlayerPrefs adapter

FlowScope.Runtime.Extensions
  -> ServiceBundle helpers

换句话说，Loxodon 对 FlowScope 的启发是：外围模块可以做厚，Kernel 必须保持薄。

最终判断

Loxodon Framework 的 Core 是一个成熟的 Unity MVVM/UI 运行时。它适合解决 UI 数据绑定、ViewModel 状态传播、窗口管理和 UI 事件命令化问题。

但它不是 FlowScope Kernel 的直接模板。对 FlowScope 来说，最值得吸收的是：

ServiceBundle 式模块装配。
Binding 管线拆分方式。
ViewModel 属性变更封装。
Window 状态管理经验。

最需要避免的是：

把 Prefs、UI、Messaging、Binding 一起塞进 Core。
用全局上下文替代显式生命周期。
让 Kernel 从机制层滑向应用便利层。

12 KiB Raw Permalink Blame History Unescape Escape

Loxodon Framework Core 分析

结论

Core 模块拆解

Context

ServiceContainer

Binding

ViewModel / Observable

View / Window

Messaging / Command / Async / Prefs

架构优点

1. MVVM UI 工程化成熟

2. Binding 管线拆得足够细

3. ServiceBundle 模式简单可控

4. 有性能意识

架构局限

1. Core 边界偏厚

2. 不是完整游戏框架内核

3. 对小团队很省事，对强边界内核有侵蚀风险

对 FlowScope 的借鉴建议

可以借鉴

不建议照搬

与 FlowScope Kernel 边界的关系

最终判断

12 KiB

Raw Permalink Blame History