HarmonyKit | 鸿蒙开发展望：HarmonyKit 未来路线图与社区共建
引言：10 个工具是起点
HarmonyKit 的 10 个工具覆盖了开发者日常高频需求。但还有更多值得加入的工具——二维码生成、JWT 调试、Markdown 预览。这篇文章规划了 v2.0 的新工具候选、架构升级方向、工程化改进，和社区共建模式。
50 篇文章贯穿了从项目启动到 v1.0 发布的完整过程。每一篇都基于 HarmonyKit 项目中的真实实践——不是在写"教程"，而是在记录"我们是怎么做的"。
项目仓库：https://atomgit.com/VON-/harmony-kit
v2.0 新工具候选
| 工具 | 优先级 | 技术方案 | 复杂度 |
|---|---|---|---|
| 二维码生成器 | P0 | Canvas API 绘制 QR Code，离线生成 | ⭐⭐⭐ |
| JWT 调试器 | P1 | 解析 JWT header/payload，Base64 解码展示 | ⭐⭐ |
| 图片 Base64 | P1 | 图片文件编码为 Data URL，支持粘贴图片 | ⭐⭐ |
| Unicode 码点转换 | P2 | 字符 ↔ 码点双向转换 | ⭐ |
| Markdown 预览 | P2 | Markdown→HTML，WebView 渲染 | ⭐⭐⭐ |
| 图形验证码生成器 | P2 | Canvas 绘制干扰线+字符，临时验证码 | ⭐⭐ |
| Cron 表达式解析器 | P3 | 解析 cron 表达式，翻译为自然语言 | ⭐⭐⭐ |
| IP 地址计算器 | P3 | 子网掩码、CIDR、可用主机数计算 | ⭐⭐ |
| 代码差异对比器 | P3 | 文本 diff，类 GitHub 的 diff 视图 | ⭐⭐⭐⭐ |
二维码生成器（P0）
这是用户反馈中呼声最高的工具。技术方案是使用 Canvas API 在 ArkUI 中直接绘制二维码矩阵，参考 QR Code 的 ISO 标准实现。主要挑战在于：
- 二维码编码的 Reed-Solomon 纠错算法需要纯 ArkTS 实现
- Canvas 绘制需要处理像素对齐和缩放
- 支持三种纠错级别（L/M/Q/H）和多种输入模式（数字、字母、字节）
如果引入第三方 QR 码库，开发时间可以缩短 80%，但会增加 HAP 体积（约 200KB）。目前正在评估"自己实现"和"引入库"的 trade-off。
JWT 调试器（P1）
JWT 调试器的核心逻辑就是 Base64 解码 + JSON 格式化——这两个能力 HarmonyKit 已经有了（Base64Tool 和 JsonFormatter）。JWT 调试器只是将两者组合起来，再加上对 JWT 三个部分（header、payload、signature）的分段展示。
// JWT 调试器的核心逻辑functiondecodeJWT(token:string):JwtResult{constparts=token.split('.');if(parts.length!==3){return{valid:false,error:'无效的 JWT 格式'};}constheader:string=Base64Utils.decode(parts[0]);constpayload:string=Base64Utils.decode(parts[1]);constsignature:string=parts[2];return{valid:true,header:JsonUtils.format(header),payload:JsonUtils.format(payload),signature:signature,};}实现难度较低——核心是一个"已有的工具组合"而非全新的逻辑。
Markdown 预览（P2）
使用 WebView 加载本地 HTML 模板，将 Markdown 编译为 HTML 后注入 WebView 展示。挑战在于 Markdown 解析器需要自行实现或引入——纯 ArkTS 目前没有成熟的 Markdown 解析库。
备选方案是使用 WebView 端的能力：在 HTML 中引入 marked.js（一个流行的 Markdown 解析器），让 Markdown 解析在 WebView 中完成。这样 ArkTS 端只需要传递原始 Markdown 文本给 WebView 即可。
架构升级
HdsNavigation 迁移
将当前基于router.pushUrl+@Entry的导航方案，迁移到NavPathStack+HdsNavigation的声明式导航体系。迁移内容包括：
- 主页 Index.ets 重写为 HdsNavigation 根容器
- 10 个工具页从 @Entry 改为普通 @Component
- 所有页面的 titleBar 由 HdsNavDestination 统一管理
- 路由声明从
main_pages.json迁移到 @Builder 中的 NavMap
这个迁移的 ROI（投资回报率）评估：
- 正面效果：统一导航体验、更灵活的路由参数、自动页面管理
- 迁移成本：11 个页面的重写 = 约 2-3 天的工作量
- 风险：导航不稳定可能导致回归 bug
沉浸光感全面应用
SDK 26+ 发布后，将所有卡片背景、标题栏、底部导航栏都开启 systemMaterial 效果。当前沉浸光感仅应用在 HdsTabs，v2.0 将扩展到：
- ToolCard 卡片背景（毛玻璃效果）
- 工具页输入区域
- 统计卡片
- 模态弹窗背景
暗色模式
完整的深色主题支持，包括：
- 所有工具页面的暗色配色方案
- ToolCard 在暗色模式下的颜色调整
- 根据系统主题自动切换
- 手动切换开关（覆盖系统设置）
暗色模式的实现依赖于 ArkUI 的@Styles和主题变量。每一个颜色值都需要准备 light 和 dark 两个版本：
// 暗色模式的颜色定义constCOLORS={background:{light:'#F5F5F5',dark:'#1A1A2E'},cardBackground:{light:'#FFFFFF',dark:'#2D2D44'},textPrimary:{light:'#1C1C1E',dark:'#F5F5F5'},textSecondary:{light:'#8E8E93',dark:'#A0A0A0'},};工程化改进
单元测试覆盖率 80%
当前 HarmonyKit 的测试覆盖率主要集中在 utils 层的工具函数（JsonUtils、Base64Utils 等），pages 层的 UI 测试较少。v2.0 的目标是：
- utils 层：100% 覆盖率（纯函数，容易测试）
- pages 层：关键交互路径的 UI 测试（输入 → 点击 → 验证输出）
- components 层：90% 覆盖率（ToolCard、CopyButton 的渲染和交互）
ArkTS 的测试框架使用 @ohos/hypium，支持 LocalUnitTest（本地测试，不依赖模拟器）和 ohosTest（真机/模拟器测试）。
CI/CD 自动化构建
当前 HarmonyKit 的构建流程是手动的：hvigor clean && hvigor build+ 签名的 APK/HAP 生成。v2.0 计划使用 GitHub Actions / 码云 CI 实现自动化：
- 推送代码到 main 分支 → 自动触发构建
- 构建通过 → 自动运行单元测试
- 测试通过 → 自动签名 → 生成 HAP
- 发布 Release → 在项目页面提供下载链接
AppGallery 正式上架
HarmonyKit 当前仅在项目仓库中提供源码和构建指南。v2.0 的目标是上架华为 AppGallery，让更多用户可以安装使用。上架流程包括：
- 注册鸿蒙开发者账号
- 准备上架材料（应用截图、描述、隐私政策）
- 提交审核
- 处理审核反馈
做一个工具不难，把过程记录下来才有价值。这些文章的目标读者是"下一个 HarmonyOS 开发者"——希望你在遇到同样的问题时，能找到这篇文章，说一句"哦，原来这里有人遇到过"。
项目仓库：https://atomgit.com/VON-/harmony-kit