這裡記錄一些關于在Windows上調試CEF/Chromium/WebRTC源碼的一些心得體會，也是怕時間久了就忘記了其中一些細節。
因為經常有需要對CEF以及WebRTC的源碼進行分析和修改，是以修改後如何調試就成了首要解決的問題。CEF，或者說Chromium與普通的小工程不同，他的龐大是衆所周知的。是以為什麼Google專門創造了GN和ninja。
在編譯了CEF以後，在out目錄下會有各種版本的編譯中間代碼檔案、二進制檔案等等，包括以下目錄：
Debug_GN_x64\
Debug_GN_x64_sandbox\
Debug_GN_x86\
Debug_GN_x86_sandbox\
Release_GN_x64\
Release_GN_x64_sandbox\
Release_GN_x86\
Release_GN_x86_sandbox\
以 Debug_GN_x86 舉例，這裡面有一個1MB多的 cef.sln檔案，如果用Visual Studio 2017打開它，在解決方案清單裡，你會看到一個超級超級長的project清單，整個工程加載也是需要很長的時間。我目前的筆記本是 i7 8550，16G，海康威視SSD，加載速度也是讓我不太能夠忍受的。而且經常動不動Visual Studio 2017就崩潰重新開機了。
是以，如果不用 cef.sln，我們怎麼調試CEF以及WebRTC呢？
我這裡提供一種方法，就是代碼的浏覽、修改使用VS Code或VS 2017（直接打開.h/.cc檔案），修改後，使用ninja在指令行中手動編譯，然後把CEF示例程式（例如cefclient.exe）運作起來，之後在Visual Studio 2017中打開需要調試的代碼，設好斷點，之後用 Debug菜單下的 Attach to process 指令，attach到對應的程序上（由于Chromium是多程序架構，是以需要根據調試内容attach到不同的程序）。
如果你打開的源碼正确，斷點也確定可以執行到，且attach到的程序也正确，那麼當你在CEF中執行相應功能時候，就會發現在Visual Studio 2017中，你剛才設定的斷點生效了。
下面舉個例子，比如我想看一下在CEF中使用js建立一個H.264編碼的視訊流，WebRTC是如何建立和初始化H.264編碼器的，以及編碼視訊幀的函數調用。按照上面介紹的方法，我們需要先找到CEF中，WebRTC H.264編碼器的源碼在哪裡：
\src\third_party\webrtc\modules\video_coding\codecs\h264\h264_encoder_impl.h/.cc
注：由于WebRTC代碼變化頻繁，本文以CEF 3729（對應的WebRTC版本是M74分支）為藍本介紹。
啟動Visual Studio 2017，打開h264_encoder_impl.cc，并随便在幾個函數入口設定斷點。例如在 H264EncoderImpl構造函數，InitEncode()、Encode()我設定了3個斷點：
然後在指令行中運作 out\Debug_GN_x86\cefclient.exe，啟動指令行參數我指定的是：
--enable-media-stream --no-proxy-server --ignore-certificate-errors --enable-logging --v=1
參數說明：
--enable-media-stream：授權CEF可以使用本地攝像頭麥克風裝置
--no-proxy-server：防止Debug版本的cefclient崩潰
--ignore-certificate-errors：我用來測試的頁面是https的但是我沒有配置站點證書，用這個來忽略一下
--enable-logging --v=1：啟用詳細日志。預設會産生在指令行視窗以及産生一個debug.log檔案（和cefclient.exe同級目錄下）
更多的啟動參數，可以參考：https://peter.sh/experiments/chromium-command-line-switches/
在啟動的cefclient.exe浏覽器視窗中，打開用于視訊推流測試網頁，先不要執行推流。
回到Visual Studio 2017，執行 Debug菜單下的Attach to process，會發現程序清單裡有3個cefclient.exe：
視訊的編碼不再主程序（有标題文字的那個），在另外的一個程序中。由于另外的2個程序沒有标題，是以需要逐一試一下。
attach到指定的程序以後，VS2017進入調試模式。現在我們回到網頁，開始執行視訊推流：
按下推流按鈕，果然如我們期望的，在VS2017中，我們剛剛在H264EncoderImpl的構造函數中設定的斷點生效了，程式停留在我們設定的斷點位置，相關變量的值，以及程式調用堆棧，一覽無餘。
F5運作，會發現我們剛才設定的其他兩處斷點也相繼生效了：
OK，這種調試方法，不需要打開整個sln工程，避免檢視龐大的project清單，避免啟動慢、解析慢等問題。缺點是需要你對CEF、WebRTC代碼工程源碼結構有一定的了解，以便準确知道你要調試内容的源碼位置并直接打開。
最後介紹一下修改CEF/WebRTC源碼後的編譯方法。
在首次全量編譯CEF的時候，我們一般是使用CEF官網提供的 automate-git.py完成的，這個python腳本集下載下傳、編譯、打包為一體，在網絡代理（你懂得）強大的情況下，用這個腳本是十分輕松友善的。但是如果我們隻修改了幾個檔案，就不用再動用automate-git.py了，隻需要使用 ninja指令來編譯即可。
舉例如下，我們随便修改一個檔案，例如：\src\third_party\webrtc\video\video_stream_encoder.cc，我随便挑了一個函數 VideoStreamEncoder::ConfigureEncoderOnTaskQueue()，修改了一條日志語句，加了幾個字元：
修改以後，在指令行視窗中轉到CEF的src目錄下，運作以下指令：
ninja -C out\Debug_GN_x86 cefclient
ninja将會幫我們進行針對修改部分的增量編譯。在我機器上，即便隻是修改了剛才那一個地方，用ninja也編譯了幾分鐘……不知道到底是機器性能不行還是真的編的慢……
OK，編譯成功後，再次啟動cefclient.exe（别忘記增加 --enable-logging --v=1），執行視訊推流，然後在cefclient.exe同級目錄下找到debug.log，打開，搜尋關鍵字：ConfigureEncoder，會看到，我們剛才的修改生效了：
當然，直接把源碼拖到VS 2017中調試，不在debug.log中檢視也是可以的。
好了，工欲善其事必先利其器，掌握了基本的編譯和調試方法，對CEF/WebRTC代碼的研究和修改、試驗就友善多了。
除此以外，閱讀一下Debugging Chromium on Windows，也會得到不小的收獲