什么是回調函數？

一，回調函數
我們經常在C 設計時通過使用回調函數可以使有些應用（如定時器事件回調處理、用回調函數記錄某操作進度等）變得非常方便和符合邏輯，那么它的內在機制如何呢，怎么定義呢?它和其它函數（比如鉤子函數）有何不同呢？

使用回調函數實際上就是在調用某個函數（通常是API函數）時，將自己的一個函數（這個函數為回調函數）的地址作為參數傳遞給那個函數。

而那個函數在需要的時候，利用傳遞的地址調用回調函數，這時你可以利用這個機會在回調函數中處理消息或完成一定的操作。至于如何定義回調函數，跟具體使用的 API函數有關，一般在幫助中有說明回調函數的參數和返回值等。C 中一般要求在回調函數前加CALLBACK（相當于FAR PASCAL），這主要是說明該函數的調用方式。

至于鉤子函數，只是回調函數的一個特例。習慣上把與SetWindowsHookEx函數一起使用的回調函數稱為鉤子函數。也有人把利用VirtualQueryEx安裝的函數稱為鉤子函數，不過這種叫法不太流行。

也可以這樣，更容易理解：回調函數就好像是一個中斷處理函數，系統在符合你設定的條件時自動調用。為此，你需要做三件事：

1. 聲明；

2. 定義；

3. 設置觸發條件，就是在你的函數中把你的回調函數名稱轉化為地址作為一個參數，以便于系統調用。

聲明和定義時應注意：回調函數由系統調用，所以可以認為它屬于WINDOWS系統，不要把它當作你的某個類的成員函數。


象窗口函數這樣由操作系統調用的函數稱回調函數，一般用戶程序不調用它.


二，回調函數、消息和事件例程


調用(calling)機制從匯編時代起已經大量使用：準備一段現成的代碼，調用者可以隨時跳轉至此段代碼的起始地址，執行完后再返回跳轉時的后續地址。 CPU為此準備了現成的調用指令，調用時可以壓棧保護現場，調用結束后從堆棧中彈出現場地址，以便自動返回。借堆棧保護現場真是一項絕妙的發明，它使調用者和被調者可以互不相識，于是才有了后來的函數和構件。

此調用機制并非完美。回調函數就是一例。函數之類本是為調用者準備的美餐，其烹制者應對食客了如指掌，但實情并非如此。例如，寫一個快速排序函數供他人調 用，其中必包含比較大小。麻煩來了：此時并不知要比較的是何類數據--整數、浮點數、字符串？于是只好為每類數據制作一個不同的排序函數。更通行的辦法是 在函數參數中列一個回調函數地址，并通知調用者：君需自己準備一個比較函數，其中包含兩個指針類參數，函數要比較此二指針所指數據之大小，并由函數返回值 說明比較結果。排序函數借此調用者提供的函數來比較大小，借指針傳遞參數，可以全然不管所比較的數據類型。被調用者回頭調用調用者的函數（夠咬嘴的），故 稱其為回調（callback）。

回調函數使程序結構亂了許多。Windows API 函數集中有不少回調函數，盡管有詳盡說明，仍使初學者一頭霧水。恐怕這也是無奈之舉。 字串1

無論何種事物，能以樹形結構單向描述畢竟讓人舒服些。如果某家族中孫輩又是某祖輩的祖輩，恐怕無人能理清其中的頭緒。但數據處理之復雜往往需要構成網狀結構，非簡單的客戶/服務器關系能窮盡。

Windows 系統還包含著另一種更為廣泛的回調機制，即消息機制。消息本是 Windows 的基本控制手段，乍看與函數調用無關，其實是一種變相的函數調用。發送消息的目的是通知收方運行一段預先準備好的代碼，相當于調用一個函數。消息所附帶的 WParam 和 LParam 相當于函數的參數，只不過比普通參數更通用一些。應用程序可以主動發送消息，更多情況下是坐等 Windows 發送消息。一旦消息進入所屬消息隊列，便檢感興趣的那些，跳轉去執行相應的消息處理代碼。操作系統本是為應用程序服務，由應用程序來調用。而應用程序一旦 啟動，卻要反過來等待操作系統的調用。這分明也是一種回調，或者說是一種廣義回調。其實，應用程序之間也可以形成這種回調。假如進程 B 收到進程 A 發來的消息，啟動了一段代碼，其中又向進程 A 發送消息，這就形成了回調。這種回調比較隱蔽，弄不好會搞成遞歸調用，若缺少終止條件，將會循環不已，直至把程序搞垮。若是故意編寫成此遞歸調用，并設好 終止條件，倒是很有意思。但這種程序結構太隱蔽，除非十分必要，還是不用為好。 字串3

