2. 程式人生 > >wxWidgets源碼分析(4) - 消息處理過程

wxWidgets源碼分析(4) - 消息處理過程

阿新 • • 發佈：2018-10-14
處理過程 HERE toe 處理流程 als upm 接收 entry false

目錄

  • 消息處理過程
    • 消息如何到達wxWidgets
    • Win32消息與wxWidgets消息的轉換
    • 菜單消息處理
    • 消息處理鏈（基於wxEvtHandler）
    • 消息處理鏈（基於wxWindow）
    • 總結

消息處理過程

消息如何到達wxWidgets

Windows程序有其自身運行的一套規律，::SendMessage是MS提供的windows消息發送接口，用戶調用這個接口後會進入到MS系統庫程序，此接口指定了目標HWND和消息參數，Windows系統內部會查找指定HWND，然後通過gapfnScSendMessage接口調用用戶的消息處理函數。
所以我們每次看到消息處理函數都是通過gapfnScSendMessage

調用進入的。

Win32消息與wxWidgets消息的轉換

wxWidgets註冊窗口時同時指定了窗口處理函數wxWndProc，當收到消息後系統會調用此函數來處理消息。

處理過程如下：

  1. 調用wxFindWinFromHandle根據當前消息指定的HWND來查找對應的wxWindow，如果沒有則需要與最近創建的一個窗口關聯起來。
  2. 接著調用窗口的MSWWindowProc方法來進行消息處理。
// Main window proc
LRESULT WXDLLEXPORT APIENTRY _EXPORT wxWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    wxWindowMSW *wnd = wxFindWinFromHandle(hWnd);

    // 關聯窗口
    if ( !wnd && gs_winBeingCreated )
    {
        wxAssociateWinWithHandle(hWnd, gs_winBeingCreated);
        wnd = gs_winBeingCreated;
        gs_winBeingCreated = NULL;
        wnd->SetHWND((WXHWND)hWnd);
    }

    LRESULT rc;
    if ( wnd && wxGUIEventLoop::AllowProcessing(wnd) )
        rc = wnd->MSWWindowProc(message, wParam, lParam);
    else
        rc = ::DefWindowProc(hWnd, message, wParam, lParam);
    return rc;
}

MSWWindowProc是在windows平臺下特有的虛函數，對於Frame類來說就是wxFrame::MSWWindowProc，消息根據Message類型來執行不同的函數：

  1. WM_CLOSE: 退出操作，直接調用wxFrame::Close;
  2. WM_SIZE: 調用wxFrame::HandleSize;
  3. WM_COMMAND: 需要特殊處理，註釋中寫的很清楚，wxWidgets提供了一套自己的機制來進行父窗口和子窗口之間的消息調用，所以就不要再使用Win32提供的功能了。
  4. 如果自己沒有處理，則給父類wxFrameBase::MSWWindowProc處理；
WXLRESULT wxFrame::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam)
{
    WXLRESULT rc = 0;
    bool processed = false;
    
    switch ( message )
    {
        case WM_CLOSE:
            processed = !Close();
            break;
        case WM_SIZE:
            processed = HandleSize(LOWORD(lParam), HIWORD(lParam), wParam);
            break;
        case WM_COMMAND:
            {
                WORD id, cmd;
                WXHWND hwnd;
                UnpackCommand((WXWPARAM)wParam, (WXLPARAM)lParam,
                              &id, &hwnd, &cmd);
                HandleCommand(id, cmd, (WXHWND)hwnd);
                processed = true;
            }
            break;
    }

    if ( !processed )
        rc = wxFrameBase::MSWWindowProc(message, wParam, lParam);

    return rc;
}

拿wxFrame::Close函數舉例，wxFrame直接使用父類的方法wxWindowBase::Close，內容就是構造wxWidgets的消息類型，然後調用HandleWindowEvent方法進行消息處理。

