20秒了解小程式卡片
案例1：幸福大巴一鍵搶座
“幸福大巴”是阿裡員工在域内使用的城際客運功能，但因為需要來回跳轉VPN工具和H5頁面，在使用者體驗上帶來了一定的障礙
搶座流程對比：
| 以前H5頁面的搶座流程 | 現在卡片應用的搶座流程 |
|---|---|
| 1.小蜜搜尋“幸福大巴” | |
| 2.點選跳轉連結 | 2.一鍵搶座，完事兒 |
| 3.連接配接VPN | null |
| 4.打開預訂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 結合服務端卡片管理系統，開發者讓開發者的接入和使用過程更輕巧簡易；多種前端開發語言和完備的調試工具，讓“編譯-預覽-調試-釋出”的開發流程更普惠，不用文法的開發者都能獲得最前沿的技術工具。
本文轉自公衆号【阿裡巴巴移動技術】