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

●VON

14人浏览 · 2026-07-12 22:47:39

●VON · 2026-07-12 22:47:39 发布

在这里插入图片描述

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 调试器的核心逻辑
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 两个版本：

// 暗色模式的颜色定义
const COLORS = {
  background: { light: '#F5F5F5', dark: '#1A1A2E' },
  cardBackground: { light: '#FFFFFF', dark: '#2D2D44' },
  textPrimary: { light: '#1C1C1E', dark: '#F5F5F5' },
  textSecondary: { light: '#8E8E93', dark: '#A0A0A0' },
};