Waft基于 WebAssembly 的AIoT应用框架实践

fannifu

Waft 基于 WebAssembly 的AIoT应用框架实践
简介： 天猫精灵大前端团队基于 WebAssembly 的AIoT应用框架实践分享。

作者 | 天猫精灵大前端

Waft 是一个专注于 AIoT 领域，面向原子化服务的应用开发框架，核心解决的是 AIoT 领域下用户和服务连接低效的问题。具备高性能、动态化、原子化、跨平台、支持多语言开发等特性：

背景

2014年年底，亚马逊推出了一个全新的智能硬件产品——"Echo" 智能音箱，该设备可以随时响应用户的语音指令，由内置的虚拟助手 Alexa 为用户提供信息、音乐、设定闹钟、控制智能家居设备等服务。一时间，全球互联网巨头纷纷入局，布局家庭 AIoT 新赛道，抢占家庭场景的流量新入口。随着新玩家的入场，智能音箱的能力也在飞速提升，不仅能听歌与智能家居控制，还可以设置闹钟与日程，百科问答与聊天等，简单高效的语音交互让用户真切的感受到人工智能技术的到来。

2019年春季，天猫精灵发布了第一款带屏的智能音箱。相比传统音箱，不仅增加了一块更利于用户交互的屏幕，还支持了各种传感器设备，成为了一款真正的智能家庭助手设备。作为一款普惠AI的产品，为了让更多的用户能够体验到人工智能的便利性，智能音箱的硬件配置相对比较低，整体硬件配置与当前市面上的手机相差甚远，对应用软件的运行性能提出了巨大的挑战。除了这些自研产品外，天猫精灵还支持了很多生态硬件产品，如：手表、电视、中控面板等。这些 AIoT 设备具有以下特点：

• 硬件配置跨度大：内存从128M到2G，存储从128M到32G
• 屏幕尺寸多样，从1.3寸、4寸、7寸、8寸、10寸到电视大屏
• 操作系统多样：Android、Linux、RTOS 等
  

我们一直在思考和探索下面两个问题的解决方案：

• 什么样的应用形态，更适合 AIoT 设备？
• 什么样的应用框架和开发方式，更适合 AIoT 领域的开发者？
  

我们陆续尝试了多种应用开发方式和框架：

2018年6月，开始引入 Andorid APP 的生态。陆续接入了优酷、芒果TV、BliBli、腾讯视频、爱奇艺、快手、抖音等30多个 APP。但由于天猫精灵设备算力与存储的限制，无法安装太多应用，一个 APP 要几十M左右，导致软件生态受到限制。

2018年12月，我们尝试引入小程序技术来解决存储空间不足的问题。并于19年1月上线第一个小程序猫精版“蚂蚁森林”，之后陆续引入了：宝宝巴士、斗鱼直播、贝瓦儿歌、汽车之家等600多个小程序。但问题也很明显：

1）在1G内存设备上，小程序的性能较差体验不太理想，冷启动需要十多秒，热启动需6秒左右。

2）面向手机开发的小程序几乎都是竖屏版本，在天猫精灵的横屏设备上体验并不好，需要开发者做UI适配或者容器端做分屏显示处理。

2020年7月，开始在天猫精灵设备上尝试云应用，想彻底突破终端的性能问题。云应用可能是应用生态的终极解决方案之一。一切应用皆可上云，当前所有的应用生态都可囊括，且终端无性能压力。但当前成本太高，还无法大规模铺开。需要等待5G和云应用的大规模爆发，来降低服务器和带宽成本以及网络延迟。

经过近三年在天猫精灵应用开放上的尝试，逐步形成了我们对 AIoT 行业的一些理解：

• 终端形态：硬件配置、操作系统和屏幕呈多样化发展、碎片化分布。
• 场景需求：触达路径短、多模态交互、多源服务灵活聚合。
• 业务核心：快速响应算法，提供多种UI形态的智能化服务。
  

这对我们的技术框架提出了非常高的要求：

• 能充分发挥硬件性能，在低配置硬件中实现极速启动。
• 支持多模态交互，通过服务原子化精准快速地满足用户意图。
• 可跨系统跨平台实现多端自适应。
• 面向AIoT行业开发者友好的开发工具链。
• 重云（边）轻端，降低终端侧的性能压力。
  

