CEF的异步CreateBrowser造成的问题及解决方案

图片由 Google Gemini 3 Pro + Nano Banana Pro 生成

公司有个软件，用到了 CEF 浏览器。CEFWebClient 是一个 CEFClient 的子类，作为一个子窗口放在另外一个由我们软件控制生命周期的父窗口中的。这个父窗口的创建，有时候是自动的，而且可能会短期内进行多次。因此，我们遇到了一个问题：如果父窗口太快被「干掉」，那么可能会 Crash。

父窗口的这个行为，当然可以被认为是「不正常」。但首先我的问题是「为什么」。为什么会出现这种事情？

一年前，查这个问题费了我不少时间和精力。本文主要是把相关经验给传承下去，因此接下来我就尽量长话短说了。

CEF 中创建浏览器的方法是先 new 一个 CEFWebClient，放在智能指针里面，然后交给 CefBrowserHost::CreateBrowser() 去创建窗口。这一步许多人都知道，教程和文档上都是这样写的。不太为人所知的细节是：CefBrowserHost::CreateBrowser() 可能是异步的。

这里就要介绍一些上下文了。
跟 Demo 不同，我们的软件，把 multi_threaded_message_loop 设置为 true。几乎是必须如此，因为这个程序并不单纯是个浏览器而已，没法把主线程消息循环让给 CEF。
在多线程模式下，CEF 会有自己的一些线程用来干活。包括创建浏览器窗口这种事情，也是在它的线程中，而不是调用线程或主线程。

因此，CefBrowserHost::CreateBrowser() 是在另一个线程中进行的。这一点我一开始确实没想到，建个窗口而已，谁会想到 CEF 要搞成异步的啊？官方文档也没强调这个事实。这导致调用线程在函数调用返回时，浏览器窗口还没真正创建起来，只是把这个任务给安排了下去而已。如果父窗口在浏览器窗口真正创建前被销毁了，实际创建浏览器窗口的时候就会出问题。

我们的调用线程其实就是主线程，一开始尝试了让主线程等着，但不行。不管是用信号同步，还是用个 while 循环暴力堵住，都会导致死锁。很明显，CefBrowserHost::CreateBrowser() 在子线程中先是作了一些准备工作，然后又用到了主线程，毕竟创建窗口只可能在主线程中进行。可能是一个 SendMessage 类似的操作。我们是直接用了 Spotify 预编译好的 CEF 二进制分发包，并没有从 CEF 源代码从头编译，所以没有往里面深究。总之如果不把主线程空出来，后面的事情没法继续。

简单休眠 20ms 再放行貌似就可以解决问题，似乎是因为工作线程那边的准备工作已经完成了，已经能够正确应对父窗口被销毁这种事情了。但 20ms 时间够不够？谁知道呢。肯定不能靠这种方式在生产环境上运作。最好是有个判断标志可以判断出准备工作做完了没有，但目前 CEF 对我们来说是个黑盒，也没留这个窗口，我们只能想办法去探上一探。

CefBrowserHost::CreateBrowser() 的第二个参数，是个 CefRefPtr 智能指针，具备引用计数。这个引用计数，对调试器是可见的。我盯着看了一阵子，发现只要引用计数上升到一定程度再放行，就没有问题。貌似工作线程在「准备阶段」把这个智能指针挂到了主线程够得着的地方了，以便创建窗口时访问。只要这个操作已经完成，此后即使父窗口被析构，引用计数也不会有被降为 0 的担忧，后面就能正常工作下去。

这个引用计数在cef_base.h里面，class CefRefCount的私有成员，

//
// Class that implements atomic reference counting.
///
class CefRefCount {
 public:
  CefRefCount() : ref_count_(0) {}

  ///
  // Increment the reference count.
  ///
  void AddRef() const { base::AtomicRefCountInc(&ref_count_); }

  ///
  // Decrement the reference count. Returns true if the reference count is 0.
  ///
  bool Release() const { return !base::AtomicRefCountDec(&ref_count_); }

  ///
  // Returns true if the reference count is 1.
  ///
  bool HasOneRef() const { return base::AtomicRefCountIsOne(&ref_count_); }

  ///
  // Returns true if the reference count is at least 1.
  ///
  bool HasAtLeastOneRef() const {
    return !base::AtomicRefCountIsZero(&ref_count_);
  }

 private:
  mutable base::AtomicRefCount ref_count_;
  DISALLOW_COPY_AND_ASSIGN(CefRefCount);
};

还好是在头文件里面，而且只是一个权限问题，因此连重新编译 libcef_dll_wrapper.lib 都不需要。魔改了一下，我们就这样用下去了。

至于引用计数要增加到多少才算是可以放行，我们取了一个经验数据。但这个方案我们一直用得有点担心。最后还是遇到了问题。重现出来一查，就是这个经验数据不再适用了。

正确的解决方案，还是要回到 CEF 的官方机制 OnAfterCreated() 上来。
官方是这样说的：一个 CefBrowser 有没有创建成功，一定要等到 OnAfterCreated() 被调用。不管是要干什么正经事情，还是要「去死」，都得等到它调用了以后。
实际试下来，虽然 OnAfterCreated() 的调用比引用计数「到位」要迟，但的确可以保证不出事情。

所以事情其实没有那么复杂：如果 OnAfterCreated() 还没被调用到，那么就不能关闭父窗口。不能关闭怎么办？先把窗口给 SW_HIDE 了，然后向 CEFWebClient 作个标记。等到 OnAfterCreated() 被调用的时候，再向父窗口发个消息让它自己销毁，调 DestroyWindow() 就行。

经验教训是：一切还得按规矩办。自己想土办法，或许能在某些场合解决问题，但终究不是长治久安之策。
但是，虽然没有看或调试源代码，不过这次也算是刺探了一下 CEF 的一些内部运行机制，也是有好处的。