作者 | 千之
来源 | 阿里技术公众号
一 前言
先说结果，今年双11期间小程序创意互动支持了超过 200+ 个品牌定制互动小程序，服务了数百个 KA 品牌，覆盖了大量的活跃用户；商家有互动类商业化流量变现的诉求，也有品牌营销的诉求、与粉丝互动的诉求，尤其是品牌商家。通过小程序创意互动的开放能力，淘宝天猫上的商家可以引入定制/模版化的游戏化互动帮助品牌商家加速沉淀消费者资产，并持续运营消费者，实现最终的品牌心智养成与 GMV 转化。
那么为什么要做小程序创意互动？个人理解需要从两个维度来看：淘宝开放的历史演进，及外部竞争趋势。
电商平台的游戏化互动最近两年越来越火，变化发生在这几年：
- 大家习惯在淘宝上云养猫，在芭芭农场种地、种果树；双11期间的盖楼、养猫游戏引得全民狂欢；来自品牌商家的海量互动化需求也让淘宝越来越开放。
- 还有拼多多的崛起，很大程度是依靠“趣味化”、“游戏化”的互动玩法，譬如简单粗暴的砍一刀，还有能领免费水果的多多果园，让拼多多成为大家眼里 “有购物功能的社交游戏” 。
这些游戏化互动本质是基于社交属性的通道能力开放，基于核心社交属性链接 B、C 端，培养创新游戏化场景，并通过广泛的应用场景产生用户粘性锁住流量。
那么，回到互动本身技术方案上来，我们也一直在思考适合淘宝自身业务形态的互动方案。自从微信小游戏的发布，业界也有诸多类似小游戏的方案不断涌现。这种方案通过灵活、动态的方式让用户可以不用下载新的 App，就可以在超级 App 中体验到即完即走的游戏互动。相对于微信的纯游戏发行的产品形态，淘宝面向我们的品牌商家提供定制 / 模版型游戏互动的诉求同样广阔。
基于这个业务背景和诉求，我们启动了小程序创意互动项目，小程序创意互动是淘宝购物小程序的游戏化互动技术方案。基于阿里统一的小程序能力和开发者标准，购物小程序和业界游戏引擎深度合作，把游戏引擎能力通过小程序以动态化的方式带入了手淘，给消费者也提供了更丰富的游戏体验和更细腻的交互效果。
小程序创意互动定义了标准的引擎接入流程和引擎接口，帮助淘系生态内的开发者降低游戏互动的开发成本，并使得 Web 游戏和微信小游戏开发者可以迁移到淘宝生态中，开放的架构技术设计使得我们可以支撑多种复杂的互动业务场景和互动形态。
二 技术设计
小程序创意互动框架作为淘宝三方互动的核心业务承载模式，在容器层提供操作系统级的资源管理管控的基础能力，基于 Flutter Engine 的高性能渲染管线和 Skia 的强大图形渲染能力，提供跨平台跨容器的统一 API 和业务能力；小程序容器层负责从小程序角度提供应用管理、资源管理等基础能力，此外容器层还提供了游戏互动必要的渲染环境，两者的有机结合共同服务互动业务的研发。下文会详细介绍里面的细节。
在前端应用形态上，我们复用了阿里经济体统一的小程序 DSL，目的是为了对外提供一致的开发体验和管控能力，并降低开发者的学习成本和保证经济体业务的平稳迁移。
游戏引擎的接入使得游戏互动开发者可以专注于用熟悉的开发方式或者语言来开发自己的游戏，并使得很多现存的小游戏 / Web 游戏可以快速迁移到淘宝生态中，加速整体的互动业务规模化节奏。
整套方案一直坚持的策略是保证对小程序容器架构的低侵入性，并兼容目前的 Web 生态标准，同时也是一个开箱即用的完整游戏化互动解决方案。核心价值是帮助新技术入淘，并据此撬动新角色和新生态的入淘。
小程序开放平台同时提供了完善的三方互动应用研发服务，主要包括云端开发、构建、测试、发布一体化的研发支撑体系。这套体系可以帮助开发者可以快速发布并上线自己的互动小程序。
接下来，我会从以下四个维度来具体解析小程序创意互动的原理及能力：
- 生产链路的打通
- 游戏引擎的移植
- 渲染能力的设计
- 任务体系的开放
1 生产链路的打通
游戏引擎除了核心的游戏引擎代码外还提供非常多的工具链和脚手架能力，大部分游戏互动开发者习惯在游戏引擎方提供的一站式开发工作台（IDE）上编码和开发，尤其是 3D 的可视化场景编辑是非常依赖于游戏 IDE 本身的功能。此外，例如 LayaAir 等很多开发者团队都使用 TypeScript、ActionScript3 等语言技术栈，目前淘宝小程序 IDE 仅支持 JavaScript 语言，这里还需要一层语言的编译转换工作。
此外所有的淘宝小程序上传和发布都是依赖于淘宝小程序 IDE 的，所以这里需要通过合理的工作流把双方 IDE 的生产链路做打通。这个工作流可以解决以下问题：
- 支持不同语言技术栈之间的编译转换
- 支持游戏项目到淘宝小程序项目的转换
- 支持游戏项目资源的云存储和加载
- 支持小程序 IDE 中预览/调试游戏
淘宝的小程序开发者可以通过游戏引擎的 IDE 来开发自己的游戏化互动小程序，并使用对应的引擎提供的能力，开发自身的游戏逻辑。游戏引擎会对开发者提供游戏相关的技术支持和指导，单一语言的游戏项目譬如用 ActionScript3 开发的项目可以通过 IDE 中内嵌的 astojs 这样的编译器编译为 JS 语言，然后并导出为淘宝小程序的标准工程，最后通过我们的小程序 IDE 来打包和构建。
我们在小程序 IDE 的模拟器中实现了对游戏项目的预览，核心思路是通过在模拟器中模拟小程序容器的渲染行为，然后把渲染指令分发到 Web Canvas 节点中，通过这种方式可以保证模拟器和真机 App 中的渲染效果保持一致。
此外，通过小程序 IDE 连接的云存储能力，开发者可以把游戏互动相关的资源都上传到小程序云上，我们小程序云的资源存储支持了 CDN 的加速，这样可以保证开发者的资源存储在运行时可以快速下载到本地，从而降低整体资源的加载时长。
开发者可以通过小程序平台进行小程序版本的管理和发布，小程序发布完成之后可以获取对应的小程序链接并装修投放在手机淘宝的各个业务入口；消费者在访问小程序的时候会在小程序容器中拉取对应的互动小程序版本包，然后启动对应的环境创建和运行时注入，并在运行时中动态调用小程序容器中的 API 能力，完成一次完整的互动小程序运行过程。
2 游戏引擎的移植
工欲善其事，必先利其器。游戏引擎便是专门为游戏而设计的工具及能力集成。之所以称为引擎，如同交通工具中的引擎，提供了最核心的技术部分。因为复杂和研发成本高，开发者不需要每次制作游戏时都重新设计引擎，重用性是游戏引擎的一个重要设计目标。在淘宝小程序中，我们引入了多个游戏引擎的能力帮助开发者快速开发每一款游戏互动。
在 2D 游戏开发领域，我们和白鹭引擎合作，支持了在淘宝小程序中使用白鹭引擎来制作 2D 游戏；此外，我们也和阿里妈妈的同学合作，把 PixiJS 的能力带入了淘宝小程序中。
在 3D 游戏开发领域，我们和 LayaAir 引擎合作，支持了在淘宝小程序中使用 LayaAir 引擎来制作 3D 游戏和渲染 3D 模型，并且支持在 Unity 编辑器中完成 3D 建模并导入淘宝小程序中使用。
这些都是原先可以完整运行在 Web 环境里的游戏引擎，但是因为小程序不是一个标准的 Web 环境，小程序的逻辑层和渲染层是分开的，逻辑层运行在 JS 引擎中，并没有一个完整浏览器对象，因而缺少相关的 DOM API 和 BOM API。这一区别导致了前端开发同学非常熟悉的一些库，在小程序中是无法运行的。
那么这些 Web 游戏引擎是如何在小程序上运作的？
我们引入了小程序适配层代码，也就是 Adaptor。小程序的运行环境在 iOS 上是 JavaScriptCore，在 Android 上是 V8，都是没有 BOM 和 DOM 的运行环境，没有全局的 document 和 window 对象。因此当你希望使用 DOM API 来创建 Canvas 和 Image 等元素的时候，会引发错误。
但是我们可以通过类似于 my.createCanvas 这样的接口来创建一个 Canvas 对象，这样就可以像在浏览器中创建元素一样创建 Canvas 了。类似的 XMLHttpRequest 我们也有 my.downloadFile 这样的小程序 API 实现，其他的如音频、图片、渲染等接口都有相应的实现替换。
这些使用小程序 API 模拟 BOM 和 DOM 的代码组成的库称之为 Adaptor。顾名思义，这是对基于浏览器环境的游戏引擎在小程序运行环境下的一层适配层，使游戏引擎在调用 DOM API 和访问 DOM 属性时不会产生错误。Adaptor 是一个抽象的代码层，并不特指某一个适配小程序的第三方库，目前这份 Adaptor 是由淘宝小程序官方维护。
通过 Adaptor 我们抹平了小程序环境和 Web 环境的差异，帮助 Web 游戏引擎可以正常运作在小程序环境中。
3 渲染能力的设计
游戏的核心是图形渲染能力。在小程序架构中，因为逻辑层和 Web 渲染层分别属于两个 JS 环境，往往会有大量的时间耗费在两者的交互中，我们为此重新设计了基于 Flutter Canvas 的小程序互动渲染方案。
这套渲染方案需要解决以下问题：
- 提供高性能的2D 图形 API 和 WebGL API
- 降低复杂的 JavaScript - Native 交互链路
- 保证稳定高效的多系统、多机型、多设备适配能力
Flutter Canvas 是淘宝小程序团队自研的新一代渲染 SDK，我们利用 Flutter Engine 中的 Skia 图形库封装了所有的 Canvas2D 接口，再通过 JS 引擎把这些接口都以 JS Binding 的形式暴露给开发者使用。此外我们还支持了标准的 WebGL 1.0 和 WebGL 2.0 接口，在渲染管线层面，我们复用了 Flutter Engine 的 rendering pipeline，这些工作都有助于我们快速把一个完备的渲染图形库完成上线。
在这里我也简单介绍下 Skia，作为最资深的 2D 图形库之一，Skia 在 Chrome 和 Android 上都是作为默认 2D 图形库，其性能，稳定性，兼容性在生产环境得到了大规模的验证， 对 Skia 的使用使得我们不用特别关心和费力气解决 iOS 和 Android 的双端渲染不一致行为。
在 Flutter Engine 层面，我们引入了小程序 Canvas 模式，所以我们的 Flutter Engine 既可以支持我们的小程序业务，也可以支持我们的 Dart 原生业务。我们在做这个改造的时候保证了以下原则：
- 与 Flutter 社区的 engine 保持基本兼容，易维护，易升级。
- 保证原生的 Dart 模式可以正常运行，Canvas 模式和 Dart 模式在 engine 创建时可以动态指定，为后续的 Flutter 业务提供更好的基础。
所有的这一切，都使得Flutter Canvas稳定得支撑了互动业务的发展。
4 任务体系的开放
品牌的定制型互动小程序会通过任务机制来驱动消费者的行为，并带来成交增长。
在小程序互动中，我们把引导用户进入店铺、浏览商品详情、观看直播这些我们定义为正向行为，通过游戏化的场景设计和权益激励，消费者可以自如地完成以上任务，这些互动任务主要集中在以下类型，譬如：
- 浏览指定的店铺 10s
- 浏览指定的商品详情页 10s
- 观看主播直播间 20s
- ...
这些任务本质上是用户的行为，但是消费者行为属于非常敏感的信息，所以需要通过安全的方式把这种信息以脱敏的方式提供给开发者来使用。为此，我们设计了任务插件来提供开发者可以访问的任务机制。
互动任务插件的实现是客户端+服务端的解决方案，在这里我们着重讲一下我们在客户端上的实现细节。
任务插件有个核心能力是匹配用户的行为轨迹，这里我们和端智能应用团队合作，支持了通过特定的 SDK 获取用户行为的判定能力。小程序任务插件可以正常查询用户的行为和匹配条件，并上报到后台做任务权益结算。
通过这种有机结合，开发者可以利用任务插件在小程序中以安全脱敏的方式获取到任务的状态，并根据插件的结果返回实现自身的业务逻辑。
三 实践应用
1 品牌 Zone 互动
今年创意互动小程序的主要投放渠道是品牌 Zone，一般我们称之为旗舰店二楼。在今年双11期间，小程序创意互动支持了大量三方店铺服务商开发的游戏化互动应用，帮助品牌商家收获多元化的价值，并助力商家个性化运营自身的店铺。
2 3D 商品互动
在游戏化场景之外，我们也把游戏引擎的能力开放给商品互动类型的开发者使用，今年双11 出现了相当多的 3D 展示互动小程序。通过小程序 Laya 引擎的 3D 能力，开发者可以把 Unity 的 Laya 插件导出的 3D 模型/素材都无缝转化为淘宝小程序可以加载的 3D 资源。
3D 商品互动小程序帮助商家把所见即所得的购物体验带给消费者，也在多个行业中产出了标杆效应。
四 技术演进
未来小程序创意互动会继续沿着两个方向演进，主要分为能力升级和形态转变两块。
1 能力升级
渲染核心优化 & 性能稳定性保障
- 持续升级迭代 Flutter Canvas 的图形渲染能力，探索下一代渲染架构，保证架构优越性。
- 提升互动小程序的性能监控水位和管控性能审核卡口，保障手淘大盘稳定性。
任务体系+权益体系进一步开放
- 进一步开放任务和权益能力，打造更开放的任务配置能力和更健全的互动权益机制。
API 能力持续升级
- 聚焦专注于优化游戏互动场景下的 API 能力，包括游戏引擎插件、分包能力等机制的引入建设。
2 形态转变
完整形态
- 提供丰富稳定的能力助力生态提升产能，拓展 C 端互动玩法。
卡片形态
- 提供切面级别的卡片互动能力，投放各大业务场景；私域场景下帮助服务前置，公域场景下增加流量入口。
- 帮助商家的小程序互动从私域走向公域，卡片形态的互动会大面积出现在手淘中，通过互动卡片，我们在私域场景下可以支持小程序整体的服务能力前置，在公域场景下我们让更多私域的互动享受到流量的红利。
五 案例体验
大家可以打开手机淘宝扫码，体验一下目前线上的小程序创意互动的一些案例：