bool wxWindowBase::Close(bool force)
{
    wxCloseEvent event(wxEVT_CLOSE_WINDOW, m_windowId);
    event.SetEventObject(this);
    event.SetCanVeto(!force);

    // return false if window wasn‘t closed because the application vetoed the
    // close event
    return HandleWindowEvent(event) && !event.GetVeto();
}

對於WM_SIZE，走的路要多一些，調用關系如下，最終由wxWindowMSW::HandleSize處理，這裏會產生wxSizeEvent消息，隨後將消息遞交給HandleWindowEvent處理：

wxFrame::MSWWindowProc()
    -> wxTopLevelWindowMSW::MSWWindowProc()
    -> wxWindowMSW::MSWWindowProc()
    -> wxWindowMSW::MSWHandleMessage()
    -> wxWindowMSW::HandleSize()

bool wxWindowMSW::HandleSize(int WXUNUSED(w), int WXUNUSED(h), WXUINT wParam)
{
    switch ( wParam )
    {
        case SIZE_RESTORED:
            wxSizeEvent event(GetSize(), m_windowId);
            event.SetEventObject(this);
            processed = HandleWindowEvent(event);
    }
}

也就是不管是哪個消息，最終還是轉換稱wxEvent消息，然後調用當前窗口的HandleWindowEvent函數處理，要註意的是此時消息已經是wxWidgets內部的消息類型了。

菜單消息處理

接下來我們驗證菜單消息在wxWidgets中的處理，首先在wxWidgets工程中增加靜態消息映射表，並實現相應的代碼：

const long ID_MenuUser = wxNewId();

BEGIN_EVENT_TABLE(debugWXFrame,wxFrame)
    EVT_MENU(ID_MenuUser, debugWXFrame::OnCheckMenu)
    EVT_UPDATE_UI(ID_MenuUser, debugWXFrame::OnCheckMenuUI)
END_EVENT_TABLE()

void debugWXFrame::OnCheckMenu(wxCommandEvent& event) {}
void debugWXFrame::OnCheckMenuUI(wxUpdateUIEvent& event) {}

我們接著看下Command消息的處理，這個用的非常多，收到Command類型的消息後調用HandleCommand處理，Frame類只處理工具欄、菜單和加速鍵命令，實現過程：

  1. 調用FindItemInMenuBar根據消息中指定的ID來查找對應的wxMenuItem，這個函數的實現就是獲取到當前wxFrame的MenuBar，然後循環查詢，菜單越多查詢的速度也就越慢;
  2. 找到MenuItem後則調用wxFrameBase::ProcessCommand(mitem)繼續處理：
bool wxFrame::HandleCommand(WXWORD id, WXWORD cmd, WXHWND control)
{
#if wxUSE_MENUS

#if defined(WINCE_WITHOUT_COMMANDBAR)
    if (GetToolBar() && GetToolBar()->FindById(id))
        return GetToolBar()->MSWCommand(cmd, id);
#endif

    // we only need to handle the menu and accelerator commands from the items
    // of our menu bar, base wxWindow class already handles the rest
    if ( !control && (cmd == 0 /* menu */ || cmd == 1 /* accel */) )
    {
#if wxUSE_MENUS_NATIVE
        if ( !wxCurrentPopupMenu )
#endif // wxUSE_MENUS_NATIVE
        {
            wxMenuItem * const mitem = FindItemInMenuBar((signed short)id);
            if ( mitem )
                return ProcessCommand(mitem); 
        }
    }
#endif // wxUSE_MENUS

    return wxFrameBase::HandleCommand(id, cmd, control);;
}

wxFrame類本身沒有實現ProcessCommand，所以將調用父類的方法wxFrameBase::ProcessCommand，關鍵流程代碼部分調用wxMenu的SendEvent函數繼續處理。
重點關註，這裏調用的是menu->SendEvent，所以接下來的調用切換到wxMenu類中進行。

bool wxFrameBase::ProcessCommand(wxMenuItem *item)
{
    ...
    wxMenu* const menu = item->GetMenu();
    return menu->SendEvent(item->GetId(), checked);
}