利用消息也可以構成狹義回調。上面所舉排序函數一例，可以把回調函數地址換成窗口 handle。如此，當需要比較數據大小時，不是去調用回調函數，而是借 API 函數 SendMessage 向指定窗口發送消息。收到消息方負責比較數據大小，把比較結果通過消息本身的返回值傳給消息發送方。所實現的功能與回調函數并無不同。當然，此例中改為消 息純屬畫蛇添腳，反倒把程序搞得很慢。但其他情況下并非總是如此，特別是需要異步調用時，發送消息是一種不錯的選擇。假如回調函數中包含文件處理之類的低 速處理，調用方等不得，需要把同步調用改為異步調用，去啟動一個單獨的線程，然后馬上執行后續代碼，其余的事讓線程慢慢去做。一個替代辦法是借 API 函數 PostMessage 發送一個異步消息，然后立即執行后續代碼。這要比自己搞個線程省事許多，而且更安全。

如今我們是活在一個 object 時代。只要與編程有關，無論何事都離不開 object。但 object 并未消除回調，反而把它發揚光大，弄得到處都是，只不過大都以事件（event）的身份出現，鑲嵌在某個結構之中，顯得更正統，更容易被人接受。應用程序 要使用某個構件，總要先弄清構件的屬性、方法和事件，然后給構件屬性賦值，在適當的時候調用適當的構件方法，還要給事件編寫處理例程，以備構件代碼來調 用。何謂事件？它不過是一個指向事件例程的地址，與回調函數地址沒什么區別。 字串4

不過，此種回調方式比傳統回調函數要高明許多。首先，它把讓人不太舒服的回調函數變成一種自然而然的處理例程，使編程者頓覺氣順。再者，地址是一 個危險的東西，用好了可使程序加速，用不好處處是陷阱，程序隨時都會崩潰。現代編程方式總是想法把地址隱藏起來（隱藏比較徹底的如 VB 和 Java），其代價是降低了程序效率。事件例程（？）使編程者無需直接操作地址，但并不會使程序減速。
=================================================
（例程似乎是進程的臺灣翻譯。）


三，精妙比喻:回調函數還真有點像您隨身帶的BP機：告訴別人號碼，在它有事情時Call您。

回調用于層間協作，上層將本層函數安裝在下層，這個函數就是回調，而下層在一定條件下觸發回調，例如作為一個驅動，是一個底層，他在收到一個數據時，除了 完成本層的處理工作外，還將進行回調，將這個數據交給上層應用層來做進一步處理，這在分層的數據通信中很普遍。其實回調和API非常接近，他們的共性都是 跨層調用的函數。但區別是API是低層提供給高層的調用，一般這個函數對高層都是已知的；而回調正好相反，他是高層提供給底層的調用，對于低層他是未知 的，必須由高層進行安裝，這個安裝函數其實就是一個低層提供的API，安裝后低層不知道這個回調的名字，但它通過一個函數指針來保存這個回調，在需要調用 時，只需引用這個函數指針和相關的參數指針。其實：回調就是該函數寫在高層，低層通過一個函數指針保存這個函數，在某個事件的觸發下，低層通過該函數指針 調用高層那個函數。


四
軟件模塊之間總是存在著一定的接口，從調用方式上，可以把他們分為三類：同步調用、回調和異步調用。同步調用是一種阻塞式調用，調用方要等待對方執行完畢 才返回，它是一種單向調用；回調是一種雙向調用模式，也就是說，被調用方在接口被調用時也會調用對方的接口；異步調用是一種類似消息或事件的機制，不過它 的調用方向剛好相反，接口的服務在收到某種訊息或發生某種事件時，會主動通知客戶方（即調用客戶方的接口）。回調和異步調用的關系非常緊密，通常我們使用 回調來實現異步消息的注冊，通過異步調用來實現消息的通知。同步調用是三者當中最簡單的，而回調又常常是異步調用的基礎。 字串6

對于不同類型的語言（如結構化語言和對象語言）、平臺（Win32、JDK）或構架（CORBA、DCOM、WebService），客戶和服務 的交互除了同步方式以外，都需要具備一定的異步通知機制，讓服務方（或接口提供方）在某些情況下能夠主動通知客戶，而回調是實現異步的一個最簡捷的途徑。

