Flutter Clean Architecture 测速功能代码层级划分与架构设计疑问

用例拆分合理性 #

你拆分3个用例的思路符合单一职责原则，没问题：

• 下载用例：只负责和网络层交互，处理IO异常、返回实时下载字节流，变更原因只有下载逻辑调整（比如换多线程下载、换测速节点），和后续计算逻辑完全解耦。
• 带宽单位换算用例：只负责基于原始字节/时间戳和用户预设单位，换算出对应带宽值，变更原因只有单位规则调整（比如要支持kB/s、GB/s新单位），和下载逻辑、UI展示逻辑无关。
• 你原本规划的「指针角度计算用例」不需要放在业务层，属于UI层渲染逻辑，下文会具体说明。

流程调度的归属 #

你原来设计的UI层层触发事件的流程不合理，业务调度权应该完全放在BLoC层，UI只负责两个核心职责：

1. 上报用户触发的业务事件（比如「点击开始测速」「切换带宽单位」）
2. 消费BLoC推送的状态渲染界面

正确的流程应该是：

1. 用户点击测速按钮，UI向BLoC发送StartSpeedTest事件
2. BLoC调用下载用例启动测速，订阅下载用例返回的实时字节流
3. 每收到新的下载分片数据，BLoC调用带宽换算用例，计算出用户设置单位对应的带宽值
4. BLoC推送SpeedUpdated状态，携带原始带宽值（单位bit/s）、格式化后的带宽文本（比如50.2 Mbps）
5. UI收到状态后，自行调用仪表盘组件内部的角度换算逻辑，更新指针位置和数值标签

这种设计的好处是UI完全和业务逻辑解耦，后续你要替换仪表盘样式、新增速度曲线展示等UI需求，不需要修改任何BLoC和用例层代码。

规则/配置的分层归属 #

你提到的三类配置，按照依赖关系分层放置即可：

• 带宽展示单位规则：放在用例层，属于核心业务规则，和UI无关，不管你用什么组件展示，单位换算的逻辑是统一的。
• 非线性仪表盘角度计算公式：放在UI层，和具体渲染组件绑定，属于展示逻辑，不属于核心业务规则，核心业务不需要知道你用线性还是非线性刻度。
• 速度更新频率：拆成两部分：底层采样频率（避免频繁计算占用资源）放在数据层/Repo层配置，UI层防抖更新频率（避免指针跳动太频繁影响体验）放在UI层配置。

另外要注意，用例层的「应用专属业务规则」指的是和业务目标相关的规则，和UI展示无关，不要把任何和渲染、样式相关的逻辑放到业务层，避免以后换UI端（比如要做桌面版、小程序版）的时候还要修改核心业务代码。

内容的提问来源于stack exchange，提问作者Mackovich