经过近两年的尝试，发现在天猫精灵 AIoT 上，APK 和小程序方案并不能很好的满足上述诉求，无法兼顾用户体验和应用生态，且云应用尚无法大规模铺开的情况下，我们从2020.08开始尝试探索一种新的解决方案 —— Waft。

Waft是什么

Waft 是一个面向 AIoT 原子化服务的应用开发框架，是一个适合 AIoT 应用开发的解决方案。

取名叫 Waft，其实有两重含义在里面：

• Waft 是 WebAssembly Framework for Things 的缩写，是一个面向 AIoT 的 WebAssembly 框架。
• Waft 单词本身的含义是“（在空气中）飘荡”，和我们的目标比较匹配：轻量的高性能的应用框架。
  

Waft的发展历程：

设计理念

Waft 的设计理念：原子化服务的快速直达和灵活的场景化组合。

化整为零：超级应用的核心内容短平快直达
移动互联网时代，一个个 App 将互联网割裂成信息孤岛，使得用户获取信息和服务的成本越来越高，操作路径越来越长。在天猫精灵智能终端上，我们希望能通过原子化服务的方式来解决这个问题。原子化服务指的是应用中能满足某个特定用户意图的完整功能，比如快递提醒，了解疫情信息，收取蚂蚁森林能量。将核心功能从应用中抽取出来后，通过卡片、浮窗这类轻量交互方式，缩短触达用户的路径，降低用户使用的成本。

化零为整：多来源的服务组合成场景化应用
当深藏在应用中的服务被原子化后，就具备了被重新组合成场景化应用的可能性。以天猫精灵中的语音头条为例，当用户起床后，可以跟精灵说“早上好”，得到天气、交通限行、新闻、音乐等信息服务，早上好就是由天气、出行、新闻、音乐等一系列应用中的原子化服务重组后的场景应用。类似的，还有中午好、晚上好等聚合了多种原子化服务的场景。更进一步的组合，是打通用户上下文信息的组合，一个服务的输出可以作为另一个服务的输入，比如用户预定了杭州到北京的机票这一信息语境，可以被传输到预定酒店的服务中，无需用户再次输入重复的信息，用户购买电影票的信息，可以作为美食餐厅推荐服务的输入，为用户提供更贴心的组合服务。

设计目标

从开发者的角度看，可以把 waft 容器简单类比成一个轻量级的浏览器，专注于 AIoT 领域，尽可能抛弃历史包袱。

和传统浏览器的差异主要在于：

1）内核的差异：

2）开发方式的差异：

Waft 的设计目标如下：

• 高性能：支持 AOT 运行模式，能接近原生应用体验，可运行在非常低配的 IoT 设备上。
• 原子化：面向原子化的服务。化整为零，超级应用的核心内容短平快直达；化零为整，多源化的服务重组成场景化应用。
• 动态化：应用和服务都可以动态下发与更新，具备与Web同级别的动态化能力。
• 跨平台：支持 Android, Linux, RTOS, MacOS 等多平台，并能实现UI自适应，能力自降级。
• 多语言：面向广大的开发者群体(前端、终端、传统 IoT 端、后端等)，支持 AssemblyScript, Kotlin, Swift, C/C++, Rust, Golang 等多种开发语言。
• 端云协同：应用逻辑和任务堆栈托管到云端执行，终端只做最终渲染和用户交互的反馈。
  

技术方案

Waft 是基于 WebAssembly 构建起来的一套应用开发框架：

WebAssembly 是一种体积小且加载快的 二进制格式， 其目标就是充分发挥硬件能力以达到原生执行效率。是一种运行在现代网络浏览器（并不局限于）中的新型代码格式，并且提供新的性能特性和效果。它设计的目的不是为了手写代码，而是为将诸如 AssemblyScript、Kotlin、Swift、C、C++、Rust、Golang 等高级语言编译为一种执行效率更高的中间字节码（可简单类比为 Web 的汇编语言）。我们选择基于 WebAssembly 来搭建 Waft 的整套技术体系，主要原因如下：

• WebAssembly 是 W3C 的标准，技术理念先进，开源社区活跃。
• 支持 AOT 模式，具有和原生几乎相当的性能表现。
• 可脱离浏览器运行，可运行在 IoT 设备上。
• 支持多语言开发，社区内已有多种语言可编译为 WebAssembly 格式。
• 具有很好的跨平台和动态化特性。
  

Waft终端架构

终端容器的核心任务是，页面的快速响应和丰富的表现形式，给用户一个非常好的交互体验。

