完成 P2 前架构整改
This commit is contained in:
JSD\13999
@@ -9,7 +9,7 @@
|
||||
|
||||
FlowScope 当前已经具备一个轻量游戏框架的基本形态，适合用于小型项目、原型项目或作为后续框架演进的 P0 基座。它的优势在于分层清晰、抽象克制、测试意识较好，并且围绕 Unity 常见横切能力建立了可替换接口。
|
||||
|
||||
当前不建议直接定义为稳定生产框架。主要原因是资源异步、运行时对象销毁、Addressables 依赖方式和自研 JSON 转换器仍存在生产风险。这些问题不影响它作为框架雏形继续推进，但应作为进入生产复用前的前置整改项。
|
||||
当前不建议直接定义为稳定生产框架。主要原因是运行时对象销毁、自研 JSON 转换器、AOT/linker 验证和真实 Unity Test Runner 验收仍存在生产风险。这些问题不影响它作为框架雏形继续推进，但应作为进入生产复用前的前置整改项。
|
||||
|
||||
## 2. 技术基线
|
||||
|
||||
@@ -57,7 +57,7 @@ FlowScope 当前已经具备一个轻量游戏框架的基本形态，适合用
|
||||
|
||||
代表文件：`Runtime/Container/Container.cs`
|
||||
|
||||
自研容器实现轻量，支持实例注册、工厂注册、作用域、父子容器、循环依赖检测和拥有对象释放。
|
||||
自研容器实现轻量，支持实例注册、singleton factory、scoped、transient、父子容器、循环依赖检测和拥有对象释放。
|
||||
|
||||
优点：
|
||||
|
||||
@@ -70,30 +70,29 @@ FlowScope 当前已经具备一个轻量游戏框架的基本形态，适合用
|
||||
|
||||
- `GeneratedFactories` 需要外部注册，长期需要配套生成器或明确手写规范。
|
||||
- 反射工厂适合开发期，但移动端/AOT 环境需要持续验证。
|
||||
- 当前没有生命周期枚举，例如 transient、scoped、singleton，实际行为需要文档明确。
|
||||
- `RegisterFactory` 仍保留为旧式 lazy singleton 兼容入口，需要避免在新代码中用于 Feature/ViewModel/短生命周期对象。
|
||||
|
||||
评价：P0 阶段可接受。后续重点不是扩大能力，而是写清注册规范和 AOT 策略。
|
||||
评价：P0/P1 阶段可接受。后续重点不是扩大能力，而是保持生命周期语义稳定、写清注册规范和 AOT 策略。
|
||||
|
||||
### 3.3 Resources
|
||||
|
||||
代表文件：`Runtime/Resources/AddressablesResourceService.cs`
|
||||
代表文件：`Runtime/Resources/ResourceService.cs`、`Addressables/AddressablesResourceBackend.cs`
|
||||
|
||||
资源层抽象了 `IResourceService`、`IResourceHandle<T>` 和 `IResourceGroup`，并实现了 Addressables 加载、引用计数和分组释放。
|
||||
资源层抽象了 `IResourceService`、`IResourceHandle<T>`、`IResourceGroup` 和 `IResourceBackend`，Runtime 核心负责共享加载、引用计数和分组释放，Addressables 适配位于独立 asmdef。
|
||||
|
||||
优点：
|
||||
|
||||
- 使用句柄释放资源，方向正确。
|
||||
- 支持同 key 同类型加载去重。
|
||||
- `ResourceGroup` 适合跟随 Feature 生命周期批量释放。
|
||||
- PlayMode 测试覆盖了复用、引用计数和取消等路径。
|
||||
- EditMode / PlayMode 测试覆盖了复用、引用计数、取消等待和完成后释放等路径。
|
||||
|
||||
风险：
|
||||
|
||||
- Addressables 通过字符串反射调用，编译期无法发现 API 变化。
|
||||
- Runtime asmdef 没有显式引用 Addressables，当前设计牺牲了类型安全。
|
||||
- 取消等待后底层 Addressables 任务可能仍继续执行，后续需要确认资源完成后的释放策略。
|
||||
- Addressables 真实 load/release 仍缺少最小集成测试资源。
|
||||
- 取消等待后底层共享加载仍会继续执行，这是设计选择；需要继续用测试保护“所有等待者取消后完成即释放”的语义。
|
||||
|
||||
评价：抽象方向正确，但 Addressables 适配层应从 Runtime 核心拆出，改为显式依赖的独立 asmdef。
|
||||
评价：抽象方向正确，Runtime 核心与 Addressables 适配层已经拆开；下一步重点是真实 Addressables 集成验收。
|
||||
|
||||
### 3.4 UI
|
||||
|
||||
@@ -130,11 +129,11 @@ UI 模块基于 `UIPanelAttribute` 标记层级和路径，通过 `UIManager`
|
||||
|
||||
风险：
|
||||
|
||||
- `LoadClip` 内部使用 `.GetAwaiter().GetResult()` 同步等待异步资源加载，在 Unity 主线程和 Addressables 场景下存在卡顿或死锁风险。
|
||||
- 同步播放 API 只适合读取已经预加载或已完成的资源；调用者如果误用未预加载资源，会得到明确异常而不是阻塞等待。
|
||||
- 音频服务是 `MonoBehaviour`，但依赖通过 `Initialize` 注入，需要文档明确创建流程。
|
||||
- 当前播放接口是同步方法，与异步资源系统存在模型冲突。
|
||||
- 新业务仍应优先使用 `PlayBgmAsync` / `PlaySfxAsync`，避免把同步 API 当作资源加载入口。
|
||||
|
||||
评价：功能够用，但异步资源加载方式必须调整后才适合生产复用。
|
||||
评价：功能够用，旧的同步阻塞风险已降低；生产复用前仍需继续明确同步 API 的使用边界。
|
||||
|
||||
### 3.6 Save / Config / Data
|
||||
|
||||
@@ -183,12 +182,11 @@ UI 模块基于 `UIPanelAttribute` 标记层级和路径，通过 `UIManager`
|
||||
|
||||
| 优先级 | 风险 | 影响 | 建议 |
|
||||
| --- | --- | --- | --- |
|
||||
| P0 | `AudioService` 同步等待异步资源 | 可能导致主线程卡顿或死锁 | 改为异步播放或预加载机制 |
|
||||
| P0 | Runtime 使用 `DestroyImmediate` | 运行时生命周期不稳 | 改为 `Destroy`，测试按帧等待 |
|
||||
| P1 | Addressables 反射调用 | 类型安全弱，升级风险高 | 拆独立 Addressables 适配 asmdef |
|
||||
| P1 | Addressables 真实集成测试不足 | 适配层编译通过不等于真实 load/release 验收通过 | 增加最小 Addressables 测试资源或人工验收步骤 |
|
||||
| P1 | 自研 JSON 转换器 | 边界和维护成本高 | 明确 DTO 限制或接入成熟 JSON 库 |
|
||||
| P1 | `GameFlow` 固定加载配置 | 启动流程不够弹性 | 配置加载移到 Bootstrap 或可选策略 |
|
||||
| P2 | 容器生命周期语义文档不足 | 使用者容易误判对象生命周期 | 补充注册和释放规范 |
|
||||
| P2 | `RegisterFactory` 兼容入口仍可能误用 | 使用者可能把 lazy singleton 用于短生命周期对象 | 新代码使用 `RegisterSingletonFactory` / `RegisterScoped` / `RegisterTransient` |
|
||||
|
||||
## 6. 审批意见
|
||||
|
||||
@@ -209,9 +207,9 @@ UI 模块基于 `UIPanelAttribute` 标记层级和路径，通过 `UIManager`
|
||||
前置整改项：
|
||||
|
||||
1. 将 `UIManager` 运行时销毁逻辑从 `DestroyImmediate` 调整为 `Destroy`。
|
||||
2. 将 `AudioService` 的资源加载从同步阻塞改为异步或预加载模型。
|
||||
3. 为 Addressables 适配明确依赖策略，优先拆出独立 asmdef。
|
||||
4. 补充框架使用约定文档，包括 Bootstrap、Feature、资源释放、UI 路径、配置 DTO 限制。
|
||||
2. 为 Addressables 适配增加真实 load/release 最小验收。
|
||||
3. 明确 Config/Save DTO 与 AOT/linker 限制。
|
||||
4. 在进入 P2 包分发前补一次 Unity Test Runner 全量验收记录。
|
||||
|
||||
## 7. 后续建议
|
||||
|
||||
@@ -239,23 +237,23 @@ UI 模块基于 `UIPanelAttribute` 标记层级和路径，通过 `UIManager`
|
||||
| --- | --- | --- |
|
||||
| 架构清晰度 | 良好 | 模块边界清楚，抽象克制 |
|
||||
| 可测试性 | 良好 | 已有较完整 EditMode/PlayMode 测试 |
|
||||
| Unity 生命周期安全 | 一般 | `DestroyImmediate` 和同步等待需修正 |
|
||||
| Unity 生命周期安全 | 一般 | `DestroyImmediate` 与 Unity Test Runner 验收仍需收口 |
|
||||
| 生产稳定性 | 一般 | 仍处于 P0/P1 框架雏形 |
|
||||
| 可演进性 | 良好 | 适合继续拆模块、补规范、稳定 API |
|
||||
|
||||
综合评级：B+。
|
||||
|
||||
结论摘要：FlowScope 是一个有工程意识的轻量 Unity 框架骨架，值得继续推进；但在正式生产复用前，需要优先修正异步资源、运行时销毁和 Addressables 依赖方式三个关键问题。
|
||||
结论摘要：FlowScope 是一个有工程意识的轻量 Unity 框架骨架，值得继续推进；但在正式生产复用前，需要优先修正运行时销毁、真实 Addressables 验收和 AOT/JSON 边界三个关键问题。
|
||||
# P1 更新记录（2026-05-20）
|
||||
|
||||
P1 已完成第一批生产化硬化，评审风险状态同步如下：
|
||||
|
||||
| 原风险 | P1 状态 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| Addressables 反射调用 | 已降低 | Addressables 适配已从 Runtime 核心拆出到 `FlowScope.Addressables` 独立 asmdef，核心资源系统通过 `IResourceBackend` 工作。最终验收仍等待 Unity 完成 Addressables 包解析。 |
|
||||
| Addressables 反射调用 | 已降低 | Addressables 适配已从 Runtime 核心拆出到 `FlowScope.Addressables` 独立 asmdef，核心资源系统通过 `IResourceBackend` 工作。包解析与生成项目编译阻塞已解除，仍缺真实 load/release 验收。 |
|
||||
| 自研 JSON 转换器缺少扩展点 | 已降低 | Config 增加 `IConfigSource` / `IConfigParser`，Save 增加版本 envelope 与 `ISaveMigration` 链。长期是否替换成熟 JSON 库仍是 P2 决策。 |
|
||||
| UI 缺少轻量导航与预加载 | 已降低 | 新增 `UIScreenNavigator` 与 `UIPreloadService`，并补充 PlayMode 编译级测试。 |
|
||||
| 样例不能体现生产化装配 | 已降低 | MainMenuP0 已改为 P1 装配方式，覆盖启动、点击、保存恢复和资源释放。 |
|
||||
| Package/editor tooling | 保持 P2 | 本轮没有做包分发、编辑器工具和跨项目模板化。 |
|
||||
|
||||
当前结论仍是“有条件通过”：P1 代码与文档已落地，但完整 Unity Test Runner 和人工场景验收需要在 Unity 工程未被占用、Addressables 包解析完成后补跑。
|
||||
当前结论仍是“有条件通过”：P1 代码与文档已落地，P2 前整改已收束 Container/Feature 生命周期、样例 Bootstrap 启动模型、资源取消与 UI 预加载边界；完整 Unity Test Runner 和人工场景验收仍需补跑。
|
||||
|
||||
Reference in New Issue
Block a user