第2章 需求与约束分析：业务离线场景识别、数据一致性等级、网络不稳定性假设、设备能力约束

离线优先架构的成败首先取决于对业务场景和物理约束的精准识别。本章围绕四类核心输入——业务离线场景、数据一致性等级、网络不稳定性假设、设备能力约束——逐一展开分析，并输出对架构边界、系统分层、模块职责、数据流与信任链路、选型权衡、风险点、落地步骤和验收标准的直接影响。

2.1 业务离线场景识别

离线场景不是简单的“断网可用”，需要从用户操作流程中分离出必须在线和可以离线完成的子任务。以下是通过任务分解法识别的三类典型离线场景：

场景识别完成后，架构边界清晰：所有用户可见操作（点击、滑动、输入）必须在本地 500ms 内响应，只有在触发同步时才允许网络依赖。同时，拒绝将离线功能退化为“空页面”或“弹窗提示无网络”——离线状态下界面功能完整度必须保持在 80% 以上。

2.2 数据一致性等级

离线场景天然引入最终一致性，但不同业务的写冲突容忍度差异极大。我们按 CRDT + 操作日志 方案定义三个一致性等级：

数据流与信任链路决策：L1 场景下，信任根始终在服务端，本地修改需附带完整操作前状态哈希；L2 场景下，信任链路为客户端 CRDT → 服务端 CRDT → 持久化，双方互验因果序；L3 场景下，信任模型简化为“客户端为最终生产者，服务端仅做日志存储”。

2.3 网络不稳定性假设

我们采用悲观假设法定义网络的三个状态级别，并以此驱动系统分层与模块职责：

网络状态定义（离线优先专用）：
  ONLINE      : 连续 30s 内 RTT ≤ 200ms，丢包率 ≤ 1%
  DEGRADED    : RTT 200-800ms，丢包率 1%-5%，或者间歇中断（单次 ≤ 5s）
  OFFLINE     : 连续 30s 无任何网络响应，或者弱信号下收不到任何 ACK

在此假设下，系统必须支持无感状态切换：

• 网络从 ONLINE 切换到 DEGRADED 时，不阻塞用户操作，仅降低同步频率与并发数。
• 网络切换为 OFFLINE 时，所有网络调用必须由同步调度器统一接管，切换时间 ≤ 100ms。
• 网络恢复时，同步引擎应按优先级（L1 → L2 → L3）回放本地操作日志。

选型权衡：为了满足状态切换的时效性，放弃传统的 OkHttp 直连，采用自定义ConnectionManager + 本地 Socket 探测 + 应用层心跳合并。代价是网络层代码复杂度升高，但换来对断续网络的精确感知。

2.4 设备能力约束

目标设备为工业手持终端与加固平板，硬件配置如下：

这些约束直接影响模块职责划分：

• 数据层必须采用WAL + 批量提交模式，避免频繁 I/O 抢占 CPU。
• 同步引擎在 DEGRADED 状态下应主动降级：压缩图片（quality=60%）、合并多条日志、使用 ChunkedUpload 避免 OOM。
• UI 层不能执行任何 CRDT 合并或文件 IO 操作——这些必须由后台Worker线程处理，主线程仅负责渲染。

2.5 架构影响总览

将上述需求与约束映射到架构方案关键维度，整理如下：

2.6 风险点与权衡

1. CRDT 膨胀风险：L2 场景下 CRDT 元数据占用持续增长。落地措施：设定单文档 CRDT 版本上限（5000 次操作后触发 squash）。
2. 离线状态与在线状态数据不一致导致的用户困惑：UI 必须在关键字段旁显示 同步状态指示器（如 🟢/🟡/🔴 圆点），并允许手动触发即时同步。
3. 设备存储写磨损：频繁的 SQlite WAL 日志 + 图片缓存可能降低 eMMC 寿命。已规划使用 临时文件 + 定期 GC 策略，且每天限制总写量 ≤ 500 MB。
4. 同步优先级反转：低优先级 L3 数据可能堵住 L1 同步队列。必须实现优先级队列 + 饥饿防止——L1 请求可跳过 L3 待发送队列。

2.7 落地步骤与验收标准

验收标准：

• 三种离线场景均能在 mock OFFLINE 状态下完成核心功能且无崩溃。
• L1、L2、L3 数据在同步后一致性等级满足定义（测试脚本自动验证）。
• 网络状态切换感知延迟 ≤ 150ms（从实际断网到应用层切换）。
• 在所有约束条件下，应用内存峰值 ≤ 220 MB，CPU 占用 ≤ 45%。