基于狀態(tài)機進行實際應用的時候，會感覺有些力不從心，因為一個應用通常會被分解為多個狀態(tài)機。這些狀態(tài)機之間如何完成協(xié)作的，如何完成通信，優(yōu)先級排列，事件派發(fā)，隊列存儲等等，這些需求在狀態(tài)機中并沒有做支持，QF的存在就對這一情況做了很好的補充。并引入了對象計算模式，抽象出了活動對象：一個對象擁有自己的控制線程，稱為活動對象。

      在多任務操作系統(tǒng)當中，每個活動對象都是保持自治的，擁有自己的控制線程（事件循環(huán)） 、事件隊列 、狀態(tài)機。也可以這樣理解，在多任務操作環(huán)境里，使用多個事件驅動型操作系統(tǒng)（簡單理解：一個活動對象可以當做一個單獨的事件驅動型系統(tǒng)）。

      活動對象在源碼中的定義，如下：

       針對控制線程還想再多說一些，并不是所有的活動對象都需要自帶控制線程，當僅適用qf框架服務時，一個名為QV的合作式內核來解決所有的活動對象的控制線程的問題，因為大家的操作都是一樣的，獲取事件、分發(fā)事件、處理事件（所以它被從活動對象中抽了出來了）下圖是簡化版的活動對象的系統(tǒng)及事件循環(huán)：

      以活動對象為核心的應用程序開發(fā)，活動對象其服務的提供，可能來源于兩部分，QF框架和RTOS系統(tǒng)。從另一個角度我們來看一下，應用，QF框架，RTOS系統(tǒng)之間的關系，如圖：

      從圖中可以看到他們的關系，有一點還想要說一下，QF框架的本質是提供服務的，他的下面可以有RTOS也可以沒有，那么問題就來了，如果底層是RTOS，那么QF可以借用他的一些服務，例如消息隊列，例如內存管理等。假如QF的下面就是裸機。那么關于他需要的資源就需要他自己實現(xiàn)了，例如一顆合作式的內核QV就可能被集成到QF上，關于QV合作式內核后面單獨聊吧。

      活動對象在應用過程中，你需要理解他最核心的三個設定：

      1. 異步通訊，活動對象擁有自己的事件隊列，并且通過從事件隊列中獲取事件，所以事件都是被異步投遞的，站在事件生產者的角度，異步通訊就意味著，他只負責生產一個事件，并將其發(fā)送給相應的活動對象，并不原地等待事件的處理。

      2. RTC————運行到完成，也就是運行到完成的過程中不被打斷，這么說還是比較模糊的，正確的理解應該是，狀態(tài)機在處理一個事件的過程中，不會去接收和處理其它事件，只有等這個事件處理完了，才可以去處理其它事件。這個過程是不會被打斷的。

      3. 封裝，這個可能是活動對象最重要的概念，其實應該是面向對象的概念，封裝意味著不共享數據和其它任意資源。

      接下來進入實戰(zhàn)部分，這一部分不要看源碼了，源碼太精彩了，后面單獨拉出來給大家分析分析，原來C語言可以這么玩，基于QP6.9.1開發(fā)者文檔中中找到關于活動對象相關的API函數，并分析一下其函數功能、參數、及返回值：

      關于如何創(chuàng)建一個活動對象并啟動對應的活動對象步驟，如下：

      1. 定義具體的活動對象類型（類比于定義結構體類型），如下：

      2.有了類型以后，實例化活動對象（類似于創(chuàng)建變量），如下：

      3.構造活動對象（類比于變量初始化），如下：

      4.啟動活動對象（類比喻執(zhí)行Table_intial函數），如下：

    5.停止活動對象相關操作并沒有顯示的調用，表明這個應用不需要停止活動對象。