wxMenu的SendEvent實現是wxMenuBase::SendEvent方法，此時我們位於wxMenu對象中，所以調用GetEventHandler()獲得的是wxMenu的EvntHandler。
重點關註win和mb兩個變量，wxMenu首先使用自己的wxEvtHandler進行處理，然後檢查它是否關聯到了win或者menubar，如果有則它還增加了一個標記event.SetWillBeProcessedAgain()，也就是命令需要被wen或者menubar處理。

win和mb兩個變量代表不同的菜單類型，mb是菜單條中的菜單，win是上下文菜單。
這裏我們調用的是mb->HandleWindowEvent(event)；

bool wxMenuBase::SendEvent(int itemid, int checked)
{
    wxCommandEvent event(wxEVT_MENU, itemid);
    event.SetEventObject(this);
    event.SetInt(checked);

    wxWindow* const win = GetWindow();
    wxMenuBar* const mb = GetMenuBar();

    wxEvtHandler *handler = GetEventHandler();
    if ( handler )
    {
        if ( win || mb )
            event.SetWillBeProcessedAgain();
            
        // 沒有想到調用這個函數的場景？
        if ( handler->SafelyProcessEvent(event) )
            return true;
    }

    // If this menu is part of the menu bar, process the event there: this will
    // also propagate it upwards to the window containing the menu bar.
    if ( mb )
        return mb->HandleWindowEvent(event);

    // Try the window the menu was popped up from.
    if ( win )
        return win->HandleWindowEvent(event);

    // Not processed.
    return false;
}

至此，我們將切換到wxMenuBar::HandleWindowEvent，所有者為wxMenuBar，wxMenuBar繼承自wxWindow類，它也是一個獨立的窗口，所以這次調用的函數是wxWindowBase::HandleWindowEvent，調用過程如下：

  1. GetEventHandler()方法返回的就是自身，wxFrame本身就是繼承自wxEvtHandler；
  2. ProcessEvent方法是由父類wxEvtHandler提供的；
bool wxWindowBase::HandleWindowEvent(wxEvent& event) const
{
    return GetEventHandler()->SafelyProcessEvent(event);
}

bool wxEvtHandler::SafelyProcessEvent(wxEvent& event)
{
    return ProcessEvent(event);
}

接著調用ProcessEvent，這個函數是通用的，只要是繼承自wxEvtHandler都會調用到這裏，下面我們分兩種情況來說明情況：

通用的處理：

  1. 處理全局過濾器，wxEvtHandler內部創建了靜態變量ms_filterList，用於保存wxEventFilter列表，用戶可以通過調用靜態函數wxEvtHandler::AddFilter來向系統中增加過濾器，具體可參考過濾器使用章節；
  2. 調用TryBeforeAndHere僅對本對象處理，調用此函數需要依賴一個標記ShouldProcessOnlyIn，這個標記僅僅在DoTryChain中會被設置，也就是只有進入了DoTryChain函數才會有此標記；
  3. 調用ProcessEventLocally執行本對象處理；
  4. 調用TryAfter執行parent的處理；

第一種情況： 位於wxMenuBar中的處理：

此時我們位於wxMenuBar中，此類繼承自wxEvtHandler，所以這裏調用的實際是wxEvtHandler::ProcessEvent，處理過程：

  1. 此時是不會有ShouldProcessOnlyIn標記，所以不會執行TryBeforeAndHere；
  2. 進入到ProcessEventLocally；由於wxMenuBar對象中並沒有綁定此菜單的處理函數，所以ProcessEventLocally是不會處理的;
  3. 進入到TryAfter執行parent的處理；

第二種情況： 位於wxFrame中的處理：

對於wxFrame的ProcessEvent流程也有同樣的效果，只不過會在ProcessEventLocally中處理。

