作者：唐諾
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 篇移動技術實踐&乾貨給你思考！
