YodaOS 中是如何生成 API 的

摘要：系统在初始化时，会加载所有，然后分别在和生成对应的。那么在中，又是如何将上述的生成为开发者直接使用的接口的呢下面就为大家介绍我们引入的。它接受一个对象，然后会遍历原型链中的对象，并且分别按照和去生成一个叫的对象，最后将这个对象返回给开发者。

在 Node.js 社区中，其实不乏通过 Markdown 生成 RESTful API 的框架，按照一定的格式约定好 API 所需要的数据，然后再通过解析 Markdown 文档，将这些关键数据提取出来，最后生成数据库模型和 HTTPS 服务。

YodaOS 作为一个前端操作系统，同样使用了类似的技术。YodaOS 中的应用分为：lightapp 和 extapp，前者是集成在语音交互运行时（Vui-daemon）进程内部的轻应用，它主要是用于一个交互简单，需要快速响应的场景，比如音量控制、系统控制等。后者作为一个独立的进程，通过 Child Process 与主进程通讯，使用场景主要是音乐、游戏、电话等需要长时期使用的应用。

为什么要有轻应用？轻应用更像是一个脚本，每当用户一次进行一次交互，只需要从预先加载的脚本中调用定义在对应脚本的函数即可完成一次响应，往往这类应用交互比较简单，如果为此要创建在每次交互的过程中进行一次
ipc 甚至 fork 时，无论对性能还是内存来说，都是比较浪费的。

在设计之初，我们期望对于开发者来说，并不需要针对不同类型的应用，只需要在 package.json 中修改类型即可，YodaOS API 应当保持完全一致。这样的话，我们则面对一个问题，即使是能做到高度抽象，也需要在每次新增一个接口时，修改两处代码，这其实是有违我们的设计初衷的。

**

**

为此，我们引入了 API Descriptor 的概念：https://github.com/yodaos-pro...。可以把它看作是用 JavaScript 写的 DSL，它用于描述每个 YodaOS API，包括命名空间、事件、方法等定义。系统在初始化时，会加载所有 API Descriptor，然后分别在 lightapp 和 extapp 生成对应的 API。

Object.assign(ActivityDescriptor.prototype,
{

/**
 * When the app is active.
 * @event yodaRT.activity.Activity#active
 */
active: {
  type: "event"
},
/**
 * When the Activity API is ready.
 * @event yodaRT.activity.Activity#ready
 */
ready: {
  type: "event"
},
/**
 * When an activity is created.
 * @event yodaRT.activity.Activity#create
 */
created: {
  type: "event"
}

}
)
上面的代码分别定义了 Activity 中的几个事件：active、ready 和 create。因此，在任何应用中都可以这样写：

module.exports = activity => {
activity.on("active", () => console.log("app activated"))
activity.on("ready", () => console.log("app is ready"))
activity.on("created", () => console.log("app is created"))
}
接下来我们再看看“方法”是如何定义：

Object.assign(ActivityDescriptor.prototype,
{

/**
 * Get all properties, it contains the following fields:
 * - `deviceId` the device id.
 * - `deviceTypeId` the device type id.
 * - `key` the cloud key.
 * - `secret` the cloud secret.
 * - `masterId` the userId or masterId.
 *
 * @memberof yodaRT.activity.Activity
 * @instance
 * @function get
 * @returns {Promise