bool wxEvtHandler::ProcessEvent(wxEvent& event)
{
    // 處理過濾器
    if ( !event.WasProcessed() )
    {
        for ( wxEventFilter* f = ms_filterList; f; f = f->m_next )
        {
            int rc = f->FilterEvent(event);
            if ( rc != wxEventFilter::Event_Skip )
            {
                return rc != wxEventFilter::Event_Ignore;
            }
        }
    }

    // 只有執行了 DoTryChain() 之後，ShouldProcessOnlyIn()方法才會返回true
    // 具體可以參考 wxEventProcessInHandlerOnly 輔助類
    if ( event.ShouldProcessOnlyIn(this) )
        return TryBeforeAndHere(event);

    // Try to process the event in this handler itself.
    if ( ProcessEventLocally(event) )
    {
        return !event.GetSkipped();
    }

    if ( TryAfter(event) )
        return true;
        
    // No handler found anywhere, bail out.
    return false;
}

還是分成兩種情況分別說明：
第一種情況： 位於wxMenuBar中的處理：

wxEvtHandler::TryBeforeAndHere會調用TryBefore||TryHereOnly，TryBefore我們暫時忽略，重點是TryHereOnly，在TryHereOnly函數中，首先超找動態綁定表，然後查找靜態綁定表，如果表中存在處理函數則調用之，否則不會調用，對於本流程來將，wxMenubar中並沒有綁定任何處理函數，所以TryHereOnly返回false，進而TryBeforeAndHere函數返回false，所以需要繼續調用DoTryChain。

第二種情況： 位於wxFrame中的處理：

對於wxFrame來說，本例中菜單的消息處理函數綁定在靜態綁定區，所以會在if ( GetEventHashTable().HandleEvent(event, this) )中處理掉，返回true。

bool wxEvtHandler::ProcessEventLocally(wxEvent& event)
{
    return TryBeforeAndHere(event) || DoTryChain(event);
}

bool wxEvtHandler::TryBeforeAndHere(wxEvent& event)
{
    return TryBefore(event) || TryHereOnly(event);
}

bool wxEvtHandler::TryHereOnly(wxEvent& event)
{
    // Handle per-instance dynamic event tables first
    if ( m_dynamicEvents && SearchDynamicEventTable(event) )
        return true;

    // Then static per-class event tables
    if ( GetEventHashTable().HandleEvent(event, this) )
        return true;
    return false;
}

繼續進入入wxMenuBar的DoTryChain，這裏是通過設置EventHandlerChain來達到消息傳遞的目的，但是在wxWidgets系統中，wxWindow繼承的過程中明確不使用這種方式進行消息傳遞，而是通過wxWindow自身的父子關系來進行消息傳遞，所以對於wxMenuBar來說，這個GetNextHandler必定返回是空的，所以DoTryChain返回false，進而wxMenuBar的ProcessEventLocally返回false。

bool wxEvtHandler::DoTryChain(wxEvent& event)
{
    for ( wxEvtHandler *h = GetNextHandler(); h; h = h->GetNextHandler() )
    {
        wxEventProcessInHandlerOnly processInHandlerOnly(event, h);
        if ( h->ProcessEvent(event) )
        {
            event.Skip(false);
            return true;
        }
        if ( !event.ShouldProcessOnlyIn(h) )
        {
            event.Skip();
            return true;
        }
    }

    return false;
}

再回到前兩步，此時我們只能通過調用wxMenuBar的TryAfter(event)繼續消息傳遞，前文有描述wxMenuBar繼承自wxWindows，所以這裏調用的是wxWindowBase::TryAfter，在下面的調用中，窗口只要可能正常接收消息，則會向上查找parent，然後調用父類的ProcessEvent繼續處理。

在本例中，wxMenuBar的parent是wxFrame，所以會繼續調用wxFrame的ProcessEvent繼續處理

bool wxWindowBase::TryAfter(wxEvent& event)
{
    if ( event.ShouldPropagate() )
    {
        if ( !(GetExtraStyle() & wxWS_EX_BLOCK_EVENTS) )
        {
            wxWindow *parent = GetParent();
            if ( parent && !parent->IsBeingDeleted() )
            {
                wxPropagateOnce propagateOnce(event, this);
                return parent->GetEventHandler()->ProcessEvent(event);
            }
        }
    }
    return wxEvtHandler::TryAfter(event);
}

