写点什么

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

作者:HMS Core
  • 2023-09-25
    广东
  • 本文字数:4182 字

    阅读完需:约 14 分钟

本文转载自支付宝体验科技,作者是蚂蚁集团客户端工程师博欢,介绍了支付宝如何基于 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.drawable.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,做到端内的业务推广,维护一套数据。

5.场景覆盖

整个实况窗的功能已经上线,只不过受限于华为鸿蒙 4.0 版本正式版本节奏,无法放开线上体验。目前也只接入了医疗场景。我们的业务后续会接入更多的场景。目前医疗场景覆盖的内容包括以下:



通知卡片可以透出:预约医院,预约时间,当前进度等内容。

6.未来可期

目前我们整体功能以及链路流程都是已经存在的,可以支持快速接入业务完成上线。我们支持的能力包括不限于:


  1. 针对音频播放类,传输进度类等业务场景的基础类型模板:



  1. 对于打车,外卖等业务场景的进度可视化模板:



  1. 针对高铁,航班等业务场景的左右文本模板:



  1. 针对体育赛事等业务场景的赛事分数模板(尤其是支付宝接入了 NBA 赛事,这个可以有):



了解更多详情>>


访问华为推送服务联盟官网


获取华为推送服务开发指导文档


访问HMS Core 联盟官网


获取HMS Core 开发指导文档


关注我们,第一时间了解 HMS Core 最新技术资讯~

用户头像

HMS Core

关注

HMS Core技术团队。 2022-06-16 加入

分享最新的技术干货,带来最全的能力应用场景,更新热门开发者圈子活动。与开发者一起,同成长,共精彩。

评论

发布
暂无评论
HarmonyOS 4.0 实况窗上线!支付宝实现医疗场景智能提醒_huawei_HMS Core_InfoQ写作社区