Flutter on Website of SauceWu

Mac Mini 作为 GitLab Runner：iOS 和 Flutter 打包节点配置指南

Fri, 24 Apr 2026 12:00:00 +0900

Mac Mini 作为 GitLab Runner：iOS 和 Flutter 打包节点配置指南

iOS 和 Flutter 项目的 CI 有一个绕不开的限制：必须在 macOS 上构建。云端 macOS 实例贵，自建 Mac Mini 作为 GitLab Runner 是最常见的低成本方案。

这篇文章记录从零把一台 Mac Mini 配置成 GitLab CI 打包节点的完整过程，覆盖环境安装、Runner 注册、.gitlab-ci.yml 配置、常见坑和维护建议。

flutter-patrol-pilot：让 AI Agent 自主跑通 Flutter iOS 测试

Thu, 23 Apr 2026 16:00:00 +0900

flutter-patrol-pilot：让 AI Agent 自主跑通 Flutter iOS 测试

Flutter iOS 的集成测试一直是个麻烦事：Xcode 环境脆、xcresult 日志难读、Patrol 框架有自己的坑、失败原因五花八门。让人类来修还好，让 AI Agent 来修——很容易陷入死循环。

flutter-patrol-pilot（简称 fpp）是一个专门解决这个问题的 Claude Code Agent Skill：它接管整个 Flutter iOS 测试生命周期，从编译到运行，从失败诊断到代码修复，带着硬性规则和停止条件，不进死循环。

Flutter 状态管理选型：Provider、Riverpod、GetIt 对比

Mon, 20 Apr 2026 13:00:00 +0000

Flutter 状态管理选型：Provider、Riverpod、GetIt 对比

一、先说结论：它们并不是同一类东西
二、Provider：最贴近 Flutter 原生心智
三、Riverpod：更现代的响应式状态管理
四、GetIt：更像依赖注入容器，不是完整状态管理方案
五、核心维度横向对比
六、实际项目怎么选
七、常见误区
八、总结

一、先说结论：它们并不是同一类东西

很多人在 Flutter 里做技术选型时，会把 Provider / Riverpod / GetIt 放在一起比较，但它们其实不完全是同一层的东西。

Provider：基于 InheritedWidget 的状态注入与订阅方案，和 Flutter widget tree 绑定很深
Riverpod：从 Provider 演化出来的独立响应式状态管理框架，不依赖 BuildContext
GetIt：本质是 Service Locator / 依赖注入容器，负责“拿对象”，不天然负责“驱动 UI 刷新”

所以如果一句话概括：

Flutter 性能优化实战

Mon, 20 Apr 2026 12:00:00 +0000

Flutter 性能优化实战

一、性能问题的三个来源

Flutter 渲染一帧的流程是：Build → Layout → Paint → Composite → Rasterize。性能问题几乎都出在前三个阶段：

Flutter 交易所架构实战：DDD + Clean 落地指南

Mon, 20 Apr 2026 20:30:00 +0900

Flutter 交易所架构实战：DDD + Clean 落地指南

交易所项目做到一定规模，就会开始还之前欠下的债——页面里写 API、规则到处复制、改一处牵十处。

用 DDD + Clean 不是为了架构好看，是因为不用它的话，这类项目很难不失控。

这篇不讲大而空的概念，只讲三个问题：

为什么交易所需要 DDD + Clean
在 Flutter 里到底怎么分层
一笔下单请求如何在系统里流转（含时序图）

一、为什么交易所适合 DDD + Clean

交易所天然是“复杂业务系统”，不是普通内容 App。你会长期面对：

Flutter FFI 插件的 GitHub CI 实践：以 ceres-wallet-core 为例

Fri, 17 Apr 2026 18:00:00 +0000

Flutter FFI 插件的 GitHub CI 实践：以 ceres-wallet-core 为例

背景

普通 Flutter 插件的 CI 很简单：跑一下 flutter test 就够了。但 Flutter FFI 插件夹着 C++/Rust native 库，问题就复杂得多——

native 库需要在 macOS 上编译 iOS，在 Linux 上编译 Android，不能混
编译一次要十几分钟，开发者 pub get 的时候不能让他们自己编
Trust Wallet Core 有几十万行 C++ 代码，子模块更新需要自动化

ceres-wallet-core 的解法是两条 workflow：

ceres-wallet-core：用 Flutter 封装 Trust Wallet Core

Thu, 16 Apr 2026 16:00:00 +0000

ceres-wallet-core：用 Flutter 封装 Trust Wallet Core

背景

