20秒瞭解小程式卡片

案例1：幸福大巴一鍵搶座

“幸福大巴”是阿里員工在域內使用的城際客運功能，但因為需要來回跳轉VPN工具和H5頁面，在使用者體驗上帶來了一定的障礙

搶座流程對比：

與以前相比，一鍵預訂一鍵查詢一鍵取消，班次座位資訊實時透出，為每位坐大巴的同學節省兩分鐘。

如何做到？

幸福大巴原本是企業智慧在釘釘上開發的一個H5應用，此次基於小程式卡片能力，快速地將前端使用者介面改造為卡片形態，而後端服務依舊複用原來系統。

我們可以這麼理解：

以前的大巴系統 = 後端服務 + 前端頁面（跳轉到新的全屏頁面 ）

現在的大巴系統 = 後端服務 + 前端卡片（內外小蜜會話中）

而這個前端的卡片，開發方式就與開發一個小程式元件一樣簡單，只要會開發小程式，就會開發卡片。

一段卡片應用程式碼示例如下：

案例2：ICBU客戶邀約卡片

ICBU基於小程式卡片能力，將原本的客戶邀約系統改造為卡片應用。

系統會通過機器人自動傳送客戶邀約，銷售人員直接在卡片上操作，選擇拜訪日期，填寫拜訪計劃表單，提交後邀約狀態的表單也會直接展示在卡片內容上。

通過卡片應用，減少了使用者在溝通與業務系統直接的來回跳轉。

從小紅點說起

看到這裡，你可能已經對小程式卡片技術有一些應用層面上的瞭解，但迴歸這項技術本身，咱們可能還需要從小紅點說起......

小紅點（Badge），起於黑莓，被 Apple 發揚光大（專利屬於蘋果），直到現在已然成為 iOS、Android 等各大系統 App 推送提醒 UI 規範。

小紅點的設計是如此成功，拋開 UI 不做討論，個人認為其對於使用者的最大意義在於它將原本需要使用者進入 APP 才能看到的資訊直接在其上層載體（比如 App Icon）中進行了標準化透出 ，大大 縮短了資訊獲取路徑。

現代作業系統中不乏類似設計，並且更進一步支援了使用者互動。比如 iOS、Android等系統小部件、通知中心、控制中心等。

在雲釘一體的戰略背景下，釘釘將越發成為企業數字化平臺的作業系統。為了縮短使用者資訊獲取路徑，我們需要一套擁有沉浸式體驗、對開發者友好的，並最終可以 Anywhere執行 的區塊級應用解決方案。

小程式卡片方案 可以很好的滿足以上訴求。

沉浸式體驗

小程式卡片相比於傳統小程式, 其最大優勢是能夠帶來沉浸式的體驗。

傳統小程式是躲在一個圖示（或者分享連結）後的應用，使用者想要基於小程式獲取或創造有效資訊需要從當前上下文中跳出。這種相對割裂的互動方式某些場景下會對使用者造成較大的困擾，比如 IM ，而釘釘的 IM 作為釘釘的核心能力，承載了大部分與工作相關的溝通訊息。

想象一下，銷售小王同學每天早上需要與群內同事同步昨天的工作進度和當天工作安排，並協同其他同事共同完成業務跟進。小王在關注其他同時聊天資訊的同時，需要在工作臺其他應用中進行客戶資訊查詢與修改，這種在聊天窗和其他應用間不斷來回切換，讓小王的工作效率非常低，甚至可能錯過重要資訊。

沉浸式互動

為了讓使用者可以直接在 IM 中操作小程式卡片，我們和釘釘 IM 團隊進行了深度合作，在渲染流程、資料鏈路上與 IM 模組深度整合，將小程式卡片變成一種特殊的訊息型別，能夠直接傳送到訊息列表中。

下圖所示為釘釘文件卡片許可權修改流程，使用者可直接在卡片上修改對應文件許可權：

並且，結合 IM 本身的特點，在 IM 的中小程式卡片還可支援置頂操作。置頂操作對於那些需要長時間互動的小程式卡片來說非常有意義，比如位置共享、資料大盤等。

實時資料同步

