HarmonyOS 鸿蒙Next系统当中的桌面卡片是什么？

鸿蒙的桌面卡片功能，也就是服务卡片，和Android端的小部件以及iOS端的小组件功能是一样的，只是叫法不一样，都是将应用内比较核心的功能，或者用户关注度高的功能，通过触发桌面应用进行添加到服务卡片上，进而添加到桌面上，以此达到信息展示的及时性，相关功能直达应用内的便捷效果，可以说在用户体验上，是一个质的提升。

触发方式也是十分的简单，无论你是Android、iOS还是HarmonyOS，只要已经适配了这个功能，在桌面长按应用图标，就可以进行添加小部件/小组件/卡片功能，毕竟，我们是鸿蒙相关的文章，重点就以鸿蒙系统的效果进行展示了。

如下的案例，目前已经开发了卡片功能，我们长按桌面图标之后，就会显示卡片的功能：

点击卡片之后，就会展示卡片的效果页面，这个页面中，我们可以自定义UI，支持多个卡片效果。

点击添加至桌面，就会在手机的桌面展示卡片效果，用户可以根据卡片上的逻辑，可以直观的进行查看一些重要的数据，并且可以点击后，直达某一个功能页面，可以大大提升了用户的体验。

今天，这篇文章，重点了解一下服务卡片的相关知识，下篇文章，会从0到1带着大家实现一个服务卡片。

卡片基础知识

从前言中，我们已经知道，所谓的卡片，就是把应用中重要的功能，添加至桌面或者锁屏页面，是提升用户体验的一个功能，目前，卡片功能无论是应用开发还是元服务开发均是支持的，有一点需要知道，那就是，卡片只支持桌面和锁屏添加使用。

开发模式

我们知道，目前开发鸿蒙提供了两种模型，分别是Stage和FA，卡片呢，也是支持这两种模型的，由于在API7之后的版本，FA不在主推，所以呢，在之后的开发中，还是以Stage模型做为首选。

模型选择Stage之后，关于UI开发方式，这里也简单说一下，也是提供了有两种方式，一种是基于声明式范式ArkTS语言开发的卡片，还有一种则是基于类Web范式JS语言开发的卡片，记得之前在《了解项目的工程结构》一文中，有过重点概述，作为移动端应用的开发者，考虑到性能，复杂度高，开发效率和发展趋势而言，声明式开发方式，绝对是我们的首选方式，当然了，官方也是主推这种方式，所以关于卡片的创建，我们还是以声明式范式ArkTS语言为主，两者的主要区别如下：

卡片类型

当我们去创建一个卡片时，可以发现，有两种选择，一种是Static Widget，也就是静态卡片，另一种是Dynamic Widget，也就是动态卡片，在对应的模块右键点后，找到服务卡片Seivice Widget，如下图所示：

这两种类型的卡片，在整体的运行框架和渲染流程上是一样的，主要的区别是在于静态卡片渲染服务将卡片内容渲染完毕后，卡片的使用方会使用最后一帧渲染的数据作为静态图片显示，其次卡片渲染服务中的卡片实例也会释放该卡片的所有运行资源以节省内存；这样就会导致频繁的刷新会使得静态卡片运行时资源不断的创建和销毁，增加卡片功耗。

以下是两种类型的区别：

静态卡片

关于静态卡片如何交互组件，官方提供了FormLink，可用于静态卡片内部和提供方应用间的交互，当前支持router、message和call三种类型的事件。

动态卡片

动态卡片中，官方提供了postCardAction接口用于动态卡片内部和提供方应用间的交互，和静态一致，也是仅支持router、message和call三种类型的事件，并且只能在卡片控件的点击事件中可以调用。

动态卡片事件实现原理

动态卡片中的三个事件应用场景分别是，首先是router事件，它主要用于跳转指定的UIAbility，有一点需要注意，如果是非系统应用，目前仅支持跳转到自己应用内的UIAbility；第二个是call事件，主要用于拉起指定UIAbility到后台，然后再通过UIAbility申请对应后台长时任务，如完成一个音乐播放等功能；最后一个是message事件，可以使用它拉起FormExtensionAbility，通过onFormEvent接口回调通知，以完成卡片内控件点击消息传递，从而更新卡片内容。

实现原理

具体的实现原理主要牵扯到四个，分别是卡片使用方，卡片提供方，卡片管理服务和卡片渲染服务。

卡片使用方，一般就是设备的桌面，也就是显示卡片内容的宿主应用，可以控制卡片的显示位置，用于和用于进行交互，还可以完成卡片的添加、删除、显示功能。

卡片提供方，也就是创建卡片的应用或者元服务，它是卡片功能的具体实现者，控制着卡片的UI及事件，以及数据更新。

卡片管理服务，它是作为卡片提供方和使用方的桥梁，向使用方提供卡片信息查询、添加、删除等能力，同时向提供方提供卡片被添加、被删除、刷新、点击事件等通知能力，其实说白了，就是用于管理系统中所添加卡片的常驻代理服务。

卡片渲染服务，主要用于管理卡片渲染实例，渲染实例与卡片使用方的卡片组件一一绑定。

卡片实现原理图

相关总结

在鸿蒙开发中，服务卡片虽然功能丰富，但也存在一些限制。例如，它不支持极速预览、断点调试和Hot Reload热重载等功能，同时也无法使用setTimeOut。此外，开发过程中还面临其他约束，如不支持导入动态共享包、使用native语言开发或加载native so。目前，服务卡片仅支持基于ArkUI的开发方式，且不支持跨平台开发，仅能使用声明式范式的部分组件、事件、动效、数据管理、状态管理和API能力。

HarmonyOS Next中的桌面卡片（服务卡片）是系统级原子化服务的重要载体，它并非简单等同于Android小部件或iOS小组件，而是鸿蒙“一次开发，多端部署”与“可分可合，自由流转”核心理念的关键体现。

其核心特性与优势在于：

1. 原子化服务：卡片本质上是应用的“精华”或独立功能模块，无需安装完整应用即可通过卡片获取核心服务与信息（如查看天气、控制音乐），实现了“服务找人”。
2. 统一生形框架：开发者使用一套ArkTS/JS代码，即可定义卡片的界面布局、交互与数据更新逻辑，并自动适配不同尺寸设备（手机、平板、手表等），极大提升了开发效率。
3. 动态交互与实时更新：卡片支持用户点击、按钮等交互操作，可直接完成部分功能（如打卡、播放暂停），无需打开主应用。同时，卡片数据可通过后台定时刷新或被动接收推送实时更新。
4. 自由组合与智能推荐：用户可将不同应用的卡片在桌面上自由拼接、堆叠，形成个性化场景。系统还会基于场景智能推荐可能需要的卡片（如出行时推荐行程卡片）。
5. 跨端无缝流转：结合HarmonyOS的分布式能力，部分卡片服务可在多设备间无缝接续。例如，手机上正在进行的导航卡片，可一键流转至车机继续使用。

技术实现简述： 开发者通过FormExtensionAbility生命周期来管理卡片，使用form_config.json配置卡片属性，并在ArkUI中通过@Component构建卡片界面。卡片支持静态、动态与代理刷新多种数据更新方式。

因此，HarmonyOS Next的桌面卡片是一个更强调服务直达、跨端协同与开发高效的系统级特性，是构建鸿蒙原生应用生态的重要一环。