Posts 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 配置、常见坑和维护建议。

子 Agent 并发的效率上限：什么时候加人反而更慢

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

子 Agent 并发的效率上限：什么时候加人反而更慢

用过 Claude 多 Agent 框架之后，第一个直觉往往是：并发数越多越快。

起 5 个 agent 写 5 个脚本，明显比串行快。那起 20 个呢？50 个？

现实不是这样的。并发 agent 和线程池一样，存在一个效率拐点，超过之后加 agent 不仅不再加速，反而可能让整个任务变慢。

一、并发加速比：从线性到平台期

理论上，N 个 agent 并行跑 N 个独立任务，应该是 N 倍加速。但实际测下来大致是这张表：

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 层，负责在多个识别器之间做出唯一裁决。

MPC 钱包：私钥从未完整存在过

Sun, 15 Mar 2026 10:00:00 +0000

MPC 钱包：私钥从未完整存在过

传统钱包的问题

用过普通钱包（MetaMask、Trust Wallet）的人都知道，创建钱包时会生成一组助记词：

witch collapse practice feed shame open despair creek road again ice least

这 12 个单词本质上就是你的私钥。它的问题很简单：

抄错一个字 → 永久丢失资产
被人拍到 → 资产全部被盗
手机丢了没备份 → 再见

私钥是单点故障。整个安全体系建立在"这串数字只有你知道"的假设上，一旦泄露，没有任何补救手段。

AA 钱包：让智能合约成为你的钱包

Wed, 28 Jan 2026 10:00:00 +0000

AA 钱包：让智能合约成为你的钱包

传统钱包的体验困境

用过 Web3 钱包的人几乎都遇到过这些问题：

第一次用 DApp，账户里没有 ETH，但用 USDC 付 gas 不行
想同时 approve + swap，得签两笔交易，付两次 gas
私钥丢了，资产永久没了，没有任何找回手段
每次操作都要手动签名确认，体验比 Web2 差太多

这些问题的根源是以太坊原始账户设计的限制——EOA（外部账户）。

两种账户类型

以太坊上有两种账户：

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

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

Solana 交易手续费与常见坑

Fri, 21 Feb 2025 15:00:00 +0900

Solana 交易手续费与常见坑

Solana 的手续费设计和 EVM 差别很大，从 EVM 过来的开发者很容易踩坑。这篇把几个最常见的问题整理一下。

手续费结构

Solana 的交易费用分两部分：

总费用 = 基础费用（Base Fee）+ 优先费用（Priority Fee，可选）

基础费用

每个签名收 5000 lamports（0.000005 SOL）。一笔交易有几个签名就收几倍。

基础费用 = 签名数 × 5000 lamports

普通转账只有 1 个签名，费用就是 5000 lamports。多签或者复杂交易有多个签名，费用叠加。

EVM 字节码与合约执行过程详解

Thu, 20 Apr 2023 14:00:00 +0000

EVM 字节码与合约执行过程详解

一、EVM 是什么

EVM（Ethereum Virtual Machine）是以太坊的智能合约运行环境。它是一个基于栈的虚拟机，与 JVM 的基于栈架构类似，但设计上做了很多针对区块链场景的取舍：

确定性：相同输入永远产生相同输出，所有节点独立执行后结果必须一致
隔离性：合约运行在沙箱里，无法访问网络、文件系统、随机数
计量性：每条指令都有固定 Gas 费用，防止无限循环

EVM 使用 256 位字长（32 字节），这是它最核心的设计决定——与 Keccak-256 哈希和椭圆曲线密钥长度对齐，避免频繁的位数转换。

EIP-1559 手续费机制详解

Sat, 21 Jan 2023 14:00:00 +0900

EIP-1559 手续费机制详解

EIP-1559 是 2021 年 8 月以太坊 London 升级引入的手续费改革，它彻底改变了 Gas 的定价方式。如果你在做钱包或交易所，发交易时不理解这套机制，要么手续费估高了用户体验差，要么估低了交易迟迟不上链。

老机制的问题

EIP-1559 之前，以太坊用的是一价拍卖（First Price Auction）：

用户自己出一个 gasPrice
矿工优先打包出价最高的交易
网络拥堵时用户只能盲猜出多少合适

结果就是：拥堵时大家拼命加价，但实际上很多人出了远超必要的手续费，钱白白浪费。

