簡介面向 C/MFC 桌面開發(fā)者與需要內(nèi)嵌瀏覽器能力的混合應用團隊這套工程資料圍繞 Visual Studio 2010 與 CEF3 90.6.0演示把 Chromium Web 視圖嵌入 MFC 窗口并建立 JavaScript 與 C 交互鏈路適合具備一定 MFC、Win32 消息循環(huán)和 C 基礎的中高級開發(fā)者參考。壓縮包共 629 個文件、約 457.22MB以 h 頭文件、pak 運行時資源、dll、lib、cpp、obj/tlog 等構(gòu)建中間文件為主并帶有解決方案與項目配置可輔助完成環(huán)境搭建、依賴引入、編譯鏈接及運行排錯。已有 1558 人學習說明該組合在實際項目中仍有參考需求。讀者可從中了解 CEF 子進程與多線程消息循環(huán)配置、MFC 窗口尺寸與繪制同步、JS 調(diào)用 C 的注冊與回調(diào)處理思路以及 Debug/Release 產(chǎn)物組織方式工程雖以示例形式呈現(xiàn)但足以作為 VS2010 下 CEF3 集成與調(diào)試的對照模板幫助縮短從零配置到可運行的時間。1. 為什么是 90.6.0 這個版本嵌入 MFC 的現(xiàn)實起點CEF3 90.6.0 屬于 Chromium 90 分支的正式二進制分發(fā)版把它塞進 vs2010 的 MFC 工程本質(zhì)是拿 2021 年的瀏覽器內(nèi)核去接 2010 年的窗口框架。老上位機、工控 HMI、醫(yī)療設備界面這類項目升級 IDE 的成本極高但前端頁面又必須跑現(xiàn)代 ES 語法于是「新內(nèi)核 老殼」的組合就成了剛需。真正要解決的無非三件事瀏覽器子窗口怎么掛到 MFC 的 View 或?qū)υ捒蛏?、消息泵歸誰泵、JS 與 C 之間怎么互調(diào)而不互相拖死。這套東西適合還在維護 VS2010 工程的 C 開發(fā)者新手能照第 3、4 章把流程跑通熟手可以直接跳到第 2 章看編譯鏈選型和第 5 章的翻車記錄。2. 編譯鏈先理清VS2010 編不動 CEF 90 的頭文件怎么辦動手之前必須接受一個事實CEF 90 的 C 頭文件用了override、std::unique_ptr、可變參數(shù)模板這些 VS2010 編不過的語法。這不是配置問題是編譯器能力問題。硬啃只有兩條路——要么放棄 VS2010要么在編譯鏈上做切分。切分的核心依據(jù)是 libcef 的導出邊界。2.1 先看清 libcef 的導出邊界C ABI 才是能跨編譯器的部分libcef.dll 對外暴露的符號是cef_*這一批 C 函數(shù)簽名里只有基礎類型、指針和結(jié)構(gòu)體指針沒有 STL 容器、沒有 C 類、沒有異常。這條 C ABI 是穩(wěn)定的任何版本的 MSVC 都能鏈接它包括 VS2010。真正編不過的是include/cef_client.h、include/cef_v8.h這些 C 封裝頭以及l(fā)ibcef_dll_wrapper這個靜態(tài)庫。wrapper 的作用是把 C 結(jié)構(gòu)體包裝成CefRefPtrCefClient那樣的 C 類它本身必須跟 libcef.dll 用同一套頭文件編譯所以它只能用 VS2019 編。于是路線就清楚了wrapper 和所有 CEF 相關(guān)的 C 代碼封進一個中間層 DLL用 VS2019 編譯VS2010 的 MFC 工程只 include 自己寫的純 C 頭文件通過LoadLibrary/ 導入庫調(diào)用?？?DLL 邊界只傳HWND、int、const char*、void*這幾類 POD 類型絕不傳std::string、CefRefPtr、std::function這樣兩套運行庫VS2010 的 msvcr100 和 VS2019 的 vcruntime140同時存在于一個進程里也不會打架。還有一種備選是直接 includeinclude/capi/下那套純 C 頭文件在 VS2010 里手動實現(xiàn)引用計數(shù)和回調(diào)函數(shù)表。這條路能走通但cef_client_t的每個回調(diào)都要自己填函數(shù)指針一個瀏覽器實例的光標、下載、生命周期回調(diào)填下來接近兩百行樣板代碼維護成本高。除非你的構(gòu)建環(huán)境完全禁止引入 VS2019否則不建議。CEF 二進制包里需要落地的文件并不多但一個都不能少文件/目錄放置位置作用漏了會怎樣libcef.dllexe 同級內(nèi)核本體啟動直接失敗libcef.lib鏈接目錄導入庫鏈接期報 LNK2019libcef_dll_wrapper.lib鏈接目錄C 封裝層同上icudtl.datexe 同級ICU 數(shù)據(jù)頁面中文亂碼或崩潰locales/*.pakexe 同級 locales語言資源界面文案回退英文cef.pak / cef_100_percent.pakexe 同級內(nèi)核資源白屏或渲染異常natives_blob.bin / v8_context_snapshot.binexe 同級V8 快照JS 引擎初始化失敗2.2 用 VS2019 編一個 C 接口中間層 DLL中間層對外只暴露五個函數(shù)夠用了初始化、創(chuàng)建瀏覽器、銷毀瀏覽器、執(zhí)行 JS、取窗口句柄。頭文件長這樣/* mycef_bridge.h —— 純 CVS2010 可以直接 include */ #ifndef MYCEF_BRIDGE_H #define MYCEF_BRIDGE_H #ifdef MYCEF_EXPORTS #define MYCEF_API __declspec(dllexport) #else #define MYCEF_API __declspec(dllimport) #endif #ifdef __cplusplus extern C { #endif /* 返回值0 成功非 0 失敗 */ MYCEF_API int MyCef_Init(void* hInstance, const char* subProcessPath, const char* cacheDir, const char* logFile, int debugPort); /* 在 parentHwnd 內(nèi)創(chuàng)建瀏覽器rect 傳客戶區(qū)大小 */ MYCEF_API int MyCef_CreateBrowser(void* parentHwnd, int x, int y, int w, int h, const char* urlUtf8); /* 主線程定時器里調(diào)每 10~30ms 一次 */ MYCEF_API void MyCef_DoMessageLoopWork(void); /* 窗口尺寸變化 */ MYCEF_API void MyCef_Resize(int w, int h); /* 執(zhí)行 JSjsUtf8 為 UTF-8 編碼腳本文本 */ MYCEF_API int MyCef_ExecuteJavaScript(const char* jsUtf8); /* 關(guān)閉瀏覽器并釋放必須在主線程調(diào)返回后再調(diào) MyCef_Shutdown */ MYCEF_API int MyCef_CloseBrowser(void); MYCEF_API void MyCef_Shutdown(void); /* 原生事件回調(diào)由中間層在 browser 進程 UI 線程回調(diào)MFC 側(cè)自行 PostMessage 回主線程 */ typedef void (*MyCef_NativeEventHandler)(const char* cmdUtf8, const char* jsonUtf8, int queryId); MYCEF_API void MyCef_SetNativeHandler(MyCef_NativeEventHandler handler); #ifdef __cplusplus } #endif #endif初始化那段的實現(xiàn)要點在參數(shù)取舍上// bridge.cpp —— 用 VS2019 編譯鏈接 libcef.lib libcef_dll_wrapper.lib MYCEF_API int MyCef_Init(void* hInstance, const char* subProcessPath, const char* cacheDir, const char* logFile, int debugPort) { CefMainArgs mainArgs((HINSTANCE)hInstance); // 傳 exe 的模塊句柄不是 dll 的 CefSettings settings; settings.no_sandbox true; // 老工程常帶第三方注入關(guān)沙箱最省事 settings.multi_threaded_message_loop false; // 關(guān)鍵消息泵交給 MFC 主線程 settings.windowless_rendering_enabled false; // 走原生子窗口不做離屏 settings.log_severity LOGSEVERITY_INFO; settings.remote_debugging_port debugPort; // 8321方便開 DevTools 查 JS CefString(settings.locale) zh-CN; if (cacheDir) CefString(settings.cache_path) cacheDir; if (logFile) CefString(settings.log_file) logFile; if (subProcessPath) CefString(settings.browser_subprocess_path) subProcessPath; CefEnableHighDPISupport(); // 必須在 Initialize 之前 if (!CefInitialize(mainArgs, settings, nullptr, nullptr)) return -1; return 0; }settings.no_sandbox true這一行在老項目里幾乎是必選項因為很多上位機會加載加密狗驅(qū)動、注入式監(jiān)控模塊沙箱一起來子進程就直接被殺。代價是安全性下降內(nèi)網(wǎng)設備可以接受公網(wǎng)產(chǎn)品要重新評估。multi_threaded_message_loop false是整套方案的樞紐。設成 true 意味著 CEF 自己起一條 UI 線程跑CefRunMessageLoop()那條循環(huán)和 MFC 的CWinThread::Run()是兩條獨立的GetMessage循環(huán)誰先拿到消息全靠運氣MFC 的模態(tài)對話框、菜單、快捷鍵會大面積失靈。設成 false 后CEF 的所有 UI 線程工作都靠主線程主動調(diào)用CefDoMessageLoopWork()驅(qū)動控制權(quán)完全在 MFC 手上。編譯 wrapper 用官方二進制包自帶的 CMake 工程:: 在 cef_binary 的 cmake 目錄下注意必須是 Win32跟 VS2010 工程位寬一致 set CEF_ROOTD:\sdk\cef_binary_90_6_0_windows32 cmake -G Visual Studio 16 2019 -A Win32 -DCMAKE_BUILD_TYPERelease .. cmake --build . --config Release --target libcef_dll_wrapper-A Win32不能省。VS2010 的工程基本都是 x86拿 x64 的 wrapper 去鏈接會一路 LNK1112 / LNK2038。構(gòu)建完成后把libcef_dll_wrapper.lib和自己的mycef_bridge.dll一起放進輸出目錄。注意中間層 DLL 和 MFC 主程序的運行庫配置/MD 或 /MT不必一致但中間層內(nèi)部的 wrapper 和 bridge 必須一致否則CefRefPtr的引用計數(shù)會在兩個堆之間來回跑退出時必崩。2.3 VS2010 側(cè)工程配置只認自己的頭文件和導入庫VS2010 工程這邊要做的只有四件事全在項目屬性里。第一附加包含目錄加mycef_bridge.h所在路徑不要加 CEF 的include/。這一步是防止有人手滑#include cef_client.h加了就會觸發(fā)幾百行 C11 報錯把真正的問題淹掉。第二附加庫目錄指向mycef_bridge.lib附加依賴項寫mycef_bridge.lib。如果暫時沒有導入庫用LoadLibraryGetProcAddress也行只是函數(shù)指針表要自己維護。第三調(diào)試工作目錄設成 exe 輸出目錄并在生成后事件里把libcef.dll、icudtl.dat、*.pak、locales/、*.bin拷過去。CEF 的資源文件路徑是相對 exe 目錄找的用 VS 調(diào)試時工作目錄不對就會白屏。第四InitInstance最開始加子進程分流這一步漏了會直接導致渲染進程起不來BOOL CMyApp::InitInstance() { // 子進程分流必須放在任何 MFC 初始化之前 HINSTANCE hInst AfxGetInstanceHandle(); CefMainArgs mainArgs(hInst); // 中間層暴露一個探測函數(shù)返回 0 說明當前是子進程立刻退出 int exitCode MyCef_ExecuteProcess(hInst); if (exitCode 0) return FALSE; // ... 正常 MFC 初始化 ... return CWinApp::InitInstance(); }MyCef_ExecuteProcess內(nèi)部就是CefExecuteProcess(mainArgs, nullptr, nullptr)。這個函數(shù)會檢查命令行里的--typerenderer之類的參數(shù)是子進程就直接進 CEF 自己的循環(huán)返回時進程該退出了是主進程則返回 -1繼續(xù)往下走。子進程的 exe 路徑默認就是主 exe所以 CEF 會用同一個可執(zhí)行文件反復啟動自己。如果你的主 exe 名字被改過、或者裝在帶空格的路徑下就要顯式設browser_subprocess_path指向一個專門的subprocess.exe否則會出現(xiàn)「主窗口出來了但頁面永遠白屏」的經(jīng)典現(xiàn)象。3. 把瀏覽器窗口塞進 MFC窗口句柄、尺寸與消息泵中間層通了之后剩下的活是把瀏覽器子窗口掛到 MFC 的客戶區(qū)里并讓主線程的消息泵既伺候 MFC 又伺候 CEF。這一段出問題的表現(xiàn)通常很直觀窗口位置不對、拖動時白屏、頁面點了沒反應。3.1 SetAsChild 與 CefWindowInfo 的父子關(guān)系CEF 在 Windows 上的默認渲染模式是原生子窗口CefWindowInfo::SetAsChild就是給內(nèi)核指定一個父 HWND 和一個初始矩形。這個父窗口通常取CView的m_hWnd或者對話框上預留的一個靜態(tài)控件。// bridge.cpp MYCEF_API int MyCef_CreateBrowser(void* parentHwnd, int x, int y, int w, int h, const char* urlUtf8) { if (!g_client) return -2; CefWindowInfo info; info.SetAsChild((HWND)parentHwnd, CefRect(x, y, w, h)); // 坐標相對父窗口客戶區(qū) CefBrowserSettings bs; bs.background_color 0xFFFFFFFF; // 白底避免加載中透出黑色 bs.javascript_access_clipboard STATE_DISABLED; CefRefPtrCefRequestContext ctx CefRequestContext::GetGlobalContext(); bool ok CefBrowserHost::CreateBrowser(info, g_client.get(), CefString(urlUtf8), bs, nullptr, ctx); return ok ? 0 : -3; }CefRect里的坐標是相對父窗口客戶區(qū)的不是屏幕坐標傳錯了瀏覽器窗口會跑到屏幕左上角。父窗口如果是對話框上的靜態(tài)控件記得把靜態(tài)控件的SS_NOTIFY打開、ID 設成非IDC_STATIC否則拿不到有效 HWND。瀏覽器創(chuàng)建是異步的CreateBrowser返回 true 只代表請求入隊成功。真正的 HWND 在CefLifeSpanHandler::OnAfterCreated里才拿得到void MyClient::OnAfterCreated(CefRefPtrCefBrowser browser) { m_browser browser; // 保存 CefRefPtr HWND child browser-GetHost()-GetWindowHandle(); // 此刻才是有效 HWND ::ShowWindow(child, SW_SHOW); }這個順序不能反。在CreateBrowser之后立刻GetWindowHandle()拿到的是 NULL后面所有::SetWindowPos都會靜默失敗表現(xiàn)出來就是「瀏覽器已經(jīng)加載完成但界面上什么都看不見」。3.2 消息循環(huán)選型CefDoMessageLoopWork 定時泵multi_threaded_message_loop false之后CEF 的內(nèi)部任務渲染合成、IPC 處理、定時器全都排隊等著被泵。泵的方式就是用 MFC 的SetTimer定期調(diào)CefDoMessageLoopWork()。// MainFrm.cpp int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct) { if (CFrameWnd::OnCreate(lpCreateStruct) -1) return -1; MyCef_Init(AfxGetInstanceHandle(), nullptr, .\\cache, .\\cef.log, 8321); MyCef_CreateBrowser(m_viewHwnd, 0, 0, m_clientW, m_clientH, http://127.0.0.1/index.html); // 10~30ms 一次低于 10ms 會明顯吃 CPU高于 33ms 滾動會卡 SetTimer(TIMER_CEF_PUMP, 10, NULL); return 0; } void CMainFrame::OnTimer(UINT_PTR nIDEvent) { if (nIDEvent TIMER_CEF_PUMP) { MyCef_DoMessageLoopWork(); // 內(nèi)部調(diào)用 CefDoMessageLoopWork() return; // 不要再往下傳避免重復處理 } CFrameWnd::OnTimer(nIDEvent); }定時器精度取 10ms 是個經(jīng)驗值。CEF 官方注釋里明確寫著CefDoMessageLoopWork調(diào)用過于頻繁會拖慢渲染線程而 33ms約 30fps在拖拽窗口時又會明顯掉幀。10~16ms 在多數(shù)工控機上能兼顧流暢度和 CPU 占用但如果目標機器是低功耗嵌入式主板建議先跑 33ms 看效果再往下調(diào)。還有一條更精細的路是external_message_pump true加CefBrowserProcessHandler::OnScheduleMessagePumpWork(int64 delay_ms)由 CEF 反過來告訴你「多久之后需要泵一次」這樣空閑時完全不占 CPU。缺點是回調(diào)發(fā)生在 CEF 內(nèi)部線程需要用PostMessage轉(zhuǎn)到主線程再泵多一層間接。項目對 CPU 占用敏感時可以換成這套。3.3 尺寸同步、DPI 與關(guān)閉時序父窗口大小變了瀏覽器子窗口不會自動跟。WM_SIZE里要做兩件事通知 CEF 尺寸變了以及真正SetWindowPos。void CMyView::OnSize(UINT nType, int cx, int cy) { CView::OnSize(nType, cx, cy); if (cx 0 || cy 0) return; MyCef_Resize(cx, cy); // 內(nèi)部browser-GetHost()-WasResized(); } // bridge.cpp 里的實現(xiàn) MYCEF_API void MyCef_Resize(int w, int h) { if (!g_browser) return; HWND hwnd g_browser-GetHost()-GetWindowHandle(); if (hwnd) ::SetWindowPos(hwnd, NULL, 0, 0, w, h, SWP_NOZORDER | SWP_NOACTIVATE); g_browser-GetHost()-WasResized(); // 通知內(nèi)核重新布局渲染表面 }SetWindowPos和WasResized兩個都要調(diào)。只調(diào)前者子窗口尺寸對了但渲染表面還是舊的頁面右側(cè)會出現(xiàn)一條沒刷新的黑邊只調(diào)后者渲染表面重排了但窗口還是老尺寸內(nèi)容會被裁掉。高 DPI 屏上還要在CefInitialize之前調(diào)CefEnableHighDPISupport()并且在 MFC 側(cè)的 manifest 里聲明dpiAware。兩邊不一致的話125% 縮放下瀏覽器子窗口會偏到右下角越拖越歪。關(guān)閉時序是最容易踩雷的地方正確順序是// 1. 主窗口 OnClose 里先讓瀏覽器自己關(guān) MyCef_CloseBrowser(); // browser-GetHost()-CloseBrowser(true)參數(shù) true 表示強制 // 2. 在 CefLifeSpanHandler::OnBeforeClose 里把 CefRefPtr 置空并停泵 void MyClient::OnBeforeClose(CefRefPtrCefBrowser browser) { ::KillTimer(g_mainHwnd, TIMER_CEF_PUMP); m_browser nullptr; // 最后一個引用在這里釋放 } // 3. MFC 退出前調(diào) CefShutdown() void CMyApp::CleanUp() { MyCef_Shutdown(); // 內(nèi)部 CefShutdown() CWinApp::CleanUp(); }CloseBrowser(true)的true表示不走onbeforeunload確認直接關(guān)。如果頁面里有未保存的表單需要攔截改傳false并在 JS 里監(jiān)聽beforeunload但老項目里這么做往往導致窗口關(guān)不掉用戶只能殺進程。4. JS 與 C 雙向調(diào)用V8Handler 與 MessageRouter 的邊界JS 調(diào) C 有兩種寫法很多人第一反應是CefV8Handler因為它寫起來最像「注冊一個函數(shù)」那么簡單。但它有個致命的進程邊界問題搞不清楚就會出現(xiàn)「代碼明明執(zhí)行了界面紋絲不動」。4.1 CefV8Handler 能做什么、不能做什么CefV8Handler是掛在 V8 上下文里的原生函數(shù)。在CefRenderProcessHandler::OnContextCreated里往全局對象上掛一個函數(shù)名頁面里就能window.nativeCall(...)直接調(diào)。void MyRenderApp::OnContextCreated(CefRefPtrCefBrowser browser, CefRefPtrCefFrame frame, CefRefPtrCefV8Context context) { CefRefPtrCefV8Value global context-GetGlobal(); CefRefPtrCefV8Value fn CefV8Value::CreateFunction(nativeCall, new MyV8Handler()); global-SetValue(nativeCall, fn, V8_PROPERTY_ATTRIBUTE_NONE); } // V8 handler bool MyV8Handler::Execute(const CefString name, CefRefPtrCefV8Value object, const CefV8ValueList arguments, CefRefPtrCefV8Value retval, CefString exception) { if (name nativeCall arguments.size() 2) { std::string cmd arguments[0]-GetStringValue().ToString(); std::string payload arguments[1]-GetStringValue().ToString(); // 關(guān)鍵這段代碼跑在 renderer 進程不能碰 MFC 的 HWND CefRefPtrCefProcessMessage msg CefProcessMessage::Create(native_call); msg-GetArgumentList()-SetString(0, cmd); msg-GetArgumentList()-SetString(1, payload); CefRefPtrCefBrowser browser CefV8Context::GetCurrentContext()-GetBrowser(); browser-GetMainFrame()-SendProcessMessage(PID_BROWSER, msg); return true; } exception bad arguments; return false; }問題就出在那行注釋上。CEF 默認是多進程模型頁面 JS 在 renderer 子進程里跑Execute回調(diào)也在 renderer 進程的 V8 線程執(zhí)行。那一刻你手里只有CefRefPtrMFC 的窗口句柄、CWnd*、成員變量統(tǒng)統(tǒng)在另一個進程的地址空間里直接拿來用輕則無效重則崩潰。想在 UI 上生效就必須像上面那樣SendProcessMessage把消息打到 browser 進程再在CefClient::OnProcessMessageReceived里收bool MyClient::OnProcessMessageReceived(CefRefPtrCefBrowser browser, CefProcessId source_process, CefRefPtrCefProcessMessage message) { if (message-GetName() native_call) { std::string cmd message-GetArgumentList()-GetString(0).ToString(); std::string payload message-GetArgumentList()-GetString(1).ToString(); // 這里在 browser 進程的 UI 線程可以安全地把結(jié)果 PostMessage 給 MFC 窗口 ::PostMessage(g_mainHwnd, WM_NATIVE_CALL, (WPARAM)new std::string(cmd), (LPARAM)new std::string(payload)); return true; } return false; }這條鏈路能跑通但缺了「返回值」——Execute里沒法同步等到 browser 進程處理完再retval-SetString(...)。異步返回值要靠再發(fā)一條消息回 renderer 進程代碼量翻倍。所以只要涉及「調(diào)完要拿結(jié)果」就換下一條路。注意OnProcessMessageReceived的簽名在不同小版本之間有過增減早期版本沒有frame參數(shù)改版本時先看cef_client.h里的聲明別照抄網(wǎng)上的舊代碼。4.2 CefMessageRouter 打通 JS 到 MFC 的完整鏈路CefMessageRouter是 CEF 自帶的請求-響應通道既解決跨進程又自帶回調(diào)和取消機制。它分兩部分renderer 側(cè)負責在頁面里注入cefQuery函數(shù)browser 側(cè)負責收請求并回調(diào)業(yè)務代碼。browser 進程側(cè)建 router// MyClient 構(gòu)造時 CefMessageRouterConfig config; config.js_query_function cefQuery; // 頁面里調(diào)用的函數(shù)名 config.js_cancel_function cefQueryCancel; // 取消函數(shù)名 m_router CefMessageRouterBrowserSide::Create(config); m_router-AddHandler(new MyQueryHandler(), true); // true 表示第一個匹配的 handler 生效然后在CefClient的幾個回調(diào)里逐一轉(zhuǎn)發(fā)少轉(zhuǎn)發(fā)一個查詢就可能永遠不回調(diào)bool MyClient::OnProcessMessageReceived(CefRefPtrCefBrowser browser, CefProcessId source_process, CefRefPtrCefProcessMessage message) { return m_router-OnProcessMessageReceived(browser, message); } bool MyClient::OnBeforeBrowse(CefRefPtrCefBrowser browser, CefRefPtrCefFrame frame, CefRefPtrCefRequest request, bool user_gesture, bool is_redirect) { m_router-OnBeforeBrowse(browser, frame); // 頁面跳轉(zhuǎn)時清掉掛起的查詢 return false; } void MyClient::OnRenderProcessTerminated(CefRefPtrCefBrowser browser, TerminationStatus status) { m_router-OnRenderProcessTerminated(browser); // 渲染進程崩了要重置狀態(tài) }renderer 側(cè)同樣要轉(zhuǎn)發(fā)一次bool MyRenderApp::OnProcessMessageReceived(CefRefPtrCefBrowser browser, CefRefPtrCefFrame frame, CefProcessId source_process, CefRefPtrCefProcessMessage message) { return m_renderRouter-OnProcessMessageReceived(browser, frame, source_process, message); }業(yè)務 handler 才是真正干活的class MyQueryHandler : public CefMessageRouterBrowserSide::Handler { public: bool OnQuery(CefRefPtrCefBrowser browser, CefRefPtrCefFrame frame, int64 query_id, const CefString request, bool persistent, CefRefPtrCallback callback) override { std::string req request.ToString(); // 建議前端統(tǒng)一傳 JSON 字符串 std::string cmd, data; if (!ParseJson(req, cmd, data)) { callback-Failure(-1, bad json); return true; } std::string result; bool ok DispatchToMfc(cmd, data, result); // 這里可以直接調(diào) MFC 成員 if (ok) callback-Success(result); else callback-Failure(-2, handler failed); return true; } };OnQuery跑在 browser 進程的 UI 線程上DispatchToMfc里可以直接訪問全局的CMainFrame*、調(diào)UpdateData、往數(shù)據(jù)庫寫記錄沒有任何跨進程問題。返回值通過callback-Success(...)同步回給頁面的onSuccess。persistent參數(shù)決定這是一次性查詢還是長連接。傳 true 時Callback不釋放可以多次Success適合做「C 主動推送狀態(tài)」傳 false默認就是一問一答用完即焚。前端調(diào)用長這樣注意request里盡量別塞裸字符串統(tǒng)一 JSONfunction callNative(cmd, data) { return new Promise(function (resolve, reject) { window.cefQuery({ request: JSON.stringify({ cmd: cmd, data: data }), onSuccess: function (response) { try { resolve(JSON.parse(response)); } catch (e) { resolve(response); } }, onFailure: function (code, msg) { reject(new Error(code : msg)); } }); }); } // 用法 callNative(readConfig, { key: baudRate }).then(function (r) { console.log(baudRate , r.value); });4.3 C 主動調(diào) JSJSON 序列化與線程約束反方向簡單一些CefFrame::ExecuteJavaScript就夠但有兩個約束必須遵守。第一只能在 browser 進程的 UI 線程調(diào)用。browser-GetMainFrame()在 renderer 進程里返回的是空殼調(diào)了不報錯但什么也不會發(fā)生。第二參數(shù)必須序列化成 JSON 再嵌進腳本字符串直接拼字符串是血淚經(jīng)驗的重災區(qū)void CallJs(const std::string eventName, const std::string jsonPayload) { if (!g_browser) return; CefRefPtrCefFrame frame g_browser-GetMainFrame(); if (!frame) return; // 轉(zhuǎn)義單引號避免 JSON 里的 把腳本字符串提前截斷 std::string safe jsonPayload; ReplaceAll(safe, \\, \\\\); ReplaceAll(safe, , \\); ReplaceAll(safe, \n, \\n); std::string js if(window.onNativeEvent){window.onNativeEvent( eventName , JSON.parse( safe ));}; frame-ExecuteJavaScript(js, frame-GetURL(), 0); }ExecuteJavaScript的第二個參數(shù)是腳本來源 URL用于 DevTools 里定位錯誤傳frame-GetURL()就能在 Sources 面板里看到這段注入代碼的出處第三個參數(shù)是起始行號一般填 0。中文參數(shù)最容易翻車。CefString在 Windows 內(nèi)部是 UTF-16ExecuteJavaScript接受的CefString用 UTF-8 構(gòu)造時要注意源字符串本身的編碼。如果 MFC 那邊拿到的是CString寬字符先WideCharToMultiByte(CP_UTF8, ...)再交出去中間任何一次用CP_ACP轉(zhuǎn)換都會把中文變成問號。如果 C 側(cè)是高頻推送比如每秒幾十幀的設備狀態(tài)ExecuteJavaScript會累積大量待執(zhí)行腳本頁面直接卡死。常見做法是在 C 側(cè)做節(jié)流攢 100ms 一次性推一個數(shù)組過去或者干脆走cefQuery的persistent模式反向給頁面發(fā)。5. 避坑與排查這套組合最容易翻車的五個點VS2010 CEF 90 這個組合橫跨兩代編譯器和十幾年的框架演進出問題的表現(xiàn)往往和真實原因隔著好幾層。下面五條是按我修過的實際現(xiàn)象排序的。5.1 啟動階段白屏、閃退、子進程缺失現(xiàn)象一主窗口出來了瀏覽器區(qū)域一片白日志里出現(xiàn)Failed to create a valid render process或The CEF renderer process is not running。原因基本鎖定在子進程分流。CefExecuteProcess沒有在InitInstance最開頭調(diào)用或者調(diào)用了但返回值處理錯了——子進程跑完CefExecuteProcess之后必須立刻返回不能再往下走 MFC 的初始化流程否則子進程會把自己當成主程序去加載主窗口、去讀配置文件然后在某個空指針上崩掉。解決方式是把分流代碼提到InitInstance的第一行并且用return FALSE而不是return exitCode。同時確認browser_subprocess_path指向的 exe 確實存在、路徑里沒有會被 shell 解釋的字符。排查時打開settings.log_severity LOGSEVERITY_INFO并設log_file子進程啟動的每一行參數(shù)都會寫進日志?，F(xiàn)象二程序啟動幾百毫秒后直接退出Windows 事件查看器里記錄0xc0000135找不到 DLL。原因不在 libcef.dll而在它依賴的 VC 運行庫。CEF 90 的 Windows 二進制是 VS2019 編的依賴vcruntime140.dll/msvcp140.dll。目標機器上只裝了 VS2010 的運行庫msvcr100.dlllibcef.dll 加載時就會失敗。解決是打包時把vcruntime140.dll、msvcp140.dll、vcruntime140_1.dll一起放進 exe 目錄或者給裝機腳本加一步 VC 2015-2022 運行庫安裝。這一步在內(nèi)網(wǎng)離線部署時特別容易被漏掉因為開發(fā)機上通常早裝過了。5.2 運行與退出階段查詢卡死、關(guān)窗崩潰、進程殘留現(xiàn)象三頁面里點了按鈕cefQuery的onSuccess和onFailure都不觸發(fā)控制臺沒有任何報錯頁面就像什么也沒發(fā)生。原因通常是有多個網(wǎng)絡請求同時發(fā)起其中某個 handler 返回了false且沒有調(diào)用callback。OnQuery的返回值語義很容易被誤解返回true表示「這個 handler 認領了這次查詢一定會調(diào) callback」返回false表示「我不處理交給下一個 handler」。如果一個 handler 既沒調(diào) callback 又返回了true路由就會一直等著后續(xù)查詢也全部排在它后面。排查手法是在OnQuery入口打一行日志、在每個分支打一行日志確認哪條路徑?jīng)]有落到Success或Failure上。另一個高發(fā)點是OnBeforeBrowse忘了轉(zhuǎn)發(fā)給 router頁面一旦發(fā)生跳轉(zhuǎn)之前掛起的查詢就變成了孤兒?，F(xiàn)象四點了主窗口的關(guān)閉按鈕界面消失了但任務管理器里進程還掛著再啟動一個實例就報端口占用或緩存目錄被鎖。原因是CefShutdown沒有等到所有瀏覽器真正關(guān)閉就被調(diào)用或者根本沒調(diào)。CloseBrowser(true)只是發(fā)起關(guān)閉請求OnBeforeClose之后內(nèi)核才會釋放資源。如果 MFC 的OnClose里直接PostQuitMessage消息循環(huán)停了CEF 的關(guān)閉流程永遠走不完進程自然退不掉。解決順序是OnClose里調(diào)CloseBrowser(true)→ 在OnBeforeClose里停定時器、置空CefRefPtr→ 再讓窗口銷毀 → 在CWinApp::CleanUp里調(diào)CefShutdown()。中間可以用一個標志位攔住重復關(guān)閉防止用戶連點。現(xiàn)象五程序退出時偶爾彈「內(nèi)存不能為 written」崩潰棧落在libcef.dll里調(diào)試符號一塌糊涂。典型原因是中間層 DLL 的導出函數(shù)返回了 C 對象或者CefRefPtr跨越了 DLL 邊界。兩套運行庫各自維護自己的堆一個進程里new出來的對象在另一個堆里delete堆管理器直接判定越界。檢查方式是看mycef_bridge.h里有沒有出現(xiàn)std::string、class、CefRefPtr這些類型。有就改成const char*intvoid*字符串在邊界上按 UTF-8 拷貝一份。另一條隱蔽路徑是CefRefPtr作為靜態(tài)變量的初始化順序問題——DLL 卸載時靜態(tài)對象析構(gòu)此時 libcef 可能已經(jīng) Shutdown引用計數(shù)操作會踩到已釋放的內(nèi)存。把全局CefRefPtr改成一個裸指針CefRefPtr*在OnAfterCreated里new、在OnBeforeClose里delete順序可控得多。6. 交付前的自檢把 JS 橋接做成可回歸的驗證用例代碼跑通和能交付是兩件事。這套組合涉及兩個進程、兩套運行庫、三層調(diào)用邊界靠手工點幾下確認「看著能用」遲早出事。我一般會在工程里放一個selftest.html把橋接的每條路徑都覆蓋一遍裝到目標機器上先跑這個頁面。頁面里做三件事。第一探測 CEF 版本和進程 ID確認內(nèi)核真的起來了// selftest.html —— 橋接自檢頁 (async function () { const info await callNative(sys.info, {}); console.log(cef_version info.cef_version); // 形如 90.6.0gc... console.log(render_pid info.render_pid); // 與主進程 pid 不同即為多進程正常 document.getElementById(ver).textContent info.cef_version; })();第二覆蓋四類邊界數(shù)據(jù)空字符串、含單引號雙引號的字符串、中文、超過 1KB 的長字符串。每一類都做一次往返比對前后是否一致。中文這一項要專門盯著因為所有亂碼都出在CP_ACP和CP_UTF8混用上正常輸入法打幾個字就能暴露。第三驗證異常路徑調(diào)一個不存在的命令確認onFailure收到的是自定義錯誤碼而不是超時連續(xù)發(fā) 100 個查詢確認全部有回調(diào)且沒有互相串號。最后一項能揪出 handler 返回值寫錯的隱患比看代碼靠譜。參數(shù)上還有兩個容易忽略的檢查點。remote_debugging_port在發(fā)布版本里要關(guān)掉或者綁定到127.0.0.1否則同網(wǎng)段任何人都能連上 DevTools 執(zhí)行任意腳本cache_path要指向可寫的用戶目錄而不是 exe 目錄裝在Program Files下時寫緩存會失敗頁面表現(xiàn)是本地存儲全丟、登錄態(tài)每次重開都掉。還有個小技巧值得加進自檢在OnBeforeClose里主動KillTimer并且把 Do本文還有配套的精品資源點擊獲取