https://saucewu.github.io/tags/kline/Recent content in Kline on Website of SauceWuHugo -- gohugo.iozhMon, 21 Jul 2025 13:35:00 +0900https://saucewu.github.io/posts/flutter-k%E7%BA%BF%E7%B3%BB%E7%BB%9F%E6%8B%86%E8%A7%A3%E4%BA%94%E7%BB%98%E5%9B%BE%E5%B7%A5%E5%85%B7%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%B7%A5%E7%A8%8B%E4%BC%98%E5%8C%96/Mon, 21 Jul 2025 13:35:00 +0900https://saucewu.github.io/posts/flutter-k%E7%BA%BF%E7%B3%BB%E7%BB%9F%E6%8B%86%E8%A7%A3%E4%BA%94%E7%BB%98%E5%9B%BE%E5%B7%A5%E5%85%B7%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1%E4%B8%8E%E5%B7%A5%E7%A8%8B%E4%BC%98%E5%8C%96/<h1 id="flutter-k线系统拆解五绘图工具系统设计与工程优化">Flutter K线系统拆解（五）：绘图工具系统设计与工程优化</h1> <h2 id="为什么要单独讲这一篇">为什么要单独讲这一篇</h2> <p>K 线里的“画线工具”看起来是附属能力，但实现难度其实很高。<br> 它同时涉及：</p> <ul> <li>绘图对象数据建模</li> <li>点位命中与拖拽编辑</li> <li>坐标与价格/时间映射</li> <li>持久化与跨周期恢复</li> <li>手势冲突与性能控制</li> </ul> <p>如果这套系统没设计好，常见问题就是：点不中、拖不稳、误触多、数据丢、越画越卡。</p> <hr> <h2 id="一先看系统分层抽象视角">一、先看系统分层（抽象视角）</h2> <p>一个完整的绘图工具系统，建议拆成 4 层：</p> <ol> <li>控制层：管理当前绘图对象集合、选中状态、缓存恢复、默认样式</li> <li>绘图对象层：定义线段/射线/矩形/圆/斐波那契等结构与完成条件</li> <li>渲染命中层：负责路径构建、绘制、命中测试、控制点渲染</li> <li>交互层：手势状态机（创建/编辑/移动/缩放）与工具面板联动</li> </ol> <p>这类分层在交易类图表里经过大量实践验证，长期维护成本也更低。</p> <hr> <h2 id="二绘图对象模型怎么设计更稳">二、绘图对象模型怎么设计更稳</h2> <h3 id="1-基础绘图对象字段">1) 基础绘图对象字段</h3> <p>建议每个绘图对象至少包含：</p>https://saucewu.github.io/posts/flutter-k%E7%BA%BF%E7%B3%BB%E7%BB%9F%E6%8B%86%E8%A7%A3%E5%9B%9B%E4%BA%A4%E4%BA%92%E4%BD%93%E7%B3%BB%E4%B8%8E%E6%80%A7%E8%83%BD%E5%B7%A5%E7%A8%8B/Mon, 07 Apr 2025 13:15:00 +0900https://saucewu.github.io/posts/flutter-k%E7%BA%BF%E7%B3%BB%E7%BB%9F%E6%8B%86%E8%A7%A3%E5%9B%9B%E4%BA%A4%E4%BA%92%E4%BD%93%E7%B3%BB%E4%B8%8E%E6%80%A7%E8%83%BD%E5%B7%A5%E7%A8%8B/<h1 id="flutter-k线系统拆解四交互体系与性能工程">Flutter K线系统拆解（四）：交互体系与性能工程</h1> <h2 id="为什么交互比指标更容易暴露问题">为什么交互比指标更容易暴露问题</h2> <p>很多交易页在功能上都能“跑起来”，但只要用户开始频繁缩放、拖动、长按，体验差异会立刻被放大。<br> 体感里的“丝滑”和“卡顿”，通常不来自单一 bug，而是交互链路里多个小问题叠加：</p> <ul> <li>手势事件触发过密</li> <li>状态更新范围过大</li> <li>动画和计算抢同一帧预算</li> <li>非关键绘制在高频交互里持续执行</li> </ul> <p>所以这一篇的重点不是“某个技巧”，而是如何把交互链路做成一套稳定的工程系统。</p> <hr> <h2 id="一交互设计里的三个关键决定">一、交互设计里的三个关键决定</h2> <h3 id="1-方向锁定先判断用户意图再决定谁接管手势">1) 方向锁定：先判断用户意图，再决定谁接管手势</h3> <p>在图表可编辑、页面又可滚动的场景里，方向锁是刚需。<br> 当手势轨迹偏垂直时，把事件交给外层滚动容器；偏水平时再由图表处理，这能明显减少“手势打架”。</p> <p>方向锁不是锦上添花，而是复杂页面里“能不能用”的分水岭。</p> <h3 id="2-状态分离长按拖拽缩放不要混成一个开关">2) 状态分离：长按、拖拽、缩放不要混成一个开关</h3> <p>把 <code>isLongPress</code>、<code>isDrag</code>、<code>isScale</code> 独立维护，收益很直接：<br> 状态更可控、回归更容易、边界问题更少。<br> 尤其在十字线与拖拽共存时，状态分离可以显著降低互相干扰。</p> <h3 id="3-绘制隔离高频区域和低频区域分开">3) 绘制隔离：高频区域和低频区域分开</h3> <p>给图表主体加 <code>RepaintBoundary</code>，本质是在缩小重绘传播范围。<br> 在包含导航栏、侧边信息、浮层工具条的复杂页面里，这个动作通常会带来稳定的帧率收益。</p>https://saucewu.github.io/posts/flutter-k%E7%BA%BF%E7%B3%BB%E7%BB%9F%E6%8B%86%E8%A7%A3%E4%B8%89%E6%B8%B2%E6%9F%93%E7%AE%A1%E7%BA%BF%E4%B8%8E%E7%BB%98%E5%88%B6%E5%88%86%E5%B1%82/Tue, 01 Apr 2025 13:00:00 +0900https://saucewu.github.io/posts/flutter-k%E7%BA%BF%E7%B3%BB%E7%BB%9F%E6%8B%86%E8%A7%A3%E4%B8%89%E6%B8%B2%E6%9F%93%E7%AE%A1%E7%BA%BF%E4%B8%8E%E7%BB%98%E5%88%B6%E5%88%86%E5%B1%82/<h1 id="flutter-k线系统拆解三渲染管线与绘制分层">Flutter K线系统拆解（三）：渲染管线与绘制分层</h1> <p>这一篇聚焦渲染层最关键的问题：<br> 如何把复杂 K 线绘制从“巨型 paint 方法”重构成可维护、可扩展、可定位问题的阶段化系统。</p> <hr> <h2 id="一渲染底座先算清楚再开始画">一、渲染底座：先算清楚，再开始画</h2> <p>一帧绘制开始前，建议先完成 5 件事：</p> <ol> <li>计算绘制区域（主图、成交量、副图）</li> <li>根据缩放和滚动计算可视区索引范围</li> <li>在可视区内扫描 max/min（主图、vol、副图）</li> <li>初始化渲染器</li> <li>构建并执行渲染管线</li> </ol> <p>其中最影响性能的是两点：</p> <ul> <li>像素坐标反推数据索引</li> <li>只绘制可见区，不遍历全量数据</li> </ul> <p>滚动和缩放能否稳定流畅，基本就看这一步是否扎实。</p> <hr> <h2 id="二渲染器组装把画什么与怎么调度分开">二、渲染器组装：把“画什么”与“怎么调度”分开</h2> <p>渲染层建议把主图、成交量、副图拆成独立渲染器，由装配层按当前模式组合：</p> <ul> <li>主图：<code>CandleRenderer</code> 或 <code>TimeLineRenderer</code></li> <li>成交量：<code>VolRenderer</code></li> <li>副图：<code>SecondaryRenderer</code></li> </ul> <p>再通过策略层控制是否启用某些区域（比如成交量、副图）。</p>https://saucewu.github.io/posts/flutter-k%E7%BA%BF%E7%B3%BB%E7%BB%9F%E6%8B%86%E8%A7%A3%E4%BA%8C%E6%8C%87%E6%A0%87%E5%BC%95%E6%93%8E%E4%B8%8E%E5%A2%9E%E9%87%8F%E8%AE%A1%E7%AE%97/Mon, 31 Mar 2025 12:45:00 +0900https://saucewu.github.io/posts/flutter-k%E7%BA%BF%E7%B3%BB%E7%BB%9F%E6%8B%86%E8%A7%A3%E4%BA%8C%E6%8C%87%E6%A0%87%E5%BC%95%E6%93%8E%E4%B8%8E%E5%A2%9E%E9%87%8F%E8%AE%A1%E7%AE%97/<h1 id="flutter-k线系统拆解二指标引擎与增量计算">Flutter K线系统拆解（二）：指标引擎与增量计算</h1> <h2 id="目标">目标</h2> <p>这篇只讲一件事：<br> 如何把 K 线指标计算做成<strong>高性能、可维护、可测试</strong>的生产级引擎。</p> <hr> <h2 id="一最佳实践架构三层拆分">一、最佳实践架构：三层拆分</h2> <p>指标模块建议拆成三层：</p> <ol> <li><code>IndicatorConfig</code>（配置层）：维护 MA/BOLL/MACD 等参数与开关</li> <li><code>IndicatorEngine</code>（计算层）：只负责输入数据、输出结果，不关心 UI</li> <li><code>ChartAdapter</code>（消费层）：把结果喂给渲染，不做任何业务计算</li> </ol> <p>核心原则：</p> <ul> <li>渲染层只读结果，不参与计算</li> <li>计算层纯函数化，避免隐式全局状态</li> <li>配置变更和行情更新走不同刷新路径</li> </ul> <hr> <h2 id="二指标计算顺序要固定">二、指标计算顺序要固定</h2> <p>生产上要明确“依赖顺序”，不能随意调整。</p> <p>推荐顺序：</p> <ol> <li>输入 <code>List&lt;KLineEntity&gt;</code></li> <li>计算 <code>MA</code></li> <li>计算 <code>BOLL</code>（依赖 MA）</li> <li>计算 <code>Volume MA</code></li> <li>计算 <code>KDJ</code></li> <li>计算 <code>MACD</code></li> <li>计算 <code>RSI</code></li> <li>计算 <code>WR</code></li> <li>计算 <code>SuperTrend</code></li> <li>结果回填到每个 <code>KLineEntity</code></li> <li>渲染层直接读取实体字段</li> </ol> <p>建议把顺序写进统一入口方法，避免外部随意单独调用。</p>https://saucewu.github.io/posts/flutter-k%E7%BA%BF%E7%B3%BB%E7%BB%9F%E6%8B%86%E8%A7%A3%E4%B8%80%E6%9E%B6%E6%9E%84%E5%88%86%E5%B1%82%E4%B8%8E%E9%A2%86%E5%9F%9F%E6%A8%A1%E5%9E%8B/Thu, 20 Mar 2025 12:30:00 +0900https://saucewu.github.io/posts/flutter-k%E7%BA%BF%E7%B3%BB%E7%BB%9F%E6%8B%86%E8%A7%A3%E4%B8%80%E6%9E%B6%E6%9E%84%E5%88%86%E5%B1%82%E4%B8%8E%E9%A2%86%E5%9F%9F%E6%A8%A1%E5%9E%8B/<h1 id="flutter-k线系统拆解一架构分层与领域模型">Flutter K线系统拆解（一）：架构分层与领域模型</h1> <p>K 线在 demo 阶段通常不难，难的是进入真实交易场景之后的长期维护。<br> 一旦业务进入高频迭代，常见问题很快会暴露出来：主题体系耦合、模式分支散落、改动范围不可控、扩展成本越来越高。</p> <p>这一篇只讲架构层面的核心问题：<br> 如何把 K 线从“能画出来的组件”做成“可长期演进的系统”。</p> <hr> <h2 id="一推荐的系统分层">一、推荐的系统分层</h2> <p>一套可维护的 K 线实现，通常至少要有这几层：</p> <pre tabindex="0"><code>入口与装配层：图表 widget 生命周期与运行时状态 SDK 抽象层：主题、国际化、事件、屏幕适配等外部能力 数据与指标层：行情实体、指标结果、计算引擎 渲染核心层：坐标、可视区、渲染器管理 渲染阶段层：背景/网格/主图/十字线/叠加层等阶段化执行 策略扩展层：现货、合约等模式差异封装 工具叠加层：订单标记、绘图工具、信息浮层 </code></pre><p>分层的价值不在“看起来规范”，而在于改动隔离：<br> 新增一个能力时，只需要改对应层，不会把整个系统拖下水。</p>