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

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

搶座流程對(duì)比：

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

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

如何做到？

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

我們可以這么理解：

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

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

而這個(gè)前端的卡片，開(kāi)發(fā)方式就與開(kāi)發(fā)一個(gè)小程序組件一樣簡(jiǎn)單，只要會(huì)開(kāi)發(fā)小程序，就會(huì)開(kāi)發(fā)卡片。

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

2案例：ICBU客戶(hù)邀約卡片

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

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

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

從小紅點(diǎn)說(shuō)起

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

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

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

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

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

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

沉浸式體驗(yàn)

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

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

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

沉浸式交互

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

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

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

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

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

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

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

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

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

與小程序融合

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

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

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

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

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

Anywhere 運(yùn)行

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

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

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

• 
  

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

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

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

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

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

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

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

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

但不可否認(rèn)的是，從 icon 到 card，無(wú)疑是當(dāng)前移動(dòng)開(kāi)發(fā)領(lǐng)域，在后續(xù)發(fā)展進(jìn)程上的一個(gè)重要方向。

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

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

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

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

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