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

HarmonyOS鸿蒙Next桌面卡片开发教程02：从底层原理开始讲透message事件的刷新机制 相关文章：

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

首先铺垫两个基础知识：

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秒时长的限制，更适合轻量化的的实现卡片内容的刷新。

接下来进入正式讲解：

本案例使用message机制，拉起FormAbility来刷新卡片内容。

使用messge机制刷新卡片的全流程主要分为3个阶段：

1. 通过卡片的postCardAction接口触发message事件
2. message事件拉起卡片对应的FormAbility，FormAbility中的onFormEvent事件获取到对应的FormID与入参，进行数据准备，准备完成后通过updateForm接口对指定卡片执行刷新事件
3. 卡片page页面接收到数据，更新卡片界面

相比于使用call机制刷新时应用主体的UIAbility不知道哪个卡片触发了事件，message机制拉起的FormAbility时会自动将卡片的FormID作为参数传递，直接在FormAbility的onFormEvent函数中获取就可以。比call机制用起来更加的简单，但受限于api9版本的系统特性，FormAbility只有5秒的存活时间，整个刷新流程都必须要这5秒内完成，导致message刷新机制无法支持复杂流程、耗时的操作，算是他的一个弱点。但据说api10开始会取消5秒的限制，到时message机制可能会成为主流的刷新机制。

postCardAction接口message事件的写法如下：

由于message机制启动的FormAbility与卡片共享内存，因此FormAbility的onFormEvent事件可以直接读取到对应的FormID，无需开发者手动保存传递。

updateForm接口的写法如下：

上案例代码：

1. 通过卡片的postCardAction接口触发message事件
2. message事件拉起卡片对应的FormAbility，FormAbility中的onFormEvent事件获取到对应的FormID与入参，进行数据准备，准备完成后通过updateForm接口对指定卡片执行刷新事件
3. 卡片page页面接收到数据，更新卡片界面

最终效果：

• 鸿蒙卡片message机制刷新演示