EIP-1559 的核心变化

EIP-1559 把手续费拆成两部分：

交易所 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（用例）编排流程。
负责“做什么流程”，不负责“怎么请求网络”。

DDD 是什么：一篇讲清领域驱动设计

Wed, 11 Aug 2021 21:10:00 +0900

DDD 是什么：一篇讲清领域驱动设计

很多人第一次听到 DDD（Domain-Driven Design，领域驱动设计）会觉得它很“玄学”。
其实它解决的问题非常现实：业务太复杂，代码开始失真，团队开始说不清同一个概念。

一、DDD 到底在解决什么问题

当系统进入复杂业务阶段（交易、支付、风控、订单流转），常见问题会出现：

同一个规则在多个地方重复实现
接口字段就是业务模型，改字段就改全系统
“下单”“成交”“结算”这些词，每个人理解都不一样

DDD 的核心目标是：
让代码结构贴近业务结构，让业务语言和代码语言一致。

二、DDD 的核心概念（只记最关键的）

1) 领域（Domain）

你的业务问题空间，比如“交易系统”就是一个领域。

2) 统一语言（Ubiquitous Language）

产品、业务、研发使用同一套术语。
比如 Order、Fill、Position 必须定义一致，避免口头理解和代码实现偏差。

JVM学习笔记（内存分区篇）

Fri, 15 May 2020 00:00:00 +0000

JVM学习笔记（内存分区篇）

概述

线程私有区

这三个区是随着线程生命周期创建销毁的。

程序计数器

与CPU中程序计数器作用相同，用于记录当前线程程序现在运行到哪里。
基于CPU的时间片轮转运行机制，CPU并不会把一个线程中的任务做完之后才切换线程，而是在不同线程中不停切换以达到并发的效果，所以我们需要记录下当切程序运行到的指令地址，在下一次轮到该线程执行时可以继续运行。
Java虚拟机中的程序计数器仅仅是虚拟机中的，存在于内存之上的“虚拟”计数器。
要注意的是在运行native方法, 使用的是cpu的程序计数器 JVM中的程序计数器会被定义为undefined。

可能产生的异常

因为程序计数器只是存储一个定长的指令地址，所以不会有OutOfMemoryError出现

虚拟机栈 /本地方法栈

把这两个区的作用大致是一样的，只是Java虚拟机栈运行的是Java方法，本地方法栈运行的是native方法。而且在很多虚拟机(比如HotSpot VM)中把这两个栈融合成所谓的“mixed stack”两种栈帧都可以储存。
栈区是由栈帧组成的。当调用方法时，Java虚拟机将新建一个帧；方法退出时，帧将自动消除。
线程运行过程中，只有一个栈帧是处于活跃状态，称为“当前活跃栈帧”，当前活动栈帧始终是虚拟机栈的栈顶元素。

栈帧

局部变量表

在编译程序代码的时候就可以确定栈帧中需要多大的局部变量表，具体大小可在编译后的 Class 文件中看到。
局部变量表的容量以Variable Slot（变量槽）为最小单位，每个变量槽都可以存储 32 位长度的内存空间。
在方法执行时，虚拟机使用局部变量表完成参数值到参数变量列表的传递过程的，如果执行的是实例方法，那局部变量表中第 0 位索引的 Slot 默认是用于传递方法所属对象实例的引用（在方法中可以通过关键字 this 来访问到这个隐含的参数）。
其余参数则按照参数表顺序排列，占用从 1 开始的局部变量 Slot。
基本类型数据以及引用和 returnAddress（返回地址）占用一个变量槽，long 和 double 需要两个。

操作数栈

同样也可以在编译期确定大小。
Frame 被创建时，操作栈是空的。操作栈的每个项可以存放 JVM 的各种类型数据，其中 long 和 double 类型（64位数据）占用两个栈深。
方法执行的过程中，会有各种字节码指令往操作数栈中写入和提取内容，也就是出栈和入栈操作（与 Java 栈中栈帧操作类似）。
操作栈调用其它有返回结果的方法时，会把结果 push 到栈上（通过操作数栈来进行参数传递）。

动态链接

每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的动态链接。
在类加载阶段中的解析阶段会将符号引用转为直接引用，这种转化也称为静态解析。另外的一部分将在运行时转化为直接引用，这部分称为动态链接。

返回地址

