淘宝小部件：全新的开放卡片技术
私域，即品牌自运营的空间，可以帮助品牌持续运营自己的消费者。
淘宝的开放技术目前主要有两种形态，小程序是其一，淘宝基于小程序做了很多业务上的探索和技术上的实践。小程序承载了大量商家的个性化诉求，通过小程序，商家可以持续释放自身的创意并运营自身的消费者。小程序一定程度上解决了商家和消费者的连接问题。
再后来我们发现卡片形态更适合场景的开放诉求，在讲究高效率的电商场，一块前置并可以高度自定义的开放区域可以有效提升消费者的触达率。我们也在积极探索一种适合电商场景并且足够灵活、开放的卡片技术。
所以，今天给大家正式介绍一下淘宝开放技术的第二种形态。
基于小程序技术体系，面向标准化、轻量化、高性能的开放卡片场景，我们在业界首次推出了全新的开放卡片技术「小部件」。
本文将从以下四点分别进一步阐述我们的一些技术思考。
技术设计策略
核心技术设施
业务场景接入
技术演进路线
小部件为开发者提供灵活、标准的技术选型。
小部件致力于解决场景卡片的开放问题，为开发者提供灵活、标准的技术选型来支撑商家的个性化诉求，并带来更具备体感的消费者体验。
面向与研发强相关的小部件， 我们希望开发者在同一个 IDE 中可以完成小部件/小程序的研发、调试、预览、上传等功能，所以「淘宝开发者工具」作为编辑工具与研发服务的结合平台，提高工具、服务之间的串联效率，一站式地帮助小部件的开发者提升整体效率。此外，在游戏互动卡片这块，开发者也可以直接使用游戏引擎的 IDE 来提高自身的研发效率。
开发者可以基于「淘宝开发者工具」的生产环境来构建自己的小部件，小部件的整个生产流程也是对齐小程序的开发模式，小部件积极拥抱三方开放生态，开发者可以使用标准的小程序 DSL，小部件的上层技术生态对齐小程序 Web 生态，无缝支持小程序前端框架、游戏引擎的运行接入。
此外面对表单配置能力，我们还在「淘宝开发者工具」支持了 JsonSchema 能力，通过 JsonSchema 的开放，小部件的开发者可以完成与小部件配套的商家端表单配置能力的研发，配置表单帮助商家可以灵活控制小部件的前台属性和后台接口。
渲染引擎是小部件的核心， 我们使用了淘宝自研的渲染引擎「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 概念，更加贴合前端的技术栈。
Canvas 能力在小部件中是一个独立的组件，得益于 Weex2.0 的 Platform View 机制，我们在自绘的引擎中实现了同层渲染 Canvas 能力。Canvas 本质是一个 W3C 图形渲染标准，面对这套标准淘宝同样自研了一套图形引擎实现「FCanvas」，FCanvas 支持 WebGL 和 Canvas2D 两套标准，跨容器且高性能的 FCanvas 的图形渲染能力我们对小部件也一并开放。同样，Canvas2D 下和 Weex2.0 同样直接对接了 Skia 图形库。
通过小程序标准的对齐和底层 SDK 的改造，我们完全兼容并支持了小程序中的游戏引擎生态。也就意味着，游戏的开发者可以直接通过我们支持的游戏引擎 IDE 自助生成小部件工程，卡片级别的互动游戏非常适合前置在业务场景中做投放。
▐ 业务场景接入
小部件是卡片，那嵌入卡片的「场」自然很重要。
在淘宝内，目前有多个业务场景支持了小部件的投放，这里面包括店铺、会员、直播、订阅等等。因为场景业务的特殊性，目前多个场景的渲染方案不尽相同，这里面涉及了 DX 渲染、H5 渲染、Weex 渲染、小程序渲染等多套技术方案。
面对纷杂的渲染环境，这里面没有捷径。我们也思考过在不同的场景下使用对应的场景渲染方案的优劣，这样会带来两个问题。
我们判断不同的渲染方案对接到一套 DSL 上的技术可行性较低，相对而言这样会破坏小部件的技术一致性，消费者的前台体验也无法得到保证。
此外多场景的技术维护性成本会持续增长，开放业务的特殊性决定了三方开发者的忍受阈值相对很低，会引入大量额外排查成本。
▐ 优化性能体验
降低图形内存占用，通过 FCanvas 的资源整合和管线优化来降低内存占用，此外我们会面向开发者提供最佳实践的手段来帮助开发者合理使用。
提升首屏加载速度，脚本引擎的性能优化会涉及两部分工作，一部分是预编译能力的支持，一部分是运行时「JIT」能力支持；还有的就是渲染引擎的进一步瘦身，运行时优化加载任务队列，支持低优先级和不必要的资源懒加载。
引入小程序插件能力，目前小程序的插件生态还是亟需支持，我们在考虑通过 API 的方式支撑插件生态的接入，可以帮助开发者直接使用会员、任务、人群等插件能力。
▐ 覆盖更多场景
小部件会继续拓展接入更多场景，尤其是商品详情页这种高频高转化的场景，也会逐步开放公域部分场景。
对商家来说，可以满足商家自身多元化的经营诉求，并有机会从公域收获额外的流量，提升品牌经营的水位线。
对于场景来说，可以积极拥抱三方开放生态，通过小部件的通投能力，形成商业要素的结构化沉淀和利用。
对于开发者来说，可以帮助开发者在多赛道持续收获商业收益，实现自身效益和效率最大化。
▐ 提升流通效率
在目前电商场流量逐步稳定的情况下，我们需要更好地帮助商家管理好营销预算和收益，提升卡片本身的流转效率至关重要，这样能帮助商家提升整体的投入产出比。
帮助开发者降低研发成本并帮助商家提升效益，进一步提升卡片流通效率。使得卡片在不同场景的分发和流转提升效率并建立相应的配套设施，最大化一个卡片的商业价值。
想知道淘宝小部件的应用情况？请耐心等待下篇。