Callback與Delegate原理，當沒有經驗時純看其定義， 是件很難弄清楚的運作名詞 我在讀.Net的delegate那章，完全被搞混了... 後來，學習c++的多執行緒程式，觀察到許多現象， 利用這樣的觀點再回來看高階的event或delegate原理 不知不覺就有點通了... 程設裏，要電腦等一段時間觸發某件事， 可以用timer這樣的元件來等待， 否則就得手工用: 代碼: while (true) { if (isWaked) break; sleep(1000); } 由於無限loop會強佔cpu，因此等待時間必須由另一執行緒來進行pooling timer的等待，其實也是用上述的原因在另一執行緒作waiting， 但它常常會讓user有個誤解，其實timer內的事件是一個獨立執行緒 其實不然，它只是在等待時是如此，但時間到， 它就會消失，並回歸主執行緒。 所以當兩個timer在同一個form時，你就能感覺到它們互相在搶資源。 程式設計師大部分很討厭看到無限loop的式子 但在陽春的c++程式裏，卻常常發現只能這樣做。 即使把它搬到另一執行緒去執行，心裏也會覺得很打擾cpu 因為它每一次每一秒都在詢問cpu，到底好了沒?! 當有n個程序需要作等待，就會打擾cpu * n倍， 雖然cpu很強，但做人的道理告訴我們，這樣的方式不是很好。 因此就衍生了Callback的原理，呼叫且執行一個函數稱為call， 若該函數在某個時間點(如執行完畢)自動回歸主執行緒，就稱為callback 它是運作於另一獨立執行緒去作等待的動作。 例如，timer所設定的時間一到，它就產生callback 最後才執行其事件內容。 在.Net裏，很多擁有callback功能的函數都以Beginxxx()或Endxxx()為名 它以另一執行緒去執行工作，完畢時進行callback通知。 然而，我們怎麼去接收callback的通知呢? 就是利用delegate(代理)事先宣告好callback後所要進行的事， 就是所謂的event(事件)。 當BeginXXX()獨立執行緒完成工作後，由於已宣告好delegate及event 因此該執行緒就會將windows message轉送給delegate， 讓delegate知道callback產生了，然後進行event內定義的工作內容。 請注意，event並不是另一獨立執行緒，它只是一個callback的處理而己 它有其順序性，意思是說，當同時很多callback進來， event是一個接著一個去執行，而不是同步在執行。 而delegate(代理)又是什麼呢? 其實它只是一個物件裏專門等待callback通知的無限while loop， 只要事先用它去宣告事件(event)， 它就會幫你監看所指定的callback產生否?! 在以往，打擾cpu = n程序*詢問時間間隔 利用delegate作整合，一個物件其下不管有多少個Event數量， 打擾cpu = 1* 詢問時間間隔。 除此之外，delegate幫你協調相關的獨立執行緒來接收callback訊號 它是一個介面，你完全不用管其細節， 最終，你只要對它所宣告的event作動作即可。 整理一下，使用delegate比陽春的無限while loop的好處在於: 1.它是callback的總管，不必一一管理每個while loop的執行緒pooling。 2.可產生n個事件，但打擾cpu次數(pooling)卻不用成正比增加。 3.直覺使用event內容，而不必理會time waiting這些監看細節。 然而不管怎樣包裝演進，系統內部裏一定有一個執行while loop在作等待 一直滾一直轉，一直迴圈著.... 然而面對這樣單調的頻繁等待工作，卻不用為這loop可憐， 因為每個執行緒都配有各自的thread time-slice， 這個while loop雖然看起來「永世不能超生」地迴轉著 但比起其他執行緒還得作內容變數的暫存、執行煩重工作而言 顯然是件坐領乾薪的輕鬆工作... 假如你不幸得土法煉鋼地使用while loop來計時等待， 記得裏頭要放一個sleep(n)或sleep(0)函式 讓cpu能夠休息或直接略過去，如此該loop才不會強佔住cpu時間。 -- 貫徹分享精神 我為人人，人人為我 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.119.52.211 ※ 編輯: tomex 來自: 140.119.52.211 (11/20 03:26)