wxFrame的ProcessEvent的調用順序與wxMenuBar的相同，只不過wxFrame會在ProcessEventLocally方法中返回true，進而導致整個處理流程完成。

消息處理鏈（基於wxEvtHandler）

wxWidgets提供了一種手段，用戶可以將消息處理函數註入到wxEvtHandler類中，而不需要使用繼承方式，實現方法就是用戶自定義一個wxEventHandler類，然後調用wxEvtHandler::SetNextHandler()將消息處理代碼加入到指定的wxEvtHandler對象上，使用舉例：

下面的代碼用於將菜單處理放到獨立的wxEvtHandler類中，通過wxEvtHandler::SetNextHandler方法將此Handler對象鏈接到wxFrame上：
註：必須使用wxEvtHandler::SetNextHandler方法註入，不能直接調用SetNextHandler，因為wxWindow重載了這個方法，直接調用不會生效。

const long ID_MenuUser = wxNewId();

class CMyEvtHandler : public wxEvtHandler {
public:
    bool ProcessEvent(wxEvent& event) {
        if (event.GetEventType() == wxEVT_MENU && event.GetId() == ID_MenuUser) {
            wxMessageBox("Menu processed in chain");
            return true;
        }
        event.Skip();
        return false;
    }
};
debugWXFrame::debugWXFrame(wxWindow* parent,wxWindowID id)
{
    ...
    Menu1->Append(ID_MenuUser,   _("Chain Menu"));
    wxEvtHandler::SetNextHandler(new CMyEvtHandler);
}

實際調用時，會進入到wxFram::DoTryChain函數中，由於我們向wxFrame中增加了wxEvtHandler，此時會取出關系鏈上的wxEvtHandler逐個調用。

註意到使用這種方式調用時會預先設定只在當前對象中處理標記，通過wxEventProcessInHandlerOnly processInHandlerOnly(event, h);實現，當processInHandlerOnly銷毀後標記消失，作用範圍僅僅是在這個循環體內。

bool wxEvtHandler::DoTryChain(wxEvent& event)
{
    for ( wxEvtHandler *h = GetNextHandler(); h; h = h->GetNextHandler() )
    {
        wxEventProcessInHandlerOnly processInHandlerOnly(event, h);
        if ( h->ProcessEvent(event) )
        {
            event.Skip(false);
            return true;
        }
        if ( !event.ShouldProcessOnlyIn(h) )
        {
            event.Skip();
            return true;
        }
    }

    return false;
}

消息處理鏈（基於wxWindow）

除了將消息處理類註入到當前wxEvtHandler對象中，還有一個辦法就是調用wxWindow::PushEventHandler將消息處理類註入到當前windows的棧中，兩種方式有區別：

  1. 註入到wxEvtHandler，wxWidgets會優先處理當前對象的wxEvtHandler，然後檢查當前對象的wxEvtHandler是否有鏈接其他的wxEvtHandler，如果有則調用之；
  2. 通過wxWindow::PushEventHandler註入的是改寫wxWindow類的當前消息處理對象，當其查找wxWindow對象的消息處理對象時，只調用最後插入的一個，所以，為了保證正常的消息能處理，我們必須在ProcessEvent()方法中調用下一個wxEvtHandler的方法。

舉例：

const long ID_MenuUser_wxWinChain = wxNewId();

class CMyWinEvtHandler : public wxEvtHandler {
public:
    bool ProcessEvent(wxEvent& event) {
        if (event.GetEventType() == wxEVT_MENU && event.GetId() == ID_MenuUser_wxWinChain) {
            wxMessageBox("Menu processed in chain, id="+wxString::Format("%d", event.GetId()));
            return true;
        }
        if (GetNextHandler())
            return GetNextHandler()->ProcessEvent(event);
        return false;
    }
};

debugWXFrame::debugWXFrame(wxWindow* parent,wxWindowID id)
{
    ...
    Menu1->Append(ID_MenuUser_wxWinChain,   _("Chain Menu"));
    PushEventHandler(new CMyWinEvtHandler);
}

