淘宝小组件「淘宝宠物卡」

今天给大家普及一下淘宝小组件「淘宝宠物卡」相关知识，最近很多在问淘宝小组件「淘宝宠物卡」，希望能帮助到您。

简介： 淘宝的开放技术目前主要有两种形态，第一种是小程序，第二种是今天的主角小部件。它是基于小程序技术体系，面向标准化、轻量化、高性能的开放卡片场景。本文我们将通过技术设计策略、核心技术设施、业务场景接入、技术演进路线，这四个方面和大家分享它。

作者 | 千之来源 | 阿里技术公众号

私域，即品牌自运营的空间，可以帮助品牌持续运营自己的消费者。

淘宝也在快速调整私域的布局：淘宝也有非常多的私域产品，譬如店铺、客服、消息等。在这些场景中，品牌商家需要利用创意、内容和服务留住消费者群体，并产生销售转化。但是做私域并不仅仅只是纯销售，更要用内容和服务把人留下来，让场里的人越留越多，这部分常驻人群才是「私域流量」。

商家和品牌通过持续稳定地提供优质内容，以及购买产品的后续服务，私域中的消费者比公域消费者能获得更大的价值，也更容易产生复购和品牌忠诚度。

所以商家会迫切希望能够深耕淘宝的私域场景，帮助自身更好地运营消费者。面对不同垂直行业不同属性的大量商家，全量满足商家的个性化诉求会是一个海量的工作，所以我们通过开放技术引入了三方生态来服务品牌和商家，帮助他们构建自己的淘系私域。

通过淘宝的开放技术，三方开发者可以为品牌商家制作创意内容和服务，最后在私域被消费者所触达。

那什么是淘宝的开放技术？

一 开放技术形态

淘宝的开放技术目前主要有两种形态，小程序是其一，淘宝基于小程序做了很多业务上的探索和技术上的实践。小程序承载了大量商家的个性化诉求，通过小程序，商家可以持续释放自身的创意并运营自身的消费者。小程序一定程度上解决了商家和消费者的连接问题。

再后来我们发现卡片形态更适合场景的开放诉求，在讲究高效率的电商场，一块前置并可以高度自定义的开放区域可以有效提升消费者的触达率。我们也在积极探索一种适合电商场景并且足够灵活、开放的卡片技术。

所以，今天给大家正式介绍一下淘宝开放技术的第二种形态。

基于小程序技术体系，面向标准化、轻量化、高性能的开放卡片场景，我们在业界首次推出了全新的开放卡片技术「小部件」。

本文将从以下四点分别进一步阐述我们的一些技术思考。

技术设计策略核心技术设施业务场景接入技术演进路线二 技术设计策略

开放业务场景，拥抱技术红利，释放商家创意，提升经营效率。

1 生产侧

小部件为开发者提供灵活、标准的技术选型。

小部件致力于解决场景卡片的开放问题，为开发者提供灵活、标准的技术选型来支撑商家的个性化诉求，并带来更具备体感的消费者体验。

面向与研发强相关的小部件， 我们希望开发者在同一个 IDE 中可以完成小部件/小程序的研发、调试、预览、上传等功能，所以「淘宝开发者工具」作为编辑工具与研发服务的结合平台，提高工具、服务之间的串联效率，一站式地帮助小部件的开发者提升整体效率。此外，在游戏互动卡片这块，开发者也可以直接使用游戏引擎的 IDE 来提高自身的研发效率。

开发者可以基于「淘宝开发者工具」的生产环境来构建自己的小部件，小部件的整个生产流程也是对齐小程序的开发模式，小部件积极拥抱三方开放生态，开发者可以使用标准的小程序 DSL，小部件的上层技术生态对齐小程序 Web 生态，无缝支持小程序前端框架、游戏引擎的运行接入。

此外面对表单配置能力，我们还在「淘宝开发者工具」支持了 JsonSchema 能力，通过 JsonSchema 的开放，小部件的开发者可以完成与小部件配套的商家端表单配置能力的研发，配置表单帮助商家可以灵活控制小部件的前台属性和后台接口。

2 投放侧

卡片形态的小部件需要一套强大的投放系统来支撑。不同场景的小部件云信息下发需要一个中心化的平台来支撑，基于这个中心化的平台，小部件卡片可以被灵活投放到不同的业务场景下。

