簡介面向 C/MFC 桌面開發(fā)者與需要內(nèi)嵌瀏覽器能力的混合應(yīng)用團(tuán)隊(duì)這套工程資料圍繞 Visual Studio 2010 與 CEF3 90.6.0演示把 Chromium Web 視圖嵌入 MFC 窗口并建立 JavaScript 與 C 交互鏈路適合具備一定 MFC、Win32 消息循環(huán)和 C 基礎(chǔ)的中高級開發(fā)者參考。壓縮包共 629 個文件、約 457.22MB以 h 頭文件、pak 運(yùn)行時資源、dll、lib、cpp、obj/tlog 等構(gòu)建中間文件為主并帶有解決方案與項(xiàng)目配置可輔助完成環(huán)境搭建、依賴引入、編譯鏈接及運(yùn)行排錯。已有 1558 人學(xué)習(xí)說明該組合在實(shí)際項(xiàng)目中仍有參考需求。讀者可從中了解 CEF 子進(jìn)程與多線程消息循環(huán)配置、MFC 窗口尺寸與繪制同步、JS 調(diào)用 C 的注冊與回調(diào)處理思路以及 Debug/Release 產(chǎn)物組織方式工程雖以示例形式呈現(xiàn)但足以作為 VS2010 下 CEF3 集成與調(diào)試的對照模板幫助縮短從零配置到可運(yùn)行的時間。1. 為什么是 90.6.0 這個版本嵌入 MFC 的現(xiàn)實(shí)起點(diǎn)CEF3 90.6.0 屬于 Chromium 90 分支的正式二進(jìn)制分發(fā)版把它塞進(jìn) vs2010 的 MFC 工程本質(zhì)是拿 2021 年的瀏覽器內(nèi)核去接 2010 年的窗口框架。老上位機(jī)、工控 HMI、醫(yī)療設(shè)備界面這類項(xiàng)目升級 IDE 的成本極高但前端頁面又必須跑現(xiàn)代 ES 語法于是「新內(nèi)核 老殼」的組合就成了剛需。真正要解決的無非三件事瀏覽器子窗口怎么掛到 MFC 的 View 或?qū)υ捒蛏?、消息泵歸誰泵、JS 與 C 之間怎么互調(diào)而不互相拖死。這套東西適合還在維護(hù) VS2010 工程的 C 開發(fā)者新手能照第 3、4 章把流程跑通熟手可以直接跳到第 2 章看編譯鏈選型和第 5 章的翻車記錄。2. 編譯鏈先理清VS2010 編不動 CEF 90 的頭文件怎么辦動手之前必須接受一個事實(shí)CEF 90 的 C 頭文件用了override、std::unique_ptr、可變參數(shù)模板這些 VS2010 編不過的語法。這不是配置問題是編譯器能力問題。硬啃只有兩條路——要么放棄 VS2010要么在編譯鏈上做切分。切分的核心依據(jù)是 libcef 的導(dǎo)出邊界。2.1 先看清 libcef 的導(dǎo)出邊界C ABI 才是能跨編譯器的部分libcef.dll 對外暴露的符號是cef_*這一批 C 函數(shù)簽名里只有基礎(chǔ)類型、指針和結(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 代碼封進(jìn)一個中間層 DLL用 VS2019 編譯VS2010 的 MFC 工程只 include 自己寫的純 C 頭文件通過LoadLibrary/ 導(dǎo)入庫調(diào)用?？?DLL 邊界只傳HWND、int、const char*、void*這幾類 POD 類型絕不傳std::string、CefRefPtr、std::function這樣兩套運(yùn)行庫VS2010 的 msvcr100 和 VS2019 的 vcruntime140同時存在于一個進(jìn)程里也不會打架。還有一種備選是直接 includeinclude/capi/下那套純 C 頭文件在 VS2010 里手動實(shí)現(xiàn)引用計(jì)數(shù)和回調(diào)函數(shù)表。這條路能走通但cef_client_t的每個回調(diào)都要自己填函數(shù)指針一個瀏覽器實(shí)例的光標(biāo)、下載、生命周期回調(diào)填下來接近兩百行樣板代碼維護(hù)成本高。除非你的構(gòu)建環(huán)境完全禁止引入 VS2019否則不建議。CEF 二進(jìn)制包里需要落地的文件并不多但一個都不能少文件/目錄放置位置作用漏了會怎樣libcef.dllexe 同級內(nèi)核本體啟動直接失敗libcef.lib鏈接目錄導(dǎo)入庫鏈接期報(bào) 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 快照J(rèn)S 引擎初始化失敗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 進(jìn)程 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初始化那段的實(shí)現(xiàn)要點(diǎ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這一行在老項(xiàng)目里幾乎是必選項(xiàng)因?yàn)楹芏嗌衔粰C(jī)會加載加密狗驅(qū)動、注入式監(jiān)控模塊沙箱一起來子進(jìn)程就直接被殺。代價是安全性下降內(nèi)網(wǎng)設(shè)備可以接受公網(wǎng)產(chǎn)品要重新評估。multi_threaded_message_loop false是整套方案的樞紐。設(shè)成 true 意味著 CEF 自己起一條 UI 線程跑CefRunMessageLoop()那條循環(huán)和 MFC 的CWinThread::Run()是兩條獨(dú)立的GetMessage循環(huán)誰先拿到消息全靠運(yùn)氣MFC 的模態(tài)對話框、菜單、快捷鍵會大面積失靈。設(shè)成 false 后CEF 的所有 UI 線程工作都靠主線程主動調(diào)用CefDoMessageLoopWork()驅(qū)動控制權(quán)完全在 MFC 手上。編譯 wrapper 用官方二進(jìn)制包自帶的 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一起放進(jìn)輸出目錄。注意中間層 DLL 和 MFC 主程序的運(yùn)行庫配置/MD 或 /MT不必一致但中間層內(nèi)部的 wrapper 和 bridge 必須一致否則CefRefPtr的引用計(jì)數(shù)會在兩個堆之間來回跑退出時必崩。2.3 VS2010 側(cè)工程配置只認(rèn)自己的頭文件和導(dǎo)入庫VS2010 工程這邊要做的只有四件事全在項(xiàng)目屬性里。第一附加包含目錄加mycef_bridge.h所在路徑不要加 CEF 的include/。這一步是防止有人手滑#include cef_client.h加了就會觸發(fā)幾百行 C11 報(bào)錯把真正的問題淹掉。第二附加庫目錄指向mycef_bridge.lib附加依賴項(xiàng)寫mycef_bridge.lib。如果暫時沒有導(dǎo)入庫用LoadLibraryGetProcAddress也行只是函數(shù)指針表要自己維護(hù)。第三調(diào)試工作目錄設(shè)成 exe 輸出目錄并在生成后事件里把libcef.dll、icudtl.dat、*.pak、locales/、*.bin拷過去。CEF 的資源文件路徑是相對 exe 目錄找的用 VS 調(diào)試時工作目錄不對就會白屏。第四InitInstance最開始加子進(jìn)程分流這一步漏了會直接導(dǎo)致渲染進(jìn)程起不來BOOL CMyApp::InitInstance() { // 子進(jìn)程分流必須放在任何 MFC 初始化之前 HINSTANCE hInst AfxGetInstanceHandle(); CefMainArgs mainArgs(hInst); // 中間層暴露一個探測函數(shù)返回 0 說明當(dāng)前是子進(jìn)程立刻退出 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ù)是子進(jìn)程就直接進(jìn) CEF 自己的循環(huán)返回時進(jìn)程該退出了是主進(jìn)程則返回 -1繼續(xù)往下走。子進(jìn)程的 exe 路徑默認(rèn)就是主 exe所以 CEF 會用同一個可執(zhí)行文件反復(fù)啟動自己。如果你的主 exe 名字被改過、或者裝在帶空格的路徑下就要顯式設(shè)browser_subprocess_path指向一個專門的subprocess.exe否則會出現(xiàn)「主窗口出來了但頁面永遠(yuǎn)白屏」的經(jīng)典現(xiàn)象。3. 把瀏覽器窗口塞進(jìn) MFC窗口句柄、尺寸與消息泵中間層通了之后剩下的活是把瀏覽器子窗口掛到 MFC 的客戶區(qū)里并讓主線程的消息泵既伺候 MFC 又伺候 CEF。這一段出問題的表現(xiàn)通常很直觀窗口位置不對、拖動時白屏、頁面點(diǎn)了沒反應(yīng)。3.1 SetAsChild 與 CefWindowInfo 的父子關(guān)系CEF 在 Windows 上的默認(rèn)渲染模式是原生子窗口CefWindowInfo::SetAsChild就是給內(nèi)核指定一個父 HWND 和一個初始矩形。這個父窗口通常取CView的m_hWnd或者對話框上預(yù)留的一個靜態(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)); // 坐標(biāo)相對父窗口客戶區(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里的坐標(biāo)是相對父窗口客戶區(qū)的不是屏幕坐標(biāo)傳錯了瀏覽器窗口會跑到屏幕左上角。父窗口如果是對話框上的靜態(tài)控件記得把靜態(tài)控件的SS_NOTIFY打開、ID 設(shè)成非IDC_STATIC否則拿不到有效 HWND。瀏覽器創(chuàng)建是異步的CreateBrowser返回 true 只代表請求入隊(duì)成功。真正的 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)部任務(wù)渲染合成、IPC 處理、定時器全都排隊(duì)等著被泵。泵的方式就是用 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; // 不要再往下傳避免重復(fù)處理 } CFrameWnd::OnTimer(nIDEvent); }定時器精度取 10ms 是個經(jīng)驗(yàn)值。CEF 官方注釋里明確寫著CefDoMessageLoopWork調(diào)用過于頻繁會拖慢渲染線程而 33ms約 30fps在拖拽窗口時又會明顯掉幀。10~16ms 在多數(shù)工控機(jī)上能兼顧流暢度和 CPU 占用但如果目標(biāo)機(jī)器是低功耗嵌入式主板建議先跑 33ms 看效果再往下調(diào)。還有一條更精細(xì)的路是external_message_pump true加CefBrowserProcessHandler::OnScheduleMessagePumpWork(int64 delay_ms)由 CEF 反過來告訴你「多久之后需要泵一次」這樣空閑時完全不占 CPU。缺點(diǎn)是回調(diào)發(fā)生在 CEF 內(nèi)部線程需要用PostMessage轉(zhuǎn)到主線程再泵多一層間接。項(xiàng)目對 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 里的實(shí)現(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 表示強(qiáng)制 // 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確認(rèn)直接關(guān)。如果頁面里有未保存的表單需要攔截改傳false并在 JS 里監(jiān)聽beforeunload但老項(xiàng)目里這么做往往導(dǎo)致窗口關(guān)不掉用戶只能殺進(jìn)程。4. JS 與 C 雙向調(diào)用V8Handler 與 MessageRouter 的邊界JS 調(diào) C 有兩種寫法很多人第一反應(yīng)是CefV8Handler因?yàn)樗鼘懫饋碜钕瘛缸砸粋€函數(shù)」那么簡單。但它有個致命的進(jìn)程邊界問題搞不清楚就會出現(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 進(jìn)程不能碰 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 默認(rèn)是多進(jìn)程模型頁面 JS 在 renderer 子進(jìn)程里跑Execute回調(diào)也在 renderer 進(jìn)程的 V8 線程執(zhí)行。那一刻你手里只有CefRefPtrMFC 的窗口句柄、CWnd*、成員變量統(tǒng)統(tǒng)在另一個進(jìn)程的地址空間里直接拿來用輕則無效重則崩潰。想在 UI 上生效就必須像上面那樣SendProcessMessage把消息打到 browser 進(jìn)程再在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 進(jìn)程的 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 進(jìn)程處理完再retval-SetString(...)。異步返回值要靠再發(fā)一條消息回 renderer 進(jìn)程代碼量翻倍。所以只要涉及「調(diào)完要拿結(jié)果」就換下一條路。注意OnProcessMessageReceived的簽名在不同小版本之間有過增減早期版本沒有frame參數(shù)改版本時先看cef_client.h里的聲明別照抄網(wǎng)上的舊代碼。4.2 CefMessageRouter 打通 JS 到 MFC 的完整鏈路CefMessageRouter是 CEF 自帶的請求-響應(yīng)通道既解決跨進(jìn)程又自帶回調(diào)和取消機(jī)制。它分兩部分renderer 側(cè)負(fù)責(zé)在頁面里注入cefQuery函數(shù)browser 側(cè)負(fù)責(zé)收請求并回調(diào)業(yè)務(wù)代碼。browser 進(jìn)程側(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ā)一個查詢就可能永遠(yuǎn)不回調(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); // 渲染進(jìn)程崩了要重置狀態(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è)務(wù) 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 進(jìn)程的 UI 線程上DispatchToMfc里可以直接訪問全局的CMainFrame*、調(diào)UpdateData、往數(shù)據(jù)庫寫記錄沒有任何跨進(jìn)程問題。返回值通過callback-Success(...)同步回給頁面的onSuccess。persistent參數(shù)決定這是一次性查詢還是長連接。傳 true 時Callback不釋放可以多次Success適合做「C 主動推送狀態(tài)」傳 false默認(rèn)就是一問一答用完即焚。前端調(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 進(jìn)程的 UI 線程調(diào)用。browser-GetMainFrame()在 renderer 進(jìn)程里返回的是空殼調(diào)了不報(bào)錯但什么也不會發(fā)生。第二參數(shù)必須序列化成 JSON 再嵌進(jìn)腳本字符串直接拼字符串是血淚經(jīng)驗(yàn)的重災(zāi)區(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 里的 把腳本字符串提前截?cái)?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è)是高頻推送比如每秒幾十幀的設(shè)備狀態(tài)ExecuteJavaScript會累積大量待執(zhí)行腳本頁面直接卡死。常見做法是在 C 側(cè)做節(jié)流攢 100ms 一次性推一個數(shù)組過去或者干脆走cefQuery的persistent模式反向給頁面發(fā)。5. 避坑與排查這套組合最容易翻車的五個點(diǎn)VS2010 CEF 90 這個組合橫跨兩代編譯器和十幾年的框架演進(jìn)出問題的表現(xiàn)往往和真實(shí)原因隔著好幾層。下面五條是按我修過的實(shí)際現(xiàn)象排序的。5.1 啟動階段白屏、閃退、子進(jìn)程缺失現(xiàn)象一主窗口出來了瀏覽器區(qū)域一片白日志里出現(xiàn)Failed to create a valid render process或The CEF renderer process is not running。原因基本鎖定在子進(jìn)程分流。CefExecuteProcess沒有在InitInstance最開頭調(diào)用或者調(diào)用了但返回值處理錯了——子進(jìn)程跑完CefExecuteProcess之后必須立刻返回不能再往下走 MFC 的初始化流程否則子進(jìn)程會把自己當(dāng)成主程序去加載主窗口、去讀配置文件然后在某個空指針上崩掉。解決方式是把分流代碼提到InitInstance的第一行并且用return FALSE而不是return exitCode。同時確認(rèn)browser_subprocess_path指向的 exe 確實(shí)存在、路徑里沒有會被 shell 解釋的字符。排查時打開settings.log_severity LOGSEVERITY_INFO并設(shè)log_file子進(jìn)程啟動的每一行參數(shù)都會寫進(jìn)日志。現(xiàn)象二程序啟動幾百毫秒后直接退出Windows 事件查看器里記錄0xc0000135找不到 DLL。原因不在 libcef.dll而在它依賴的 VC 運(yùn)行庫。CEF 90 的 Windows 二進(jìn)制是 VS2019 編的依賴vcruntime140.dll/msvcp140.dll。目標(biāo)機(jī)器上只裝了 VS2010 的運(yùn)行庫msvcr100.dlllibcef.dll 加載時就會失敗。解決是打包時把vcruntime140.dll、msvcp140.dll、vcruntime140_1.dll一起放進(jìn) exe 目錄或者給裝機(jī)腳本加一步 VC 2015-2022 運(yùn)行庫安裝。這一步在內(nèi)網(wǎng)離線部署時特別容易被漏掉因?yàn)殚_發(fā)機(jī)上通常早裝過了。5.2 運(yùn)行與退出階段查詢卡死、關(guān)窗崩潰、進(jìn)程殘留現(xiàn)象三頁面里點(diǎn)了按鈕cefQuery的onSuccess和onFailure都不觸發(fā)控制臺沒有任何報(bào)錯頁面就像什么也沒發(fā)生。原因通常是有多個網(wǎng)絡(luò)請求同時發(fā)起其中某個 handler 返回了false且沒有調(diào)用callback。OnQuery的返回值語義很容易被誤解返回true表示「這個 handler 認(rèn)領(lǐng)了這次查詢一定會調(diào) callback」返回false表示「我不處理交給下一個 handler」。如果一個 handler 既沒調(diào) callback 又返回了true路由就會一直等著后續(xù)查詢也全部排在它后面。排查手法是在OnQuery入口打一行日志、在每個分支打一行日志確認(rèn)哪條路徑?jīng)]有落到Success或Failure上。另一個高發(fā)點(diǎn)是OnBeforeBrowse忘了轉(zhuǎn)發(fā)給 router頁面一旦發(fā)生跳轉(zhuǎn)之前掛起的查詢就變成了孤兒。現(xiàn)象四點(diǎn)了主窗口的關(guān)閉按鈕界面消失了但任務(wù)管理器里進(jìn)程還掛著再啟動一個實(shí)例就報(bào)端口占用或緩存目錄被鎖。原因是CefShutdown沒有等到所有瀏覽器真正關(guān)閉就被調(diào)用或者根本沒調(diào)。CloseBrowser(true)只是發(fā)起關(guān)閉請求OnBeforeClose之后內(nèi)核才會釋放資源。如果 MFC 的OnClose里直接PostQuitMessage消息循環(huán)停了CEF 的關(guān)閉流程永遠(yuǎn)走不完進(jìn)程自然退不掉。解決順序是OnClose里調(diào)CloseBrowser(true)→ 在OnBeforeClose里停定時器、置空CefRefPtr→ 再讓窗口銷毀 → 在CWinApp::CleanUp里調(diào)CefShutdown()。中間可以用一個標(biāo)志位攔住重復(fù)關(guān)閉防止用戶連點(diǎn)?，F(xiàn)象五程序退出時偶爾彈「內(nèi)存不能為 written」崩潰棧落在libcef.dll里調(diào)試符號一塌糊涂。典型原因是中間層 DLL 的導(dǎo)出函數(shù)返回了 C 對象或者CefRefPtr跨越了 DLL 邊界。兩套運(yùn)行庫各自維護(hù)自己的堆一個進(jìn)程里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引用計(jì)數(shù)操作會踩到已釋放的內(nèi)存。把全局CefRefPtr改成一個裸指針CefRefPtr*在OnAfterCreated里new、在OnBeforeClose里delete順序可控得多。6. 交付前的自檢把 JS 橋接做成可回歸的驗(yàn)證用例代碼跑通和能交付是兩件事。這套組合涉及兩個進(jìn)程、兩套運(yùn)行庫、三層調(diào)用邊界靠手工點(diǎn)幾下確認(rèn)「看著能用」遲早出事。我一般會在工程里放一個selftest.html把橋接的每條路徑都覆蓋一遍裝到目標(biāo)機(jī)器上先跑這個頁面。頁面里做三件事。第一探測 CEF 版本和進(jìn)程 ID確認(rèn)內(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); // 與主進(jìn)程 pid 不同即為多進(jìn)程正常 document.getElementById(ver).textContent info.cef_version; })();第二覆蓋四類邊界數(shù)據(jù)空字符串、含單引號雙引號的字符串、中文、超過 1KB 的長字符串。每一類都做一次往返比對前后是否一致。中文這一項(xiàng)要專門盯著因?yàn)樗衼y碼都出在CP_ACP和CP_UTF8混用上正常輸入法打幾個字就能暴露。第三驗(yàn)證異常路徑調(diào)一個不存在的命令確認(rèn)onFailure收到的是自定義錯誤碼而不是超時連續(xù)發(fā) 100 個查詢確認(rèn)全部有回調(diào)且沒有互相串號。最后一項(xiàng)能揪出 handler 返回值寫錯的隱患比看代碼靠譜。參數(shù)上還有兩個容易忽略的檢查點(diǎn)。remote_debugging_port在發(fā)布版本里要關(guān)掉或者綁定到127.0.0.1否則同網(wǎng)段任何人都能連上 DevTools 執(zhí)行任意腳本cache_path要指向可寫的用戶目錄而不是 exe 目錄裝在Program Files下時寫緩存會失敗頁面表現(xiàn)是本地存儲全丟、登錄態(tài)每次重開都掉。還有個小技巧值得加進(jìn)自檢在OnBeforeClose里主動KillTimer并且把 Do本文還有配套的精品資源點(diǎn)擊獲取