作者：千之

上篇回顾：淘宝小部件：全新的开放卡片技术！

2021 双十一，淘宝全新的开放形态「小部件」大促中首次亮相，并且支撑开放业务初步规模化；说起小部件，我们还是先回顾一下淘宝小程序开放的前世今生。

小程序开放的前世今生

从页面级开放到模块级开放

淘宝开放业务的本质，就是通过联合三方开放生态的力量，帮助商家在淘內完成更好的商业运营行为，提供优秀的消费者体验。面对商家开放定制程度高、经营数据协同性强、更高效运营链路的追求下，我们对开放技术的探索永无止境。

过去我们提供了小程序的能力，打破了 H5 页面之间的边界和割裂，商家可以深度经营自身的消费者；在这个过程中，我们借力了小程序成熟的业界生态和完善的工程基建，通过独立页面的形态来支撑了我们自身业务的发展，譬如购物小程序、淘积木广告等等。

后来，我们和店铺团队合作，通过基于小程序环境下的插件开放，帮助店铺引入了 100+ ISV和数千家设计师，为上万的品牌和商家提供了差异化营销能力。这套技术天然是以小程序插件为核心的技术方案，也是小程序环境+小程序标准；将商家自运营主阵地店铺小程序插件化，并对旺铺平台升级，使店铺成为商家可高度模块化定制、个性化运营、差异化承接公域的核心经营阵地。

再后来，我们发现小程序技术虽然带来了业务资源的统一和利用率的巨大提升，但小程序独立形态的本质让我们的追求受限。小程序独立的页面形态和消费者流量承接效率之间天然会存在博弈，这里包括用户点击会存在跳失率的原因，也包括整个消费者访问路径过长的原因，也有缺少消费者前台心智的原因。

种种原因下，基于在小程序多年的技术积累和沉淀，我们启动了小部件开放项目。

小部件本质上是一个开放的模块全域通投技术， 通过小部件，我们可以把业务投放在各大非小程序环境的业务场景中，譬如详情、搜索、首猜、订阅等等，当然也可以在店铺中投放。

小部件和小程序的关系

小程序的姊妹形态

小部件和小程序的关系是什么？

一言以概之，小部件是小程序的姊妹形态。

过去，我们基于在小程序多年的技术积累和沉淀，我们沉淀了小程序平台，作为小程序/小程序的核心系统平台，也是小程序系统的基石，提供着最基础稳定的运行服务和数据能力；

在开发者使用的开放能力的背后，我们还有着诸多能力的基础平台，开放平台，提供了大量可使用可应用的基础能力；在小程序中我们积累了成熟的开发者工具体系，包括 IDE、构建器等等这些一站式的工程工具；此外，我们在横向自研了一个高效又轻量的 Weex2.0 渲染内核，通过渲染内核的升级和打磨，我们使得 Weex2.0 成为小部件渲染的核心基础；另外还有我们有着在小程序下积累的一批富有淘宝特色的 API 和基础 API 能力，这些 API 可以无缝在小部件下被我们的开发者所使用；再者，我们拥有和小程序同构的业务容器，稳定隔离的业务容器使得我们可以高效推进小部件相关的业务在安全的水位下运行。

除了这些平台自身的基础能力，我们还有来自广告公司、品牌的新鲜创意，通过创意的组合和生态的合作，我们为业务供给养料；另外还有来自开源社区的输入，与之配套的健壮工程体系。

站在这些巨人的肩膀上，通过这些生产要素的组合，我们在小程序之外孵化了一个新的开放形态：小部件。

小部件通过标准、能力、场景的三层开放，释放了新一轮技术红利；我们继续标准化了开放能力的使用和完整的技术接入流程，通过新的场景开放提升了生态的创收空间。

在业务侧，我们希望通过小部件可以撬动商家的运营心智，并最终提升商家的经营链路效果，为商家的经营效果所买单负责。

小部件是什么

淘宝开放的新形态，卡片级开放方案

那么，回到小部件上来，小部件是什么？

小部件是淘宝开放的新形态，是我们模块级的开放解决方案。

小部件生态里的开发者和设计师们可以通过我们的前台业务（LiveCard/前置卡片）来进入小部件的生产流程，通过我们的开放工具譬如淘宝开发者工具或者游戏引擎IDE来生产自身的物料，再通过我们的云函数/云应用来连接开发者自身的云，实现业务逻辑的研发闭环。

小部件的开发者生产完物料之后，会通过我们复杂的投放系统来做投放；这里平台会有一些规则的检测和约束机制来保证流通的效率，针对不同的场景下，开发者可以开发不同的小部件来适配场景和适应场景的业务规则，此外，针对投放侧还有一些配置数据的关系存储，最后这些业务数据会以报表的形态展现在商家前台；方便商家知道自家模块的正题情况，包括消费者点击PV、UV这些，还有引导成交数据等等。

