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

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

搶座流程對比：

以前H5頁面的搶座流程	現(xiàn)在卡片應(yīng)用的搶座流程
1.小蜜搜索“幸福大巴”	1.小蜜搜索“幸福大巴搶座”
2.點擊跳轉(zhuǎn)鏈接	2. 一鍵搶座，完事兒
3.連接VPN
4.打開預(yù)訂H5頁面進行搶座

與以前相比，一鍵預(yù)訂一鍵查詢一鍵取消，班次座位信息實時透出，為每位坐大巴的同學(xué)節(jié)省兩分鐘。

如何做到？

幸福大巴原本是企業(yè)智能在釘釘上開發(fā)的一個H5應(yīng)用，此次基于小程序卡片能力，快速地將前端用戶界面改造為卡片形態(tài)，而后端服務(wù)依舊復(fù)用原來系統(tǒng)。

我們可以這么理解：

• 以前的大巴系統(tǒng) = 后端服務(wù) + 前端頁面（跳轉(zhuǎn)到新的全屏頁面 ）

• 現(xiàn)在的大巴系統(tǒng) = 后端服務(wù) + 前端卡片（內(nèi)外小蜜會話中）

而這個前端的卡片，開發(fā)方式就與開發(fā)一個小程序組件一樣簡單，只要會開發(fā)小程序，就會開發(fā)卡片。

一段卡片應(yīng)用代碼示例如下：

2案例：ICBU客戶邀約卡片

ICBU基于小程序卡片能力，將原本的客戶邀約系統(tǒng)改造為卡片應(yīng)用。

系統(tǒng)會通過機器人自動發(fā)送客戶邀約，銷售人員直接在卡片上操作，選擇拜訪日期，填寫拜訪計劃表單，提交后邀約狀態(tài)的表單也會直接展示在卡片內(nèi)容上。

通過卡片應(yīng)用，減少了用戶在溝通與業(yè)務(wù)系統(tǒng)直接的來回跳轉(zhuǎn)。

從小紅點說起

看到這里，你可能已經(jīng)對小程序卡片技術(shù)有一些應(yīng)用層面上的了解，但回歸這項技術(shù)本身，咱們可能還需要從小紅點說起......

小紅點（Badge），起于黑莓，被 Apple 發(fā)揚光大（專利屬于蘋果），直到現(xiàn)在已然成為 iOS、Android 等各大系統(tǒng) App 推送提醒 UI 規(guī)范。

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

現(xiàn)代操作系統(tǒng)中不乏類似設(shè)計，并且更進一步支持了用戶交互。比如 iOS、Android等系統(tǒng)小部件、通知中心、控制中心等。

在 云釘一體 的戰(zhàn)略背景下，釘釘將越發(fā)成為企業(yè)數(shù)字化平臺的操作系統(tǒng)。為了縮短用戶信息獲取路徑，我們需要一套擁有沉浸式體驗、對開發(fā)者友好的，并最終可以 Anywhere運行 的區(qū)塊級應(yīng)用解決方案。

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

沉浸式體驗

小程序卡片相比于傳統(tǒng)小程序, 其最大優(yōu)勢是能夠帶來沉浸式的體驗。

傳統(tǒng)小程序是躲在一個圖標（或者分享鏈接）后的應(yīng)用，用戶想要基于小程序獲取或創(chuàng)造有效信息需要從當前上下文中跳出。這種相對割裂的交互方式某些場景下會對用戶造成較大的困擾，比如 IM ，而釘釘?shù)?IM 作為釘釘?shù)暮诵哪芰?，承載了大部分與工作相關(guān)的溝通信息。

想象一下，銷售小王同學(xué)每天早上需要與群內(nèi)同事同步昨天的工作進度和當天工作安排，并協(xié)同其他同事共同完成業(yè)務(wù)跟進。小王在關(guān)注其他同時聊天信息的同時，需要在工作臺其他應(yīng)用中進行客戶信息查詢與修改，這種在聊天窗和其他應(yīng)用間不斷來回切換，讓小王的工作效率非常低，甚至可能錯過重要信息。

沉浸式交互

為了讓用戶可以直接在 IM 中操作小程序卡片，我們和釘釘 IM 團隊進行了深度合作，在渲染流程、數(shù)據(jù)鏈路上與 IM 模塊深度整合，將小程序卡片變成一種特殊的消息類型，能夠直接發(fā)送到消息列表中。

下圖所示為釘釘文檔卡片權(quán)限修改流程，用戶可直接在卡片上修改對應(yīng)文檔權(quán)限：

并且，結(jié)合 IM 本身的特點，在 IM 的中小程序卡片還可支持置頂操作。置頂操作對于那些需要長時間交互的小程序卡片來說非常有意義，比如位置共享、數(shù)據(jù)大盤等。

實時數(shù)據(jù)同步

Functional UI 告訴我們 UI = F(data) ，可見數(shù)據(jù)對于 UI 所起到的決定性重要性。

