丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
最真实的开发者用云体验
让每位学生受益于普惠算力
让创作激发创新
资深技术专家手把手带教
遇见技术追梦人
技术交流，直击现场
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
为开发者定制的Chrome浏览器插件
Waft是一个专注于AIoT领域，面向原子化服务的应用开发框架，核心解决的是AIoT领域下用户和服务连接低效的问题。具备高性能、动态化、原子化、跨平台、支持多语言开发等特性：
2019年春季，天猫精灵发布了第一款带屏的智能音箱。相比传统音箱，不仅增加了一块更利于用户交互的屏幕，还支持了各种传感器设备，成为了一款真正的智能家庭助手设备。作为一款普惠AI的产品，为了让更多的用户能够体验到人工智能的便利性，智能音箱的硬件配置相对比较低，整体硬件配置与当前市面上的手机相差甚远，对应用软件的运行性能提出了巨大的挑战。除了这些自研产品外，天猫精灵还支持了很多生态硬件产品，如：手表、电视、中控面板等。这些AIoT设备具有以下特点：
我们一直在思考和探索下面两个问题的解决方案：
我们陆续尝试了多种应用开发方式和框架：
2018年6月，开始引入AndoridAPP的生态。陆续接入了优酷、芒果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是一个面向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和NativeServices(基础服务)：
说明如下：
在基于WebAssembly运行的基础上，为了更好的支持前端开发者生态，我们选用了AssemblyScript作为前端框架的逻辑开发语言，它是TypeScript的语法变种。在前端框架的设计上，主要包含了3个层面：
在开发者工具上，目前支持了4个部分：
当前市面上的跨端方案也比较多，Waft与其他方案相比，优势在于同时兼顾了动态化、高性能和跨端一致性；劣势在于因只支持CSS的子集，页面编写灵活性上不如H5/小程序：
除了这些特点外，Waft还具备一些其他方案少有的特性。
Waft有一个核心目标是云化：页面跳转逻辑和任务堆栈交由云端管理，终端只做页面渲染和交互的反馈。
借助于天猫精灵云端DM(DialogManager,对话管理)服务的能力，Waft应用的跳转逻辑和业务堆栈管理可交由云端管控。终端页面在点击某个跳转按钮时，只需给DM传递相应的意图参数，DM负责分发意图，调用对应的技能服务(应用)，再由技能服务向终端推送新的页面，这里的意图和Android的Intent的作用非常相似。
借助于猫精的对话流编排平台，可将多个零散的原子化服务(页面)，组合为一个复合场景，在平台上通过可视化编排的方式，构建多个页面间的跳转逻辑。
如下图“早上好场景”的对话流：
得益于WebAssembly的技术优势，Waft可实现AOT级别的动态化能力，整体逻辑上跟动态加载运行一个so比较类似，且因为WASM运行在Waft容器的沙箱环境中，相比动态化so更安全可控。
因WebAssembly(简称Wasm)只是一种二进制格式，理论上只要某种语言的工具链支持将源码编译为Wasm格式，就可以在Waft容器中运行。
可将原来在终端上完成的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的调试协议(ChromeDebugProtocol)，通过Chrome浏览器内置的调试工具，提供日志、元素审查、网络请求监控等功能。下图展示了调试器如何与设备进行通信，并获取调试信息的流程：
Waft作为“端云一体化”框架，不仅支持通过源码方式开发复杂的应用，同样支持通过低代码搭建平台，更高效、灵活的开发“轻服务”。轻服务，是连接用户意图与服务之间的直通桥梁，将原本藏在技能、应用的原子化服务释放出来，方便用户在天猫精灵端上直接触达某一个特定的完整功能，而无需提前打开技能、应用。在天猫精灵上创建一个轻服务的流程如下：
下面是低代码开发的演示视频：
Waft已支持多种业务表现形态，可根据设备形态和应用形态灵活使用。
特点：云端编排剧本，将多个页面组合为智能场景，交互逻辑由云端决策，终端做页面展示与用户操作反馈。
适用领域：适用于助手类业务，如：早上好、晚上好、回家/离家模式等。
特点：云端下发数据和模版，终端通过DataBinding实现信息的透出，重展示轻交互。
特点：兼顾核心信息展示与应用导流的作用，并通过声屏联动，在恰当时机内自动关闭轻服务弹窗
适用领域：适用于关键信息查询，且背后都有一个完整应用的领域，如：查快递、查课表等。
特点：不打扰当前页面交互，以简洁的方式和当前页面融合。
可做为Widget，嵌入到任意页面内，以信息流的方式，实现内容透出、分发和引流。
6.6多端适配可针对不同的设备不同场景，做差异化的适配，以提供更好的交互流程，提升用户交互体验。在保证基础交互一致性的基础上，充分利用设备硬件特点和优势。如我们在优酷TV大屏上天气展示：
Waft最核心的目标是高性能，能快速的响应用户的请求。以下是Waft在天猫精灵1G设备上的性能表现，截取其中三个线上业务的监控数据：
下面是猫精版的蚂蚁森林，在1G设备上，Waft和小程序方案的冷启动对比视频：
虽然当前的性能表现还不错，但性能是Waft立足之本，我们会进一步挑战冷启1.5s，热启1s的极致体验。从当前业务性能监控来看，启动耗时的瓶颈在于渲染，因此，渲染引擎的优化将是我们后续重点投入的方向。
提面提到过的原子化服务包含两重含义：
已上线原子化服务有：快递、课表、疫情、股市大盘、蚂蚁能量等，用户可快捷获取这些服务的核心信息。
2）也可以嵌入到其他页面内，提供分发效率。如在天猫精灵的“服务直达“页面内，嵌入了多个Waft的轻服务卡片。
Waft的核心模块都是使用C/C++开发的，可便于做多平台的移植。目前已经在Android端上线，并且在RTOS和Linux平台已跑通DEMO。因Waft是聚焦在AIoT领域，暂不考虑iOS设备：
除了技术框架的跨平台外，对于不同屏幕的UI自适应也是我们的一个重点方向：
得益于WebAssembly的技术优势，借助开源社区的力量，可支持多语言开发。当前已支持AssemblyScript，C/C++/Rust也经过可行性验证。我们还会陆续支持C/C++、Kotlin、Swift、Golang等开发语言。