拿菜單處理舉例，在wxMenuBar調用wxWindowBase::TryAfter查找父類調用時，會直接調用父類的方法，對於我們這個例子來說，會直接調用CMyWinEvtHandler::ProcessEvent方法，所以我們在實現ProcessEvent必須註意，需要調用GetNextHandler()->ProcessEvent(event)以保證其他消息的正常處理。

if ( !(GetExtraStyle() & wxWS_EX_BLOCK_EVENTS) )
{
    wxWindow *parent = GetParent();
    if ( parent && !parent->IsBeingDeleted() )
    {
        wxPropagateOnce propagateOnce(event, this);

        return parent->GetEventHandler()->ProcessEvent(event);
    }
}

註：在測試過程中發現總會有the last handler of the wxWindow stack should have this window as next handler的提示，這個是wxWidgets庫本身代碼的Bug，窗口鏈不需要雙向鏈表，窗口本身的wxEvtHandler不需要指向任何wxEvtHandler，因為它就是最後一個。

總結

本節中主要描述了wxWidgets的消息處理過程。

wxWidgets源碼分析(4) - 消息處理過程

相關推薦

wxWidgets源碼分析(4) - 消息處理過程

處理過程 HERE toe 處理流程 als upm 接收 entry false 目錄 消息處理過程 消息如何到達wxWidgets Win32消息與wxWidgets消息的轉換 菜單消息處理 消息處理鏈（基於wxEvtHandler） 消息處理鏈（基於wxWindow

wxWidgets源碼分析(3) - 消息映射表

增加 iter size_t amp 進行 但是 刪除 rtu trie 目錄 消息映射表 靜態消息映射表 靜態消息映射表處理過程 動態消息映射表 動態消息映射表處理過程 消息映射表 消息是GUI程序的核心，所有的操作行為均通過消息傳遞。 靜態消息映射表 使用靜態Ev

Raw-OS源代碼分析之消息系統-Queue_Buffer

存儲倉庫 ive 優先 free avi 都是 部分 沒有 mar 分析的內核版本號截止到2014-04-15，基於1.05正式版。blogs會及時跟進最新版本號的內核開發進度，若源代碼凝視出現”？？？”字樣，則是未深究理解部分。

[SpringBoot]源碼分析SpringBoot的異常處理機制

stat file rto ide ror ise cat read 實現類 微信號：GitShare微信公眾號：愛折騰的稻草如有問題或建議，請在公眾號留言[1]前續為幫助廣大SpringBoot用戶達到“知其然，更需知其所以然”的境界，作者將通過SpringBoot系列文

wxWidgets源碼分析(8) - MVC架構

當前 first 文件 範圍 wxwidgets 調用 let 函數 dll 目錄 MVC架構 wxDocManager文檔管理器 框架菜單命令的執行過程 SDI消息傳遞總結 更新視圖 MVC架構 wxDocManager文檔管理器 wxWidgets使用wxDocM

Android 7.0 Gallery圖庫源碼分析4 - SlotView手勢監聽及頁面跳轉

ofo 自帶 end follow mat views mha creat 找到 上篇文章講了初始化View時會實例化一個SlotView並監聽其事件，至於它是怎麽實現的，用的是Android自帶的GestureDetector。 GestureDetector是Andro

三、消息處理過程與集群維護

頁緩存 topic 找文件 nsf 開源 但是 index 處理 reassign 一、Kafka消息組織原理 1.磁盤重認識 當需要從磁盤讀取數據時，要確定讀的數據在哪個磁道，哪個扇區：首先必須找到柱面，即磁頭需要移動對準相應磁道，這個過程叫做尋道，所耗費時

Spring源碼分析專題 —— IOC容器啟動過程（上篇）

ati apm isp more them try list not in sources 聲明 1.建議先閱讀《Spring源碼分析專題 —— 閱讀指引》 2.強烈建議閱讀過程中要參照調用過程圖，每篇都有其對應的調用過程圖 3.寫文不易，轉載請標明出處 前言 關於 I

