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，做到端內的業務推廣，維護一套資料。