开发者入驻后，选择自身需要研发投放的场景后，可以获取不同场景的尺寸信息和视觉规范，通过这层约束得以保证场景的消费者体验一致性。而对此，小部件的开发者通过我们的适配方案后仅需简单适配即可完成产物交付，实现一套代码多处运行的技术目标。

为此，我们提供了一套完整的投放能力。当开发者完成小部件的交付并且审核通过后，商家需要在商家端完成小部件的业务配置，并投放到线上环境。商家可以自主选择投放的场景，譬如店铺、会员、订阅、直播等等。

前台的业务场景服务端对接投放系统完成之后即可完成场景的小部件投放。

3 运行侧

卡片本身的特殊性导致了对渲染、性能、体验的要求极高。小部件容器提供了高效、稳定的环境来保证业务代码的执行效率。

能力方面，通过基础库技术协议的对齐，所有的基础/业务 API 能力我们都保证了对小程序容器的复用，并且和支付宝小程序容器保证了接口标准的一致性。这意味着开发者可以几乎 0 成本地调用所有小程序开放出来的 API 能力并获得和小程序完全一致的体验。

渲染方面，传统的 WebView 渲染方案在卡片形态下会比较厚重，多个卡片共存同一场景下的内存和体验问题也无法得到很好解决。为此，我们重新设计了一套更适合卡片场景的渲染方案，相对于小程序的 WebView 渲染引擎，我们在卡片场景中替换为全新的渲染引擎，即 Weex2.0。

通过 Weex2.0 的跨平台渲染能力，我们在 iOS 和 Android 上保持了极高的一致性。三方场景的特殊性会导致卡片本身的技术容错率很低，所以，从性能和复杂度角度出发的角度考虑，我们也收敛了整体 CSS 样式的支持度。整体样式能力的规范的整体设计很大程度上兼容 W3C 标准，实现了一部分子集，在子集范围内的功能都和标准一致。

此外，小部件的运行安全也是非常重要的，为此我们引入了沙箱机制。通过沙箱机制我们得以保证不同的小部件环境之间是互相隔离并不互相影响的，通过底层技术的复用，我们也合并了多个 JavaScript 虚拟机的创建，保证性能和效率能够最大化。

三 核心技术设施

接下来展开讲讲我们的核心技术设施，这里包括脚本引擎、渲染引擎还有图形引擎。

1 脚本引擎

小部件的技术产物是 JavaScript 源文件，小部件中我们使用了 QuickJS 虚拟机作为脚本执行引擎。基于 QuickJS，我们可以获取一个轻量并且高效的 JavaScript 执行环境。相较于庞大的 V8 引擎，QuickJS 虚拟机的启动性能和包大小收益都远远超出我们的预期。

在卡片场景下，脚本引擎的快速启动是一个非常重要并且迫切的任务，所以基于 QuickJS 虚拟机，我们做了大量的定制和优化工作。

在虚拟机层面的优化工作有助于我们使用新的技术特性来加速，基于「ByteCode」机制，我们已经考虑在小部件构建的时候把 JavaScript 源码预编译为二进制来加速整体的渲染。此外，我们也在推进标准字节码的设计工作，通过字节码的优化，可以获取加载速度与代码体积的双重优化。

同样，在面向脚本引擎的接口这层，我们统一对接了集团标准「JSI」。通过 JSI 的帮助，我们可以实现不同 JavaScript 引擎之间的切换，并且可以帮助我们在异构容器下实现同构的标准编程。

2 渲染引擎

渲染引擎是小部件的核心， 我们使用了淘宝自研的渲染引擎「Weex2.0」，Weex2.0 的前身是 Weex1.0，相对于1.0 的 系统 UI 渲染，2.0 上我们全面切换到了跨平台 C 自绘方案。通过 C 的跨平台开发，我们在原生层面使用 C 实现了组件化、MVVM、声明式模板、响应式更新等复杂功能，也顺便抹平了 iOS 和 Android 上平台相关的组件差异。

接口注册层面，我们通过 JS Binding 直接把原生渲染接口注册绑定到 JavaScript 环境中，几乎没有序列化成本。C 框架下沉以后，可以更加细粒度的实现节点更新和回收复用。

渲染管线上，我们借鉴了 Flutter Engine 的线程模型及布局算法，最后会被提交到 Skia 本身的渲染流程上。这部分工作的复用有助于我们快速实现落地，此外由于我们的渲染管线是面向 Web 的技术特点设计，没有 Flutter FrameWork 中的 Dart Widget 概念，更加贴合前端的技术栈。