方法开始执行后，只有 2 种方式可以退出：方法返回指令，异常退出。

可能产生的异常

线程请求分配的栈容量>Java虚拟机最大栈容量，则JVM会抛出StackOverFlowError异常。

从 setTint 引发的Drawable 的缓存问题

Sun, 10 May 2020 15:00:00 +0000

从 setTint 引发的Drawable 的缓存问题

这两天在做一个新需求是突然发现 DrawableCompat.setTint()更改drawable 渲染颜色的方法居然是全局生效的。变相说明getResource().getDrawable() 每次取出drawable的时候都是从一个缓存池里面出去的。

避免缓存的解决方案

第一反应是clone一个新的对象出来进行修改但是貌似drawable并没有实现Cloneable的借口0那看来得想想别的办法了

看了一会源码果然google在drawable类中已经给我们提供了一个 mutate方法看注释看似乎这个方法可以返回一个新的drawable对象

 /**
 * Make this drawable mutable. This operation cannot be reversed. A mutable
 * drawable is guaranteed to not share its state with any other drawable.
 * This is especially useful when you need to modify properties of drawables
 * loaded from resources. By default, all drawables instances loaded from
 * the same resource share a common state; if you modify the state of one
 * instance, all the other instances will receive the same modification.
 *
 * Calling this method on a mutable Drawable will have no effect.
 *
 * @return This drawable.
 * @see ConstantState
 * @see #getConstantState()
 */
 public @NonNull Drawable mutate() {
 return this;
 }

最终的实现是根据不同的drawable类型有不同的实现方式这里就用bitmapdrawable作为例子不仅clone了的对象还禁止了这个对象再次被复制猜测是为了方式无限clone导致oom

VPS 被暴力尝试登录的几种解决方案

Thu, 02 Apr 2020 20:00:00 +0000

VPS 被暴力尝试登录的几种解决方案

背景

最近登录自己blog的服务器时偶然发现

There were 34176 failed login attempts since the last successful login.

被人扫到了端口还被疯狂尝试登录虽然这个破服务器没什么东西但被破解出来被黑产拉去挖矿什么的也是有点难受的

首先先看一下到底是谁在扫我的机器

# lastb

解决方案

1.denyhost

一顿google之后被安利了denyhost这个python脚本原理就是通过它会分析sshd的日志文件（/var/log/secure），当发现重复的攻击时就会记录IP到/etc/hosts.deny文件，从而达到自动屏IP的功能

WebView实现离线缓存

Tue, 10 Mar 2020 20:00:00 +0000

WebView实现离线缓存

场景

在App在长期发展之中，对动态性要求很高的活动页面或是一些带有简单功能的详情页面都可能会有大量Webview使用的情况。但是webview初始化时极有可能遇到网络波动的影响导致加载不出或者会重复下载一些公共资源造成性能问题。这时我们希望有一种缓存方案能够暂时解决这些初始化变慢的问题

原理

android WebViewClient提供了shouldInterceptRequest的接口供我们使用这个接口会拦截webview所有请求。如果错误缓存了资源，可能会出现web页面无法更新的情况。所以用的时候要谨慎只对我们需要使用缓存的部分进行拦截

override fun shouldInterceptRequest(view: WebView?, request: WebResourceRequest?): WebResourceResponse? {
 if (view != null && request != null) {
 //判断需要使用缓存的url
 if (WebViewCacheUtils.needCache(request.url.toString())) {
 //从缓存池中获取缓存
 val cache = WebViewCacheUtils.getCache(request)
 if (cache != null) {
 return cache
 }
 }
 }
 //未找到缓存文件或者不需要缓存 还是正常走请求
 return super.shouldInterceptRequest(view, request)
}

 fun getCache(webResourceRequest: WebResourceRequest): WebResourceResponse? {
 val uri = webResourceRequest.url
 try {
 //获取加载资源类型
 var mimeType: String? = MimeTypeMapUtils.getMimeTypeFromUrl(uri.toString())
 val type: String
 val header = HashMap<String, String>()
 //我们可能对多个域名进行缓存 先设置跨域
 header["Access-Control-Allow-Origin"] = "*"
 header["Access-Control-Allow-Headers"] = "Content-Type"
 if (mimeType == null) {
 if (uri.path!!.contains("js")) {
 type = "js"
 mimeType = "application/javascript"
 header["content-type"] = "application/javascript; charset=utf-8"
 } else {
 mimeType = "text/html"
 type = "html"
 header["content-type"] = "text/html; charset=utf-8"
 }

 } else if (mimeType.contains("img") || mimeType.contains("image")) {
 type = "img"
 } else {
 //这里主要是css 格式是 text/css
 type = mimeType.split("/".toRegex()).dropLastWhile { it.isEmpty() }.toTypedArray()[1]
 }
//确定是否获取了资源类型
 if (!TextUtils.isEmpty(mimeType)) {
 val name = (if (type == "html") {
 //由于多个url可能使用的是同一个html 这里需要判断下 返回的是 该html的md5
 needCacheHtml(uri.path)
 } else {
 MD5Utils.encode(uri.path)
 })
 //从缓存池中获取缓存
 val cacheSteam=getWebCache(name, type)
 //构造响应体 并返回
 return WebResourceResponse(mimeType, "", 200, "ok", header, cacheSteam)
 }
 } catch (e: FileNotFoundException) {
 e.printStackTrace()
 }

 return null
 }