在做 Flutter 钱包应用时，密钥管理和交易签名是绕不开的核心模块。社区里能用的方案要么只支持 EVM 单链、要么 Dart 原生实现存在安全隐患、要么直接调 Web3 RPC 把私钥暴露在网络层。

Trust Wallet Core 是目前业界覆盖链最广、经过生产验证的开源密钥库，用 C++ 实现，已经支持 60+ 条链。问题是它没有官方的 Flutter 绑定。

ceres-mpc：基于 DKLs23 的 Flutter 两方 MPC 钱包 SDK

Sun, 12 Apr 2026 17:00:00 +0000

ceres-mpc：基于 DKLs23 的 Flutter 两方 MPC 钱包 SDK

为什么需要 MPC 钱包

传统 HD 钱包的私钥完整存储在用户设备上，一旦设备丢失或被攻击，资产就没了。助记词备份虽然能恢复，但本身也是攻击面。

MPC（Multi-Party Computation）钱包的思路是：私钥从始至终都不存在于任何单一设备，签名由多方协作计算完成。两方 ECDSA 的典型部署是客户端持有一份密钥分片，服务端持有另一份，任意一方单独都无法完成签名。

ceres-mpc 基于 DKLs23 协议实现了一套完整的 Flutter MPC 钱包 SDK，密码学核心用 Rust 编写，通过 flutter_rust_bridge 暴露给 Dart 调度层。

Flutter 手势系统与竞技场机制详解

Fri, 10 Apr 2026 10:00:00 +0000

Flutter 手势系统与竞技场机制详解

一、Gesture Arena（手势竞技场）运行原理

1. 两层触摸模型

Flutter 的触摸处理分为两层：

层级	说明	对应类
Pointer	原始触摸事件（down / move / up）	`PointerEvent`
Gesture	语义手势（tap、drag、scale 等）	`GestureRecognizer`

Pointer 层不做任何裁决，所有命中节点都会收到完整的 PointerEvent 序列。Gesture Arena 工作在 Gesture 层，负责在多个识别器之间做出唯一裁决。

Flutter 渲染流程与三棵树详解

Tue, 20 Jan 2026 10:00:00 +0000

Flutter 渲染流程与三棵树详解

一、Flutter 渲染架构全览

Flutter 的渲染流程从 Dart 代码到屏幕像素，经过了多个层次的处理：

你写的 Widget
↓
Widget Tree（配置描述）
↓
Element Tree（生命周期 + 状态管理）
↓
RenderObject Tree（布局 + 绘制）
↓
Layer Tree（合成）
↓
Skia / Impeller（光栅化）
↓
GPU → 屏幕

这套架构的核心设计目标是把"描述"和"执行"分离，让 Widget 可以廉价重建，而真正昂贵的布局和绘制操作尽量复用。

StatefulShellRoute 踩坑：为什么 Loading 只遮半屏，pop 还会误关页面

Sat, 20 Dec 2025 16:00:00 +0000

StatefulShellRoute 踩坑：为什么 Loading 只遮半屏，pop 还会误关页面

一、问题现象

我在用 go_router + StatefulShellRoute 做多 Tab 导航时，遇到了一个很烦的坑：

Flutter 路由方案对比：原生 Router 与 go_router

Mon, 10 Nov 2025 14:00:00 +0000

Flutter 路由方案对比：原生 Router 与 go_router

一、为什么 Flutter 路由总让人觉得“有点拧巴”
二、先区分三套东西：Navigator、原生 Router、go_router
三、原生 Router 的价值到底是什么
四、go_router 做了什么封装
五、go_router 的独特优势
六、什么时候该选原生 Router，什么时候该选 go_router
七、常见误区
八、总结

一、为什么 Flutter 路由总让人觉得“有点拧巴”

很多人第一次接触 Flutter 路由时，会觉得：

Flutter 键盘弹起不流畅的根因与优化方案

Thu, 23 Oct 2025 19:20:00 +0000

Flutter 键盘弹起不流畅的根因与优化方案

一、现象：为什么总感觉“不顺”
二、根因 1：Flutter 响应的是 Insets 变化，不是系统级联动动画
三、根因 2：键盘一弹，往往整棵页面都在重排
四、根因 3：默认方案优先保证“别挡住”，不保证“像原生一样丝滑”
五、几个最常见的踩坑场景
六、优化思路：不要让整页跟着键盘一起动
七、几种常见实现方案
八、一个更稳的实战建议
九、总结

一、现象：为什么总感觉“不顺”

