鸿蒙元服务开发教程03：从底层原理开始讲透桌面卡片的router事件刷新机制

相关文章：

鸿蒙元服务开发教程：从底层原理开始讲透桌面卡片的call事件刷新机制

鸿蒙元服务开发教程02：从底层原理开始讲透桌面卡片的message事件刷新机制

 

​首先铺垫两个基础知识：

1.为什么桌面卡片需要使用特殊机制来刷新？

主要有两个原因：第一是HarmonyOS Api9的桌面卡片出于降低系统能耗的目的，被限制了只有5秒的活动时间。超过5秒以后桌面卡片的相关进程会被强制销毁，变成一个静态的页面。只有通过router机制、call机制或者message机制拉起相关后台，才能再次进行卡片内容的刷新。

第二个原因是从实际的运行机制来说，桌面卡片实际上并不是应用主体的一部分，而是归属于鸿蒙系统的桌面所管理的一系列服务，桌面卡片与其对应的应用主体之间相互隔离，只能使用专门的接口来进行数据交互与页面管理。

每张卡片都有一个独立的LocalStorage可以用来存储页面级变量，但同一个LocalStorage的数据只能在UIAbility内部共享，对外隔离，UIAbility无法直接访问。

桌面卡片刷新机制的本质就是通过专门的接口，改变特定桌面卡片的LocalStorage参数。以实现桌面卡片的UI更新。

 

2.router机制、call机制与message机制有什么不同？

这三个机制都可以用来刷新桌面卡片的，三种机制的数据都以JSON的格式进行配置，并使用formBindingData.createFormBindingData()函数构建数据对象。

主要区别在于：

router机制会直接打开应用界面，效果有点像点击桌面图标。也可以带参数打开应用，直接进入应用内部的某个特定位置，或者触发某项功能。更适用于桌面卡片结构复杂或是需要用户参与自定义卡片内容的场景。

call机制是不打开应用界面，仅在后台拉起应用主体的UIAbility，来执行UIAbility内部的相关代码。call机制不受5秒时长的限制，可以先实现复杂且费时的数据加载，再提供给桌面卡片进行刷新。

message机制则不涉及到应用的UIAbility，只是拉起桌面卡片自己的FormAbility，也可以刷新卡片，但仍然受5秒时长的限制，更适合轻量化的的实现卡片内容的刷新。

---

 

接下来进入正式讲解：（本案例使用router机制&#x