這一篇來聊一聊如何開發基于QP的應用程序，他可能和我們平時開發的應用程序所遵循的規則不太一樣，其實規則一詞有點別扭，不如說是套路，每個人開發軟件都有自己的套路，每個套路都是你站在問題需求的一個角度上理解以后，產生的策略，問題需求的角度不同，你能產生的策略就不一樣，不要站在一個套路的高度，嘗試著把軟件融入到另一種套路中，一切重新從需求出發，問題會變得更簡單。

      QP這本書提了兩點要求我們必須遵守的準則，并且用了很大的篇幅去說服你一定要遵守這兩條準則：

      準則一、活動對象之間僅應該通過異步事件交換來相互作用，不應該共享內存或者其它資源。（通俗舉例：取消全局變量）

      準則二、活動對象不應該被阻塞或者在RTC處理中間忙等待事件。（通俗來講：不太好講，大概是活動對象內部處理代碼不要有死等或者被掛起的操作）

      知道這兩條規則，你依舊是寫不好QP的應用，就像是懂得了很多大道理卻依舊過不好這一生（扯遠了），規則的目的，不是讓你僅僅停留在理解的階段，而是要在今后的實戰應用中，不斷地實踐，不斷的進階，才會獲得更好的理解（莫要怕犯錯，不犯錯你就永遠無法掌握它）。

      這兩條規則都在圍繞著一個核心的主題來，也就是【活動對象】，他爹就是【狀態機】，時代變了，很難靠狀態機來打天下了，必須要披上一層QF的糖衣，這樣生意就好做多了，QF提供了事件隊列，內存池等等一系列的基礎設施給狀態機使用，同樣，用上了這些高端貨的狀態機，已經不能叫做狀態機了，于是，他有了另一個喜人的名字【活動對象】。

      一個基于QP的應用程序，實際上是被分割成了多個【活動對象】，每個活動對象都為系統管理一部分【資源】，資源這個詞很有意思，看到管理資源，第一時間可能想到的是管理內存，其實在活動對象看來，不光是一片內存叫資源，兩個IO引腳，一個LED燈都可以叫做是資源，如何實現應用，其實就是靠管理這些資源協調運作，從而實現應用的功能。

      又扯遠了，【活動對象】的本職就是管理資源，他們高度的自治，就是我管的事情別人不可以插手，那么如何協調工作呢，那就需要一個叫做【事件】的郵件，你想改變某個資源，對不起，發郵件告訴我。什么？你很急？哦，那你趕緊寫郵件啊（大家必須遵守規則，不然又回到了全局變量滿地找的解放前）~！

      整個應用程序功能可以很復雜，有可能很多活最終都分配給某個【活動對象】，其它的【活動對象】就很閑，是不是會讓你想起ARM打天下的場景，嘿嘿~！這就要看作者的創作水平了，這個叫【某個】的【活動對象】變得很忙，其他人都在聊天打屁，還時不時給他發郵件，讓他干這干那，他倒是任勞任怨，但是好多郵件到家門口的時候，他可能在忙，于是郵遞員【QF】把郵件放到他家門口，敲門就走了，這貨現在忙得跟孫子似的，根本沒時間開門接郵件，結果一陣大風刮過，他開門的時候啥也沒了。整個應用到這里就凌亂了。

      為了解決這個問題，于是乎，QF就給每個【活動對象】在他們家門口都按了一個箱子，叫郵箱（這個郵箱是真實生活中的郵箱，可不是操作系統概念中的郵箱）【事件隊列】，于是乎，這個問題仿佛得到了一部分解決，快遞員每次來的時候，就把郵件放到你的郵箱里，然后敲門離開，當然也會遇到一種特殊情況，郵件太多，實在放不下了（一個合適大小的事件隊列有多重要，只能等你實戰的時候體會了），這時候，快遞小哥只能把郵件放在門口，敲門離開，繼續送信，小心大風~！

      針對這個寫的郵件【事件】，還有一個重要的方面沒講，也就是【活動對象】能處理的郵件的要求是受限，你不能寫個郵件【事件】，內容是幫我造一顆原子彈，這時候【活動對象】可能懶得理你，也可能和警察【QF】報告抓你，為了防止惡作劇的存在，于是大家規定了一整套的【事件】類型的定義，叫做【信號】，通過枚舉來完成，確保大家都不同。

      到這里已經引出了本篇的所有主題，你要開發QP應用程序，就必須將他分解成多個【活動對象】，并用【事件】機制將他們串起來，這個復雜的機制又引入了【信號】、【事件隊列】等等內容。

      于是總結一下：

      QP應用程序 = 多個【活動對象】+【信號】+【事件】+【事件隊列】；

     【活動對象】是可以展開的，展開就是狀態機，如何基于狀態機開發應用程序的專題我寫了，所以這里就不展開了。

      下一篇，教你如何分解成活動對象，基于一個官方的實例，從問題需求，到順序圖，到活動對象一條龍。再見~！