事件驅動
基本概念
-
窗口/組件
-
事件
-
消息(隊列)
-
事件響應(服務處理程序)
-
調度算法
-
進程/線程
-
非阻塞I/O
-
程序的執行可以看成對CPU,內存,IO資源一次佔用
-
現代操作系統支持多任務,可以分時複用上述資源.
1. 爲什麼採用事件驅動模型?
事件驅動模型也就是我們常說的觀察者，或者發佈-訂閱模型；理解它的幾個關鍵點：
-
首先是一種對象間的一對多的關係；最簡單的如交通信號燈，信號燈是目標（一方），行人注視着信號燈（多方）；
-
當目標發送改變（發佈），觀察者（訂閱者）就可以接收到改變；
-
觀察者如何處理（如行人如何走，是快走/慢走/不走，目標不會管的），目標無需干涉；所以就鬆散耦合了它們之間的關係。
2. 代碼執行流程
在傳統的或“過程化”的應用程序中，應用程序自身控制了執行哪一部分代碼和按何種順序執行代碼。從第一行代碼執行程序並按應用程序中預定的路徑執行，必要時調用過程。
在事件驅動的應用程序中，代碼不是按照預定的路徑執行－而是在響應不同的事件時執行不同的代碼片段。事件可以由用戶操作觸發、也可以由來自操作系統或其它應用程序調度算法的消息觸發、甚至由應用程序本身的消息觸發。這些事件的順序決定了代碼執行的順序，因此應用程序每次運行時所經過的代碼的路徑都是不同的。
3. 事件驅動模型
在UI編程中，常常要對鼠標點擊進行相應，首先如何獲得鼠標點擊呢？
方式一：創建一個線程，該線程一直循環檢測是否有鼠標點擊，那麼這個方式有以下幾個缺點：
- CPU資源浪費，可能鼠標點擊的頻率非常小，但是掃描線程還是會一直循環檢測，這會造成很多的CPU資源浪費；如果掃描鼠標點擊的接口是阻塞的呢？
- 如果是堵塞的，又會出現下面這樣的問題，如果我們不但要掃描鼠標點擊，還要掃描鍵盤是否按下，由於掃描鼠標時被堵塞了，那麼可能永遠不會去掃描鍵盤；
- 如果一個循環需要掃描的設備非常多，這又會引來響應時間的問題；所以，該方式是非常不好的。
方式二：就是事件驅動模型目前大部分的UI編程都是事件驅動模型，如很多UI平臺都會提供onClick()事件，這個事件就代表鼠標按下事件。事件驅動模型大體思路如下：
-
有一個事件（消息）隊列；
-
鼠標按下時，往這個隊列中增加一個點擊事件（消息）；
-
有個循環，不斷從隊列取出事件，根據不同的事件，調用不同的函數，如onClick()、onKeyDown()等；
-
事件（消息）一般都各自保存各自的處理函數指針，這樣，每個消息都有獨立的處理函數；如圖:
4. 事件驅動處理庫
-
select
-
poll
-
epoll
-
libev
5.效率比較
讓我們用例子來比較和對比一下單線程、多線程以及事件驅動編程模型。下圖展示了隨着時間的推移，這三種模式下程序所做的工作。這個程序有3個任務需要完成，每個任務都在等待I/O操作時阻塞自身。阻塞在I/O操作上所花費的時間已經用灰色框標示出來了。
在單線程同步模型中，任務按照順序執行。如果某個任務因爲I/O而阻塞，其他所有的任務都必須等待，直到它完成之後它們才能依次執行。這種明確的執行順序和串行化處理的行爲是很容易推斷得出的。如果任務之間並沒有互相依賴的關係，但仍然需要互相等待的話這就使得程序不必要的降低了運行速度。
在多線程版本中，這3個任務分別在獨立的線程中執行。這些線程由操作系統來管理，在多處理器系統上可以並行處理，或者在單處理器系統上交錯執行。這使得當某個線程阻塞在某個資源的同時其他線程得以繼續執行。與完成類似功能的同步程序相比，這種方式更有效率，但程序員必須寫代碼來保護共享資源，防止其被多個線程同時訪問。多線程程序更加難以推斷，因爲這類程序不得不通過線程同步機制如鎖、可重入函數、線程局部存儲或者其他機制來處理線程安全問題，如果實現不當就會導致出現微妙且令人痛不欲生的bug。
在事件驅動版本的程序中，3個任務交錯執行，但仍然在一個單獨的線程控制中。當處理I/O或者其他昂貴的操作時，註冊一個回調到事件循環中，然後當I/O操作完成時繼續執行。回調描述了該如何處理某個事件。事件循環輪詢所有的事件，當事件到來時將它們分配給等待處理事件的回調函數。這種方式讓程序儘可能的得以執行而不需要用到額外的線程。事件驅動型程序比多線程程序更容易推斷出行爲，因爲程序員不需要關心線程安全問題。
當我們面對如下的環境時，事件驅動模型通常是一個好的選擇：
程序中有許多任務，而且…
任務之間高度獨立（因此它們不需要互相通信，或者等待彼此）而且…
在等待事件到來時，某些任務會阻塞。
當應用程序需要在任務間共享可變的數據時，這也是一個不錯的選擇，因爲這裏不需要採用同步處理。
網絡應用程序通常都有上述這些特點，這使得它們能夠很好的契合事件驅動編程模型。
事件驅動機制跟消息驅動機制相比
消息驅動和事件驅動很類似，都是先有一個事件，然後產生一個相應的消息，再把消息放入消息隊列，由需要的項目獲取。他們的區別是消息是誰產生的
消息驅動：鼠標管自己點擊不需要和系統有過多的交互，消息由系統（第三方）循環檢測，來捕獲並放入消息隊列。消息對於點擊事件來說是被動產生的，高內聚。
事件驅動：鼠標點擊產生點擊事件後要向系統發送消息“我點擊了”的消息，消息是主動產生的。再發送到消息隊列中。
事件：按下鼠標，按下鍵盤，按下游戲手柄，將U盤插入USB接口，都將產生事件。比如說按下鼠標左鍵，將產生鼠標左鍵被按下的事件。
消息：當鼠標被按下，產生了鼠標按下事件，windows偵測到這一事件的發生，隨即發出鼠標被按下的消息到消息隊列中，這消息附帶了一系列相關的事件信息，比如鼠標哪個鍵被按了，在哪個窗口被按的，按下點的座標是多少？如此等等。
注意：
- 要理解事件驅動和程序，就需要與非事件驅動的程序進行比較。實際上，現代的程序大多是事件驅動的，比如多線程的程序，肯定是事件驅動的。早期則存在許多非事件驅動的程序，這樣的程序，在需要等待某個條件觸發時，會不斷地檢查這個條件，直到條件滿足，這是很浪費cpu時間的。而事件驅動的程序，則有機會釋放cpu從而進入睡眠態（注意是有機會，當然程序也可自行決定不釋放cpu），當事件觸發時被操作系統喚醒，這樣就能更加有效地使用cpu.
- 再說什麼是事件驅動的程序。一個典型的事件驅動的程序，就是一個死循環，並以一個線程的形式存在，這個死循環包括兩個部分，第一個部分是按照一定的條件接收並選擇一個要處理的事件，第二個部分就是事件的處理過程。程序的執行過程就是選擇事件和處理事件，而當沒有任何事件觸發時，程序會因查詢事件隊列失敗而進入睡眠狀態，從而釋放cpu。
- 事件驅動的程序，必定會直接或者間接擁有一個事件隊列，用於存儲未能及時處理的事件。
- 事件驅動的程序的行爲，完全受外部輸入的事件控制，所以，事件驅動的系統中，存在大量這種程序，並以事件作爲主要的通信方式。
- 事件驅動的程序，還有一個最大的好處，就是可以按照一定的順序處理隊列中的事件，而這個順序則是由事件的觸發順序決定的，這一特性往往被用於保證某些過程的原子化。
- 目前windows,linux,nucleus,vxworks都是事件驅動的，只有一些單片機可能是非事件驅動的。
事件模式耦合高，同模塊內好用；消息模式耦合低，跨模塊好用。事件模式集成其它語言比較繁瑣，消息模式集成其他語言比較輕鬆。事件是侵入式設計，霸佔你的主循環；消息是非侵入式設計，將主循環該怎樣設計的自由留給用戶。如果你在設計一個東西舉棋不定，那麼你可以參考win32的GetMessage，本身就是一個藕合度極低的接口，又足夠自由，接口任何語言都很方便，具體應用場景再在其基礎上封裝成事件並不是難事，接口耦合較低，即便哪天事件框架調整，修改外層即可，不會傷經動骨。而如果直接實現成事件，那就完全反過來了。
什麼是數據驅動編程
正題
作者在介紹Unix設計原則時，其中有一條爲“表示原則：把知識疊入數據以求邏輯質樸而健壯”。結合之前自己的一些經驗，我對這個原則很有共鳴，所以先學習了數據驅動編程相關的內容，這裏和大家分享出來和大家一起討論。
核心
數據驅動編程的核心出發點是相對於程序邏輯，人類更擅長於處理數據。數據比程序邏輯更容易駕馭，所以我們應該儘可能的將設計的複雜度從程序代碼轉移至數據。
真的是這樣嗎？讓我們來看一個示例。假設有一個程序，需要處理其他程序發送的消息，消息類型是字符串，每個消息都需要一個函數進行處理。第一印象，我們可能會這樣處理：
void msg_proc(const char *msg_type, const char *msg_buf)
{
if (0 == strcmp(msg_type, "inivite"))
{
inivite_fun(msg_buf);
}
else if (0 == strcmp(msg_type, "tring_100"))
{
tring_fun(msg_buf);
}
else if (0 == strcmp(msg_type, "ring_180"))
{
ring_180_fun(msg_buf);
}
else if (0 == strcmp(msg_type, "ring_181"))
{
ring_181_fun(msg_buf);
}
else if (0 == strcmp(msg_type, "ring_182"))
{
ring_182_fun(msg_buf);
}
else if (0 == strcmp(msg_type, "ring_183"))
{
ring_183_fun(msg_buf);
}
else if (0 == strcmp(msg_type, "ok_200"))
{
ok_200_fun(msg_buf);
}
。。。。。。
else if (0 == strcmp(msg_type, "fail_486"))
{
fail_486_fun(msg_buf);
}
else
{
log("未識別的消息類型%s\n", msg_type);
}
}
上面的消息類型取自sip協議（不完全相同，sip協議借鑑了http協議），消息類型可能還會增加。看着常常的流程可能有點累，檢測一下中間某個消息有沒有處理也比較費勁，而且，沒增加一個消息，就要增加一個流程分支。
按照數據驅動編程的思路，可能會這樣設計：
typedef void (*SIP_MSG_FUN)(const char *); typedef struct __msg_fun_st { const char *msg_type;//消息類型 SIP_MSG_FUN fun_ptr;//函數指針 }msg_fun_st; msg_fun_st msg_flow[] = { {"inivite", inivite_fun}, {"tring_100", tring_fun}, {"ring_180", ring_180_fun}, {"ring_181", ring_181_fun}, {"ring_182", ring_182_fun}, {"ring_183", ring_183_fun}, {"ok_200", ok_200_fun}, 。。。。。。 {"fail_486", fail_486_fun} }; void msg_proc(const char *msg_type, const char *msg_buf) { int type_num = sizeof(msg_flow) / sizeof(msg_fun_st); int i = 0; for (i = 0; i < type_num; i++) { if (0 == strcmp(msg_flow[i].msg_type, msg_type)) { msg_flow[i].fun_ptr(msg_buf); return ; } } log("未識別的消息類型%s\n", msg_type); }
數據驅動優勢
1、可讀性更強，消息處理流程一目瞭然。
2、更容易修改，要增加新的消息，只要修改數據即可，不需要修改流程。
3、重用，第一種方案的很多的else if其實只是消息類型和處理函數不同，但是邏輯是一樣的。下面的這種方案就是將這種相同的邏輯提取出來，而把容易發生變化的部分提到外面。
隱含在背後的思想：
很多設計思路背後的原理其實都是相通的，隱含在數據驅動編程背後的實現思想包括：
1、控制複雜度。通過把程序邏輯的複雜度轉移到人類更容易處理的數據中來，從而達到控制複雜度的目標。
2、隔離變化。像上面的例子，每個消息處理的邏輯是不變的，但是消息可能是變化的，那就把容易變化的消息和不容易變化的邏輯分離。
3、機制和策略的分離。和第二點很像，本書中很多地方提到了機制和策略。上例中，我的理解，機制就是消息的處理邏輯，策略就是不同的消息處理（後面想專門寫一篇文章介紹下機制和策略）。
數據驅動可以用來做什麼：
如上例所示，它可以應用在函數級的設計中。
同時，它也可以應用在程序級的設計中，典型的比如用表驅動法實現一個狀態機（後面寫篇文章專門介紹）。
也可以用在系統級的設計中，比如DSL（這方面我經驗有些欠缺，目前不是非常確定）。
它不是什麼：
1、 它不是一個全新的編程模型：它只是一種設計思路，而且歷史悠久，在unix/linux社區應用很多；
2、它不同於面向對象設計中的數據：“數據驅動編程中，數據不但表示了某個對象的狀態，實際上還定義了程序的流程；OO看重的是封裝，而數據驅動編程看重的是編寫儘可能少的代碼。”
書中的值得思考的話：
數據壓倒一切。如果選擇了正確的數據結構並把一切組織的井井有條，正確的算法就不言自明。編程的核心是數據結構，而不是算法。——Rob Pike
程序員束手無策。。。。。只有跳脫代碼，直起腰，仔細思考數據纔是最好的行動。表達式編程的精髓。——Fred Brooks
數據比程序邏輯更易駕馭。儘可能把設計的複雜度從代碼轉移至數據是個好實踐。——《unix編程藝術》作者。
轉載自：學時網 » 事件驅動編程、消息驅動編程、數據驅動編程