作者：唐诺

20 秒理解小程序卡片

视频请点击此处，进行查看

案例：幸福大巴一键抢座

大家如果之前应用过幸福大巴抢座性能，可能还记得被连贯 vpn 以及各种来回跳转 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 开发 小程序卡片。

在咱们确定开发者应以何种形式开发区块级利用时，咱们感觉其必须满足以下三个条件：

1. 被开发者宽泛承受并应用
2. 足够标准化
3. 面向凋谢

被宽泛承受并应用

被宽泛承受并应用意味着其生态必然有相当规模，而规模效应会带来老本升高。老本包含两方面：

1. 开发者自身须要把握的技术老本和生态为开发者带来的各种技术红利（多端框架、UI 库等）;
2. 凋敝的小程序生态为企业所节约的人才老本。

自 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.

面向凋谢

区块级利用作为一种独立的利用状态，凋谢是其人造诉求。但随着小程序开发者数量越来越宏大，开发者程度 难免会参差不齐。

小程序自身 双线程架构 + 对立运行时 + 离线包机制 能够保障其性能始终处于较高水平，晋升利用品质底线。

且因为咱们对小程序架构有残缺的控制力，这意味着咱们能够对其进行继续迭代降级，而这些对开发者来说都将是通明的，开发者将从框架自身的降级中继续受害。

小程序卡片 在框架设计和平台管控策略上将与小程序保持一致。

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 篇挪动技术实际 & 干货给你思考！