HarmonyOS 4.0 实况窗上线！支付宝实现医疗场景智能提醒

本文转载自支付宝体验科技，作者是蚂蚁集团客户端工程师博欢，介绍了支付宝如何基于 HarmonyOS 4.0 实况窗实现医疗场景履约智能提醒。

1.话题背景

8 月 4 日，华为在 HDC（华为 2023 开发者大会）上推出了新版本操作系统HarmonyOS 4.0，主打个性化与多元化的的口号。在功能介绍环节，支付宝依托HarmonyOS 4.0 能力提供的一项新功能出现在了大会的介绍PPT上。

这个功能乍一看就像一个系统的通知，实际上也确实是一个通知，只不过与通知有很大的区别。在华为的官方文档里，这个被称之为实时活动或者是实况通知。实时活动是最开始的名称，现在官方文档称之为实况窗。

为什么说它是国产灵动岛呢？因为这个实况窗具备多种形态，其中的胶囊态与iOS的灵动岛在UI展示上几乎就是"如出一辙"。除此之外，实况窗具有更加丰富的展示位置，从熄屏，锁屏，到桌面，通知栏，通知中心，都有其身影。我们首先来看一下官方的效果展示：

依次分别是通知栏卡片，桌面胶囊态，桌面胶囊态展开形态，锁屏卡片，胶囊态。

在上方官方的UI展示效果图上，胶囊态不光展示在桌面上，支持点击扩展为通知卡进行操作，同时出现在熄屏界面。熄屏页面的胶囊态文案不支持点击扩展为实时卡片。点击熄屏胶囊态，会进入锁屏卡片页面查看详情。

实况窗本质上是履约类消息的推送展示。华为的官方定义为：帮助用户聚焦任务，进行快速查看和及时处理的通知形体。实况窗具有实效性，阶段性和变化性的特点。实效性是指，整个通知服务会持续一段时间，在用户不主动关闭的前提下，具备自动展示和结束的能力。实效性是指，通知的消息在一段时间内有效。通知具有变化性，它是支持内容动态刷新。

2.成果展示

在了解了华为实况窗的背景和能力之后，我们回到发布会上所展示的支付宝实时活动通知。目前支付宝在最新10.5.10版本已经具备了华为实况窗能力，目前主要接入应用场景在医疗方面，后续会开放更多的应用场景。那我们先来欣赏一下支付宝上的"国产灵动岛"的真实上机形态。

通知栏状态：

左侧展示正常创建实时活动卡片；

右侧展示支持用户对卡片进行更多操作，包括设置和删除卡片。

桌面胶囊态：

左侧展示手机桌面左上角的胶囊文案；

中间侧展示点击胶囊态可展开通知卡片；

右侧展示在胶囊态展开卡片后支持用户更多操作，包括设置和删除卡片。

锁屏状态：

展示用户按下电源键进入锁屏页面展通知卡片（手机拍摄）；

熄屏胶囊态：

手机界面进入息屏界面展示胶囊文案（手机拍摄）；

上述所展示的仅为强调文案类模板在支付宝医疗场景下的UI效果，除了强调文案类模板外，华为还提供了多种展示模板应用于不同的场景，比如说针对打车或者外卖场景下的进度可视化类模板，针对体育赛事的赛事比分模板。

实况窗可以作为一个强提醒通知渠道，对于重要信息可以多方位展示。如果考虑到对于部分用户出现过度打扰，实时活动同样支持减少胶囊态文案透出，只出现通知栏中。

3.实现细节

展示了这么多状态的实况窗UI，大家会比较好奇怎么实现这样一套实况窗通知呢？

刚才在开头已经介绍了实况窗其实是一个通知，本质上是Android通知功能的扩展。HarmonyOS通过解析通知的扩展参数，创建对应的模板并填充数据。对于接入功能的第三方应用而言，不需要绘制UI，只需要定制接口协议与模版参数，即可实现通知活动卡片的创建与展示。另外我们所看到的胶囊态其实不是一种独立的形态，它是卡片形态的扩展形式，依附于具体的卡片模板，这就是为什么在桌面通过点击胶囊态可以展开卡片。

以支付宝接入医疗场景的实况窗为例，简单介绍一下实现细节。

3.1处理链路

在支付宝端内，实现一个实况窗通知，涉及到三个业务团队的合作，包括客户端团队，消息平台服务端团队以及消息Push团队，这三个团队的分工如下：

客户端团队：接收消息平台下发的sync消息(服务端与客户端之间的双向可靠数据同步服务，包括sync上行和下行)，创建实况通知，也就是通知“上岛”，并将卡片信息与token信息发送至消息平台团队和Push团队；

消息平台服务端团队：查询用户在服务场景下创建的履约订单，按照通信协议通过sync下行通知到客户端，接收客户端sync上行的卡片信息；

Push团队：接收客户端Rpc上报的token信息，并且作为下游，接收上游消息平台传递来的卡片通知更新信息。将更新参数发送至厂商云端，由厂商完成通知卡片的更新以及删除操作；

详细的流程通过甬道图表示：

对于三方应用而言，不需要关心UI绘制。对于客户端团队而言，完成通知卡片的创建之后，无感后续的更新操作。由三方应用云端直接对接厂商云端，厂商平台接收更新数据后直接下发到对应的通知卡片，完成状态与数据更新。下图展示的是通知卡片更新状态下的数据流转：