Waft容器的三个核心模块为 Framework、Engine和 Native Services (基础服务)：

• Framework: 作为终端的大脑，职责包括：端云协同、包管理、场景管理、资源管理等等。
• Engine: 页面渲染与逻辑执行的核心模块，包括：Runtime 虚拟机、DOM Parser 以及页面渲染与绘制。
• Native Services (基础服务)：提供多种高性能的原子化服务，减轻业务开发的难度与工作量。
  

Waft渲染管线

说明如下：

• AST：抽象语法树，通过编译器将 XML 和 CSS Styles 编译为一个json格式的抽象语法树。
• VDOM Tree：虚拟 DOM 树，根据自定义的 JSON 数据格式生成，UI 的虚拟表现形式，并可以通过设置不同的数据修改 VDOM 结构和数据，最终驱动真实组件进行绘制。
• Layout Tree：由 Yoga 创建的，包含宽高、Padding 等位置信息的数据结构，用于布局排版。
• Render Tree：CSSOM 和 DOM 合并而成，包含节点的样式、布局等信息，用于渲染。
  

Waft前端框架和工具

在基于 WebAssembly 运行的基础上，为了更好的支持前端开发者生态，我们选用了 AssemblyScript 作为前端框架的逻辑开发语言，它是 TypeScript 的语法变种。在前端框架的设计上，主要包含了3个层面：

• 框架核心层：封装了渲染引擎、容器的API，具备生命周期、状态管理、多页路由等前端框架的核心能力。
• 工程构建层：集成了框架核心的构建能力。通过解析工程目录和 DSL，并进行编译成 Wasm/AOT 包的能力。并增加了内置函数，语法检查等实用功能。
• 应用能力层：建设框架的UI组件库，WebAPI/CSS标准，响应式&自适应能力，以及语音/触屏多模态交互能力，并支持卡片开发标准。
  

在开发者工具上，目前支持了4个部分：

• IDE 插件：VSCode 插件集成了工程初始化，开发调试，编码辅助，应用管理等综合能力。
• CLI 工具：CLI 支持无界面形式的工程流程化管理，包括创建、调试、打包、单测等阶段。
• Chrome DevTools：基于 Chrome DevTools Protocol 协议的开发调试工具，可支持本地模拟器、无线方式连接真机的方式进行调试，进行元素检查、日志查看等功能。
• 在线工具：支持低代码平台进行快速搭建产出应用，CloudIDE 云端编辑和云真机等能力。
  

技术特点

当前市面上的跨端方案也比较多，Waft 与其他方案相比，优势在于同时兼顾了动态化、高性能和跨端一致性；劣势在于因只支持 CSS的子集，页面编写灵活性上不如H5/小程序：

除了这些特点外，Waft还具备一些其他方案少有的特性。

端云协同

Waft有一个核心目标是云化：页面跳转逻辑和任务堆栈交由云端管理，终端只做页面渲染和交互的反馈。

借助于天猫精灵云端 DM (Dialog Manager, 对话管理) 服务的能力，Waft应用的跳转逻辑和业务堆栈管理可交由云端管控。终端页面在点击某个跳转按钮时，只需给 DM 传递相应的意图参数，DM 负责分发意图，调用对应的技能服务(应用)，再由技能服务向终端推送新的页面，这里的意图和 Android 的 Intent 的作用非常相似。

借助于猫精的对话流编排平台，可将多个零散的原子化服务(页面)，组合为一个复合场景，在平台上通过可视化编排的方式，构建多个页面间的跳转逻辑。

如下图“早上好场景”的对话流：

端云协同交互流程

动态化的AOT

得益于 WebAssembly 的技术优势，Waft 可实现 AOT 级别的动态化能力，整体逻辑上跟动态加载运行一个 so 比较类似，且因为 WASM 运行在Waft容器的沙箱环境中，相比动态化so更安全可控。

多语言开发

因 WebAssembly (简称Wasm) 只是一种二进制格式，理论上只要某种语言的工具链支持将源码编译为 Wasm 格式，就可以在 Waft 容器中运行。

为了降低代码实现难度、提高可扩展性，现代编译器一般都会按模块化的方式设计和实现。典型的做法是把编译器分成前端（Front End）、中端（Middle End）、后端（Back End）。前端主要负责预处理、词法分析、语法分析，生成便于后续处理的中间表示（Intermediate Representation, IR）。中端对IR进行分析和各种优化，例如常量折叠、死代码消除、函数内联。后端生成目标代码，把IR转换成平台相关的汇编代码，最终由汇编器编译为机器码。