Functional UI 告訴我們 UI = F(data) ，可見資料對於 UI 所起到的決定性重要性。舉個例子：

釘釘的群投票卡片允許我們直接在 IM 中進行投票操作。相對於從 IM 中跳轉一個獨立的 "投票" 應用再進行投票的互動體驗，無疑往前邁了一大步。

但如果我們想實時跟蹤投票進度，獲取最終投票結果呢？比如下方所示的能力：

想要實現這種能力，常規做法是業務方自己在其業務邏輯中加入資料同步機制，重新整理資料進而更新檢視。但這種資料同步方式其實非常低效，作為 client 端，為了保證資料的時效性很多時候只能通過定時器做定時重新整理（長連線同樣存在其他問題）。試想下，在一個 100 人的群裡，有一張卡片需要進行資料同步，意味著同時會有 100 個請求打到伺服器。如果在 n 個群同時存在 m 張卡片呢？

小程式卡片內建了一套高效的資料同步機制，開發者只需將最新卡片資料同步到小程式卡片框架，即可快速將所有同 ID 卡片更新。

與小程式融合

小程式卡片作為一個獨立應用執行時，由於其區塊級應用定位，無法承載過於複雜的使用者互動和業務流程。此時，小程式卡片可以與小程式能力進行整合，點選小程式卡片的某個 action 區域，支援半屏喚起一個擁有完整能力的小程式，在保持沉浸式體驗的同時給開發者足夠的能力支撐其業務。

同時，在該小程式內支援訪問小程式卡片的資料並對其進行更改，同樣的，這些資料變更將同步到所有同 ID 的卡片上。

此時小程式卡片可以做為主體小程式核心資訊和操作的載體，用以快速觸達使用者，完成核心業務流程。

“傳統”應用 vs. 卡片應用

Anywhere 執行

我們希望當開發者完成小程式卡片開發後，可以將其執行在：

多端：iOS、Android、Windows、Mac 端；

多執行時：native（IM列表、搜尋結果頁）、小程式、H5，甚至 iOS widget 內。

傳統小程式使用 webview 作為渲染容器，但如果直接在 IM 中為每張卡片嵌入一個 webview 就顯得過於重了，且多卡片共存情況下記憶體佔用過大的問題也難以解決。

所以，基於同一套 DSL ，我們會通過不同的 compiler 將其打包成不同產物以適應不同的宿主環境，並通過 DSL 的強約束性保證多端渲染一致性。

依託於當前小程式離線包機制，我們將多種產物（未來可配置）統一打包到小程式離線包內實現資源離線化。

在卡片被渲染前，卡片框架會先判斷當前所處的環境，並根據不同環境選擇不同打包產物進行卡片渲染。

使用卡片統一 DSL 可以將業務程式碼與"卡片底層引擎實現"解耦，未來加入更多渲染引擎支援時業務可以無痛升級。

基於這套方案，釘釘小程式卡片已支援 Webview、Native、小程式 三種容器。

卡片容器的全行業耕耘

卡片技術作為一個全新的應用形態和技術方案，仍有諸多不完善之處，需要持續迭代與優化，提高卡片效能和產品化能力。

但不可否認的是，從 icon 到 card，無疑是當前移動開發領域，在後續發展程序上的一個重要方向。

除了釘釘小程式卡片外，「支付寶」自研的魔方卡片（Cube）也在通過 mPaaS 正式開放對外輸出，每一個魔方卡片（Cube）都可以獨立嵌在原生頁面內的一個區域，將區域內容通過卡片模版進行展示。

提供動態內容展示

魔方卡片（Cube)通過卡片的形式嵌入到原生 Native 頁面中，Android/iOS 雙端的高度一致性可以大大提升開發效率，而僅 5.5mb 的包體積和 32mb 的記憶體消耗，讓動態化開發更輕量化。

為開發者的“私人定製”

客戶端 SDK 結合服務端卡片管理系統，開發者讓開發者的接入和使用過程更輕巧簡易；多種前端開發語言和完備的除錯工具，讓“編譯-預覽-除錯-釋出”的開發流程更普惠，不用語法的開發者都能獲得最前沿的技術工具。

本文轉自公眾號【阿里巴巴移動技術】