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 创建卡片
实况窗是在通知的基础上附加了扩展参数,若是在支持实况窗的设备上发送,则系统会根据这些扩展参数,将通知按照实况窗的样式进行显示。
3.3.2 扩展胶囊
前文讲过胶囊态是卡片的扩展形态,在开发上,设计好胶囊的参数,然后添加至实况窗卡片的扩展参数上。
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.未来可期
目前我们整体功能以及链路流程都是已经存在的,可以支持快速接入业务完成上线。我们支持的能力包括不限于:
针对音频播放类,传输进度类等业务场景的基础类型模板:
对于打车,外卖等业务场景的进度可视化模板:
针对高铁,航班等业务场景的左右文本模板:
针对体育赛事等业务场景的赛事分数模板(尤其是支付宝接入了 NBA 赛事,这个可以有):
了解更多详情>>
关注我们,第一时间了解 HMS Core 最新技术资讯~
评论