很多 Flutter 开发者都遇到过这个问题：

输入框获取焦点时，页面像被突然“顶”了一下
底部输入栏和键盘不是一起上来的，而是分两拍
列表先跳一下，输入框再动一下
iOS 上尤其明显，总觉得没有原生页面跟键盘联动得自然

功能上看，它通常是对的：

Flutter K线系统拆解（五）：绘图工具系统设计与工程优化

Mon, 21 Jul 2025 13:35:00 +0900

Flutter K线系统拆解（五）：绘图工具系统设计与工程优化

为什么要单独讲这一篇

K 线里的“画线工具”看起来是附属能力，但实现难度其实很高。
它同时涉及：

绘图对象数据建模
点位命中与拖拽编辑
坐标与价格/时间映射
持久化与跨周期恢复
手势冲突与性能控制

如果这套系统没设计好，常见问题就是：点不中、拖不稳、误触多、数据丢、越画越卡。

一、先看系统分层（抽象视角）

一个完整的绘图工具系统，建议拆成 4 层：

控制层：管理当前绘图对象集合、选中状态、缓存恢复、默认样式
绘图对象层：定义线段/射线/矩形/圆/斐波那契等结构与完成条件
渲染命中层：负责路径构建、绘制、命中测试、控制点渲染
交互层：手势状态机（创建/编辑/移动/缩放）与工具面板联动

这类分层在交易类图表里经过大量实践验证，长期维护成本也更低。

二、绘图对象模型怎么设计更稳

1) 基础绘图对象字段

建议每个绘图对象至少包含：

Flutter K线系统拆解（四）：交互体系与性能工程

Mon, 07 Apr 2025 13:15:00 +0900

Flutter K线系统拆解（四）：交互体系与性能工程

为什么交互比指标更容易暴露问题

很多交易页在功能上都能“跑起来”，但只要用户开始频繁缩放、拖动、长按，体验差异会立刻被放大。
体感里的“丝滑”和“卡顿”，通常不来自单一 bug，而是交互链路里多个小问题叠加：

手势事件触发过密
状态更新范围过大
动画和计算抢同一帧预算
非关键绘制在高频交互里持续执行

所以这一篇的重点不是“某个技巧”，而是如何把交互链路做成一套稳定的工程系统。

一、交互设计里的三个关键决定

1) 方向锁定：先判断用户意图，再决定谁接管手势

在图表可编辑、页面又可滚动的场景里，方向锁是刚需。
当手势轨迹偏垂直时，把事件交给外层滚动容器；偏水平时再由图表处理，这能明显减少“手势打架”。

方向锁不是锦上添花，而是复杂页面里“能不能用”的分水岭。

2) 状态分离：长按、拖拽、缩放不要混成一个开关

把 isLongPress、isDrag、isScale 独立维护，收益很直接：
状态更可控、回归更容易、边界问题更少。
尤其在十字线与拖拽共存时，状态分离可以显著降低互相干扰。

3) 绘制隔离：高频区域和低频区域分开

给图表主体加 RepaintBoundary，本质是在缩小重绘传播范围。
在包含导航栏、侧边信息、浮层工具条的复杂页面里，这个动作通常会带来稳定的帧率收益。

Flutter K线系统拆解（三）：渲染管线与绘制分层

Tue, 01 Apr 2025 13:00:00 +0900

Flutter K线系统拆解（三）：渲染管线与绘制分层

这一篇聚焦渲染层最关键的问题：
如何把复杂 K 线绘制从“巨型 paint 方法”重构成可维护、可扩展、可定位问题的阶段化系统。

一、渲染底座：先算清楚，再开始画

一帧绘制开始前，建议先完成 5 件事：

计算绘制区域（主图、成交量、副图）
根据缩放和滚动计算可视区索引范围
在可视区内扫描 max/min（主图、vol、副图）
初始化渲染器
构建并执行渲染管线

其中最影响性能的是两点：

像素坐标反推数据索引
只绘制可见区，不遍历全量数据

滚动和缩放能否稳定流畅，基本就看这一步是否扎实。

二、渲染器组装：把“画什么”与“怎么调度”分开

渲染层建议把主图、成交量、副图拆成独立渲染器，由装配层按当前模式组合：

主图：CandleRenderer 或 TimeLineRenderer
成交量：VolRenderer
副图：SecondaryRenderer

再通过策略层控制是否启用某些区域（比如成交量、副图）。

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));
}

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

Clean Architecture 是什么：一篇讲清分层与依赖

Sat, 04 Sep 2021 21:20:00 +0900