對于一般的結構化語言，可以通過回調函數來實現回調。回調函數也是一個函數或過程，不過它是一個由調用方自己實現，供被調用方使用的特殊函數。

在面向對象的語言中，回調則是通過接口或抽象類來實現的，我們把實現這種接口的類成為回調類，回調類的對象成為回調對象。對于象C 或Object Pascal這些兼容了過程特性的對象語言，不僅提供了回調對象、回調方法等特性，也能兼容過程語言的回調函數機制。

Windows平臺的消息機制也可以看作是回調的一種應用，我們通過系統提供的接口注冊消息處理函數（即回調函數），從而實現接收、處理消息的目的。由于Windows平臺的API是用C語言來構建的，我們可以認為它也是回調函數的一個特例。

對于分布式組件代理體系CORBA，異步處理有多種方式，如回調、事件服務、通知服務等。事件服務和通知服務是CORBA用來處理異步消息的標準服務，他們主要負責消息的處理、派發、維護等工作。對一些簡單的異步處理過程，我們可以通過回調機制來實現。

下面我們集中比較具有代表性的語言（C、Object Pascal）和架構（CORBA）來分析回調的實現方式、具體作用等。


2 過程語言中的回調（C）


2.1 函數指針
回調在C語言中是通過函數指針來實現的,通過將回調函數的地址傳給被調函數從而實現回調。因此，要實現回調，必須首先定義函數指針，請看下面的例子：

void Func(char *s)；// 函數原型
void (*pFunc) (char *);//函數指針

可以看出，函數的定義和函數指針的定義非常類似。

一般的化，為了簡化函數指針類型的變量定義，提高程序的可讀性，我們需要把函數指針類型自定義一下。

typedef void(*pcb)(char *);

回調函數可以象普通函數一樣被程序調用，但是只有它被當作參數傳遞給被調函數時才能稱作回調函數。

被調函數的例子：

void GetCallBack(pcb callback)
{
/*do something*/
}
用戶在調用上面的函數時，需要自己實現一個pcb類型的回調函數：
void fCallback(char *s)
{
/* do something */
}
然后，就可以直接把fCallback當作一個變量傳遞給GetCallBack,
GetCallBack（fCallback）;

如果賦了不同的值給該參數，那么調用者將調用不同地址的函數。賦值可以發生在運行時，這樣使你能實現動態綁定。 字串9

2.2 參數傳遞規則
到目前為止，我們只討論了函數指針及回調而沒有去注意ANSI C/C 的編譯器規范。許多編譯器有幾種調用規范。如在Visual C 中，可以在函數類型前加_cdecl，_stdcall或者_pascal來表示其調用規范（默認為_cdecl）。C Builder也支持_fastcall調用規范。調用規范影響編譯器產生的給定函數名，參數傳遞的順序（從右到左或從左到右），堆棧清理責任（調用者或者被調用者）以及參數傳遞機制（堆棧，CPU寄存器等）。

將調用規范看成是函數類型的一部分是很重要的；不能用不兼容的調用規范將地址賦值給函數指針。例如：

// 被調用函數是以int為參數，以int為返回值
__stdcall int callee(int);

// 調用函數以函數指針為參數
void caller( __cdecl int(*ptr)(int));

// 在p中企圖存儲被調用函數地址的非法操作
__cdecl int(*p)(int) = callee; // 出錯

指針p和callee()的類型不兼容，因為它們有不同的調用規范。因此不能將被調用者的地址賦值給指針p，盡管兩者有相同的返回值和參數列

2.3 應用舉例
C語言的標準庫函數中很多地方就采用了回調函數來讓用戶定制處理過程。如常用的快速排序函數、二分搜索函數等。 字串7

快速排序函數原型：

void qsort(void *base, size_t nelem, size_t width, int (_USERENTRY *fcmp)(const void *, const void *));
二分搜索函數原型：
void *bsearch(const void *key, const void *base, size_t nelem,
size_t width, int (_USERENTRY *fcmp)(const void *, const void *));

其中fcmp就是一個回調函數的變量。

下面給出一個具體的例子：


#include <stdio.h>
#include <stdlib.h>

int sort_function( const void *a, const void *b);
int list[5] = { 54, 21, 11, 67, 22 };