釘釘?shù)娜和镀笨ㄆ试S我們直接在 IM 中進行投票操作。相對于從 IM 中跳轉(zhuǎn)一個獨立的 "投票" 應(yīng)用再進行投票的交互體驗，無疑往前邁了一大步。

但如果我們想實時跟蹤投票進度，獲取最終投票結(jié)果呢？

想要實現(xiàn)這種能力，常規(guī)做法是業(yè)務(wù)方自己在其業(yè)務(wù)邏輯中加入數(shù)據(jù)同步機制，刷新數(shù)據(jù)進而更新視圖。但這種數(shù)據(jù)同步方式其實非常低效，作為 client 端，為了保證數(shù)據(jù)的時效性很多時候只能通過定時器做定時刷新（長連接同樣存在其他問題）。試想下，在一個 100 人的群里，有一張卡片需要進行數(shù)據(jù)同步，意味著同時會有 100 個請求打到服務(wù)器。如果在 n 個群同時存在 m 張卡片呢？

小程序卡片內(nèi)置了一套高效的數(shù)據(jù)同步機制，開發(fā)者只需將最新卡片數(shù)據(jù)同步到小程序卡片框架，即可快速將所有同 ID 卡片更新。

與小程序融合

小程序卡片作為一個獨立應(yīng)用運行時，由于其區(qū)塊級應(yīng)用定位，無法承載過于復(fù)雜的用戶交互和業(yè)務(wù)流程。此時，小程序卡片可以與小程序能力進行整合，點擊小程序卡片的某個 action 區(qū)域，支持半屏喚起一個擁有完整能力的小程序，在保持沉浸式體驗的同時給開發(fā)者足夠的能力支撐其業(yè)務(wù)。

同時，在該小程序內(nèi)支持訪問小程序卡片的數(shù)據(jù)并對其進行更改，同樣的，這些數(shù)據(jù)變更將同步到所有同 ID 的卡片上。

此時小程序卡片可以做為主體小程序核心信息和操作的載體，用以快速觸達用戶，完成核心業(yè)務(wù)流程。 

“傳統(tǒng)”應(yīng)用 vs. 卡片應(yīng)用

“傳統(tǒng)”應(yīng)用	卡片應(yīng)用
藏在圖標或鏈接背后的系統(tǒng)	以區(qū)塊化方式，前置到溝通、工作臺、搜索等核心場景中
查看數(shù)據(jù)需要跳轉(zhuǎn)進入應(yīng)用頁面 進行操作需要跳轉(zhuǎn)進入應(yīng)用頁面	沉浸式交互，無須跳離上下文。 卡片上實時透出內(nèi)容，數(shù)據(jù)自動更新（實時座位信息） 基本交互閉環(huán)可以在卡片上操作完成（進行搶座）
人與系統(tǒng)的交互	融入溝通后，增加了人與人的互動

Anywhere 運行

我們希望當開發(fā)者完成小程序卡片開發(fā)后，可以將其運行在：

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

• 多運行時：native（IM列表、搜索結(jié)果頁）、小程序、H5，甚至 iOS widget 內(nèi)。

• 
  

傳統(tǒng)小程序使用 webview 作為渲染容器，但如果直接在 IM 中為每張卡片嵌入一個 webview 就顯得過于重了，且多卡片共存情況下內(nèi)存占用過大的問題也難以解決。

所以，基于同一套 DSL ，我們會通過不同的 compiler 將其打包成不同產(chǎn)物以適應(yīng)不同的宿主環(huán)境，并通過 DSL 的強約束性保證多端渲染一致性。

依托于當前小程序離線包機制，我們將多種產(chǎn)物（未來可配置）統(tǒng)一打包到小程序離線包內(nèi)實現(xiàn)資源離線化。

在卡片被渲染前，卡片框架會先判斷當前所處的環(huán)境，并根據(jù)不同環(huán)境選擇不同打包產(chǎn)物進行卡片渲染。

使用卡片統(tǒng)一 DSL 可以將業(yè)務(wù)代碼與"卡片底層引擎實現(xiàn)"解耦，未來加入更多渲染引擎支持時業(yè)務(wù)可以無痛升級。

基于這套方案，釘釘小程序卡片已支持 Webview、Native、小程序 三種容器。

卡片容器的全行業(yè)耕耘

卡片技術(shù)作為一個全新的應(yīng)用形態(tài)和技術(shù)方案，仍有諸多不完善之處，需要持續(xù)迭代與優(yōu)化，提高卡片性能和產(chǎn)品化能力。

但不可否認的是，從 icon 到 card，無疑是當前移動開發(fā)領(lǐng)域，在后續(xù)發(fā)展進程上的一個重要方向。

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

1提供動態(tài)內(nèi)容展示

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

2為開發(fā)者的“私人定制”

客戶端 SDK 結(jié)合服務(wù)端卡片管理系統(tǒng)，開發(fā)者讓開發(fā)者的接入和使用過程更輕巧簡易；多種前端開發(fā)語言和完備的調(diào)試工具，讓“編譯-預(yù)覽-調(diào)試-發(fā)布”的開發(fā)流程更普惠，不用語法的開發(fā)者都能獲得最前沿的技術(shù)工具。