簡介在 CEF 離屏渲染開發(fā)中性能瓶頸往往集中在紋理傳輸與合成環(huán)節(jié)尤其是在多窗口、復(fù)雜頁面和 GPU 加速場景下。這份示例工程面向需要借助 D3D11 共享紋理優(yōu)化 OSR 渲染效果的開發(fā)者圍繞官方建議的 OnAcceleratedPaint() 回調(diào)展開演示了從 GPU 表面獲取渲染結(jié)果、完成混合與合成的完整過程可有效改善復(fù)雜 HTML 內(nèi)容下的渲染流暢度與響應(yīng)速度。資源包體積僅 137KB共 32 個(gè)文件主體為 C 源碼同時(shí)包含多套 CMake 構(gòu)建腳本、Windows 批處理命令、補(bǔ)丁文件、說明文檔及少量資源文件結(jié)構(gòu)緊湊便于對照工程生成、代碼閱讀與二次改造。當(dāng)前已有 77 人瀏覽學(xué)習(xí)。除核心混合器與合成器實(shí)現(xiàn)外資源還覆蓋 VS2017/VS2019 工程生成腳本、FindCEF 模塊查找方式、共享紋理問題補(bǔ)丁和許可證說明適合準(zhǔn)備在桌面應(yīng)用中嵌入網(wǎng)頁、希望繞開離屏渲染兼容性坑點(diǎn)的中高級 CEF 開發(fā)者。1. 離屏渲染不是新東西但 CEF 的 OSR 總被人用成低性能如果你需要在游戲引擎里嵌一個(gè)設(shè)置界面、在直播工具里放一塊可交互的 Web 面板、或者在自研渲染器里塞進(jìn)完整的 Chromium最直接的辦法不是把瀏覽器窗口釘在你的窗口上而是讓 Chromium 把每一幀的像素直接交到你手里——這就是 CEF 的離屏渲染OSR。這個(gè)演示 zip 里打包的東西本質(zhì)上就是一套「怎么把 CEF 的 OSR 跑起來并且跑得不像玩具」的最小工程。說它高性能是因?yàn)槟J(rèn)的 OnPaint 回調(diào)拿到的位圖直接拷給 GPU 的方式在大分辨率下會把 CPU 打滿真正能用的方案要繞開這條路。這篇筆記面向兩類人一類是第一次接 CEF想知道 OSR 和普通窗口模式差在哪另一類是已經(jīng)在用 OSR 但被幀率、黑屏、輸入法坑到懷疑人生的。我按自己做過的落地路徑來拆從原理到代碼到參數(shù)到排錯。2. 選型與原理為什么 OSR 能嵌進(jìn)任何渲染管線以及性能從哪來2.1 三種嵌入瀏覽器的方案對比窗口句柄嵌入、窗口重父化、OSR常見做法是把瀏覽器內(nèi)容裝進(jìn)自己的應(yīng)用大致有三條路。第一種是在宿主窗口里創(chuàng)建了一個(gè)子窗口把 CEF 的瀏覽器窗口直接掛進(jìn)去SetAsChild這個(gè)方案最簡單瀏覽器自己處理輸入、繪制、IME完全不用你管。缺點(diǎn)是它是個(gè)真正的系統(tǒng)窗口你的渲染引擎沒法對它做變換、裁剪、混合去不掉彈窗和陰影跨平臺表現(xiàn)也不一致。第二種是窗口重父化把瀏覽器的原生窗口 reparent 到你的窗口層級里本質(zhì)上還是窗口模式只是換了個(gè)爹邊框和焦點(diǎn)問題依然存在。OSR 是第三條路瀏覽器不創(chuàng)建可見窗口Chromium 內(nèi)部照常布局、繪制、合成最終把像素?cái)?shù)據(jù)通過回調(diào)交給你。你可以把這堆像素貼到 3D 物體表面、寫進(jìn)視頻幀、或者和自研 UI 做統(tǒng)一混合。代價(jià)是輸入事件、焦點(diǎn)管理、IME、拖拽這些本來由系統(tǒng)窗口幫你做的事全都要你手動轉(zhuǎn)發(fā)給 CEF。三種方案的取舍很清晰要求開發(fā)速度、不需要不規(guī)則裁剪就選窗口嵌入要嵌進(jìn) OpenGL/D3D/Vulkan 管線、要統(tǒng)一渲染就選 OSR。方案開發(fā)成本功能完整度嵌入自研渲染器典型場景窗口句柄嵌入低高不行窗口層級限制多桌面工具、IDE 面板窗口重父化低高有限位置同步麻煩老項(xiàng)目遷移OSR中高中需補(bǔ)償輸入/IME完全可控像素/紋理任取游戲 UI、視頻合成、虛擬桌面我做桌面端三年最后穩(wěn)定下來的選型套路是只要渲染引擎已經(jīng)存在、或者產(chǎn)品圖里出現(xiàn)過「任意形狀的瀏覽器窗口」就別猶豫直接 OSR。2.2 CEF 的 OSR 工作鏈路從 Chromium 合成器到你的紋理OSR 的核心是讓 Chromium 的合成器把最終畫面輸出到內(nèi)存或共享紋理再通過 CefRenderHandler 接口交給你。這里面有兩個(gè)回調(diào)最容易混淆一個(gè)是 OnPaint它給你的是 CPU 可讀的位圖數(shù)據(jù)RGBA適合小窗口、低幀率、或者你本來就做軟件渲染的場景另一個(gè)是 OnAcceleratedPaint它交給你的不是像素而是一個(gè) GPU 紋理的句柄在 Windows 上是 D3D11 共享紋理在 Linux 上是 dmabuf 文件描述符。拿到句柄后你的渲染器可以直接把它作為紋理采樣省掉了 CPU 到 GPU 的上傳。鏈路大致是這樣渲染進(jìn)程產(chǎn)生產(chǎn)出GPU 進(jìn)程做合成合成結(jié)果以紋理或位圖形式跨進(jìn)程交給瀏覽器進(jìn)程瀏覽器進(jìn)程通過 CefRenderHandler 的 OnAcceleratedPaint 或 OnPaint 拋給你。所以性能瓶頸從來不在 Chromium 本身而在你接住幀之后干了什么。很多人覺得 CEF OSR 卡其實(shí)是自己寫的 OnPaint 里在做像素格式轉(zhuǎn)換、memcpy、再通過 glTexImage2D 上傳一條流水線全是同步操作UI 線程不卡才怪。2.3 多進(jìn)程模型和用自己的子進(jìn)程到底解決什么CEF 天生是多進(jìn)程架構(gòu)主程序是 browser 進(jìn)程頁面跑在 renderer 進(jìn)程里合成和光柵化在 GPU 進(jìn)程里。這里有個(gè)關(guān)鍵設(shè)計(jì)理念browser 進(jìn)程和 renderer 進(jìn)程不是同一個(gè)可執(zhí)行文件的兩個(gè)函數(shù)而是同一個(gè)二進(jìn)制用不同命令行參數(shù)啟動后的不同角色。演示 zip 里通常只有一個(gè) exe那么你在 main 函數(shù)一開始就要判斷命令行參數(shù)如果是--typerenderer就直接調(diào) CefExecuteProcess 把自己變成渲染進(jìn)程然后退出 main否則才走正常的 UI 初始化。// main.cpp 入口分流 int main(int argc, char* argv[]) { CefMainArgs main_args(argc, argv); CefRefPtrCefApp app(new DemoApp()); // 關(guān)鍵子進(jìn)程入口必須復(fù)用同一個(gè) exe。 // 否則 CEF 會嘗試用 CefSettings.browser_subprocess_path 指定的路徑 // 找不到就起不來頁面。 int exit_code CefExecuteProcess(main_args, app.get(), nullptr); if (exit_code 0) { // 當(dāng)前進(jìn)程已經(jīng)作為 renderer/gpu 子進(jìn)程運(yùn)行完畢 return exit_code; } // 只有主進(jìn)程會走到這里 return RunBrowserProcess(main_args, app); }這段代碼解決的是一個(gè)非常現(xiàn)實(shí)的部署問題很多新手工程不寫 CefExecuteProcess 分支而是把 browser_subprocess_path 指向一個(gè)不存在或者不完整的 helper 文件結(jié)果就是瀏覽器進(jìn)程能啟動但頁面一直白屏或者崩在不起眼的地方。用自己的子進(jìn)程本質(zhì)上是讓 CEF 的多進(jìn)程模型在一個(gè)文件里自洽這在交付演示 zip 時(shí)尤其重要——少一個(gè)依賴文件就少一個(gè)翻車現(xiàn)場。參數(shù)上要注意CefSettings.browser_subprocess_path在 Windows 上必須指向包含完整 CEF 運(yùn)行時(shí)的可執(zhí)行文件Linux 下如果不設(shè)置會用 /proc/self/exe 兜底但顯式指定更穩(wěn)妥。2.4 為什么說高性能更多是策略問題幀延遲和 CPU 占用這兩個(gè)指標(biāo)在 OSR 里高度依賴你選擇的輸出路徑。純 OnPaint 路徑適合分辨率不高、幀率不高的場景OnAcceleratedPaint 路徑把像素搬運(yùn)交給 GPU 進(jìn)程和你的顯卡驅(qū)動主線程只做紋理句柄的注冊和采樣。還有一個(gè)被忽略的點(diǎn)CEF 提供 SetWindowlessFrameRate 控制瀏覽器端的幀率上限如果你不設(shè)置它默認(rèn)是 30某些版本會自適應(yīng)。你以為是瀏覽器慢其實(shí)是它被幀率上限卡住了這個(gè)參數(shù)我在下一章展開講。3. 把它跑起來最小 OSR 演示工程的關(guān)鍵代碼3.1 初始化設(shè)置讓 CEF 進(jìn)入離屏模式這一節(jié)是可抄作業(yè)的核心。CefSettings 里有幾個(gè)字段直接決定 OSR 能不能生效。第一個(gè)是windowless_rendering_enabled必須設(shè)為 true否則后續(xù) SetAsWindowless 不會進(jìn)入離屏模式。第二個(gè)是background_color如果你要的是透明背景就要設(shè)成帶 alpha 的黑色0x00000000但注意這只在 GPU 合成時(shí)保留 alpha軟件路徑下不一定生效。第三個(gè)是multi_threaded_message_loop建議保持 false讓 CEF 跑在專用線程里方便你自己控制消息泵。bool RunBrowserProcess(CefMainArgs main_args, CefRefPtrCefApp app) { CefSettings settings; settings.no_sandbox true; // 演示環(huán)境方便調(diào)試生產(chǎn)環(huán)境按需開啟 settings.windowless_rendering_enabled true; // 進(jìn)入離屏渲染模式 settings.background_color 0xFF2B2B2B; // 不透明底色透明場景用 0x00000000 settings.log_severity LOGSEVERITY_WARNING; // 日志別太吵排錯時(shí)再調(diào) VERBOSE // 子進(jìn)程路徑不設(shè)置則默認(rèn)復(fù)用當(dāng)前 exe前提是上面 main 里做了 CefExecuteProcess 分支 // settings.browser_subprocess_path demo_helper.exe; CefInitialize(main_args, settings, app.get(), nullptr); // 之后進(jìn)入消息循環(huán) CefRunMessageLoop(); CefShutdown(); return true; }邏輯說明這一段的順序是有講究的。先設(shè) no_sandbox 再設(shè) windowless是避免某些平臺上沙箱和離屏模式互相干擾background_color 要按你的 UI 底色來很多黑屏問題就是這里用了純黑不透明值而頁面背景又是深灰色混在一起以為是渲染失敗。browser_subprocess_path我注釋掉了這是故意的——如果你的 exe 已經(jīng)做了 CefExecuteProcess 分流就不需要額外 helper 文件如果沒有你才需要指定一個(gè)能完整加載 CEF 的 helper 程序。參數(shù)調(diào)整時(shí)最容易踩的坑是改了 windowless_rendering_enabled 但沒重啟進(jìn)程CEF 有些設(shè)置在運(yùn)行時(shí)是不可變的。3.2 實(shí)現(xiàn) CefRenderHandler 的四個(gè)回調(diào)OSR 的本質(zhì)就是你實(shí)現(xiàn)一個(gè) CefRenderHandler把它綁定到瀏覽器窗口上。四個(gè)回調(diào)缺一不可GetViewRect 告訴 CEF 你的渲染區(qū)域多大OnPaint 接收軟件像素OnAcceleratedPaint 接收 GPU 紋理再就是鼠標(biāo)事件轉(zhuǎn)發(fā)。前兩個(gè)回調(diào)不實(shí)現(xiàn)瀏覽器直接不畫。class DemoOSRHandler : public CefRenderHandler { public: // 告訴瀏覽器離屏畫布的尺寸邏輯像素不是物理像素 void GetViewRect(CefRefPtrCefBrowser browser, CefRect rect) override { rect CefRect(0, 0, view_width_, view_height_); } // 軟件渲染路徑拿到像素矩形列表和編碼后的 RGBA 數(shù)據(jù) void OnPaint(CefRefPtrCefBrowser browser, PaintElementType type, const RectList dirtyRects, const void* buffer, int width, int height) override { if (type ! PET_VIEW) return; // 只關(guān)心主畫面不關(guān)心彈窗氣泡等覆蓋層 // 把 buffer 拷貝到你的共享內(nèi)存/紋理上傳隊(duì)列 UploadPixelsToEngine(buffer, dirtyRects, width, height); } // GPU 路徑拿到共享紋理句柄交給渲染線程注冊 GPU 資源 bool OnAcceleratedPaint(CefRefPtrCefBrowser browser, PaintElementType type, const RectList dirtyRects, const CefAcceleratedPaintInfo info) override { if (type ! PET_VIEW) return false; // info.shared_texture_handle 或 info.fd具體取法按平臺走 AttachSharedTexture(info); return true; } private: int view_width_ 1280; int view_height_ 720; };參數(shù)說明dirtyRects 表示這次哪些區(qū)域發(fā)生了變化。如果你只需要局部刷新可以按這個(gè)矩形列表去更新渲染引擎里的對應(yīng)區(qū)域這就是高性能省帶寬的基礎(chǔ)。width 和 height 是緩沖區(qū)的實(shí)際尺寸它一定大于等于上次 GetViewRect 給的值因?yàn)楦?DPI 屏幕上會有縮放緩沖區(qū)可能是邏輯尺寸的 2 倍你要按 width/height 來算像素偏移。OnAcceleratedPaint 里的 CefAcceleratedPaintInfo 在不同平臺字段不同Windows 是 shared_texture_handleLinux 是 fd 加上尺寸信息我一般會封裝一層平臺適配把這兩種情況統(tǒng)一成自己的 TextureHandle 結(jié)構(gòu)。鼠標(biāo)和鍵盤事件也要轉(zhuǎn)發(fā)到 CefBrowserHost否則頁面完全無法交互void SendMouseEvent(CefRefPtrCefBrowser browser, int x, int y, MouseButtonType btn, bool mouseUp, int modifiers) { CefMouseEvent ev; ev.x x; // 邏輯坐標(biāo)和 GetViewRect 坐標(biāo)系一致 ev.y y; ev.modifiers modifiers; if (btn MBT_LEFT) { browser-GetHost()-SendMouseClickEvent(ev, btn, false, mouseUp); } // 滾輪事件用 SendMouseWheelEvent }邏輯說明事件坐標(biāo)必須和 GetViewRect 的定義一致否則會出現(xiàn)「鼠標(biāo)點(diǎn)不到按鈕」的靈異問題。這個(gè)坐標(biāo)是邏輯像素如果你的宿主窗口在 Windows 上開啟了 DPI 縮放系統(tǒng)給你的是物理像素要先除以縮放系數(shù)再傳進(jìn)來。modifiers 要自己拼常見錯誤是只傳左鍵不傳 Shift/Ctrl導(dǎo)致頁面的多選、新標(biāo)簽頁中打開這類交互失效。3.3 像素到渲染引擎的兩種落地方式CPU 位圖 vs GPU 共享紋理拿到像素之后怎么送進(jìn)自己的渲染引擎是決定性能的分水嶺。第一種方式適合小窗口或低幀率在 OnPaint 里直接 memcpy 到一個(gè)固定緩沖區(qū)然后在渲染線程里 glTexSubImage2D 上傳。第二種方式適合 1080p 以上、幀率要 60 的場景走 OnAcceleratedPaint 拿到共享紋理句柄通過 glImportShareHandleEXT 或 D3D11 OpenSharedResource 把紋理引入自己的圖形 API 上下文整個(gè)過程零 CPU 拷貝。路徑輸出形式CPU 開銷延遲適用場景OnPaint glTexUploadRGBA 位圖高每幀拷貝高小面板、設(shè)置頁、低交互OnAcceleratedPaint 共享紋理GPU 紋理句柄極低低視頻播放、動畫、全屏 Web 內(nèi)容我見過一個(gè)視頻渲染工具最初用 OnPaint 路線跑 4K 60fps 的 Web 頁面CPU 占用直接拉滿到 80%后來切換成 OnAcceleratedPaint降到 15%畫面還更流暢。切紋理的代價(jià)是平臺代碼陡增Windows 上要處理 D3D11 共享資源的多線程安全Linux 上要處理 dmabuf 的跨設(shè)備問題。演示項(xiàng)目如果只是想先通起來建議先跑通 OnPaint 路徑確認(rèn)業(yè)務(wù)流程沒問題再在低耦合的位置換紋理路徑。4. 性能參數(shù)與調(diào)優(yōu)把能用變成流暢4.1 幀率控制與臟矩形別讓 OnPaint 拖垮你的 UI 線程很多人不知道 CEF 離屏模式有一個(gè)獨(dú)立的幀率控制參樹在 CefBrowserHost 上通過 SetWindowlessFrameRate(int) 設(shè)置默認(rèn)值各版本略有差異一般不超過 30。這意味著即使頁面里有 CSS 動畫你拿到的回調(diào)頻率也受這個(gè)限制。想要 60fps就要在創(chuàng)建瀏覽器后盡快調(diào)用GetHost()-SetWindowlessFrameRate(60)。但幀率不是越高越好如果頁面是純靜態(tài)的60fps 的調(diào)度本身就會持續(xù)喚醒渲染進(jìn)程白白消耗 CPU。我一般會在收到網(wǎng)絡(luò)請求完成、動畫結(jié)束之類的事件后把幀率切回 30 或 15交互時(shí)再切到 60。臟矩形是另一個(gè)關(guān)鍵的壓縮手段。OnPaint 回調(diào)里的 dirtyRects 已經(jīng)告訴你了哪些區(qū)域需要更新但實(shí)際工程里很多人不看它拿到整幀就上傳完全浪費(fèi)了 Chromium 好不容易算出來的局部性。正確的做法是把 dirtyRects 轉(zhuǎn)成 UV 坐標(biāo)上傳時(shí)用 glTexSubImage2D 只更新那幾塊區(qū)域。配合場景靜態(tài)檢測能省掉大量無意義的帶寬和上傳指令。注意臟矩形在 GPU 路徑下也存在但取紋理句柄后你沒法只摳局部——你拿到的是一整個(gè)紋理局部更新發(fā)生在紋理內(nèi)部所以 GPU 路徑下臟矩形更多用來做 UI 線程和渲染線程之間的同步信號而不是真的去裁剪紋理。4.2 幀數(shù)據(jù)通路設(shè)計(jì)單緩沖、雙緩沖還是環(huán)形隊(duì)列這里要區(qū)分 CPU 路徑和 GPU 路徑。CPU 路徑下OnPaint 是在 CEF 的 IO 線程或 UI 線程回調(diào)的如果你在里面直接操作渲染引擎的資源等于跨線程訪問圖形上下文輕則卡頓重則崩潰。常見做法是準(zhǔn)備兩到三個(gè)緩沖區(qū)做乒乓切換OnPaint 往空閑緩沖寫入渲染線程讀取上一次完成的那塊并上傳不共享同一塊內(nèi)存。class FrameBufferPool { public: FrameBufferPool(int w, int h, int count 3) { for (int i 0; i count; i) { buf_.push_back(std::shared_ptruint8_t( new uint8_t[w * h * 4], [](uint8_t* p) { delete[] p; })); } } std::shared_ptruint8_t AcquireWrite() { std::lock_guardstd::mutex lock(mtx_); auto it std::find_if(buf_.begin(), buf_.end(), [](auto p) { return p.use_count() 1; }); return *it; } private: std::vectorstd::shared_ptruint8_t buf_; std::mutex mtx_; };邏輯說明AcquireWrite 通過 shared_ptr 的 use_count 判斷哪個(gè)緩沖區(qū)當(dāng)前沒人引用這樣 OnPaint 和渲染線程之間不需要額外的同步鎖誰引用計(jì)數(shù)歸到 1 誰就是空閑的。緩沖區(qū)數(shù)量一般 3 個(gè)夠用2 個(gè)會經(jīng)?；ハ嗟却? 個(gè)以上白白吃內(nèi)存。參數(shù)調(diào)整的規(guī)律是分辨率越高緩沖區(qū)越吃內(nèi)存幀率越高需要的緩沖數(shù)越少——因?yàn)樯a(chǎn)者消費(fèi)者周期變短。GPU 路徑不需要這套池子但要做紋理生命周期管理從 OnAcceleratedPaint 拿到的共享紋理句柄必須在當(dāng)前幀引用的反射里顯式釋放否則紋理泄漏在 Windows 上特別明顯跑一個(gè)小時(shí)顯存漲上百 MB。4.3 實(shí)測方法與判斷指標(biāo)幀延遲、CPU 占用、字體閃爍性能優(yōu)化永遠(yuǎn)要有數(shù)據(jù)支撐。我的驗(yàn)證手段分三層第一層看綜合指標(biāo)用 PresentMon 抓 CPU/GPU 幀耗時(shí)用 CE 自帶的--enable-logging --v1看瀏覽器端的丟幀日志第二層看端到端延遲在頁面里放一個(gè) requestAnimationFrame 的時(shí)間戳在引擎?zhèn)葘Ρ燃y理采樣時(shí)刻就能算出完整的端到端延遲這個(gè)值是最能體現(xiàn) OSR 體驗(yàn)的第三層是肉眼檢查異?，F(xiàn)象比如字體閃爍、滾動時(shí)文字撕裂、視頻畫面偶發(fā)黑幀。幀率上限設(shè)置得是否合理直接觀察 CPU 占用和幀耗時(shí)是否呈明顯臺階關(guān)系。如果你發(fā)現(xiàn)幀率上限 60 和 30 時(shí) CPU 占用幾乎一樣那說明瓶頸不在瀏覽器端而在你的渲染引擎上傳路徑上如果 30 幀時(shí) CPU 只有 10%60 幀時(shí)瞬間 50%那瓶頸在 Chromium 的合成和拷貝這時(shí)候才值得去調(diào)窗口大小、換紋理路徑或降低分辨率。字體閃爍是另一個(gè)高頻怪現(xiàn)象通常是因?yàn)榕K矩形沒合并、局部更新和滾動不同步造成的處理辦法是每次滾動開始時(shí)暫時(shí)切到全量刷新滾動停止后再回到局部更新。5. 避坑OSR 項(xiàng)目里翻車最多的 5 個(gè)地方5.1 窗口尺寸為 0 導(dǎo)致的永遠(yuǎn)白屏現(xiàn)象程序啟動后窗口位置是出來了但頁面始終白屏沒有任何繪制回調(diào)日志也沒有明顯錯誤。 原因GetViewRect 在初始化時(shí)返回了 (0, 0) 尺寸或者 host 創(chuàng)建時(shí)窗口參數(shù)里給的寬高為 0。CEF 在尺寸為 0 時(shí)不會觸發(fā)首幀繪制。 解決在創(chuàng)建瀏覽器之前確定初始尺寸GetViewRect 里不能依賴尚未完成的異步布局。我一般會在初始化參數(shù)里寫死默認(rèn)寬度和高度等宿主窗口真正 resize 時(shí)再調(diào)browser-GetHost()-NotifyMoveOrResizeStarted()以及更新 handler 里的 view_width_ 和 view_height_而不是在 GetViewRect 里動態(tài)去查。5.2 鼠標(biāo)點(diǎn)擊位置和頁面元素對不上現(xiàn)象點(diǎn)擊按鈕時(shí)總偏斜尤其是高 DPI 屏幕下點(diǎn)不中按鈕或者點(diǎn)擊位置往右下角偏。 原因宿主系統(tǒng)的鼠標(biāo)事件是物理像素坐標(biāo)而 CEF 的 OSR 坐標(biāo)是 DIP設(shè)備無關(guān)像素Windows 上默認(rèn)縮放 125% 或 150% 時(shí)兩者差了一個(gè) ScaleFactor。 解決在 SendMouseEvent 前做一次坐標(biāo)轉(zhuǎn)換dip_x physical_x / dpi_scaledpi_scale 用 GetDpiForWindow 或 QScreen 的 devicePixelRatio 獲取。不要在 GetViewRect 里把 rect 的寬高除以縮放那樣會破壞 CEF 內(nèi)部的緩沖尺寸計(jì)算只在事件入口做轉(zhuǎn)換像素緩沖的尺寸由 CE 自己按 DPI 調(diào)整。5.3 視頻播放黑屏或綠屏現(xiàn)象頁面里的video標(biāo)簽有聲音但畫面是黑屏或者 GPU 路徑下偶爾出現(xiàn)綠屏條帶。 原因CEF 的 GPU 進(jìn)程默認(rèn)采用硬件視頻解碼解碼后的數(shù)據(jù)在合成時(shí)要走共享紋理如果你的 OSR 是軟件路徑OnPaint合成器無法把硬件解碼幀導(dǎo)入位圖回調(diào)反過來GPU 路徑下共享紋理格式不匹配或者句柄泄漏會導(dǎo)致綠屏。 解決演示和低性能場景直接關(guān)閉硬件加速settings.no_sandbox true并在命令行加--disable-gpu性能要求高的場景走 OnAcceleratedPaint 并保證共享紋理的句柄在你的圖形上下文里做了正確的 OpenSharedResource 操作同時(shí)每幀 refs 用完釋放。5.4 中文輸入法不彈候選詞或候選框位置錯亂現(xiàn)象OSR 下輸入中文時(shí)輸入法候選框要么不出現(xiàn)要么出現(xiàn)在屏幕左下角而不是光標(biāo)附近。 原因CEF 的 OSR 不創(chuàng)建原生窗口所以 IMM/TSF 和瀏覽器之間的消息通道斷裂候選框位置需要宿主自己通過 CefRenderHandler 的 GetScreenPoint 回調(diào)把編輯框坐標(biāo)轉(zhuǎn)成屏幕坐標(biāo)喂給系統(tǒng)。 解決先確認(rèn) CefRenderHandler 里實(shí)現(xiàn)了 GetScreenPoint把傳入的 view 坐標(biāo)加上瀏覽器窗口在屏幕上的位置偏移返回正確的屏幕坐標(biāo)然后需要把焦點(diǎn)管理做好每次點(diǎn)擊 OSR 區(qū)域時(shí)調(diào)host-SetFocus(true)并用SendFocusEvent(true)通知頁面。這在 Windows 上很費(fèi)時(shí)間我的建議是先用英文交互驗(yàn)證業(yè)務(wù)邏輯等核心鏈路跑通再補(bǔ) IME避免兩頭都卡住。5.5 子進(jìn)程路徑不匹配導(dǎo)致的進(jìn)程反復(fù)崩潰現(xiàn)象頁面加載到 30% 就崩主進(jìn)程日志反復(fù)出現(xiàn) renderer process gone甚至主程序一啟動就異常退出。 原因main 函數(shù)里沒做 CefExecuteProcess 分流同時(shí)把 CefSettings.browser_subprocess_path 指向了一個(gè)不存在或者不是同一套 CEF 庫的 exe。CEF 的瀏覽器進(jìn)程和渲染進(jìn)程要通過同一個(gè) IPC 通道通信二進(jìn)制不匹配或入口不對就沒法建立通道。 解決優(yōu)先采用「自己的子進(jìn)程」方案即在 main 開頭統(tǒng)一調(diào)用 CefExecuteProcess讓同一個(gè) exe 同時(shí)承擔(dān)主進(jìn)程和子進(jìn)程兩種角色。這樣交付物只有一個(gè)文件路徑問題天然消失。確認(rèn)分流代碼沒有跑錯分支——主進(jìn)程調(diào)用 CefExecuteProcess 返回 -1 是正常的0 表示子進(jìn)程邏輯已執(zhí)行完畢要繼續(xù)往下走的只有 -1 這一條路。6. 進(jìn)階從演示到產(chǎn)品的最后幾公里演示 zip 跑通之后真正上生產(chǎn)前還有三件事值得認(rèn)真處理。透明度是第一個(gè)坎。OSR 默認(rèn)背景是不透明灰色你要在 settings.background_color 里設(shè)置帶 alpha 的值同時(shí)頁面的根元素也要是透明背景兩層有一層不干凈就會前功盡棄。驗(yàn)證透明是否真的生效不要用截圖工具直接在你的引擎里去采樣紋理的 alpha 通道截圖工具會把窗口背景合成進(jìn)去造成假性成功。鍵盤焦點(diǎn)和 IME 的完整鏈路是第二個(gè)坎。窗口模式瀏覽器遇到 Tab 鍵焦點(diǎn)循環(huán)會自己處理OSR 下 Tab 鍵要轉(zhuǎn)發(fā)給 CE 的 SendKeyEvent焦點(diǎn)切換信號要反饋給宿主窗口系統(tǒng)。IME 部分建議在 Windows 平臺優(yōu)先實(shí)現(xiàn) TSF 相關(guān)的 CefRenderHandler 回調(diào)這條路上沒有捷徑但可以先用--enable-featuresTSF開啟 CE 對 TSF 的支持減少一部分自研工作量。多窗口 OSR 是第三個(gè)坎。CEF 一個(gè) browser 實(shí)例對應(yīng)一個(gè)獨(dú)立頁面多窗口場景要共用同一個(gè) CefApp 和 CefRequestContext避免每個(gè)窗口單獨(dú)初始化 Chromium內(nèi)存會爆炸。正確的做法是先初始化一次全局環(huán)境然后按窗口創(chuàng)建多個(gè) CefBrowserFrameRate 和緩沖區(qū)管理要獨(dú)立避免相互搶占線程。最后說一個(gè)我踩了一年才改過來的習(xí)慣把 OnPaint 和 OnAcceleratedPaint 路徑做成可切換的編譯開關(guān)而不是長期只保留一條。因?yàn)椴煌蛻魴C(jī)器的顯卡驅(qū)動兼容性差異很大有的機(jī)器 OnAcceleratedPaint 能拿到紋理有的就會崩成黑匣子保留 CPU 路徑作為兜底是 OSR 產(chǎn)品上線冷靜期的后悔藥。我自己做最后一個(gè) OSR 項(xiàng)目時(shí)初期沒留這條后路結(jié)果在批量部署時(shí)遇到一批集顯驅(qū)動的兼容問題硬生生加了兩周排期。希望你不用走這條彎路——先抄上面的最小工程把切換開關(guān)留好再慢慢調(diào)幀率、換紋理穩(wěn)著來。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取