简介：卡片技术在钉钉上的应用20秒看懂小程序卡片案例一：一键点击幸福巴士“幸福巴士”被阿里巴巴员工使用域城际客运的功能，但是由于需要在VPN工具和H5页面之间来回跳转，给用户体验带来了一定的障碍。抢座流程对比：与以往的一键预订、一键查询、一键取消相比，换班座位信息实时展现，为每位乘车同学节省了两分钟时间。怎么做？幸福巴士最初是企业智能在钉钉上开发的一款H5应用。此次基于小程序卡片能力，将前端用户界面快速转化为卡片形式，而后台服务仍然复用了原有系统。我们可以这样理解：以前的总线系统=后台服务+前端页面（跳转到新的全屏页面）现在的总线系统=后台服务+前端卡（在内部和externalxiaomisession)和这个前端卡，开发方法和开发小程序组件一样简单，只要会开发小程序就可以开发卡。卡片应用代码示例如下：案例2：ICBU客户邀请卡ICBU基于小程序的卡片能力，将原有的客户邀请系统改造为卡片应用。系统会自动通过机器人发送客户邀请，业务员直接在卡片上操作，选择拜访日期，填写拜访计划表，提交后邀请状态表也会直接显示在卡片内容上。通过卡片应用，减少了用户在通信和业务系统之间的直接跳转。从小红点说起看到这里，你可能已经对小程序卡片技术有了一些应用层面的了解，但是回到技术本身，我们可能还是要从小红点说起……小红点(Badge)，起源于黑莓，被苹果发扬光大（专利归苹果所有），直到现在成为iOS、Android等各大系统应用推送提醒的UI规范。小红点的设计太成功了，撇开UI不谈了。个人认为它对用户最大的意义在于，将用户直接进入APP才能看到的信息，直接转化为它的上层载体（比如AppIcon）。标准化揭示，大大缩短了信息获取的路径。现代操作系统中不乏类似的设计，进一步支持用户交互。如iOS、Android等系统小部件、通知中心、控制中心等。在云钉一体的战略背景下，钉钉将越来越成为企业数字化平台的操作系统。为了缩短用户获取信息的路径，我们需要一个具有沉浸式体验、对开发者友好、最终可以随处运行的块级应用解决方案。小程序卡片方案可以很好的满足上述需求。与传统小程序相比，沉浸式体验小程序卡片最大的优势在于可以带来身临其境的体验。传统的小程序是隐藏在图标（或共享链接）后面的应用程序。用户想要基于小程序获取或创建有效信息，需要跳出当前上下文。这种相对碎片化的交互方式在一些场景下会给用户带来很大的困扰，比如IM，而钉钉的IM作为钉钉的核心能力，承载了绝大部分工作相关的沟通信息。想象一下，业务员小王需要每天早上和群里的同事同步昨天的工作进度和工作安排，配合其他同事完成业务跟进。在关注其他同步聊天信息的同时，小王需要在工作台的其他应用中查询和修改客户信息。这种在聊天窗口和其他应用之间不断切换，让小王的工作效率很低，甚至可能会错过。重要信息。沉浸式交互为了让用户可以直接在IM中操作小程序卡片，我们与钉钉IM团队进行深度合作，在渲染流程和数据链接上与IM模块进行深度融合，将小程序卡片变成一个特殊的消息类型可以直接发送到消息列表。下图为钉钉文档卡片权限修改流程。用户可以直接在卡片上修改相应的文档权限：并且，结合IM本身的特点，IM中的中小程序卡片也可以支持置顶操作。置顶操作对于那些需要长时间交互的小程序卡片来说是非常有意义的，比如位置分享，数据看盘等实时数据同步函数式UI告诉我们UI=F(data)，可见决定性的重要性用户界面的数据。比如：钉钉的群投票卡片让我们可以直接在IM里投票。相比从IM跳转到单独的“投票”应用再进行投票的交互体验，无疑是向前迈进了一大步。但是如果我们想实时跟踪投票进度，得到最终的投票结果呢？例如下图的能力：要实现这个能力，传统的做法是业务方在业务逻辑中加入数据同步机制，刷新数据，然后更新视图。但是这种数据同步方式其实是非常低效的。作为客户端，为了保证数据的及时性，只能通过定时器定时刷新（长连接也有其他问题）。试想一下，100人一组，有一张卡需要同步，也就是说100个请求会同时打到服务器。如果n组同时有m张牌怎么办？小程序卡片内置高效的数据同步机制。开发者只需将最新的卡片数据同步到小程序卡片框架，即可快速更新所有同ID卡片。与小程序集成小程序卡片作为独立应用运行时，由于其块级应用定位，无法承载过于复杂的用户交互和业务流程。此时，小程序卡片就可以集成小程序能力了。点击小程序卡片的一个动作区域，支持半屏唤起能力齐全的小程序，在保持业务沉浸式体验的同时，给予开发者足够的支持。同时，小程序支持访问小程序卡片的数据并进行修改。同样，这些数据的变化也会同步到所有具有相同ID的卡上。此时小程序卡片可以作为小程序主体核心信息和运营的载体，快速触达用户，完成核心业务流程。“传统”应用vs卡片应用Anywhere操作我们希望开发者完成小程序卡片开发后，可以运行在：多终端：iOS、Android、Windows、Mac；多运行时：原生（IM列表、搜索结果页面）、小程序、H5，甚至在iOS小部件内。传统小程序使用webview作为渲染容器，直接在IM中为每张卡片嵌入一个webview会显得过于笨重，难以解决多卡片共存时内存占用过大的问题。因此，基于同一套DSL，我们会通过不同的编译器将其打包成不同的产品，以适应不同的主机环境，通过DSL的强约束保证多端渲染的一致性。依托目前小程序离线包机制，我们将多个商品（未来可配置）打包到小程序离线包中，实现资源下线。在卡片渲染之前，卡片框架首先判断当前环境，根据不同的环境选择不同的封装产品进行卡片渲染。使用卡片统一DSL，可以将业务代码与“卡片底层引擎实现”解耦，未来增加更多渲染引擎支持时，业务可以无痛升级。基于该方案，钉钉小程序卡片已经支持Webview、Native、Applet三种容器。卡片容器的全行业培育作为一种全新的应用形态和技术方案，卡片技术还存在诸多不完善之处，需要不断迭代优化，以提升卡片性能和产品化能力。但不可否认的是，从icon到card无疑是当前移动开发领域后续开发过程中的一个重要方向。除了钉钉小程序卡片，支付宝自研魔方卡片（Cube）也正式开放通过mPaaS对外输出。每张立方体卡片（Cube）都可以在原生页面中独立嵌入一个区域，该区域的内容通过卡片模板展示。提供动态内容展示魔方卡片（Cube）以卡片的形式嵌入到原生Native页面中。Android/iOS双端的高一致性可以大大提高开发效率，仅5.5mb的包体积和32mb的内存消耗让动态开发变得更轻。面向开发者的“私人定制”客户端SDK，结合服务器卡管理系统，让开发者的接入和使用过程更加轻便；多种前端开发语言和完备的调试工具让“编译-预览-调试-发布”的开发过程更具包容性，不使用语法的开发者也可以获得最前沿的技术工具。原文链接本文为阿里云原创内容，未经许可不得转载。
