目录

ArkTS卡片概述

以下内容介绍基于ArkTS声明式开发范式语言开发卡片。

亮点/特征

  1. 统一开发范式

    • ArkTS卡片统一了卡片和应用页面的开发范式，应用页面的布局可以直接复用到卡片布局中，提升开发体验和开发效率。具体请参考图1 卡片工程结构对比。

    图1 卡片工程结构对比

  2. 卡片能力增强

    • 新增了动效的能力：ArkTS卡片开放了属性动画和显式动画的能力，使卡片的交互更加友好。
    • 新增了自定义绘制的能力：ArkTS卡片开放了Canvas画布组件的能力，卡片可以使用自定义绘制的能力构建更多样的显示和交互效果。
    • 允许卡片中运行逻辑代码：开放逻辑代码运行能力后，部分业务逻辑可以在卡片内部实现，拓宽了业务适用场景。

实现原理

图2 ArkTS卡片实现原理

图3 ArkTS卡片渲染服务运行原理

与JS卡片相比，ArkTS卡片支持在卡片中运行逻辑代码，为确保ArkTS卡片发生问题后不影响卡片使用方应用的使用，ArkTS卡片新增了卡片渲染服务用于运行卡片页面代码widget.abc，卡片渲染服务由卡片管理服务管理。卡片使用方的每个卡片组件都对应了卡片渲染服务里的一个渲染实例，同一卡片提供方的渲染实例运行在同一个ArkTS虚拟机运行环境中，不同卡片提供方的渲染实例运行在不同的ArkTS虚拟机运行环境中，通过ArkTS虚拟机运行环境隔离不同卡片提供方卡片之间的资源与状态。开发过程中需要注意的是globalThis对象的使用，相同卡片提供方的卡片globalThis对象是同一个，不同卡片提供方的卡片globalThis对象是不同的。

ArkTS卡片类型

ArkTS卡片分为动态卡片、静态卡片和互动卡片三种类型。

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

卡片类型 支持的能力 适用场景 优缺点
静态卡片 仅支持UI组件和布局能力。 主要用于展示静态信息（UI相对固定），仅可以通过FormLink组件跳转到指定的UIAbility。 功能简单但可以有效控制内存开销。
动态卡片 除了支持UI组件和布局能力，还支持通用事件能力和自定义动效能力。 用于有复杂业务逻辑和交互的场景。例如：卡片页面图片的刷新、卡片内容的刷新等。 功能丰富但内存开销较大。
互动卡片 在动态卡片基础上，额外支持破框动效能力。 用于有复杂业务逻辑和交互，需要执行破框动效呈现更好视觉体验的场景。例如：桌面卡片游戏等。 功能丰富但内存开销较大。

[h2]动态卡片

ArkTS卡片中提供了postCardAction接口用于卡片Card.ets和FormExtensionAbility之间的交互，当前支持router、message和call三种类型的事件，仅在卡片控件的点击事件中可以调用。

图4 ArkTS事件交互实现原理

动态卡片事件的主要使用场景如下：

[h2]静态卡片

ArkTS卡片提供FormLink静态卡片交互组件，用于静态卡片内部和提供方应用间的交互，当前支持router、message和call三种类型的事件。请参见FormLink。

[h2]互动卡片

从API version 20开始支持互动卡片，互动卡片提供破框动效能力，并实现人机交互，提升信息提醒、浅层交互和可玩性。具体请参考互动卡片概述。

约束与限制

ArkTS卡片支持在UI内运行逻辑代码，相较于JS卡片具备了更加丰富的能力，但也增加了使用卡片进行恶意行为的风险。因为承载ArkTS卡片UI部分的widget.abc代码运行在系统公共的FRS进程内，并最终显示在卡片使用方应用中（一般为桌面应用），为确保系统渲染进程的稳定性、各卡片之间的隔离安全性，以及内存功耗等资源考虑，对ArkTS卡片UI可使用的能力做了以下约束：

除此之外，当前ArkTS卡片还存在如下约束：