HarmonyKit | 鸿蒙新特性应用10 个开发工具的选型与分类选型不是拍脑袋HarmonyKit 目前包含 10 个工具。从最初 5 个 MVP 工具到后来扩展到 10 个每一个工具的增加都经过了三个维度的评估使用频率、实现复杂度和独立价值。这篇文章详细拆解了 10 个工具的选型逻辑、四分类体系的设计原则以及在两次迭代中验证过的工具-架构协同方法论。项目仓库https://atomgit.com/VON-/harmony-kit三维评估模型维度一使用频率开发者日常工作中有些操作几乎每天都会遇到。HarmonyKit 的工具入选标准是每周至少一次。我统计了自己一个月的开发者日常JSON 格式化/校验每周 15-20 次查看 API 响应、调试配置文件、检查 build 输出时间戳转换每周 5-8 次排查日志中的时间、API 参数中的时间戳Base64 编解码每周 3-5 次解 JWT payload、编码凭证信息URL 编解码每周 2-3 次构造 API 请求参数哈希计算每周 1-2 次校验文件完整性、生成 token 指纹这些操作在桌面端通过浏览器或终端完成——打开 Chrome DevTools 的 Console跑一行JSON.stringify(JSON.parse(str), null, 2)。但在移动端呢你需要打开一个网站忍受广告和加载。HarmonyKit 的价值就是把一行代码能搞定的操作搬到手机上让它在 3 秒内完成。维度二实现复杂度每个工具的核心逻辑必须控制在合理范围内。HarmonyKit 的衡量标准是核心算法代码不超过 100 行总页面代码不超过 200 行。超过这个标准的有两个候选被放到了 2.0 版本二维码生成需要 Canvas 绘制或引入 QR 编码库。QRCodeGenerator的核心算法有上千行。不满足100 行核心逻辑的约束。JWT 调试器需要解析 JWT 结构、验证签名、处理多种算法。复杂度分散在多个子功能中不是一个单一工具。符合标准的工具反而是那些看起来简单但每天用的进制转换parseInt(input, fromRadix).toString(toRadix)——核心就一行UUID 生成器一个模板字符串 随机数生成——20 行文本统计length、split、正则计数——20 行简单的算法不代表没价值。恰恰相反最简单的工具往往使用频率最高。维度三独立价值每个工具必须能独立使用不依赖其他工具的输出。如果一个工具的典型使用场景是先在这个工具里处理再跳到那个工具里继续那这两个工具可能应该合并。HarmonyKit 所有 10 个工具都满足单次使用闭环——用户在工具页内完成输入→操作→复制不需要跨页面跳转。四分类体系的设计格式化分类成员JSON 格式化这个分类目前只有一个工具但它是整个应用的入口级工具。JSON 格式化有三个子功能格式化美化缩进、压缩去除空白、校验错误定位。为什么格式化只有一个工具因为格式化类操作本质上是一个有损→无损的转换过程。JSON 格式化是其中最典型的代表。XML 格式化、YAML 格式化属于低频需求不在首版范围。编解码分类成员Base64 编解码、URL 编解码编解码类工具的共同特征是双向操作——编码和解码是成对出现的。UI 设计上编码和解码放在同一个页面的两个按钮中而不是分拆为两个独立页面。Base64 和 URL 是编码领域的双子星。它们解决的问题相似但场景互补Base64 用于二进制→文本的转换URL 编码用于保留字符的转义。两个工具放在同一个分类下用户心智模型一致。计算分类成员时间戳转换、哈希计算、UUID 生成器、颜色转换、进制转换计算分类是最大的分类有五个工具。它们的共同特征是单向或双向计算——输入参数输出结果。计算过程不需要用户理解底层算法。时间戳和进制转换是翻译型计算——将一个表达形式翻译为另一个。哈希和 UUID 是生成型计算——根据输入或随机数生成一个确定的输出。颜色转换是互转型计算——三个色彩空间之间的任意转换。五个工具共享同一个页面模板输入控件 参数选项 计算按钮 结果展示 复制按钮。差异性体现在参数选项的复杂度——哈希需要选择算法进制需要选择源进制颜色需要选择转换方向。文本分类成员正则测试器、文本统计文本分类的两个工具处理的是非结构化文本——用户的输入不是格式化的数据而是任意文本。正则测试器的输出是匹配项列表文本统计的输出是数字指标。这个分类的特点是实时反馈。正则测试器需要用户反复调整表达式和测试文本文本统计需要随着输入实时更新计数。因此这两个工具的 UI 设计上操作按钮和输入区域紧密耦合反馈延迟几乎是即时的。从 5 到 10 的迭代经验首版 5 个工具JSON、Base64、时间戳、URL、哈希覆盖了格式化和编解码两个分类。这个选择是刻意的——先验证两个分类的页面模板是否可以复用然后再扩展到其他分类。结果证明模板设计足够通用。第二批 5 个工具正则、UUID、颜色、进制、文本统计加入时不需要修改任何现有工具页的代码也不需要修改 ToolCard 或 CopyButton 组件。只是在TOOL_LIST数组中追加了 5 个对象然后创建了 5 个页面文件。这种零破坏性扩展是三层架构的核心价值。如果第一批工具和第二批工具在代码上有耦合比如共享了某个带状态的 service 类那么新增工具可能影响现有功能。但 HarmonyKit 的 utils 都是无状态的静态方法每个工具页是独立的功能单元。没有入选的工具除了前面提到的二维码和 JWT还有几个候选被评估后被搁置图片 Base64 编码。将图片文件编码为 Base64 Data URL 是一个常见需求。但实现需要访问文件系统kit.CoreFileKit和图片解码kit.ImageKit引入了两个额外的系统 Kit。而且不同格式的图片PNG、JPEG、WebP编码逻辑各异。首版暂不纳入。Unicode 码点转换。Unicode 字符和码点之间的互转比如U4E2D↔中。核心逻辑简单String.fromCharCodecharCodeAt但使用频率太低。可能作为未来字符工具分类的一个子功能。Markdown 预览。Markdown 转 HTML 需要完整的 Markdown 解析器。即使使用最简化的正则替换方案代码量也在 300 行以上。而且预览效果需要 WebView 渲染引入了新的组件类型。暂不纳入。分类的未来演进随着工具数量增长四个分类会逐渐变得不平衡。“计算分类已经有 5 个工具而格式化只有 1 个。未来可能会拆分计算为转换计算和生成计算两个子类或者新增图形”、网络等新分类。但分类体系的调整不能影响现有的 Tab 导航。CATEGORIES数组定义在 model 层Index.ets通过ForEach(CATEGORIES, ...)动态生成 Tab。这意味着增加或重命名分类只需要修改 model 中的一行数组不需要改任何 UI 代码。这种数据驱动 UI的设计在 ArkUI 中特别自然——ForEach的声明式语法配合响应式状态管理让你感觉不到数据和 UI 的同步是一个需要解决的问题。项目仓库https://atomgit.com/VON-/harmony-kit