HarmonyKit | 鸿蒙新特性架构：计算类工具的 @State 状态管理与响应式模式

引言：计算与编解码的本质区别

HarmonyKit 的 10 个工具中有一半属于"计算"分类：时间戳转换、哈希计算、UUID 生成器、颜色转换、进制转换。这些工具的共性非常清晰——输入一组参数，系统执行一个确定性的计算，输出一个结果。

但与"编解码"工具（如 Base64、URL）不同，计算类工具有一个核心的交互设计问题：应该在用户修改参数后自动计算，还是等用户点击"计算"按钮后再计算？

HarmonyKit 没有选择"全自动"路线。每个计算工具都保留了一个明确的执行按钮。这是权衡了性能、交互明确性和用户预期的结果。这篇文章将详细拆解计算类工具的 @State 管理策略、三种初始化模式、以及手动触发在移动端工具类应用中的合理性。

项目仓库：https://atomgit.com/VON-/harmony-kit

@State 响应式模型

ArkTS 中 @State 装饰的变量是响应式的。值变化 → build() 重新执行 → UI 自动刷新。不需要手动调用 setState 或 notifyPropertyChanged。

但"UI 自动刷新"不等于"业务逻辑自动执行"。以进制转换器为例：

@State input: string = '255';
@State fromRadix: number = 10;
@State results: string[] = ['', '', '', ''];

当 fromRadix 从 10 变为 16 时，所有依赖 fromRadix 的 UI 元素（按钮的选中状态）自动刷新。但 results 数组的值不会自动重新计算——因为 ArkUI 不知道 results 应该等于 parseInt(input, fromRadix).toString(...)。这个计算关系需要开发者显式调用 convert() 方法来触发。

这是 ArkUI 响应式系统的核心特征：UI 渲染是自动的，业务逻辑更新是手动的。 这个模式与 React 的 useEffect 不同——React 允许你声明"当 dependency 变化时重新执行这段逻辑"，而 ArkUI 的 @State 只负责 UI 层面的响应式。

三种初始化模式

模式一：aboutToAppear 预计算

时间戳转换器和 UUID 生成器在 aboutToAppear() 中自动执行首次计算：

@State tsInput: string = String(TimestampUtils.nowSec());
@State dateOutput: string = '';

aboutToAppear() {
  this.tsToDate();
}

用户打开页面的第一时间就看到"当前时间戳 = 某日期"——不需要点任何按钮。这种"零点击就有效果"的设计降低了"空状态焦虑"——用户面对空白输入框时的不确定感。也让用户立刻理解"这个工具是把时间戳变成日期"。

UUID 生成器同样在 aboutToAppear() 中自动生成 5 个 UUID。用户打开页面时已经有了"产品"，可以立刻复制使用。

模式二：默认值 + 自动计算

进制转换器和颜色转换器在声明 @State 时设置了默认值（'255'、'#007aff'），并在 aboutToAppear() 中调用 convert()。用户打开页面就看到预填充的计算结果。

255(十进制) = 11111111(二进制) = 377(八进制) = FF(十六进制)

这个预填充的结果表不仅方便——更关键的是它向用户展示了工具的功能。一个空白页面无法传达工具的用途，但一个预填充了 255 的结果表立刻让用户明白"这个工具能做四种进制之间的转换"。

模式三：空白等待输入

JSON 格式化、Base64、URL、正则测试器、文本统计——初始化空白。因为"空输入有意义的结果"对它们不适用——空 JSON 是什么？没有答案。空白 + placeholder 提示用户"粘贴内容到这里"。

手动触发 vs 自动触发

为什么哈希计算器不在用户切换算法时自动重算？两个原因：

性能考量。 哈希计算是 HarmonyKit 中唯一真正消耗 CPU 的操作。cryptoFramework.createMd() 需要创建哈希实例、将字符串编码为字节数组、执行多轮哈希轮函数。对于长输入（粘贴一整篇日志文件），MD5 计算可能需要几十到上百毫秒。如果用户快速点击 MD5 → SHA1 → SHA256 三个按钮，自动重算会触发三次不必要的哈希计算——对于长输入这是资源的浪费。

交互明确性。 切换算法选项 ≠ 需要立即计算结果。用户可能在调整输入文本的中途换了算法——此时自动计算的结果用户并不需要。"等我准备好了再算"是更好的交互节奏。

反例是文本统计工具——它实现了实时自动统计。每个字符输入都触发六项统计数字的更新。因为 length、split、正则匹配这些操作在 JavaScript 引擎中只需微秒级——不存在"等待"的感觉。

规则：计算耗时 < 1ms → 自动触发；计算耗时 > 10ms → 手动触发；中间地带 → 保守选择手动触发。

状态变量的粒度控制

HarmonyKit 的每个计算工具都保持最精简的 @State 变量集合。进制转换器只需三个：

@State input: string = '255';          // 输入值
@State fromRadix: number = 10;         // 源进制
@State results: string[] = ['', '', '', ''];  // 四个进制的结果

没有 loading 状态（计算是同步的），没有独立验证状态（无效输入时 results 变为 ['无效输入', ...]，用结果本身承载错误信息）。少一个状态变量就少一个需要同步的位置。

@Provide/@Consume 的跨层级通信

导航栈 NavPathStack 通过 @Provide/@Consume 在 HarmonyKit 中跨层级传递：

// Index.ets — 提供者
@Provide('pathStack') pathStack: NavPathStack = new NavPathStack();

// ToolCard.ets — 消费者
@Consume('pathStack') pathStack: NavPathStack;

React 中需要 Context + Provider + useContext 三件套才能实现的能力，ArkUI 中用两个装饰器就完成了。@Provide 的变量变化时，所有 @Consume 的后代组件自动重渲染。

HarmonyKit 只用了这一组 Provide/Consume——没有 AppState、Redux Store、ViewModel。10 个工具页的复杂度下，全局状态管理不是必需的。

项目仓库：https://atomgit.com/VON-/harmony-kit