https://saucewu.github.io/tags/performance/Recent content in Performance on Website of SauceWuHugo -- gohugo.iozhMon, 20 Apr 2026 12:00:00 +0000https://saucewu.github.io/posts/flutter-%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%E5%AE%9E%E6%88%98/Mon, 20 Apr 2026 12:00:00 +0000https://saucewu.github.io/posts/flutter-%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%E5%AE%9E%E6%88%98/<h1 id="flutter-性能优化实战">Flutter 性能优化实战</h1> <h2 id="目录">目录</h2> <ul> <li>一、性能问题的三个来源</li> <li>二、Build 阶段优化</li> <li>三、Layout / Paint 阶段优化</li> <li>四、内存与图片优化</li> <li>五、列表性能</li> <li>六、用 DevTools 定位问题</li> <li>七、速查清单</li> </ul> <hr> <h2 id="一性能问题的三个来源">一、性能问题的三个来源</h2> <p>Flutter 渲染一帧的流程是：<strong>Build → Layout → Paint → Composite → Rasterize</strong>。性能问题几乎都出在前三个阶段：</p>https://saucewu.github.io/posts/flutter-%E9%94%AE%E7%9B%98%E5%BC%B9%E8%B5%B7%E4%B8%8D%E6%B5%81%E7%95%85%E7%9A%84%E6%A0%B9%E5%9B%A0%E4%B8%8E%E4%BC%98%E5%8C%96%E6%96%B9%E6%A1%88/Thu, 23 Oct 2025 19:20:00 +0000https://saucewu.github.io/posts/flutter-%E9%94%AE%E7%9B%98%E5%BC%B9%E8%B5%B7%E4%B8%8D%E6%B5%81%E7%95%85%E7%9A%84%E6%A0%B9%E5%9B%A0%E4%B8%8E%E4%BC%98%E5%8C%96%E6%96%B9%E6%A1%88/<h1 id="flutter-键盘弹起不流畅的根因与优化方案">Flutter 键盘弹起不流畅的根因与优化方案</h1> <h2 id="目录">目录</h2> <ul> <li>一、现象：为什么总感觉“不顺”</li> <li>二、根因 1：Flutter 响应的是 Insets 变化，不是系统级联动动画</li> <li>三、根因 2：键盘一弹，往往整棵页面都在重排</li> <li>四、根因 3：默认方案优先保证“别挡住”，不保证“像原生一样丝滑”</li> <li>五、几个最常见的踩坑场景</li> <li>六、优化思路：不要让整页跟着键盘一起动</li> <li>七、几种常见实现方案</li> <li>八、一个更稳的实战建议</li> <li>九、总结</li> </ul> <h2 id="一现象为什么总感觉不顺">一、现象：为什么总感觉“不顺”</h2> <p>很多 Flutter 开发者都遇到过这个问题：</p> <ul> <li>输入框获取焦点时，页面像被突然“顶”了一下</li> <li>底部输入栏和键盘不是一起上来的，而是分两拍</li> <li>列表先跳一下，输入框再动一下</li> <li>iOS 上尤其明显，总觉得没有原生页面跟键盘联动得自然</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%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%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>