摘要：系統在初始化時，會加載所有，然后分別在和生成對應的。那么在中，又是如何將上述的生成為開發者直接使用的接口的呢下面就為大家介紹我們引入的。它接受一個對象，然后會遍歷原型鏈中的對象，并且分別按照和去生成一個叫的對象，最后將這個對象返回給開發者。

在 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