云端渲染

可将原来在终端上完成的UI数据解析、绑定、测量等渲染前的耗时操作由终端转移到云端，云端仅下发绘制指令，由自研渲染引擎直接完成渲染。部分场景下可将UI渲染转移到云端，直接在云端生成 UI 图片后推送到终端进行显示。大致思路如下：

上图的补充说明：

• 在云和端上部署同一套 Waft Contanier 运行环境。
• 将整个渲染拆分为5个步骤：
  

• 数据绑定 (DataBinding): 将 AST 和 Data 进行数据绑定，形成一个 VDom Tree (JSON 格式)
• 大小测量与位置计算 (Measure & Layout)：对 VDom Tree 进行 CSS 解析和布局处理，计算出每个元素的x、y坐标和width、height等信息。产出一个包含详细布局信息的 Layout Tree。
• 创建UI组件：将 LayoutTree 中的每个节点，转换为调用实际的创建UI组件的代码(如：createButton, createTextView, createImageView等等)。
• 绘制(Paint)：使用Skia图形库，在显示的 FrameBuffer 中绘制。
• 展示(Display)：在屏幕中展示 FrameBuffer 中的内容，展示出最终的页面。
  

• 渲染的5个步骤，可以按场景决定云端和终端分别执行哪几步，比如：将数据绑定、大小测量与位置计算、创建UI组件指令这些操作放在云端的 Waft Container 中执行，将 Paint、Display 两步交给端上执行。
  

注：云端渲染能力，还在预研阶段，待线上业务落地后，我们会再详细展开介绍这部分的实践经验

应用开发方式

在应用开发上，我们遵循“前端友好，研发提效”的理念，在框架设计和开发工具建设上提供更完整的解决方案，降低前端和AIoT开发者的开发门槛。所以Waft开发的上手也主要分为两个部分，一个是前端框架的学习使用，包括开发语言、组件库、API等；另一个是开发工具的上手使用，包括源码CLI工具的流程命令以及Devtools的使用；另外，开发者也可以使用我们的低代码搭建平台来快速生产卡片应用。

开发语言

前端 UI 框架支持两种DSL，支持类Web的单文件写法，以及阿里系的小程序写法。目前支持的逻辑脚本语言为 AssemblyScript，AS 是专门为 WebAssembly 设计的一种新语言，采用了类似 TypeScript 的变种语法，可以让熟悉 TS 的前端开发者更快地上手。此外，我们也正在支持Kotlin/Swift/Rust/C/C++等其他开发语言。为了让大家对Waft有一个直观了解，在此展示下简单的页面开发代码和运行效果：

研发流程

Waft-CLI脚手架是辅助开发者源码开发的提效工具，封装了多阶段的不同功能：

• 初始化阶段：通过waft init快速初始化应用，内置了1个通用开发模板以及多种业务模板。
• 开发调试阶段：通过waft dev开启调试模式，内置了连接多平台的Devtools工具，支持Web浏览器、Mac模拟器和真机的调试预览。
• 质量检测：封装了单测运行、视觉稿对比、性能performance等质量检测功能。
• 打包上传：通过waft build构建wasm包和多平台AOT包，并支持和云端技能平台关联进行上传和发布。
• 运行监控：在运行态下，Waft框架和容器已经默认携带了应用的性能监控和基础数据埋点能力，后期会在开发者平台逐渐对三方开发者开放。
  

开发调试工具

调试工具(DevTools)可以帮助开发者更容易地定位与解决问题，目前功能支持了元素，日志，网络请求信息检查，如下方视频所示。

点击查看视频

为了达到 web 的开发调试体验，Waft 遵循了Chrome的调试协议(Chrome Debug Protocol)，通过 Chrome 浏览器内置的调试工具，提供日志、元素审查、网络请求监控等功能。下图展示了调试器如何与设备进行通信，并获取调试信息的流程：

低代码开发工具

Waft作为“端云一体化”框架，不仅支持通过源码方式开发复杂的应用，同样支持通过低代码搭建平台，更高效、灵活的开发“轻服务”。轻服务，是连接用户意图与服务之间的直通桥梁，将原本藏在技能、应用的原子化服务释放出来，方便用户在天猫精灵端上直接触达某一个特定的完整功能，而无需提前打开技能、应用。在天猫精灵上创建一个轻服务的流程如下：