注意事项

HTML的缓存一定要小心最好是由前端同学出一份目录的接口并且做好版本管理防止误操作否则线上可能会出严重问题
存储的文件名都是用md5过的防止有特殊字符影响持久化
如果有大文件缓存最好需要有文件完整性验证

关于 Androidx 的5.x版本 webview crash

Tue, 10 Mar 2020 15:00:00 +0000

关于 Androidx 的5.x版本 webview crash

这两更新了androidx compat 在5.x一下版本手机上遇到crash问题

android.content.res.Resources$NotFoundException: String resource ID #0x2040002

确定是androidx 1.1.0版本问题 google issue

而且是只有 1.1.0 正式包才会有问题。以后还是少升级这种基础包为好

WebView页面软键盘弹出无法正确折叠页面的问题

Thu, 03 May 2018 18:30:00 +0000

WebView页面软键盘弹出无法正确折叠页面的问题

问题出在webview页面选中webview中edit控件弹出的软键盘无法正确折叠页面遮挡了输入框。一开始认为是webview的适配问题，想当然的加上了

<activity android:name=".WebViewActivity" android:windowSoftInputMode="adjustPan" >
...
</activity>

结果当然是毫！无！反！应！

在一番调试之后发现时隐藏了状态栏之后屏幕尺寸计算出现问题的缘故也是个老google issue了

网上有很多解决办法最通用的当然还是原理很简单就是每当页面有变动的时候自行去计算页面高度- -

public class AndroidBug5497Workaround {
 public static void assistActivity(Activity activity) {
 new AndroidBug5497Workaround(activity);
 }

 private View mChildOfContent;
 private int usableHeightPrevious;
 private FrameLayout.LayoutParams frameLayoutParams;
 private int contentHeight;
 private boolean isfirst = true;
 private int statusBarHeight;

 private AndroidBug5497Workaround(Activity activity) {
 if (activity == null) {
 return;
 }
 //获取状态栏的高度
 int resourceId = activity.getResources().getIdentifier("status_bar_height", "dimen", "android");
 statusBarHeight = activity.getResources().getDimensionPixelSize(resourceId);
 FrameLayout content = activity.findViewById(android.R.id.content);
 mChildOfContent = content.getChildAt(0);

 //界面出现变动都会调用这个监听事件
 mChildOfContent.getViewTreeObserver().addOnGlobalLayoutListener(() -> {
 if (isfirst) {
 contentHeight = mChildOfContent.getHeight();//兼容华为等机型
 isfirst = false;
 }
 possiblyResizeChildOfContent();
 });

 frameLayoutParams = (FrameLayout.LayoutParams)
 mChildOfContent.getLayoutParams();
 }

 //重新调整跟布局的高度
 private void possiblyResizeChildOfContent() {

 int usableHeightNow = computeUsableHeight();

 //当前可见高度和上一次可见高度不一致 布局变动
 if (usableHeightNow != usableHeightPrevious) {
 //int usableHeightSansKeyboard2 = mChildOfContent.getHeight();//兼容华为等机型
 int usableHeightSansKeyboard = mChildOfContent.getRootView().getHeight();
 int heightDifference = usableHeightSansKeyboard - usableHeightNow;
 if (heightDifference > (usableHeightSansKeyboard / 4)) {
 // keyboard probably just became visible
 //frameLayoutParams.height = usableHeightSansKeyboard - heightDifference;
 frameLayoutParams.height = usableHeightSansKeyboard - heightDifference + statusBarHeight;
 } else {
 frameLayoutParams.height = contentHeight;
 }

 mChildOfContent.requestLayout();
 usableHeightPrevious = usableHeightNow;
 }
 }

