HarmonyKit | 鸿蒙开发kit.UIDesignKit 组件体系完整解读引言一套组件体系而非一个组件库kit.UIDesignKit是 HarmonyOS 在 API 22 引入的核心 UI 套件。在 HarmonyKit 项目中它被用于首页的 Tab 导航HdsTabs和材质效果hdsMaterial。但这仅是冰山一角——UIDesignKit 是一个完整的、由 30 个 HDSHarmony Design System组件构成的体系。理解这个体系不仅是为了能用它的组件更是为了理解鸿蒙对应用应该如何构建 UI的设计立场。这篇文章完整解读 UIDesignKit 的组件生态、设计理念、选型逻辑和未来展望。项目仓库https://atomgit.com/VON-/harmony-kitUIDesignKit 的定位一个 Kit不是多个组件首先要理解kit.UIDesignKit在鸿蒙 Kit 体系中的位置。鸿蒙的系统能力被组织为多个 Kit 包kit.ArkUI # ArkUI 框架核心组件、布局、动画 kit.UIDesignKit # HDS 组件体系标准化设计组件 kit.AbilityKit # Ability 和生命周期管理 kit.BasicServicesKit # 基础服务粘贴板、通知等 kit.CryptoArchitectureKit # 加密框架 ...kit.UIDesignKit与kit.ArkUI的关系是ArkUI 提供组件构建能力Component、State、Builder 等底层机制UIDesignKit 提供标准化组件实现在这些底层机制之上封装的设计系统组件。你可以只使用 ArkUI 构建整个应用——就像 HarmonyKit 的 10 个工具页面它们只使用了基础组件Column、Row、Text、Button、TextArea等。但当你需要导航栏、选项卡、对话框等系统级 UIUIDesignKit 提供了标准化的实现。HDS 组件全景图UIDesignKit 包含以下主要组件类别导航类组件组件用途是否用于 HarmonyKitHdsNavigation页面级导航框架计划中HdsTabs标签页切换已使用首页分类导航HdsToolbar工具栏未使用HdsBreadcrumb面包屑导航未使用内容类组件组件用途是否用于 HarmonyKitHdsList标准化列表未使用使用了基础 GridHdsCard标准化卡片未使用自定义了 ToolCardHdsEmptyState空状态占位未使用HdsLoading加载状态指示未使用交互类组件组件用途是否用于 HarmonyKitHdsButton标准化按钮未使用使用了基础 ButtonHdsTextField标准化文本输入未使用使用了基础 TextInput/TextAreaHdsSwitch标准化开关未使用HdsSlider标准化滑块未使用HdsStepper步进器未使用反馈类组件组件用途是否用于 HarmonyKitHdsDialog标准化对话框未使用HdsToast标准化提示未使用使用了 promptAction.showToastHdsSnackbar底部消息条未使用HdsBottomSheet底部弹出面板未使用选择类组件组件用途是否用于 HarmonyKitHdsDatePicker日期选择器未使用HdsTimePicker时间选择器未使用HdsDropdownMenu下拉菜单未使用HdsSegmentedControl分段控制器未使用为什么 HarmonyKit 只用了一个 HDS 组件HarmonyKit 目前只在首页使用了HdsTabs和对应的hdsMaterial。其他所有 UI——ToolCard、CopyButton、各个工具页——都使用了 ArkUI 基础组件。这是一个有意的技术选择背后有四个考量考量一工具页需要定制化 UIHarmonyKit 的工具页如 RegexTester、ColorConverter的 UI 布局高度定制化——输入框和结果区并排、自定义的旗标按钮、预览色块。这些布局不是标准化的表单或列表强行套用 HDS 组件反而增加适配成本。以 RegexTester 为例// 手动布局的自定义旗标按钮组Row(){Button(g).fontSize(11).height(28).backgroundColor(this.flags.includes(g)?#007aff:#f0f0f0).fontColor(this.flags.includes(g)?#ffffff:#333).borderRadius(6).padding({left:8,right:8}).margin({left:4}).onClick(()this.toggleFlag(g));// ... i, m 旗标按钮}这个场景中如果使用HdsSegmentedControl替换手动布局的旗标按钮反而会因为 HdsSegmentedControl 的设计约束等宽、等间距、单选而无法实现当前的交互效果多个独立开关、不等宽标签。考量二最小依赖原则每引入一个 HDS 组件就增加了一个 API 版本依赖。HdsTabs是 API 22 的组件——HarmonyKit 的compatibleSdkVersion已经是6.0.2(22)所以使用它没有新增限制。但如果使用HdsNavigationAPI 24就会将最低兼容版本提升到 API 24。在开箱即用的标准化体验和更多的设备兼容范围之间HarmonyKit 选择保守的策略只在确实需要时才引入新 API 依赖。考量三HAP 体积每个 HDS 组件引入都会增加一小部分代码到最终的 HAP 中通过 Tree Shaking 优化未使用的 HDS 组件不会被打包。但如果 20 个 HDS 组件都被使用即使 Tree Shaking 生效HDS 的共享基础设施代码也会增加。对于 HarmonyKit 这样的轻量级工具应用目标 HAP 在 3MB 左右每 KB 体积都要有对应的功能回报。考量四学习曲线的平缓化作为一个开源项目HarmonyKit 的代码被设计为可读的学习材料。使用 ArkUI 基础组件构建的 UI 可以直接阅读——每行代码都对应具体的视觉和交互。使用 HDS 组件时一部分行为由系统接管如材质效果、自适应布局代码的可读性反而降低——你必须查阅 HDS 文档才能理解某个属性的行为。对于目标是展示鸿蒙开发最佳实践的项目而言基础组件的可读性优于 HDS 组件的便捷性。但这不是说 HDS 组件不好——在商业应用中使用HdsButton替代手动配置的Button能带来一致的设计语言、更少的代码、更好的无障碍支持和更可靠的跨设备适配。这是一种工程上的取舍。HDS 组件的技术特性使用 HDS 组件不仅仅是使用一个封装好的 UI 控件它还带来了以下技术特性1. 无障碍Accessibility内置每个 HDS 组件都内置了完整的无障碍支持——正确的accessibilityLabel、accessibilityHint、焦点顺序、屏幕阅读器兼容。这些是基础组件需要开发者手动配置的。对于 HarmonyKit 来说无障碍不是当前优先级——因为核心交互非常简单输入文本→查看结果→复制。但对于面向广泛用户群的商业应用HDS 组件的内置无障碍支持可以节省大量开发时间。2. 自适应布局HDS 组件会自动适应不同屏幕尺寸和方向。以HdsTabs为例手机竖屏Tab 标签等宽排列手机横屏Tab 标签紧凑排列平板Tab 标签可能需要调整间距或采用侧边栏布局由 HdsNavigation 处理这些自适应逻辑由 HDS 内部处理开发者不需要编写条件布局代码。3. 设计一致性HDS 组件共享一套设计令牌Design Tokens——颜色、间距、圆角、字重等基础设计参数。使用 HDS 组件的应用会自动获得视觉一致性不需要为每个按钮配置相同的颜色和阴影。HarmonyKit 没有使用 HDS 设计令牌因为它的视觉风格是自定义的#007aff蓝色主色调、#f5f5f5灰色背景、14px 圆角。这是一种有意的偏离——HarmonyKit 要表达的不是系统的中性风格而是开发者工具的干净、精确、克制的气质。4. 系统主题联动HDS 组件会自动联动系统主题深色模式、字体大小、强调色。当用户切换深色模式时使用 HDS 组件的 UI 会自动适配——不需要写if (darkMode) { ... }的条件逻辑。HarmonyKit 通过在EntryAbility.onCreate中设置ColorMode.COLOR_MODE_NOT_SET主动跟随了系统颜色模式this.context.getApplicationContext().setColorMode(ConfigurationConstant.ColorMode.COLOR_MODE_NOT_SET);但由于工具页的组件使用的是基础组件颜色硬编码实际对深色模式的支持有限。这是一个已知的改进项——计划通过 HDS 组件替换或引入系统颜色资源来完善深色模式体验。5. 未来兼容性当鸿蒙引入新的视觉特性如 ImmersiveMaterialHDS 组件会自动获益。使用 HDS Tabs 的应用在 API 26 上自动拥有材质效果不需要任何代码变更。这正是HDS 作为设计系统的抽象层的核心价值——你的应用通过 HDS 与系统设计语言保持一致而不需要跟踪每个 API 的新 UI 特性。迁移路径从基础组件到 HDS 组件对于已经使用基础组件构建的应用如 HarmonyKit迁移到 HDS 组件需要分阶段实施第一阶段识别可替换的标准化交互应用中有两类 UI标准化交互导航、选项卡、对话框、菜单。这些应该替换为 HDS 组件。定制化交互工具页面的输入/输出配置。这些保留基础组件。HarmonyKit 目前处于第一阶段的初期——已完成首页导航的 HDS 迁移HdsTabs正在考虑工具页面的导航栏是否迁移到 HdsNavigation。第二阶段替换系统级 UI将以下组件替换为 HDS 对应物对话框AlertDialog→HdsDialog按钮Button→HdsButton——仅限系统级的按钮工具页面的自定义按钮保留输入框TextInput→HdsTextField——仅限表单场景HarmonyKit 的工具页中大部分 Button 和 TextInput 都是高度自定义的颜色、尺寸、字体都不同不适合替换为 HDS 变体。但 CopyButton复制到剪贴板这种通用操作按钮可以考虑迁移到HdsButton以获得更好的无障碍支持。第三阶段采用设计令牌将硬编码的颜色、间距、圆角替换为 HDS 设计令牌或自定义令牌// 替换前.fontColor(#1a1a1a).backgroundColor(#f5f5f5)// 替换后使用 HDS 令牌.fontColor($r(sys.color.font_primary)).backgroundColor($r(sys.color.background_secondary))或者保持自定义令牌但统一管理.fontColor($r(app.color.text_primary)).backgroundColor($r(app.color.background))第四阶段启用高级特性在基础组件已替换为标准 HDS 组件的基础上启用材质效果、自适应布局等高级特性。这是 API 26 特有的能力需要设备运行对应的系统版本。HDS 组件选择的决策树当你面对该用基础组件还是 HDS 组件的选择时可以参考以下决策树是全局导航/框架级元素吗 ├── 是 → 使用 HDS 组件HdsTabs, HdsNavigation └── 否 → 用户交互是标准化的吗对话框、菜单、表单 ├── 是 → 使用 HDS 组件HdsDialog, HdsTextField └── 否 → UI 高度定制化吗自定义布局、颜色、动画 ├── 是 → 使用 ArkUI 基础组件 └── 否 → 可以提升API兼容性吗 ├── 是 → 使用 HDS 组件 └── 否 → 使用 ArkUI 基础组件HarmonyKit 当前的状态是顶部 Tab 导航使用 HDS 组件全局框架元素所有内容/工具页面使用 ArkUI 基础组件高度定制化 UI。UIDesignKit 的未来演进基于 HarmonyOS 的发展趋势UIDesignKit 可能会在以下几个方面继续演进1. HdsNavigation 作为页面导航的默认方案目前 HarmonyKit 使用router.pushUrl()进行页面导航。HdsNavigation提供了一种声明式的、带返回栈管理的导航方案。随着 API 26 的普及预计HdsNavigation会取代router.pushUrl()成为推荐的页面导航方式。2. 更多智能组件趋势是从组件库到智能组件库——组件不仅仅是封装 UI还内置了行为智能。例如HdsList自动检测数据量并启用虚拟滚动HdsTextField自动检测输入内容类型并调整键盘HdsNavigation自动管理手势返回和动画过渡3. 跨设备形态的统一随着鸿蒙生态扩展到车机、手表、电视等设备形态HDS 组件需要在这些形态间提供统一的 API 和自适应的视觉表现。开发者用同一套 HDS API在不同设备上获得最合适的体验。结语kit.UIDesignKit不仅是鸿蒙的 UI 组件库它是鸿蒙对应用应该长什么样的设计立场。选择 HDS 组件意味着你选择了一致的视觉语言、内置的无障碍支持、自适应的布局和未来兼容性。选择 ArkUI 基础组件意味着你保留了完全的 UI 控制权。两者不是非此即彼的关系——就像 HarmonyKit 展示的导航层用 HDS内容层用基础组件是一种实用主义的混合策略。理解何时拥抱系统的设计体系、何时坚持自己的设计表达是鸿蒙 UI 开发的核心技能。项目仓库https://atomgit.com/VON-/harmony-kit
HarmonyKit | 鸿蒙开发kit.UIDesignKit 组件体系完整解读引言一套组件体系而非一个组件库kit.UIDesignKit是 HarmonyOS 在 API 22 引入的核心 UI 套件。在 HarmonyKit 项目中它被用于首页的 Tab 导航HdsTabs和材质效果hdsMaterial。但这仅是冰山一角——UIDesignKit 是一个完整的、由 30 个 HDSHarmony Design System组件构成的体系。理解这个体系不仅是为了能用它的组件更是为了理解鸿蒙对应用应该如何构建 UI的设计立场。这篇文章完整解读 UIDesignKit 的组件生态、设计理念、选型逻辑和未来展望。项目仓库https://atomgit.com/VON-/harmony-kitUIDesignKit 的定位一个 Kit不是多个组件首先要理解kit.UIDesignKit在鸿蒙 Kit 体系中的位置。鸿蒙的系统能力被组织为多个 Kit 包kit.ArkUI # ArkUI 框架核心组件、布局、动画 kit.UIDesignKit # HDS 组件体系标准化设计组件 kit.AbilityKit # Ability 和生命周期管理 kit.BasicServicesKit # 基础服务粘贴板、通知等 kit.CryptoArchitectureKit # 加密框架 ...kit.UIDesignKit与kit.ArkUI的关系是ArkUI 提供组件构建能力Component、State、Builder 等底层机制UIDesignKit 提供标准化组件实现在这些底层机制之上封装的设计系统组件。你可以只使用 ArkUI 构建整个应用——就像 HarmonyKit 的 10 个工具页面它们只使用了基础组件Column、Row、Text、Button、TextArea等。但当你需要导航栏、选项卡、对话框等系统级 UIUIDesignKit 提供了标准化的实现。HDS 组件全景图UIDesignKit 包含以下主要组件类别导航类组件组件用途是否用于 HarmonyKitHdsNavigation页面级导航框架计划中HdsTabs标签页切换已使用首页分类导航HdsToolbar工具栏未使用HdsBreadcrumb面包屑导航未使用内容类组件组件用途是否用于 HarmonyKitHdsList标准化列表未使用使用了基础 GridHdsCard标准化卡片未使用自定义了 ToolCardHdsEmptyState空状态占位未使用HdsLoading加载状态指示未使用交互类组件组件用途是否用于 HarmonyKitHdsButton标准化按钮未使用使用了基础 ButtonHdsTextField标准化文本输入未使用使用了基础 TextInput/TextAreaHdsSwitch标准化开关未使用HdsSlider标准化滑块未使用HdsStepper步进器未使用反馈类组件组件用途是否用于 HarmonyKitHdsDialog标准化对话框未使用HdsToast标准化提示未使用使用了 promptAction.showToastHdsSnackbar底部消息条未使用HdsBottomSheet底部弹出面板未使用选择类组件组件用途是否用于 HarmonyKitHdsDatePicker日期选择器未使用HdsTimePicker时间选择器未使用HdsDropdownMenu下拉菜单未使用HdsSegmentedControl分段控制器未使用为什么 HarmonyKit 只用了一个 HDS 组件HarmonyKit 目前只在首页使用了HdsTabs和对应的hdsMaterial。其他所有 UI——ToolCard、CopyButton、各个工具页——都使用了 ArkUI 基础组件。这是一个有意的技术选择背后有四个考量考量一工具页需要定制化 UIHarmonyKit 的工具页如 RegexTester、ColorConverter的 UI 布局高度定制化——输入框和结果区并排、自定义的旗标按钮、预览色块。这些布局不是标准化的表单或列表强行套用 HDS 组件反而增加适配成本。以 RegexTester 为例// 手动布局的自定义旗标按钮组Row(){Button(g).fontSize(11).height(28).backgroundColor(this.flags.includes(g)?#007aff:#f0f0f0).fontColor(this.flags.includes(g)?#ffffff:#333).borderRadius(6).padding({left:8,right:8}).margin({left:4}).onClick(()this.toggleFlag(g));// ... i, m 旗标按钮}这个场景中如果使用HdsSegmentedControl替换手动布局的旗标按钮反而会因为 HdsSegmentedControl 的设计约束等宽、等间距、单选而无法实现当前的交互效果多个独立开关、不等宽标签。考量二最小依赖原则每引入一个 HDS 组件就增加了一个 API 版本依赖。HdsTabs是 API 22 的组件——HarmonyKit 的compatibleSdkVersion已经是6.0.2(22)所以使用它没有新增限制。但如果使用HdsNavigationAPI 24就会将最低兼容版本提升到 API 24。在开箱即用的标准化体验和更多的设备兼容范围之间HarmonyKit 选择保守的策略只在确实需要时才引入新 API 依赖。考量三HAP 体积每个 HDS 组件引入都会增加一小部分代码到最终的 HAP 中通过 Tree Shaking 优化未使用的 HDS 组件不会被打包。但如果 20 个 HDS 组件都被使用即使 Tree Shaking 生效HDS 的共享基础设施代码也会增加。对于 HarmonyKit 这样的轻量级工具应用目标 HAP 在 3MB 左右每 KB 体积都要有对应的功能回报。考量四学习曲线的平缓化作为一个开源项目HarmonyKit 的代码被设计为可读的学习材料。使用 ArkUI 基础组件构建的 UI 可以直接阅读——每行代码都对应具体的视觉和交互。使用 HDS 组件时一部分行为由系统接管如材质效果、自适应布局代码的可读性反而降低——你必须查阅 HDS 文档才能理解某个属性的行为。对于目标是展示鸿蒙开发最佳实践的项目而言基础组件的可读性优于 HDS 组件的便捷性。但这不是说 HDS 组件不好——在商业应用中使用HdsButton替代手动配置的Button能带来一致的设计语言、更少的代码、更好的无障碍支持和更可靠的跨设备适配。这是一种工程上的取舍。HDS 组件的技术特性使用 HDS 组件不仅仅是使用一个封装好的 UI 控件它还带来了以下技术特性1. 无障碍Accessibility内置每个 HDS 组件都内置了完整的无障碍支持——正确的accessibilityLabel、accessibilityHint、焦点顺序、屏幕阅读器兼容。这些是基础组件需要开发者手动配置的。对于 HarmonyKit 来说无障碍不是当前优先级——因为核心交互非常简单输入文本→查看结果→复制。但对于面向广泛用户群的商业应用HDS 组件的内置无障碍支持可以节省大量开发时间。2. 自适应布局HDS 组件会自动适应不同屏幕尺寸和方向。以HdsTabs为例手机竖屏Tab 标签等宽排列手机横屏Tab 标签紧凑排列平板Tab 标签可能需要调整间距或采用侧边栏布局由 HdsNavigation 处理这些自适应逻辑由 HDS 内部处理开发者不需要编写条件布局代码。3. 设计一致性HDS 组件共享一套设计令牌Design Tokens——颜色、间距、圆角、字重等基础设计参数。使用 HDS 组件的应用会自动获得视觉一致性不需要为每个按钮配置相同的颜色和阴影。HarmonyKit 没有使用 HDS 设计令牌因为它的视觉风格是自定义的#007aff蓝色主色调、#f5f5f5灰色背景、14px 圆角。这是一种有意的偏离——HarmonyKit 要表达的不是系统的中性风格而是开发者工具的干净、精确、克制的气质。4. 系统主题联动HDS 组件会自动联动系统主题深色模式、字体大小、强调色。当用户切换深色模式时使用 HDS 组件的 UI 会自动适配——不需要写if (darkMode) { ... }的条件逻辑。HarmonyKit 通过在EntryAbility.onCreate中设置ColorMode.COLOR_MODE_NOT_SET主动跟随了系统颜色模式this.context.getApplicationContext().setColorMode(ConfigurationConstant.ColorMode.COLOR_MODE_NOT_SET);但由于工具页的组件使用的是基础组件颜色硬编码实际对深色模式的支持有限。这是一个已知的改进项——计划通过 HDS 组件替换或引入系统颜色资源来完善深色模式体验。5. 未来兼容性当鸿蒙引入新的视觉特性如 ImmersiveMaterialHDS 组件会自动获益。使用 HDS Tabs 的应用在 API 26 上自动拥有材质效果不需要任何代码变更。这正是HDS 作为设计系统的抽象层的核心价值——你的应用通过 HDS 与系统设计语言保持一致而不需要跟踪每个 API 的新 UI 特性。迁移路径从基础组件到 HDS 组件对于已经使用基础组件构建的应用如 HarmonyKit迁移到 HDS 组件需要分阶段实施第一阶段识别可替换的标准化交互应用中有两类 UI标准化交互导航、选项卡、对话框、菜单。这些应该替换为 HDS 组件。定制化交互工具页面的输入/输出配置。这些保留基础组件。HarmonyKit 目前处于第一阶段的初期——已完成首页导航的 HDS 迁移HdsTabs正在考虑工具页面的导航栏是否迁移到 HdsNavigation。第二阶段替换系统级 UI将以下组件替换为 HDS 对应物对话框AlertDialog→HdsDialog按钮Button→HdsButton——仅限系统级的按钮工具页面的自定义按钮保留输入框TextInput→HdsTextField——仅限表单场景HarmonyKit 的工具页中大部分 Button 和 TextInput 都是高度自定义的颜色、尺寸、字体都不同不适合替换为 HDS 变体。但 CopyButton复制到剪贴板这种通用操作按钮可以考虑迁移到HdsButton以获得更好的无障碍支持。第三阶段采用设计令牌将硬编码的颜色、间距、圆角替换为 HDS 设计令牌或自定义令牌// 替换前.fontColor(#1a1a1a).backgroundColor(#f5f5f5)// 替换后使用 HDS 令牌.fontColor($r(sys.color.font_primary)).backgroundColor($r(sys.color.background_secondary))或者保持自定义令牌但统一管理.fontColor($r(app.color.text_primary)).backgroundColor($r(app.color.background))第四阶段启用高级特性在基础组件已替换为标准 HDS 组件的基础上启用材质效果、自适应布局等高级特性。这是 API 26 特有的能力需要设备运行对应的系统版本。HDS 组件选择的决策树当你面对该用基础组件还是 HDS 组件的选择时可以参考以下决策树是全局导航/框架级元素吗 ├── 是 → 使用 HDS 组件HdsTabs, HdsNavigation └── 否 → 用户交互是标准化的吗对话框、菜单、表单 ├── 是 → 使用 HDS 组件HdsDialog, HdsTextField └── 否 → UI 高度定制化吗自定义布局、颜色、动画 ├── 是 → 使用 ArkUI 基础组件 └── 否 → 可以提升API兼容性吗 ├── 是 → 使用 HDS 组件 └── 否 → 使用 ArkUI 基础组件HarmonyKit 当前的状态是顶部 Tab 导航使用 HDS 组件全局框架元素所有内容/工具页面使用 ArkUI 基础组件高度定制化 UI。UIDesignKit 的未来演进基于 HarmonyOS 的发展趋势UIDesignKit 可能会在以下几个方面继续演进1. HdsNavigation 作为页面导航的默认方案目前 HarmonyKit 使用router.pushUrl()进行页面导航。HdsNavigation提供了一种声明式的、带返回栈管理的导航方案。随着 API 26 的普及预计HdsNavigation会取代router.pushUrl()成为推荐的页面导航方式。2. 更多智能组件趋势是从组件库到智能组件库——组件不仅仅是封装 UI还内置了行为智能。例如HdsList自动检测数据量并启用虚拟滚动HdsTextField自动检测输入内容类型并调整键盘HdsNavigation自动管理手势返回和动画过渡3. 跨设备形态的统一随着鸿蒙生态扩展到车机、手表、电视等设备形态HDS 组件需要在这些形态间提供统一的 API 和自适应的视觉表现。开发者用同一套 HDS API在不同设备上获得最合适的体验。结语kit.UIDesignKit不仅是鸿蒙的 UI 组件库它是鸿蒙对应用应该长什么样的设计立场。选择 HDS 组件意味着你选择了一致的视觉语言、内置的无障碍支持、自适应的布局和未来兼容性。选择 ArkUI 基础组件意味着你保留了完全的 UI 控制权。两者不是非此即彼的关系——就像 HarmonyKit 展示的导航层用 HDS内容层用基础组件是一种实用主义的混合策略。理解何时拥抱系统的设计体系、何时坚持自己的设计表达是鸿蒙 UI 开发的核心技能。项目仓库https://atomgit.com/VON-/harmony-kit
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
