作者 | 天猫精灵大前端
Waft 是一个专注于 AIoT 领域，面向原子化服务的应用开发框架，核心解决的是 AIoT 领域下用户和服务连接低效的问题。具备高性能、动态化、原子化、跨平台、支持多语言开发等特性：
2014年年底，亚马逊推出了一个全新的智能硬件产品——"Echo" 智能音箱，该设备可以随时响应用户的语音指令，由内置的虚拟助手 Alexa 为用户提供信息、音乐、设定闹钟、控制智能家居设备等服务。一时间，全球互联网巨头纷纷入局，布局家庭 AIoT 新赛道，抢占家庭场景的流量新入口。随着新玩家的入场，智能音箱的能力也在飞速提升，不仅能听歌与智能家居控制，还可以设置闹钟与日程，百科问答与聊天等，简单高效的语音交互让用户真切的感受到人工智能技术的到来。
2019年春季，天猫精灵发布了第一款带屏的智能音箱。相比传统音箱，不仅增加了一块更利于用户交互的屏幕，还支持了各种传感器设备，成为了一款真正的智能家庭助手设备。作为一款普惠AI的产品，为了让更多的用户能够体验到人工智能的便利性，智能音箱的硬件配置相对比较低，整体硬件配置与当前市面上的手机相差甚远，对应用软件的运行性能提出了巨大的挑战。除了这些自研产品外，天猫精灵还支持了很多生态硬件产品，如：手表、电视、中控面板等。这些 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 行业的一些理解：
这对我们的技术框架提出了非常高的要求：
经过近两年的尝试，发现在天猫精灵 AIoT 上，APK 和小程序方案并不能很好的满足上述诉求，无法兼顾用户体验和应用生态，且云应用尚无法大规模铺开的情况下，我们从2020.08开始尝试探索一种新的解决方案 —— Waft。
Waft是什么Waft 是一个面向 AIoT 原子化服务的应用开发框架，是一个适合 AIoT 应用开发的解决方案。
取名叫 Waft，其实有两重含义在里面：
Waft的发展历程：
Waft 的设计理念：原子化服务的快速直达和灵活的场景化组合。
化整为零：超级应用的核心内容短平快直达
移动互联网时代，一个个 App 将互联网割裂成信息孤岛，使得用户获取信息和服务的成本越来越高，操作路径越来越长。在天猫精灵智能终端上，我们希望能通过原子化服务的方式来解决这个问题。原子化服务指的是应用中能满足某个特定用户意图的完整功能，比如快递提醒，了解疫情信息，收取蚂蚁森林能量。将核心功能从应用中抽取出来后，通过卡片、浮窗这类轻量交互方式，缩短触达用户的路径，降低用户使用的成本。
化零为整：多来源的服务组合成场景化应用
当深藏在应用中的服务被原子化后，就具备了被重新组合成场景化应用的可能性。以天猫精灵中的语音头条为例，当用户起床后，可以跟精灵说“早上好”，得到天气、交通限行、新闻、音乐等信息服务，早上好就是由天气、出行、新闻、音乐等一系列应用中的原子化服务重组后的场景应用。类似的，还有中午好、晚上好等聚合了多种原子化服务的场景。更进一步的组合，是打通用户上下文信息的组合，一个服务的输出可以作为另一个服务的输入，比如用户预定了杭州到北京的机票这一信息语境，可以被传输到预定酒店的服务中，无需用户再次输入重复的信息，用户购买电影票的信息，可以作为美食餐厅推荐服务的输入，为用户提供更贴心的组合服务。
从开发者的角度看，可以把 waft 容器简单类比成一个轻量级的浏览器，专注于 AIoT 领域，尽可能抛弃历史包袱。
和传统浏览器的差异主要在于：
1）内核的差异：
2）开发方式的差异：
Waft 的设计目标如下：
Waft 是基于 WebAssembly 构建起来的一套应用开发框架：
WebAssembly 是一种体积小且加载快的 二进制格式， 其目标就是充分发挥硬件能力以达到原生执行效率。是一种运行在现代网络浏览器（并不局限于）中的新型代码格式，并且提供新的性能特性和效果。它设计的目的不是为了手写代码，而是为将诸如 AssemblyScript、Kotlin、Swift、C、C++、Rust、Golang 等高级语言编译为一种执行效率更高的中间字节码（可简单类比为 Web 的汇编语言）。我们选择基于 WebAssembly 来搭建 Waft 的整套技术体系，主要原因如下：
终端容器的核心任务是，页面的快速响应和丰富的表现形式，给用户一个非常好的交互体验。
Waft容器的三个核心模块为 Framework、Engine和 Native Services (基础服务)：
说明如下：
在基于 WebAssembly 运行的基础上，为了更好的支持前端开发者生态，我们选用了 AssemblyScript 作为前端框架的逻辑开发语言，它是 TypeScript 的语法变种。在前端框架的设计上，主要包含了3个层面：
在开发者工具上，目前支持了4个部分：
当前市面上的跨端方案也比较多，Waft 与其他方案相比，优势在于同时兼顾了动态化、高性能和跨端一致性；劣势在于因只支持 CSS的子集，页面编写灵活性上不如H5/小程序：
除了这些特点外，Waft还具备一些其他方案少有的特性。
端云协同Waft有一个核心目标是云化：页面跳转逻辑和任务堆栈交由云端管理，终端只做页面渲染和交互的反馈。
借助于天猫精灵云端 DM (Dialog Manager, 对话管理) 服务的能力，Waft应用的跳转逻辑和业务堆栈管理可交由云端管控。终端页面在点击某个跳转按钮时，只需给 DM 传递相应的意图参数，DM 负责分发意图，调用对应的技能服务(应用)，再由技能服务向终端推送新的页面，这里的意图和 Android 的 Intent 的作用非常相似。
借助于猫精的对话流编排平台，可将多个零散的原子化服务(页面)，组合为一个复合场景，在平台上通过可视化编排的方式，构建多个页面间的跳转逻辑。
如下图“早上好场景”的对话流：
端云协同交互流程
得益于 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 图片后推送到终端进行显示。大致思路如下：
上图的补充说明：
注：云端渲染能力，还在预研阶段，待线上业务落地后，我们会再详细展开介绍这部分的实践经验
应用开发方式在应用开发上，我们遵循“前端友好，研发提效”的理念，在框架设计和开发工具建设上提供更完整的解决方案，降低前端和AIoT开发者的开发门槛。所以Waft开发的上手也主要分为两个部分，一个是前端框架的学习使用，包括开发语言、组件库、API等；另一个是开发工具的上手使用，包括源码CLI工具的流程命令以及Devtools的使用；另外，开发者也可以使用我们的低代码搭建平台来快速生产卡片应用。
开发语言前端 UI 框架支持两种DSL，支持类Web的单文件写法，以及阿里系的小程序写法。目前支持的逻辑脚本语言为 AssemblyScript，AS 是专门为 WebAssembly 设计的一种新语言，采用了类似 TypeScript 的变种语法，可以让熟悉 TS 的前端开发者更快地上手。此外，我们也正在支持Kotlin/Swift/Rust/C/C++等其他开发语言。为了让大家对Waft有一个直观了解，在此展示下简单的页面开发代码和运行效果：
Waft-CLI脚手架是辅助开发者源码开发的提效工具，封装了多阶段的不同功能：
调试工具(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
| 欢迎光临 谷动谷力 (http://bbs.sunsili.com/) | Powered by Discuz! X3.2 |