qzl
286 lines
9.8 KiB
Markdown
286 lines
9.8 KiB
Markdown
# 前端导航解耦与统一缓存重构设计
|
||
|
||
## 1. 背景与问题定义
|
||
|
||
当前 `apps` 端在日历（日/月）与待办页面中存在以下系统性问题：
|
||
|
||
1. 页面切换语义错误：将业务 tab 切换实现为 `push/go` 混用，导致页面重建与路由栈膨胀。
|
||
2. 数据刷新触发错误：页面通过路由监听触发 `load`，频繁重复请求后端。
|
||
3. 状态职责耦合：导航状态、页面状态、数据状态边界不清，导致“切换逻辑改动会牵出数据 bug”。
|
||
4. 回主页语义不一致：Dock 首页按钮被 `canPop -> pop` 策略污染，行为变成“返回上页”。
|
||
5. 缓存能力分散：仅存在局部的个人信息缓存（`SettingsUserCache`），缺少统一可复用缓存模块。
|
||
|
||
目标是完成一次结构化重构，建立「解耦的导航切换 + 统一缓存 + 可控一致性」体系。
|
||
|
||
## 2. 目标与非目标
|
||
|
||
### 2.1 目标
|
||
|
||
1. Home/Calendar/Todo 切换不重建主页面（保持页面实例与滚动状态）。
|
||
2. 日/月视图切换不触发整页重建和无必要网络请求。
|
||
3. 建立统一缓存模块，合并个人信息缓存并覆盖 Calendar/Todo 数据读取。
|
||
4. 启动体验采用「本地优先 + 后台静默刷新」策略，减少进入 App 的重复请求。
|
||
5. 数据只在必要时刷新：手动下拉、写操作失效、生命周期关键点、缓存策略命中。
|
||
6. 主页按钮语义固定为“回主页”，不再变成“返回上一页”。
|
||
|
||
### 2.2 非目标
|
||
|
||
1. 本次不改后端协议与接口契约。
|
||
2. 本次不引入复杂离线同步冲突解决（如多端 CRDT）。
|
||
3. 本次不引入全量本地数据库迁移（先基于 SharedPreferences 持久化层）。
|
||
|
||
## 3. 复杂度与风险分级
|
||
|
||
- Complexity: `S3`
|
||
- 跨 router、calendar、todo、settings、DI 的架构级调整。
|
||
- Risk Tier: `L1`
|
||
- 不触及鉴权协议和支付等高风险域，但涉及导航返回栈与数据一致性高回归区。
|
||
|
||
## 4. 架构总览
|
||
|
||
### 4.1 导航分层
|
||
|
||
采用两级导航：
|
||
|
||
1. 一级（主容器）：`StatefulShellRoute.indexedStack`
|
||
- 分支：Home / Calendar / Todo
|
||
- 作用：保活分支页面，避免 tab 切换重建。
|
||
2. 二级（分支内部）
|
||
- Calendar 分支：管理 month/day 主视图切换 + event detail/edit/share 子路由。
|
||
- Todo 分支：管理 list/detail/edit 子路由。
|
||
|
||
### 4.2 状态与数据边界
|
||
|
||
1. 导航状态：Shell 当前分支 index、Calendar 内部视图类型。
|
||
2. UI 状态：选中日期、滚动位置、拖拽态、loading/error。
|
||
3. 数据状态：统一缓存模块管理（内存 + 持久化 + 网络回写）。
|
||
|
||
结论：页面只发“意图”，不直接承担缓存与路由策略。
|
||
|
||
## 5. 统一缓存模块设计
|
||
|
||
## 5.1 模块结构
|
||
|
||
新增 `apps/lib/core/cache/`：
|
||
|
||
1. `cache_key.dart`
|
||
- 统一 key 命名规范。
|
||
2. `cache_policy.dart`
|
||
- TTL、软/硬过期、最小刷新间隔、刷新原因枚举。
|
||
3. `cache_entry.dart`
|
||
- 标准缓存实体（data/fetchedAt/expiresAt/version/dirty）。
|
||
4. `cache_store.dart`
|
||
- 抽象接口（get/set/remove/invalidateNamespace）。
|
||
5. `memory_cache_store.dart`
|
||
- 会话级热缓存。
|
||
6. `persistent_cache_store.dart`
|
||
- 本地冷缓存（SharedPreferences JSON）。
|
||
7. `hybrid_cache_store.dart`
|
||
- 两级缓存协调与 singleflight 去重。
|
||
8. `cache_invalidator.dart`
|
||
- 统一精准失效入口。
|
||
|
||
### 5.2 key 设计（首版）
|
||
|
||
1. 用户信息
|
||
- `user:profile:me`
|
||
2. 日历
|
||
- `calendar:day:YYYY-MM-DD`
|
||
- `calendar:month:YYYY-MM`
|
||
3. 待办
|
||
- `todo:list:pending`
|
||
- `todo:list:priority:<n>`（按需）
|
||
- `todo:detail:<id>`（按需）
|
||
|
||
### 5.3 策略设计（平衡型）
|
||
|
||
读取顺序：`memory -> persistent -> network`。
|
||
|
||
刷新策略：
|
||
|
||
1. 软过期（stale-while-revalidate）
|
||
- 先展示缓存，后台静默刷新。
|
||
2. 硬过期
|
||
- 超过硬过期后必须请求网络或提示数据过旧。
|
||
3. 最小刷新间隔
|
||
- 避免频繁切换/回前台引发抖动请求。
|
||
|
||
建议默认值：
|
||
|
||
1. `user:profile`：软过期 30min，硬过期 24h。
|
||
2. `calendar:day`：软过期 2min，硬过期 30min。
|
||
3. `calendar:month`：软过期 5min，硬过期 60min。
|
||
4. `todo:list:pending`：软过期 2min，硬过期 30min。
|
||
|
||
### 5.4 个人信息缓存合并方案
|
||
|
||
现有 `SettingsUserCache` 并入统一缓存模块：
|
||
|
||
1. 新建 `UserProfileRepository`（或在现有 settings service 中引入统一缓存）。
|
||
2. `getProfile()` 通过 hybrid cache 获取 `user:profile:me`。
|
||
3. 更新 profile 成功后立即写回缓存并同步持久化。
|
||
4. 登出/会话失效时统一调用 `invalidateNamespace('user')`。
|
||
|
||
## 6. 一致性风险与解决方案
|
||
|
||
平衡型缓存会存在“短暂陈旧窗口”。本设计通过以下机制将体验风险降到可接受范围。
|
||
|
||
### 6.1 触发刷新矩阵
|
||
|
||
1. 手动下拉刷新：强制网络刷新。
|
||
2. 写操作成功：精准失效受影响 key 并触发回填。
|
||
3. App 回前台：若超过最小刷新间隔，触发静默刷新。
|
||
4. 网络离线 -> 在线：触发静默刷新。
|
||
5. 进入关键详情页：按策略进行 freshness check。
|
||
|
||
### 6.2 写后一致性
|
||
|
||
1. 乐观更新：本地先更新 UI 与缓存，避免“我刚改完却没变”。
|
||
2. 失败回滚：API 失败时恢复旧值并 Toast 提示。
|
||
3. 精准失效：不做全局清空，只失效关联 key，兼顾一致性与性能。
|
||
|
||
### 6.3 并发安全
|
||
|
||
1. singleflight：同 key 同时只允许一个网络请求。
|
||
2. 版本保护：缓存写入比较 `updatedAt/version`，拒绝旧响应覆盖新状态。
|
||
3. 失败兜底：请求失败不清空旧缓存，保持可读并允许重试。
|
||
|
||
### 6.4 可见性保障
|
||
|
||
1. 页面可显示“上次同步时间”（轻提示）。
|
||
2. 硬过期数据需可见提醒（弱提示，不阻断基础浏览）。
|
||
3. 提供稳定手动刷新入口。
|
||
|
||
## 7. 导航与页面职责重构
|
||
|
||
### 7.1 路由重构
|
||
|
||
1. `app_router` 引入 shell 分支，不再平铺所有主页面。
|
||
2. Dock 切换改为 branch index 切换，不再 `push` 主页面。
|
||
3. Calendar 内部 month/day 切换改为视图切换，不新增栈层。
|
||
4. 事件详情/编辑等保留 `push`（细节页合理叠栈）。
|
||
|
||
### 7.2 回主页逻辑修正
|
||
|
||
1. Dock Home 统一执行“切到 Home 分支/`go('/home')`”。
|
||
2. `returnToHomePreserveState` 仅用于非 Dock 的返回策略场景。
|
||
3. 消除 `canPop -> pop` 对主页按钮语义的影响。
|
||
|
||
### 7.3 页面职责收敛
|
||
|
||
1. Calendar/Todo 页面移除路由监听触发 `load`。
|
||
2. 页面只调用 repository：
|
||
- `get(policy)`
|
||
- `refresh(force: true)`
|
||
- `mutate(...) + invalidate(...)`
|
||
3. 页面不直接感知“缓存在哪一层”。
|
||
|
||
## 8. 分阶段实施计划（里程碑）
|
||
|
||
### M1 导航壳层与切换语义
|
||
|
||
1. 引入 shell + 分支保活。
|
||
2. Dock 接口改造与主 tab 切换实现。
|
||
3. Home 按钮语义修正。
|
||
|
||
### M2 统一缓存骨架
|
||
|
||
1. 新增 core cache 模块。
|
||
2. 接入 user profile（替换 `SettingsUserCache`）。
|
||
3. DI 注入 cache store 与 invalidator。
|
||
|
||
### M3 Calendar 接入
|
||
|
||
1. 引入 `CalendarRepository` 与 day/month key。
|
||
2. 移除 route listener 自动刷新。
|
||
3. 切换 month/day 时默认走缓存，不触发无必要请求。
|
||
|
||
### M4 Todo 接入
|
||
|
||
1. 引入 `TodoRepository` 与 list/detail key。
|
||
2. 拖拽、完成、编辑后的精准失效。
|
||
3. 下拉刷新走强制网络。
|
||
|
||
### M5 清理与验证
|
||
|
||
1. 清理旧缓存与重复加载逻辑。
|
||
2. 补齐测试与性能观测。
|
||
3. 评估参数并收敛默认策略。
|
||
|
||
## 9. 验收标准
|
||
|
||
### 9.1 体验验收
|
||
|
||
1. Home/Calendar/Todo 切换无明显重建卡顿。
|
||
2. 日/月切换响应明显变快。
|
||
3. 首次冷启动可先看到本地缓存内容。
|
||
4. Dock Home 始终回主页。
|
||
|
||
### 9.2 网络验收
|
||
|
||
1. 切换页面时网络请求显著减少。
|
||
2. 写操作后关联数据可及时更新。
|
||
3. 手动刷新可强制拉取并回写缓存。
|
||
|
||
### 9.3 一致性验收
|
||
|
||
1. 不出现旧响应覆盖新数据。
|
||
2. 离线后恢复在线可自动静默同步。
|
||
3. 软过期/硬过期行为符合策略定义。
|
||
|
||
## 10. 测试与验证计划
|
||
|
||
### 10.1 单元测试
|
||
|
||
1. `hybrid_cache_store`：命中链路、singleflight、软硬过期判定。
|
||
2. `cache_invalidator`：写操作触发的 key 精准失效。
|
||
3. repository：读缓存、后台刷新、失败兜底、版本保护。
|
||
|
||
### 10.2 组件/页面测试（高回归）
|
||
|
||
1. Dock 切换不重建分支主页面。
|
||
2. 日/月切换不重复触发全量加载。
|
||
3. Home 按钮行为稳定。
|
||
|
||
### 10.3 集成回归
|
||
|
||
1. Calendar -> Todo -> Calendar 多轮切换请求计数。
|
||
2. Todo 完成后列表更新与缓存一致性。
|
||
3. profile 更新后设置页/其他依赖页可见一致。
|
||
|
||
## 11. 风险与回滚
|
||
|
||
### 11.1 主要风险
|
||
|
||
1. 导航壳层改造可能引发深链与返回栈回归。
|
||
2. 缓存策略参数不当可能造成陈旧感。
|
||
3. 早期失效 key 设计不完整可能出现局部不刷新。
|
||
|
||
### 11.2 控制策略
|
||
|
||
1. 按里程碑逐步落地，每个里程碑可单独回滚。
|
||
2. 默认保留手动刷新兜底。
|
||
3. 增加请求计数与缓存命中日志（开发态）。
|
||
|
||
### 11.3 回滚策略
|
||
|
||
1. 若 M1 不稳定，可先回退 shell 改造并保留缓存模块。
|
||
2. 若缓存接入问题集中，可按域回退（user/calendar/todo 分域开关）。
|
||
|
||
## 12. 最终落地参数（2026-03-20）
|
||
|
||
1. 导航分级
|
||
- 一级页面唯一为 `Home`。
|
||
- 二级页面（日/月、待办、设置）侧滑返回统一回 `Home`，不允许直接退出 App。
|
||
- App 退出入口仅保留在 `Home`。
|
||
2. 缓存默认策略
|
||
- `user:profile`：软过期 30min，硬过期 24h。
|
||
- `calendar:day`：软过期 2min，硬过期 30min。
|
||
- `calendar:month`：软过期 5min，硬过期 60min。
|
||
- `todo:list:pending`：软过期 2min，硬过期 30min。
|
||
3. 生命周期刷新
|
||
- App 回前台时启用最小间隔 5min 的静默刷新协调器。
|
||
4. 提醒归档策略
|
||
- App 活跃态点击取消：立即请求后端归档。
|
||
- 延迟归档（pending/outbox）仅用于 App 不可用场景兜底。
|