Android 消息處理源代碼分析（2）

urn msg illegal r.java roi fin 報錯 mes pri Android 消息處理源代碼分析（1）點擊打開鏈接 繼續接著分析剩下的類文件 Looper.java public final class Looper {

moquette源碼分析之七--qos1和qos2消息的處理

mqtt broker moquette 源碼 首先解釋一下mqtt協議的session的概念，因為只有有了session才會存在消息質量保證一說 如果清理會話（CleanSession）標誌被設置為0，服務端必須基於當前會話（使用客戶端標識符識別）的狀態恢復與客戶端的通信。如果沒有與這個客戶

[編織消息框架][netty源碼分析]7 Unsafe 實現類NioSocketChannelUnsafe職責與實現

實現 final .get 綁定 emp 通知 com over dex Unsafe 是channel的內部接口， 負責跟socket底層打交道。從書寫跟命名上看是不公開給開發者使用的，直到最後實現NioSocketChannelUnsafe也沒有公開出去 publ

[編織消息框架][netty源碼分析]9 Promise 實現類DefaultPromise職責與實現

flush alt read true boolean listener seconds ren ces netty Future是基於jdk Future擴展，以監聽完成任務觸發執行Promise是對Future修改任務數據DefaultPromise是重要的模板類，其它

[編織消息框架][netty源碼分析]11 UnpooledHeapByteBuf 與 ByteBufAllocator

form 源碼分析 updater 流程 sys 如果 說明 技術分享 例子 每種ByteBuf都有相應的分配器ByteBufAllocator，類似工廠模式。我們先學習UnpooledHeapByteBuf與其對應的分配器UnpooledByteBufAlloc

[編織消息框架][netty源碼分析]14 PoolChunk 的 PoolSubpage

ini 構造 free min oid chunk val 一是 一位 final class PoolSubpage<T> implements PoolSubpageMetric { //該page分配的chunk fina

Spring AMQP 源碼分析 06 - 手動消息確認

方法 message href sage str remes 分享 bit release ### 準備 ## 目標 了解 Spring AMQP 如何手動確認消息已成功消費 ## 前置知識 《Spring AMQP 源碼分析 04 - Mess

Akka源碼分析-Remote-發消息

tro result map 問題 比較 dep art actor 進行 　　上一篇博客我們介紹了remote模式下Actor的創建，其實與local的創建並沒有太大區別，一般情況下還是使用LocalActorRef創建了Actor。那麽發消息是否意味著也是相同的呢？ 　

Android異步消息處理機制掌握，從源碼了解常使用的Handler

.html sdn pub may ide klass enable 簡單 keep 1、概述： 　　大家都知道，在Android中，UI線程是不安全的，更新UI在UI線程中處理，其他耗時工作都不能在該線程執行，相信大家在面試的時候也知道Handler是面試官非常喜歡問的一

RocketMQ源碼分析之從官方示例窺探：RocketMQ事務消息實現基本思想

code flag ice arr 技術分享 -a etime 代碼 修復 RocketMQ4.3.0版本開始支持事務消息，後續分享將開始將剖析事務消息的實現原理。首先從官方給出的Demo實例入手，以此通往RocketMQ事務消息的世界中。 官方版本未發布之前，從apach

RocketMQ源碼分析之RocketMQ事務消息實現原理中篇----事務消息狀態回查

下一個 核心 with chcon detail 偏移 ffffff begin n) 上節已經梳理了RocketMQ發送事務消息的流程（基於二階段提交），本節將繼續深入學習事務狀態消息回查，我們知道，第一次提交到消息服務器時消息的主題被替換為RMQ_SYS_TRANS_H

RocketMQ源碼分析之RocketMQ事務消息實現原下篇(事務提交或回滾)

ext back mes 分享 lba term 是否一致 return gof 本文將重點分析RocketMQ Broker如何處理事務消息提交、回滾命令，根據前面的介紹，其入口EndTransactionProcessor#proce***equest： Operati