HarmonyKit | 鸿蒙开发展望：HarmonyKit 未来路线图与社区共建

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）的分段展示。

typescript 复制代码

// JWT 调试器的核心逻辑
function decodeJWT(token: string): JwtResult {
  const parts = token.split('.');
  if (parts.length !== 3) {
    return { valid: false, error: '无效的 JWT 格式' };
  }
  const header: string = Base64Utils.decode(parts[0]);
  const payload: string = Base64Utils.decode(parts[1]);
  const signature: 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 两个版本：

typescript 复制代码

// 暗色模式的颜色定义
const COLORS = {
  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