3.2通信协议

实况窗的通信协议主要包括两方面：

三方应用内的通信协议：数据由消息平台下行到客户端，并在客户端创建通知卡片后，将更新消息发送下游Push平台。

三方应用外与厂商平台的通信协议：Push平台接收上游消息平台的更新消息后，将数据流转对接到厂商平台完成更新；

这两个通信协议其实也是通知卡片生命周期流程。三方应用内的通信协议应用于实况窗通知卡片的创建，三方应用与厂商平台的通信协议是应用于实况窗通知卡片的更新。

3.2.1 应用内通信协议

应用内的通信协议并不是独立的，而是继承自iOS灵动岛在支付宝端内的通信协议。为什么说是继承？为什么说是非独立？

继承是因为华为实况窗的协议是iOS灵动岛在支付宝端内通信协议的扩展版本，及在原有的协议基础上，扩展创建华为实时活动卡片的必须字段。整个协议的创建原则是：最大包容原则，即能复用现有字段则复用现有字段，缺少则通过团队协商后进行扩展。

非独立是指，整个通信协议的确定必须具有前瞻性，包括能满足未来支持华为更多种类模板的实时活动，也能满足后续其他国内厂商跟进同类“灵动岛”功能的需求。

这一套协议目前已经支持iOS灵动岛以及华为实况窗，由客户端团队维护.

3.2.2 应用外通信协议

应用外的通信协议主要是用于Push团队对接厂商进行通知卡片更新操作。这个的复杂在于，需要翻译应用内的通信协议。将翻译后的应用内的通信协议字段请求厂商接口，完成实况窗通知卡片的更新。

如何翻译应用内的协议，主要是将消息平台，客户端，Push三个团队的对接字段关联起来，做成一个三元组参数。

应用外的通信协议目前依然由客户端团队维护。

3.3代码接入

代码接入主要是以客户端的角度来描述。

3.3.1 创建卡片

实况窗是在通知的基础上附加了扩展参数，若是在支持实况窗的设备上发送，则系统会根据这些扩展参数，将通知按照实况窗的样式进行显示。

// 创建 bundle 保存通知信息，设置 type 为 4，表示强调文本模板类型
Bundle liveNotificationData = new Bundle();
liveNotificationData.putInt("XXXX", 0);
liveNotificationData.putString("XXXX, "Other");
liveNotificationData.putInt("XXXX", 4);
// 创建 bundle 保存强调文本模板类型的通知所需的扩展参数
Bundle feature = new Bundle();
feature.putString("XXXX", "取餐码");
feature.putString("XXXX", "750");
// 将 feature 的 bundle 设置到通知参数 liveNotificationData 中
liveNotificationData.putBundle("XXXX", feature);
// 创建通知，调用 addExtras 添加通知信息
Notification notification = new Notification.Builder(context, channelId)

3.3.2 扩展胶囊

前文讲过胶囊态是卡片的扩展形态，在开发上，设计好胶囊的参数，然后添加至实况窗卡片的扩展参数上。

// 创建 bundle 保存胶囊所需的参数
Bundle capsule = new Bundle();
capsule.putInt("XXXX", 1);
capsule.putInt("XXXX", 1);
capsule.putParcelable("XXXX", Icon.createWithResource(context, R.drawa
ble.xxx));
capsule.putInt("XXXX", Color.parseColor("# FFFF0000"));
capsule.putString("XXXX", "胶囊标题");
capsule.putString("XXXX", "胶囊扩展内容");
// 将胶囊参数设置到通知参数中
liveNotificationData.putBundle("XXXX, capsule);

4.持续优化

目前而言，华为实况窗功能在支付宝端内的的实现方案并非绝对完美，出现的问题主要是包含两个方面：

厂商推送更新能力并非百分之百：目前有数据表明华为在接收三方应用的Push更新的过程中，达到率是92%，也就是说会有8%的数据会丢失在厂商更新用户设备链路的通道上；

用户设备信息存在多业务团队的同时获取：华为实况窗卡片的更新依赖用户设备的PushToken信息，在支付宝端内目前至少存在两个团队需要获取PushToken。但是华为对PushToken的获取频次有限制，有概率会造成某个业务Token信息的获取失败；

4.1 端侧更新

对于第一个问题，厂商推送更新能力存在缺陷时，更新机制需要具有兜底措施，目前在支付宝内部保留了端内更新的能力，该能力与厂商更新有所区别，体现在更新时机以及更新字段协议。

厂商的更新时机主要是在接收到三方应用发起更新接口请求时，端内的的更新时机则是在指定时机内主动请求消息平台数据，对于更新数据采用覆盖更新，即将获取到字段按照协议更新到对应模板参数中。

4.2 PushToken复用

对于第二个问题，是支付宝端内复杂的业务场景导致，毕竟一个团队在需要PushToken时，没办法知晓哪些团队同样需要PushToken，在多个业务同时请求设备PushToken信息时，会存在失败的可能。由于时间节奏比较紧，目前的方案由Push团队收拢，在实时活动未上报PushToken的情况下，获取其他业务上传的PushToken。（在这里需要说明，华为的PushToken信息基本不变，所以区别于iOS灵动岛的Token信息上报）。

在后期的解决方案中，团队打算采用缓存方案，缓存PushToken，做到端内的业务推广，维护一套数据。