int main(void)
{
int x;

qsort((void *)list, 5, sizeof(list[0]), sort_function);
for (x = 0; x < 5; x++)
printf("%i\n", list[x]);
return 0;
}

int sort_function( const void *a, const void *b)
{
return *(int*)a-*(int*)b;
}

2.4 面向對象語言中的回調（Delphi）

Dephi與C++一樣，為了保持與過程語言Pascal的兼容性，它在引入面向對象機制的同時，保留了以前的結構化特性。因此，對回調的實現，也有兩種截然不同的模式，一種是結構化的函數回調模式，一種是面向對象的接口模式。


=====================================================================================

=====================================================================================
Windows程序設計---消息機制
Tag：[ study&work ]

可曾在郵局寄過郵包? 可曾給相好遞過紙條? 都干過?! 太棒了,弟真乃學習Windows程序的不二好胚.請看下圖:(至少我認為是圖)

----------------------------------------------------------------------
| 系統消息隊列 |
----------------------------------------------------------------------
↓ ↓ ↓

------------------ ------------------- ------------------
| 應用程序消息隊列1 | | 應用程序消息隊列2 | | 應用程序消息隊列3|
------------------ ------------------- ------------------
↓↑ ↓↑ ↓↑
-------------------- ---------------------- ---------------------
| 應用程序1 | | 應用程序2 | | 應用程序3 |
| ------------- | | ------------- | | ------------- |
| | WinMain中的 | | | | WinMain中的 | | | | WinMain中的 | |
| | 消息循環 | | | | 消息循環 | | | | 消息循環 | |
| ------------- | | ------------- | | ------------- |
| ↓ ↓ | | ↓ ↓ | | ↓ ↓ |?
| 窗口過程1 窗口過程2| | 窗口過程1 窗口過程2 | | 窗口過程1 窗程2 |?
-------------------- ---------------------- ---------------------

Windows是個搶占式多任務系統.在其上可以運行多個Windows程序,而Windows只有一個系統消息隊列,并為每一個Windows程序維護一個應用程序消息隊列.隊列者,先進先出的一塊內存區.

隊列中的消息如何產生? 事件產生.
何為事件? 某鍵按下、鼠標移動、最大化窗口等等行為皆為事件.

需各位牢記的是:Windows應用程序的運行需要依靠外部發生的事件來驅動.Windows程序所做的一切都是響應發送給窗口過程的消息.不過由于事件 只是個概念化的東西,而由它產生的消息具有實際的使用意義,所以讓我們簡化一下,只談消息不提事件.即某鍵按下的事件就稱為某鍵按下的消息.

消息長的帥嗎? 讓我們去瞅瞅:

typedef struct tagMSG

{

HWND hwnd ; //接受該消息的窗口句柄

UINT message ; //消息的種類

WPARAM wParam ; //與消息種類相關的消息參數

LPARAM lParam ; //同上

DWORD time ; //消息放入消息隊列的時間

POINT pt ; //消息放入隊列時鼠標的位置

}

MSG, * PMSG ;

看出來了嗎? 它象不象個郵包? 不象嗎?

typedef struct tagMSG

{

HWND hwnd ; //該郵包的接受方

UINT message ; //郵包的種類(是書、糕點或其他)

WPARAM wParam ; //書的頁數或糕點的盒數

LPARAM lParam ; //書的其他重要特征或糕點的其他重要特征

DWORD time ; //郵包寄出的時間(即郵戳)

POINT pt ; //消息放入隊列時鼠標的位置

}

MSG, * PMSG ;

需說明的是:WPARAM 和 LPARAM 在 Win16 中是不同的兩個數據類型, 在 Win32 中它們類型一樣,都是32位的int型. 而 POINT 是個結構體類型, like this:

typedef struct tagPOINT
{
int x;
int y;
}
POINT, * PPOINT;

另外: 給相好遞紙條怎么回事? 在這件事上你并沒有通過郵局啊? 是的,你做的很對,如果也通過郵局,相好被人捷足先登拐跑了呢. 所以,就某些希望盡快處理的消息,可以不放入消息隊列直接送到窗口過程去. 這些稱為不進隊消息.

本講的總結:
系統消息隊列 like 中央郵政總局
應用程序消息隊列 like 各地方郵政分局
進隊列的消息 like 郵包
不進隊列的消息 like 快遞

Windows程序就是靠各種各樣遞來傳去的消息(郵包)來保持通信并運行的.

總結

以上是生活随笔為你收集整理的彻彻底底了解回调函数的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。