投放操作完成后，小部件会在前台业务场景完成渲染，这里的技术细节会非常复杂。因为在不同的场景下会涉及多个场景自身的容器，这里包括PHA、Weex｜DX、小程序等等，所以我们需要通过一些方式直接嵌入在前台场景中。然后运行时会动态拉取对应的JS包再加以执行，这个逻辑也会非常复杂，在小部件容器层面，我们会统一元信息、基础库能力、生命周期等等能力；部分能力和小程序容器是直接公用的。最后 JS 代码会传递到小部件的内核，也就是 Weex2.0 内核中，Weex2.0 内核中包括了我们自研的脚本引擎、图形引擎还有渲染引擎。内核主要负责执行逻辑和提供渲染实现，通过Weex2.0 提供的跨平台渲染一致性能力，我们在 iOS/Android 上可以实现几乎一摸一样的样式能力和动画能力，也能保证开发者的代码可以无缝渲染两端。

最后是我们的支撑平台，通过开放平台、小程序平台、小二运营平台的横向支撑和上述生产侧、投放侧、运行侧的配合，我们可以面向私域场景输送小部件的供给。这里包括店铺、详情、搜索、首猜、订阅等等；面向这些场景下，我们可以提供最上方的卡片供给，还有商品卡片、互动卡片、小程序卡片、内容卡片、权益卡片、3D卡片等等。

关于小部件的详细技术介绍，可以参看笔者之前的文章：淘宝小部件：全新的开放卡片技术！

小部件能帮助业务解决什么问题

那回到一个业务命题上来，小部件可以帮助业务解决什么问题？

我们拿店铺举例。

首先回顾一下店铺开放业务的今年策略，店铺今年重新做了开放业务的策略升级，主要是三个关键词。

1. 首先是「表达模式升级」，店铺模块升级为 LiveCard，并通过多个 LiveCard 组合为 MiniShop、每日好店等；
2. 第二个关键词是「开放模式升级」，通过视觉开放、功能开放、应用开放的三个纬度，可以以卡片组合的方式来作为业务的前台表达；
3. 第三个关键词是「内容供给升级」，过去店铺里的模块大多数是商品货架卡片为主，内容化的模块相对较少，通过内容供给的升级，利用小部件丰富的开发者生态和强大的互动前置能力，我们可以将互动游戏直接前置在店铺模块中。

刚刚好，小部件的技术体系完美契合了店铺业务升级的思路。

开发者开发的一个 LiveCard 模块在店铺装修后，可以流通到详情页，并且在详情页的体验和店铺首页的体验是一模一样的。当然，这里面详情只是其中一个场景，店铺通过 LiveCard 可以从单纯的货架类卡片拓展到单品、推荐、权益、互动、内容、小程序等多类型卡片，丰富了各个场景的卡片供给，满足了商家多元化的经营诉求，最大限度得释放商家的生产力。

店铺使用小部件可以实现商家价值与平台价值的统一，业务可以通过小部件来沉淀自身的商家资产，并作结构化沉淀和利用，商家可以在店铺内通过小部件获取体验一致性和更大的开放空间作自家店铺的深度定制，对于我们的生态来说，生态里的开发者可以获取多场景、多赛道的创收空间，帮助开发者可以在更多的业务场景获得商业价值。

小部件在双11的规模化应用：店铺场景

为商家私域带来更为丰富的场景体验和更强大的创新创造力

淘宝小部件第一次登上双十一舞台。在大促中总体覆盖商家数 300+，涉及多个核心 KA 和 SKA 商家，前台峰值消费者曝光 PV 1900W+，UV 470W+。

• 支撑了双十一 98 个店铺 LiveCard 的上线，涉及多个 KA/SKA 品牌的定制小部件和大量腰部商家的模版小部件；
• 帮助平台上的商家通过 LiveCard 更快触达潜在客群，并在大促期间成功获客蓄水。

小部件在双11的规模化应用：会员场景

帮助 Nike 打造品牌会员定制标杆项目，提升会员运营效率

1. 支撑了天猫行业 Top 定制项目 「Wildwood 」正式上线 Nike、Jordan、Nike Kids 三家旗舰店会员页，整体项目对外为「Nike 会员进阶计划」，项目完整使用了小部件复杂的交互能力，并串联了背后的小程序增加深度体验；整体消费者回访率和停留时长均高于大盘水位；
2. Nike 借助小部件引入一系列高度个性化、有趣且更为深入的会员互动，借此会员进阶计划，优化了中国消费者的会员体验。

