Hasor Start階段

• doStart ：執(zhí)行 start 階段的起始標志。
• ContextEvent_Started ：通過事件機制發(fā)送 AppContext#ContextEvent_Started 事件。
• doStartCompleted ：執(zhí)行 start 階段的終止標志。

如一開始在 0. 生命周期 小結(jié)中所介紹，Start 階段一共有三個擴展點（0.生命周期：圖右側(cè)）它們分別是 ContextStartListener 接口的 doStart、doStartCompleted 方法，以及 LifeModule 接口的 onStart 方法。

A. 意義

下面這張圖為我們展現(xiàn)了這三個節(jié)點對我們的重要意義。

對于框架而言，加載 LifeModule 的先后順序沒有多大重要性，但是對于開發(fā)者而言可能有著很重要的意義，例如：先初始化數(shù)據(jù)庫連接，在創(chuàng)建測試數(shù)據(jù)。我們知道通常在同一個應(yīng)用中，創(chuàng)建數(shù)據(jù)庫連接的 Module 和 創(chuàng)建測試數(shù)據(jù)的 Module 它們的加載順序我們是可以控制的。但是當引入一個基于 Hasor Module 的第三方組件時。我們就無法保證 Module 的加載順序，因為框架不會對它們進行排序的，同時開發(fā)者也無法進行控制。

這時候 ContextStartListener 接口的兩個方法就會為我們提供一些幫助。這一組方法執(zhí)行的時機相當于給所有 LifeModule 在執(zhí)行它們的 onStart 方法前后加了一個大的全局攔截器。

B. 什么時候使用 ContextStartListener？

嚴格意義上說，ContextStartListener 的設(shè)計初衷并不是給業(yè)務(wù)系統(tǒng)準備的。但當您被此類問題困擾時候，可以嘗試使用這個接口來解決問題。當然這個接口也不是萬能的，它也有一些限制。

• 第一個限制：ContextStartListener，即便可以在所有 LifeModule 執(zhí)行 onStart 之前執(zhí)行，但是它依然無法控制 LifeModule 具體的執(zhí)行順序。
• 第二個限制：ContextStartListener，無法知道哪些 LifeModule 被加載。同樣的 ContextShutdownListener 也無法知道哪些 LifeModule 沒有成功執(zhí)行 onStop。