Trading on Website of SauceWu

Flutter K线系统拆解（二）：指标引擎与增量计算

Mon, 31 Mar 2025 12:45:00 +0900

Flutter K线系统拆解（二）：指标引擎与增量计算

目标

这篇只讲一件事：
如何把 K 线指标计算做成高性能、可维护、可测试的生产级引擎。

一、最佳实践架构：三层拆分

指标模块建议拆成三层：

IndicatorConfig（配置层）：维护 MA/BOLL/MACD 等参数与开关
IndicatorEngine（计算层）：只负责输入数据、输出结果，不关心 UI
ChartAdapter（消费层）：把结果喂给渲染，不做任何业务计算

核心原则：

渲染层只读结果，不参与计算
计算层纯函数化，避免隐式全局状态
配置变更和行情更新走不同刷新路径

二、指标计算顺序要固定

生产上要明确“依赖顺序”，不能随意调整。

推荐顺序：

输入 List<KLineEntity>
计算 MA
计算 BOLL（依赖 MA）
计算 Volume MA
计算 KDJ
计算 MACD
计算 RSI
计算 WR
计算 SuperTrend
结果回填到每个 KLineEntity
渲染层直接读取实体字段

建议把顺序写进统一入口方法，避免外部随意单独调用。

Flutter K线系统拆解（一）：架构分层与领域模型

Thu, 20 Mar 2025 12:30:00 +0900

Flutter K线系统拆解（一）：架构分层与领域模型

K 线在 demo 阶段通常不难，难的是进入真实交易场景之后的长期维护。
一旦业务进入高频迭代，常见问题很快会暴露出来：主题体系耦合、模式分支散落、改动范围不可控、扩展成本越来越高。

这一篇只讲架构层面的核心问题：
如何把 K 线从“能画出来的组件”做成“可长期演进的系统”。

一、推荐的系统分层

一套可维护的 K 线实现，通常至少要有这几层：

入口与装配层：图表 widget 生命周期与运行时状态
SDK 抽象层：主题、国际化、事件、屏幕适配等外部能力
数据与指标层：行情实体、指标结果、计算引擎
渲染核心层：坐标、可视区、渲染器管理
渲染阶段层：背景/网格/主图/十字线/叠加层等阶段化执行
策略扩展层：现货、合约等模式差异封装
工具叠加层：订单标记、绘图工具、信息浮层

分层的价值不在“看起来规范”，而在于改动隔离：
新增一个能力时，只需要改对应层，不会把整个系统拖下水。

交易所 WebSocket 连接管理踩坑录

Sat, 21 May 2022 10:00:00 +0900

交易所 WebSocket 连接管理踩坑录

交易所 App 对实时连接的依赖极高，行情、深度、订单状态全靠 WebSocket 推送，连接一断用户就处于盲区。从基础到深度整理踩过的坑。

一、重连与指数退避

裸写的 WebSocket.connect 断了就断了，没有自愈能力：

Future<void> connect(String url) async {
 while (!_disposed && _retryCount < _maxRetries) {
 try {
 _socket = await WebSocket.connect(url);
 _retryCount = 0;
 await _socket!.listen(
 onData: _onMessage,
 onDone: () => _scheduleReconnect(url),
 onError: (_) => _scheduleReconnect(url),
 cancelOnError: true,
 ).asFuture();
 } catch (_) {
 _scheduleReconnect(url);
 break;
 }
 }
}

void _scheduleReconnect(String url) {
 if (_disposed) return;
 final delay = _baseDelay * (1 << _retryCount.clamp(0, 6)); // 1s → 2s → 4s … → 64s
 _retryCount++;
 Future.delayed(delay, () => connect(url));
}

指数退避必须加。服务端重启时如果所有客户端同时重连，会瞬间打死服务器。