Clean Architecture 是什么：一篇讲清分层与依赖

Clean Architecture 常被说成“分层架构”，但它最关键的不是分层本身，而是：
依赖方向必须可控。

一、Clean 想解决什么问题

项目变大后，最容易失控的是依赖关系：

页面直接调 API
业务规则写在网络回调里
换个数据库或 SDK，核心逻辑跟着重写

Clean 的核心目标是：
让核心业务不依赖外部框架和实现细节。

二、经典四层怎么理解

1) Presentation（表现层）

页面、组件、状态管理。
负责“怎么展示”和“怎么交互”。

2) Application（应用层）

UseCase（用例）编排流程。
负责“做什么流程”，不负责“怎么请求网络”。

Flutter on Website of SauceWu

Mac Mini 作为 GitLab Runner：iOS 和 Flutter 打包节点配置指南

Mac Mini 作为 GitLab Runner：iOS 和 Flutter 打包节点配置指南

flutter-patrol-pilot：让 AI Agent 自主跑通 Flutter iOS 测试

flutter-patrol-pilot：让 AI Agent 自主跑通 Flutter iOS 测试

Flutter 状态管理选型：Provider、Riverpod、GetIt 对比

Flutter 状态管理选型：Provider、Riverpod、GetIt 对比

目录

一、先说结论：它们并不是同一类东西

Flutter 性能优化实战

Flutter 性能优化实战

目录

一、性能问题的三个来源

Flutter 交易所架构实战：DDD + Clean 落地指南

Flutter 交易所架构实战：DDD + Clean 落地指南

一、为什么交易所适合 DDD + Clean

Flutter FFI 插件的 GitHub CI 实践：以 ceres-wallet-core 为例

Flutter FFI 插件的 GitHub CI 实践：以 ceres-wallet-core 为例

背景

ceres-wallet-core：用 Flutter 封装 Trust Wallet Core

ceres-wallet-core：用 Flutter 封装 Trust Wallet Core

背景

ceres-mpc：基于 DKLs23 的 Flutter 两方 MPC 钱包 SDK

ceres-mpc：基于 DKLs23 的 Flutter 两方 MPC 钱包 SDK

为什么需要 MPC 钱包

Flutter 手势系统与竞技场机制详解

Flutter 手势系统与竞技场机制详解

目录

一、Gesture Arena（手势竞技场）运行原理

1. 两层触摸模型

Flutter 渲染流程与三棵树详解

Flutter 渲染流程与三棵树详解

目录

一、Flutter 渲染架构全览

StatefulShellRoute 踩坑：为什么 Loading 只遮半屏，pop 还会误关页面

StatefulShellRoute 踩坑：为什么 Loading 只遮半屏，pop 还会误关页面

目录

一、问题现象

Flutter 路由方案对比：原生 Router 与 go_router

Flutter 路由方案对比：原生 Router 与 go_router

目录

一、为什么 Flutter 路由总让人觉得“有点拧巴”

Flutter 键盘弹起不流畅的根因与优化方案

Flutter 键盘弹起不流畅的根因与优化方案

目录

一、现象：为什么总感觉“不顺”

Flutter K线系统拆解（五）：绘图工具系统设计与工程优化

Flutter K线系统拆解（五）：绘图工具系统设计与工程优化

为什么要单独讲这一篇

一、先看系统分层（抽象视角）

二、绘图对象模型怎么设计更稳

1) 基础绘图对象字段

Flutter K线系统拆解（四）：交互体系与性能工程

Flutter K线系统拆解（四）：交互体系与性能工程

为什么交互比指标更容易暴露问题

一、交互设计里的三个关键决定

1) 方向锁定：先判断用户意图，再决定谁接管手势

2) 状态分离：长按、拖拽、缩放不要混成一个开关

3) 绘制隔离：高频区域和低频区域分开

Flutter K线系统拆解（三）：渲染管线与绘制分层

Flutter K线系统拆解（三）：渲染管线与绘制分层

一、渲染底座：先算清楚，再开始画

二、渲染器组装：把“画什么”与“怎么调度”分开

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

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

目标

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

二、指标计算顺序要固定

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

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

一、推荐的系统分层

交易所 WebSocket 连接管理踩坑录

交易所 WebSocket 连接管理踩坑录

一、重连与指数退避

Clean Architecture 是什么：一篇讲清分层与依赖

Clean Architecture 是什么：一篇讲清分层与依赖

一、Clean 想解决什么问题

二、经典四层怎么理解

1) Presentation（表现层）

2) Application（应用层）