背景

落地场景

盒马App版本5.73.0刚上线一周，订单配送和门店取餐实况通知数据表现非常亮眼，通知点击率相比普通push消息高达数十倍，随着App版本升级和鸿蒙4.0系统用户覆盖率上升，实况通知业务数据应该还会有很大增长空间。也欢迎各位技术发烧友们，下载更新盒马App至5.73.0及以上版本，抢先体验华为实况窗功能。

订单配送

用户在盒马App购买即时配送商品，想知道订单配送状态，之前需要频繁打开盒马App进入订单详情查看；通过配送服务接入实况通知，桌面锁屏和胶囊屏订单状态实时感知更便捷。

实况胶囊效果

门店取餐

盒马鲜生门店海鲜岛堂食点餐时，用户付款取号后，之前经常要去服务台问餐品进度，取餐时要给顾客发短信或者打电话，遇到人多或者顾客过号经常会有客诉。通过餐饮服务接入实况通知，锁屏桌面出餐状态更新，菜品制作进度尽在掌握。

技术方案

技术流程

实况通知通用流程

核心流程大致以下三步：

1. 要先集成Push Android SDK，获取推送服务PushToken。

2. 构建本地实况通知，并将本地实况通知的需要刷新的数据信息和Token上报到应用服务端。

3. 应用服务端向Push服务端发送实况通知刷新请求，更新实况通知内容。

盒马业务流程

盒马的业务特点是线下门店+线上App融合的新零售创新业态，在盒马App里面要实现一个实况通知推送，涉及到很多跨团队合作。详细业务流程如上图所示，以生鲜配送为例，各角色核心职责为：

1. H5前端：判断手机系统是否支持实况，并查询订单信息，与Native端通信创建实况通知卡片。

2. Native端：集成华为PushSDK，封装实况通知创建、更新、关闭功能。并将订单ID，手机设备PushToken 和通知ID上报至消息服务端。

3. 消息服务端：作为基础消息中间层，一方面与Native交互，记录订单实况卡片映射关系；一方面与业务服务端交互，接收订单和履约状态的变化，并按照华为消息云端协议封装数据，控制实况卡片更新和关闭。

4. 交易服务端：下单时创建订单并返回订单信息，通知创建实况通知卡片【已付款】；配送完成后通知到消息服务端，更新实况通知卡片【交易完成】。

5. 履约服务端：订单下发到仓库后，整个商品的作业状态和配送状态的变化，通知到消息服务端，更新实况通知卡片【商品打包中】【配送中】

技术要点

PushToken获取与更新

盒马App跟集团淘系其他App一样，消息服务接入集团统一Agoo推送平台。端侧AccsSDK封装了华为Push SDK的初始化和服务注册能力，对外并不暴露获取华为PushToken的接口。我们采取了一些hack办法复写AccsSDK部分代码逻辑，在初始化时 调用getToken方法获取PushToken；在消息接收服务中调用onNewToken方法刷新PushToken。并且把它做成全局通用方法，避免不同场景对PushToken过度获取与更新，导致华为推送服务的不稳定。

实况通知创建时机

为了用户体验，实况通知的创建时机选择很重要，对于即时配送订单，最佳时机是下单支付；对于门店海鲜区点餐，最佳时机是门店扫码付款。两者最终路径都是支付成功页，但是盒马支付成功页是前端H5页面，因此需要Native提供JSBridge到H5，判断当前手机系统是否支持创建鸿蒙实况通知，以及真正的创建实况通知。

支付成功接口返回实况通知数据示例：

"liveActivityDTOs": [      {        "content": {          "itemPic": "//img.alicdn.com/bao/uploaded/i3/3991285532/O1CN011qjhdMs6GYWlIaI_!!3991285532.gif",          "title": "支付成功",          "content": "订单将于指定时间内配送"        },        "id": "3447600912033344233",        "scenario": "fulfill_delivery_track"      }    ]

实况通知ID生成逻辑

Android 应用可以调用 NotificationManager notify 接口创建实况通知，开发者可以指定id和Notification对象。Id即为实况通知activityId，由开发者生成，在设备内要保持唯一，以免影响到实况通知的正确更新。

在盒马实际场景，我们可以使用订单号来创建activityId，实际情况下配送订单和点餐订单两种场景生成activityId的逻辑是不一样的。具体为：

1. 配送订单通常是只生成一个主单，当然对于不同业态合并下单场景会拆分多个主单，我们从中过滤出生鲜即时配送订单，只针对此类型订单创建实况通知，activityId采用主单号生成。

2. 餐饮订单通常是生成一个主单多个子单，因为顾客会点多个菜品，它们的处理加工烹饪方式不一样，餐饮订单创建实况通知，activityId采用每道菜的子单号生成更为合理。

辅助区内容更新

盒马不同用户购买的商品往往不一样，辅助区的商品图片需要根据用户订单商品个性化展示。但是华为官方技术和设计文档对辅助区做了限制：“44*44vp，支持展示：图片、胶囊带文字、icon & logo、纯文本”。这意味着不支持网络图片的渲染，我们采取做法是 对服务端返回的商品图片链接进行处理，其中对于普通商品图，通过Phenix图片库直接下载到本地，转成Bitmap；对于Gif动图，通过网络库下载获取Gif图片第一帧，再转成Bitmap；最后调用华为原生API更新到辅助区。

体验细节优化

配送订单限制

1. 触发对象，必须满足下述所有条件的订单：

• O2O-鲜生业态订单（不包含云超、会员店、NB）

• 订单类型为普通订单（不包含预售、团餐订单）

• 含配送信息，且履约结束时间-支付时间≤8h

2. 异常CASE

• 若订单的实际履约时间超过2h，或触发逆向流程导致交易/履约单中断，需要关闭提醒。

• 手机内存不足时，支付成功页回收后自动恢复，或导致同一笔订单创建2个实况通知，需要过滤掉。

• 深圳政府限塑令，要求生鲜订单收取0.01元包装费，下单后会自动拆成两单。交易返回数据时过滤掉此类型订单，避免创建无效通知。

胶囊形态适配

• 配置文案支持滚动

• 底色采用盒马蓝

• 字数限制，以3个字符最佳

小折叠屏手机外屏适配

未来展望

进一步到体验细节

• 在实际配送场景，因为天气变化等不可抗因素，配送经常延迟。如果在通知上表达天气，可以更好体现盒马的服务温度，降低用户负面情绪。实况通知当前并不支持背景设置和个性化，与华为沟通后待支持。

• 在实际配送场景，盒马有一定比例用户选择预约配送，目前华为侧不支持预约场景（非即时发生的持续性服务，如未来的航班、未来的配送等）指定时间创建实况通知。与华为沟通后待支持。

• 在实际餐饮场景，有顾客反馈取餐码更新不及时，取餐服务刷新机制优化；取餐提醒通知不一致，按照实时消息＞PUSH＞短信＞外呼（仅判定存在项）的顺序，进行优先级触发。

更多场景拓展

• 后续会基于盒马“多业态、平台化、商业化”的大方向，做更多的尝试；包含不限于：茅台抢购、尝新试吃开奖、菜谱跟做提醒、平台商家OMS系统接入、生活服务场景探索、用户生命周期＆高潜会员的重要触达手段。

• 更多终端设备的联动，比如将盒马App配送实况通知流转到华为手表、汽车显示屏，让服务触点更加多元化。