 /**
 * 计算mChildOfContent可见高度
 ** @return 高度
 */
 private int computeUsableHeight() {
 Rect r = new Rect();
 mChildOfContent.getWindowVisibleDisplayFrame(r);
 return (r.bottom - r.top);
 }
}

Android 编译期的黑科技（三）-字节码篇

Thu, 05 Apr 2018 19:00:00 +0000

Android 编译期的黑科技（三）- 字节码篇

字节码织入

可以绕过编译，直接操作字节码，从而实现代码注入。所以使用 Javassist 的时机就是在构建工具 Gradle 将源文件编译成 .class 文件之后，在将 .class 打包成 .dex 文件之前。也有两个相当成熟的字节码框架可供使用。使用起来大同小异这节主要介绍ASM

ASM

ASM 是一个 Java 字节码操控框架。它能被用来动态生成类或者增强既有类的功能。ASM 可以直接产生二进制 class 文件，也可以在类被加载入 Java 虚拟机之前动态改变类行为。Java class 被存储在严格格式定义的 .class 文件里，这些类文件拥有足够的元数据来解析类中的所有元素：类名称、方法、属性以及 Java 字节码（指令）。ASM 从类文件中读入信息后，能够改变类行为，分析类信息，甚至能够根据用户要求生成新类。

Android 编译期的黑科技（二）- AOP 篇

Sat, 17 Mar 2018 19:00:00 +0000

Android 编译期的黑科技（二）- AOP 篇

AOP 定义

AOP 是 Aspect Oriented Programming 的缩写，即“面向切面编程”。使用 AOP，可以在编译期间对代码进行动态管理，以达到统一维护的目的。AOP 是 OOP 编程的一种延续，也是 Spring 框架中的一个重要模块。利用 AOP 可以对业务逻辑的各个模块进行隔离，从而使得业务逻辑各个部分之间的耦合度降低，提高程序的可重用性，同时提高开发的效率。利用 AOP，我们可以在无浸入的在宿主中插入一些代码逻辑，从而可以实现一些特殊的功能，比如日志埋点、性能监控、动态权限控制、代码调试等。

优点

织入的代码都是Java代码没有过多的学习难度

缺点

无法织入第三方的库
由于定义的切点依赖编程语言，该方案无法兼容 Lambda 语法

使用

AOP只是个概念的定义有很多库都可以实现。例如Javapoet/AspectJ。使用的方法都很相似这里只介绍Javapoet。防不胜防来啦这部分会用InjectExtra为例解释

Android 编译期的黑科技（一）基础篇

Sat, 10 Mar 2018 19:00:00 +0000

Android 编译期的黑科技（一）基础篇

序言

为什么需要这些编译期的黑科技使用这些编译期的小工具可以有效减少重复代码和重复逻辑在android中大量运用的ButterKnife Gilde Room和DataBind都大量的时候用编译期生成代码的技术
哪里可以用到这些应用场景很多最经典的应用场景是无痕埋点技术和解决重复逻辑
为什么需要这个基础篇直接上工具当然也可以使用，但毕竟写代码知其然还要知其所以然不然除了各种问题无法解决就很尴尬了

什么是编译

它主要的目的是将便于人编写、阅读、维护的高级计算机语言所写作的源代码程序，翻译为计算机能解读、运行的低阶机器语言的程序，也就是可执行文件。编译器将原始程序（source program）作为输入，翻译产生使用目标语言（target language）的等价程序。源代码一般为高级语言（High-level language），如Pascal、C、C++、C# 、Java等，而目标语言则是汇编语言或目标机器的目标代码（Object code），有时也称作机器代码（Machine code）。 java编译专指 .java —>.class

Fragment 踩坑实录

Sat, 10 Feb 2018 15:00:00 +0000

Fragment 踩坑实录

不要轻易使用commitNowAllowingStateLoss