3 图形引擎

Canvas 是 Web 生态中非常重要的组件，适用于富交互并且注重互动体验的业务场景，譬如游戏互动、3D渲染、图表绘制、AR渲染等图形场景。

Canvas 能力在小部件中是一个独立的组件，得益于 Weex2.0 的 Platform View 机制，我们在自绘的引擎中实现了同层渲染 Canvas 能力。Canvas 本质是一个 W3C 图形渲染标准，面对这套标准淘宝同样自研了一套图形引擎实现「FCanvas」，FCanvas 支持 WebGL 和 Canvas2D 两套标准，跨容器且高性能的 FCanvas 的图形渲染能力我们对小部件也一并开放。同样，Canvas2D 下和 Weex2.0 同样直接对接了 Skia 图形库。

通过小程序标准的对齐和底层 SDK 的改造，我们完全兼容并支持了小程序中的游戏引擎生态。也就意味着，游戏的开发者可以直接通过我们支持的游戏引擎 IDE 自助生成小部件工程，卡片级别的互动游戏非常适合前置在业务场景中做投放。

四 业务场景接入

小部件是卡片，那嵌入卡片的「场」自然很重要。

在淘宝内，目前有多个业务场景支持了小部件的投放，这里面包括店铺、会员、直播、订阅等等。因为场景业务的特殊性，目前多个场景的渲染方案不尽相同，这里面涉及了 DX 渲染、H5 渲染、Weex 渲染、小程序渲染等多套技术方案。

面对纷杂的渲染环境，这里面没有捷径。我们也思考过在不同的场景下使用对应的场景渲染方案的优劣，这样会带来两个问题。

我们判断不同的渲染方案对接到一套 DSL 上的技术可行性较低，相对而言这样会破坏小部件的技术一致性，消费者的前台体验也无法得到保证。此外多场景的技术维护性成本会持续增长，开放业务的特殊性决定了三方开发者的忍受阈值相对很低，会引入大量额外排查成本。

由此，在不同的渲染方案下，我们都分别封装了对应的组件，通过组件的调用，再实现小部件的嵌入。这种方式前期成本相对而言较高，但对于跨场景一致性会得到保证，开发者也可以避免关心场景的渲染，只需要专注于完成自身业务逻辑的开发即可。

五 技术演进路线

主要围绕三个关键词，性能、场景、效率来展开。

1 优化性能体验

卡片场景对加载性能和运行性能会非常敏感，所以我们会持续优化技术性能，针对卡片场景进一步优化内存占用并提升整体运行性能，充分释放商家的创意和提升开发者的灵活度。

降低图形内存占用，通过 FCanvas 的资源整合和管线优化来降低内存占用，此外我们会面向开发者提供最佳实践的手段来帮助开发者合理使用。提升首屏加载速度，脚本引擎的性能优化会涉及两部分工作，一部分是预编译能力的支持，一部分是运行时「JIT」能力支持；还有的就是渲染引擎的进一步瘦身，运行时优化加载任务队列，支持低优先级和不必要的资源懒加载。引入小程序插件能力，目前小程序的插件生态还是亟需支持，我们在考虑通过 API 的方式支撑插件生态的接入，可以帮助开发者直接使用会员、任务、人群等插件能力。

2 覆盖更多场景

小部件会继续拓展接入更多场景，尤其是商品详情页这种高频高转化的场景，也会逐步开放公域部分场景。

对商家来说，可以满足商家自身多元化的经营诉求，并有机会从公域收获额外的流量，提升品牌经营的水位线。对于场景来说，可以积极拥抱三方开放生态，通过小部件的通投能力，形成商业要素的结构化沉淀和利用。对于开发者来说，可以帮助开发者在多赛道持续收获商业收益，实现自身效益和效率最大化。

3 提升流通效率

在目前电商场流量逐步稳定的情况下，我们需要更好地帮助商家管理好营销预算和收益，提升卡片本身的流转效率至关重要，这样能帮助商家提升整体的投入产出比。

帮助开发者降低研发成本并帮助商家提升效益，进一步提升卡片流通效率。使得卡片在不同场景的分发和流转提升效率并建立相应的配套设施，最大化一个卡片的商业价值。

「链接」

本文为阿里云原创内容，未经允许不得转载。