下面是低代码开发的演示视频：

点击查看视频业务形态

Waft已支持多种业务表现形态，可根据设备形态和应用形态灵活使用。

智能场景

特点：云端编排剧本，将多个页面组合为智能场景，交互逻辑由云端决策，终端做页面展示与用户操作反馈。

适用领域：适用于助手类业务，如：早上好、晚上好、回家/离家模式等。

点击查看视频单页面

特点：云端下发数据和模版，终端通过 DataBinding 实现信息的透出，重展示轻交互。

适用领域：适用于信息展示为主的领域、如：天气、时间、百科等

点击查看视频轻服务

特点：兼顾核心信息展示与应用导流的作用，并通过声屏联动，在恰当时机内自动关闭轻服务弹窗

适用领域：适用于关键信息查询，且背后都有一个完整应用的领域，如：查快递、查课表等。

点击查看视频浮层

特点：不打扰当前页面交互，以简洁的方式和当前页面融合。

适用领域：屏幕特效，如：放鞭炮/烟花/炸弹等；以及个人相关时效性信息的推送通知，如：快递、外卖等；

点击查看视频Widget

可做为Widget，嵌入到任意页面内，以信息流的方式，实现内容透出、分发和引流。

点击查看视频

6.6 多端适配
可针对不同的设备不同场景，做差异化的适配，以提供更好的交互流程，提升用户交互体验。在保证基础交互一致性的基础上，充分利用设备硬件特点和优势。如我们在优酷TV大屏上天气展示：

点击查看视频总结与展望

自2020.09年开始到现在，Waft经过大半年的发展，上线了10多个业务：早上好、晚安等智能场景，天气、时间等单页应用，查快递、查疫情等原子化的轻服务，放鞭炮、放烟花等节日彩蛋特效；除了天猫精灵自研设备外，还在优酷TV大屏、海尔电视等生态设备上线，阶段性地完成了最初的一些技术设想与目标。

高性能

Waft 最核心的目标是高性能，能快速的响应用户的请求。以下是Waft在天猫精灵1G设备上的性能表现，截取其中三个线上业务的监控数据：

下面是猫精版的蚂蚁森林，在1G设备上，Waft和小程序方案的冷启动对比视频：

点击查看视频

虽然当前的性能表现还不错，但性能是Waft立足之本，我们会进一步挑战冷启1.5s，热启1s的极致体验。从当前业务性能监控来看，启动耗时的瓶颈在于渲染，因此，渲染引擎的优化将是我们后续重点投入的方向。

原子化

提面提到过的原子化服务包含两重含义：

• 化整为零：超级应用的核心内容短平快直达，缩短用户获取服务的路径。
• 化零为整：多来源的服务组合成场景化应用，提升用户的需求满足度。
  

已上线原子化服务有：快递、课表、疫情、股市大盘、蚂蚁能量等，用户可快捷获取这些服务的核心信息。

服务原子化后，还带来了更多的可能性：
1）可以很方便被各种场景组合，如天猫精灵上早上好、晚上好等场景。在这些场景内编排组合了天气、时间、限行、早安新闻、精选歌单等多个原子化的服务。

2）也可以嵌入到其他页面内，提供分发效率。如在天猫精灵的“服务直达“页面内，嵌入了多个Waft的轻服务卡片。

跨平台

Waft的核心模块都是使用C/C++开发的，可便于做多平台的移植。目前已经在Android端上线，并且在RTOS和Linux平台已跑通DEMO。因 Waft 是聚焦在AIoT领域，暂不考虑iOS设备：

除了技术框架的跨平台外，对于不同屏幕的UI自适应也是我们的一个重点方向：

多语言

得益于WebAssembly的技术优势，借助开源社区的力量，可支持多语言开发。当前已支持AssemblyScript，C/C++/Rust也经过可行性验证。我们还会陆续支持C/C++、Kotlin、Swift、Golang等开发语言。

我们会持续基于 WebAssembly 和自绘渲染引擎做更多的探索和尝试。如果您对 WebAssembly 或者 AIoT 领域的应用研发也感兴趣，欢迎在文末评论区留言和我们进行交流。如果您想加入猫精大前端团队一起探索，欢迎发送简历到 ziyuan.tzy@alibaba-inc.com