小部件遇到的技术挑战

开放业务有着比较鲜明且明显迥异于其他业务的业务特征，这些业务特征在今年双十一对小部件带来了全新的技术挑战。

交付工期短：

1. ISV 通常开发、测试的时间准备不足，交付工期被项目上线时间压缩，缺少严格测试周期能力
2. ISV 水平和质量都参差不齐，项目交付水准也无特定标准，缺少最佳实践指导

上线不可控：

1. 商家私域业务上线时间自由不可控，缺少单业务粒度的监控和运维能力
2. 商家私域业务发布装修即全量，缺少灰度放量机制

回滚难度高：

1. 上线后遇到问题再回滚/降级的成本商家是无法 cover 的，并且存在投诉风险
2. 商家/品牌的业务预期一向比较明确，通常需要配合生意经营节奏，一般不轻易回滚

这些显著的业务特征给我们的双十一带来了一些棘手的挑战，巨量的开发者提交版本和商家发布过程使得我们在双十一期间经历了报警、回滚、排查、修复、发布的多轮考验。在不影响商家品牌的核心体验的前提下，我们和开发者一起经历了多轮排查问题再修复上线的过程。

结合我们的业务特征和双十一期间的一些问题，我们总结了目前小部件最大的挑战和瓶颈，同时我们也在痛苦中寻求解法：

其一，稳定性挑战： 主要是小部件内核成熟度欠缺导致的全局稳定性风险，目前小部件的内核（Unicorn）还在快速迭代中，大量的功能需求和优化策略也在并行开发中；在快速迭代的过程中势必会导致稳定性受到挑战，这里存在业务场景对稳定性的高要求和技术迭代过快之间的矛盾；针对稳定性挑战的问题，我们后面会持续建设内核的稳定性，和内核团队一起把稳定性建设作为小部件最重要的技术目标；努力夯实内核的基本功，面向轻量、现代、高性能的渲染引擎目标迈进；

其二，语法能力： 小部件的样式语法限制目前还是相对严格，主要表现在部分受限制的CSS样式能力和数据协议声明；相对于小程序/Web体系的语法，小部件的一些语法限制对开发者确实提升了学习成本，帮助小部件的开发者获取和 Web一样的优秀体验，是我们正在努力优化的一件事；我们希望通过后续文档的持续完善、内核对样式能力的进一步支持、工具链的持续增强来帮助开发者进一步降低成本；

其三，开发体验： 小部件的研发工程链路细节粗糙；作为一个面向开发者的技术产品，小部件的工程链路上存在很多细节点需要深入打磨优化，这里包括预览环境和真实环境的对齐、性能面板能力的提供、调试工具链的增强、线上监控数据的披露、多场景流传的最佳实践、B端配置能力的升级等等；面这些开发者最关心最迫切的问题，小部件会尽快通过产品化的方式来优化我们的开发者体验，帮助开发者可以持续通过平台能力的升级来提升自身的开发效率和体验。

小部件的后续规划

小部件项目组全面支撑了开放业务的 2021 双十一大促，小部件技术方案实现了从框架演进到内核切换全流程的全面升级和优化。项目组30多位核心成员，成功走过了 KO、方案评审设计、封闭测试开发、大促冲刺等各个阶段，历经考验、自证预言，顺利上线。

一路走来，筚路蓝缕。

我们希望后续持续构建可支撑多场景多形态、API无差别能力、端到端建设的新一代开放技术，实现极致的全局开放，面向生态提供更高质量更广阔的开放赛道。

在生态体验这块：

1. 我们计划会面向生态开放全新的 Rax DSL，给开发者提供新的技术语言选择；
2. 我们计划面向开发者升级整个监控运维体系，提供监控报警、自动化运维等报表；
3. 我们计划继续丰富小部件的样式和动画能力，并提供更多的 API 能力；
4. 我们计划持续优化开发者的体验，帮助开发者提高小部件的研发效率。

在技术基建这块：

1. 我们计划持续接入更多淘宝的公私域场景，提高小部件的流通可能性；
2. 我们计划完善小部件的跨场景流通能力，并提升小部件的流通效率；
3. 我们计划优化小部件的前台消费者体验，优化小部件前台加载时长和引入小部件集群方案；
4. 我们计划夯实小部件内核基础稳定性，修炼内功持续建设底层基建。

通过生态体验和技术基建的双重建设，我们希望小部件可以成为商家在私域运营的核心武器，帮助商家在淘宝可以更好运营自身的消费者。

关注【阿里巴巴移动技术】微信公众号，每周 3 篇移动技术实践&干货给你思考！