簡介：卡片技術在釘釘上的運用。

20秒了解小程序卡片

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

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

搶座流程對比：

以前H5頁面的搶座流程現在卡片應用的搶座流程

1.小蜜搜索“幸福大巴”	1.小蜜搜索“幸福大巴”
2.點擊跳轉鏈接	2.一鍵搶座，完事兒
3.連接VPN	null
4.打開預訂H5頁面進行搶座	null

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

如何做到？

幸福大巴原本是企業智能在釘釘上開發的一個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 結合服務端卡片管理系統，開發者讓開發者的接入和使用過程更輕巧簡易；多種前端開發語言和完備的調試工具，讓“編譯-預覽-調試-發布”的開發流程更普惠，不用語法的開發者都能獲得最前沿的技術工具。

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?

總結

以上是生活随笔為你收集整理的小程序下一破局点？钉钉小程序卡片，应用与平台的深度集成的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。