共计 2914 个字符，预计需要花费 8 分钟才能阅读完成。
简介：卡片技术在钉钉上的使用
20 秒理解小程序卡片
案例 1：幸福大巴一键抢座
“幸福大巴”是阿里员工在域内应用的城际客运性能，但因为须要来回跳转 VPN 工具和 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 联合服务端卡片管理系统，开发者让开发者的接入和应用过程更笨重繁难；多种前端开发语言和齐备的调试工具，让“编译 - 预览 - 调试 - 公布”的开发流程更普惠，不必语法的开发者都能取得最前沿的技术工具。
原文链接
本文为阿里云原创内容，未经容许不得转载。