作者：唐諾
20秒瞭解小程式卡片
案例：幸福大巴一鍵搶座
大家如果之前使用過幸福大巴搶座功能，可能還記得被連線vpn以及各種來回跳轉H5所支配的恐懼。
搶座流程對比：
| 以前H5頁面的搶座流程 | 現在卡片應用的搶座流程 |
|---|---|
| 1.小蜜搜尋“幸福大巴” | 1.小蜜搜尋“幸福大巴搶座” |
| 2.點選跳轉連結 | 2. 一鍵搶座，完事兒 |
| 3.連線VPN | |
| 4.開啟預訂H5頁面進行搶座 |
與以前相比，一鍵預訂一鍵查詢一鍵取消，班次座位資訊實時透出，為每位坐大巴的同學節省兩分鐘。
如何做到
幸福大巴原本是企業智慧在釘釘上開發的一個H5應用，此次基於小程式卡片能力，快速地將前端使用者介面改造為卡片形態，而後端服務依舊複用原來系統。
我們可以這麼理解：
- 以前的大巴系統 = 後端服務 + 前端頁面（跳轉到新的全屏頁面 ）
- 現在的大巴系統 = 後端服務 + 前端卡片（內外小蜜會話中）
而這個前端的卡片，開發方式就與開發一個小程式元件一樣簡單，只要會開發小程式，就會開發卡片。
一段卡片應用程式碼示例如下：
案例：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、小程式 三種容器。
一致的開發體驗
使用小程式 DSL
開發者使用小程式 DSL 作為卡片統一 DSL 開發 小程式卡片。
在我們確定開發者應以何種方式開發區塊級應用時，我們覺得其必須滿足以下三個條件：
- 被開發者廣泛接受並使用
- 足夠標準化
- 面向開放
被廣泛接受並使用
被廣泛接受並使用意味著其生態必定有相當規模，而規模效應會帶來成本降低。成本包括兩方面：
- 開發者本身需要掌握的技術成本和生態為開發者帶來的各種技術紅利（多端框架、UI庫等）;
- 繁榮的小程式生態為企業所節約的人才成本。
自 2016 年微信推出微信小程式後，小程式憑藉其較低的開發成本、開箱即用的開發模式和相比於傳統 web 應用更優的效能表現，快速成為各平臺最熱門的開放應用形態。在 2018 年，小程式開發者數量就已到 百萬級別 。小程式生態的快速成熟和像支付寶、淘寶、釘釘等擁有海量註冊使用者的玩家入場，勢必會大大加速小程式的普及，進而吸引更多高質量的開發者入場。
標準化的 DSL
足夠標準化的 DSL 意味著穩定。
2019年9月，阿里巴巴結合自身的小程式實踐並聯合相關公司，在W3C制定釋出《小程式標準化白皮書 / MiniApp Standardization White Paper》，推動制定統一的小程式標準。當前，已成立了 MiniApps Ecosystem Community Group，同Google，華為，小米，Facebook等公司一同孵化小程式的國際標準。
正是在該標準中，定義了卡片 —— 這種區塊級的小程式應用形態。
章節 2.1.4 ：
In addition to being presented in the form of an MiniApp page, MiniApp can also be displayed in the form of information fragment, that is, a MiniApp widget. In this form, developers can put their service and/or content to various host scenarios, called host environment, such as assistants, search page, etc.. This feature connects services of the MiniApp with the scenario, providing users with more convenience.
面向開放
區塊級應用作為一種獨立的應用形態，開放是其天然訴求。但隨著小程式開發者數量越來越龐大，開發者水平難免會參差不齊。
小程式本身雙執行緒架構 + 統一執行時 + 離線包機制可以保證其效能始終處於較高水平，提升應用質量底線。
| 應用型別 | 編碼靈活度 | 效能 | 平臺管控能力 |
|---|---|---|---|
| H5 | 高 | 方差較大，對開發者要求較高。平均水平，中等。 | 弱，管控 url 和後端介面 |
| 小程式 | 相對較弱 | 方差較小，平均水平較 H5 有明顯提升。 | 強，可做到程式碼層面管控 |
且由於我們對小程式架構有完整的控制力，這意味著我們可以對其進行持續迭代升級，而這些對開發者來說都將是透明的，開發者將從框架本身的升級中持續受益。
小程式卡片 在框架設計和平臺管控策略上將與小程式保持一致。
IDE 整合
為了降低卡片研發門檻，我們在 IDE 中新增了小程式卡片應用，開發者可以在 IDE 中一站式建立、開發、測試、預覽、上傳小程式卡片（目前在專有釘工作臺專案中落地）。
同時，我們在卡片 Anywhere 執行和卡片編碼靈活度上進行了取捨。
小程式卡片作為區塊級應用，決定了其業務場景中的互動和 UI 不會過於複雜（圖表等場景可使用卡片 canvas 繪製），所以我們對小程式卡片 DSL 進行了簡化。嚴格來說其為小程式 DSL 的子集。同時，為了能更好的適配多端多場景，我們使用了類 tailwindcss 技術實現卡片樣式開發，從而實現對樣式的強約束。
在對小程式 DSL 進行簡化及加入 tailwindcss（子集） 後，勢必需要工具對其進行校驗和預編譯，方便在開發階段對開發者進行相關提示。基於此，我們提供了卡片官方 IDE 外掛，該外掛負責在卡片卡發過程中對 DSL 能力進行校驗並提供必要的錯誤提示。
當開發者在 IDE 中建立小程式卡片應用時，IDE 將自動為其建立可直接執行的初始化程式碼，並同時自動安裝官方 IDE 外掛。初始化程式碼包含一個 demo 卡片和簡單的卡片資料 mock 方案，可以讓開發者快速上手進行第一個卡片開發。
低程式碼搭建
對於專用於 IM 的卡片，目前釘釘團隊已結合釘釘場景群業務，於釘釘開放平臺正式對外提供卡片搭建服務。詳情請見：建立訊息模板 - 釘釘開放平臺。
在搭建平臺上，釘釘結合自身的小程式卡片實踐，目前已沉澱了一系列通用模板供開發者直接使用，旨在幫助開發者以儘可能低的成本開發、使用小程式卡片。
演進路線
小程式卡片作為一個全新的應用形態和技術方案，仍有諸多不完善之處，之後我們會持續迭代與優化，提高卡片效能和產品化能力。
全平臺支援
目前小程式卡片只可執行在釘釘客戶端內的 IM、搜尋、工作臺等場景中，宿主環境支援native、H5、小程式，對於更大的應用場景：端外 web 並不支援。
卡片的 H5 執行時端內外並無太大差異，問題在於資源鏈路和資料鏈路。其中涉及到鑑權、離線資源載入、容器協議 web 化、資料安全等問題，但這些問題並非完全無解，之後我們將逐步解決鏈路問題，實現卡片Anywhere價值最大化。
基礎能力升級
在執行時層面，小程式卡片會在已有元件基礎上做持續擴充，引入諸如 地圖、視訊、音訊、畫布 等基礎元件，並逐步完成與小程式標準元件的對齊。
JS 執行時支援上，卡片將逐步接入符合小程式標準的自定義元件模式，提高卡片開發效率。
生產效率提升
目前小程式卡片 fullcode 模式主要以 CLI 方式面向一方開發者，CLI 模式足夠靈活，但在對外開放時，卻並不適合所有外部開發者。
所以，未來我們會把已在專有釘落地的 IDE 整合開發模式做持續優化並遷移到標準釘，同時在標準釘上建立一條較為完善的從開發到上線的卡片研發鏈路，給開發者提供開箱即用的卡片研發環境。
關注我們，每週 3 篇移動技術實踐&乾貨給你思考！