在很多情况下使用不正确使用Fragment 会导致 java.lang.IllegalStateException 网上很多推荐commitNowAllowingStateLoss 来治标但使用commitNowAllowingStateLoss 会导致当前Fragment 以其子Fragment 丢失状态如 getVisibility() isHidden() 等等而且会出现很多不可预知的问题

出现问题:

1 在不正确的时机commit 如 onActivityResult 回调方法中 fragmentManager的 commit方法只能在onResume-onPause 的状态中使用如必须在其他状态下改变状态建议将状态记录下来在onResume中执行操作
2 重复add 同一个Fragment 由于commit属于异步操作可能由于commit 过快导致判断fragment是否为空的方法失效应先使用executePendingTransactions让上一次commit执行完成后再执行新的操作

不要在初始化方法中直接生成新的Fragment

在很多Activity 被重建的情况下直接生成新的Fragment 会导致旧Fragment 无法回收导致泄露如果在这些fragment中还有轮训或者socket 回调会导致崩溃解决方案: 为每个Fragment添加tag 使用findFragmentByTag() 获取Fragment 若为null 再创建新的Fragment

BTC 笔记

Thu, 10 Aug 2017 15:00:00 +0000

BTC 笔记

序

主要脉络为精通比特币(第二版) 以 bitoin源码

比特币原理

2.1交易，块，挖矿和区块链

2.2.1交易输入输出

交易就像复式记账法账簿中的行。简单来说，每一笔交易包含一个或多个“输入”，输入是针对一个比特币账号的负债

2.2.3交易链

一（多）笔交易输出就是另一（多）笔交易的输入

2.2.4找零

重要的是，找零地址不必与输入时提供的地址相同，出于隐私的原因，通常是所有者钱包中的新地址
比特币交易建立和签名时不用连接比特币网络。只有在执行交易时才需要将交易发送到网络。

2.3 交易的构建

比特币交易建立和签名时不用连接比特币网络。只有在执行交易时才需要将交易发送到网络。

2.3.1 获取正确的输入

完整客户端含有整个区块链中所有交易的所有未消费输出副本。这使得钱包既能拿这些输出构建交易，又能在收到新交易时很快地验证其输入是否正确。然而，完整客户端占太大的硬盘空间，所以大多数钱包使用轻量级的客户端，只保存用户自己的未消费输出。 可交给后端处理

2.3.2 创建交易输出

交易的输出会被创建成为一个包含这笔数额的脚本的形式，只能被引入这个脚本的一个解答后才能兑换。使用私钥签名

2.4 比特币挖矿

▷ 挖矿节点通过参考比特币的共识规则验证所有交易。因此，挖矿通过拒绝无效或畸形交易来提供比特币交易的安全性。

从零建站（基于Ubuntu 16.04）

Fri, 14 Apr 2017 18:00:00 +0000

从零建站（基于 Ubuntu 16.04）

初始化

免密登录

client生成ssh公钥

**ssh-keygen -t rsa -C “xxxxx@xxxxx.com” ** Generating public/private rsa key pair… 三次回车即可生成 ssh key

将ssh公钥放入service ~/.ssh/authorized_keys 文件下
重新登陆

Docker

INSTALL Docker

切换为Docker 官方源

sudo apt-get update

sudo apt-get install
apt-transport-https
ca-certificates
curl
software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg |
sudo apt-key add -

sudo add-apt-repository
“deb [arch=amd64] https://download.docker.com/linux/ubuntu
$(lsb_release -cs)
stable”

Install Docker CE

sudo apt-get update

sudo apt-get install docker-ce

apt-cache madison docker-ce

创建Docker内部网络

没有远程连接mySQL和Redis的需求且link方式连接容器维护繁琐使用Docker 内建网络连接节省端口资源

Posts on Website of SauceWu

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

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

子 Agent 并发的效率上限：什么时候加人反而更慢

子 Agent 并发的效率上限：什么时候加人反而更慢

一、并发加速比：从线性到平台期

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. 两层触摸模型

MPC 钱包：私钥从未完整存在过

MPC 钱包：私钥从未完整存在过

传统钱包的问题

AA 钱包：让智能合约成为你的钱包

AA 钱包：让智能合约成为你的钱包

传统钱包的体验困境

两种账户类型

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线系统拆解（一）：架构分层与领域模型

WebView页面软键盘弹出无法正确折叠页面的问题

WebView页面软键盘弹出无法正确折叠页面的问题