chrome瀏覽器二次開發和chromium源碼編譯官方教程中文版(windows)
其他平台的説明請參見 獲取代碼 頁面中的鏈接。
谷歌員工專用説明
您是 Google 員工嗎?請改為查看 go/building-chrome-win。
系統要求
- 一台 x86-64 架構的機器,至少 8GB 內存,建議使用超過 16GB 內存。
- 至少 100GB 的可用磁盤空間,且硬盤必須為 NTFS 格式。FAT32 格式無法使用,因為某些 Git 包文件大於 4GB。
- 下文所述版本的 Visual Studio。
- Windows 10 或更高版本。
設置 Windows 環境
Visual Studio
Chromium 構建需要 Visual Studio 2022(版本 ≥17.0.0)。Visual Studio 也可用於調試 Chromium。
雖然使用的是 clang-cl 編譯器,但仍然需要 Visual Studio 的頭文件、庫和部分工具。Visual Studio Community Edition 也可以使用,只要它的許可證適用於您即可。必須安裝 “使用 C++ 的桌面開發” 組件和 “MFC/ATL 支持” 子組件。可以通過命令行傳遞以下參數給 Visual Studio 安裝器來完成安裝(ARM64 安裝説明見下):
$ PATH_TO_INSTALLER.EXE ^
--add Microsoft.VisualStudio.Workload.NativeDesktop ^
--add Microsoft.VisualStudio.Component.VC.ATLMFC ^
--includeRecommended
如果您希望構建 ARM64 Win32,則還需要一些額外參數。完整參數如下:
$ PATH_TO_INSTALLER.EXE ^
--add Microsoft.VisualStudio.Workload.NativeDesktop ^
--add Microsoft.VisualStudio.Component.VC.ATLMFC ^
--add Microsoft.VisualStudio.Component.VC.Tools.ARM64 ^
--add Microsoft.VisualStudio.Component.VC.MFC.ARM64 ^
--includeRecommended
必須安裝的組件:
- Windows 11 SDK,版本 10.0.26100.3323。可以單獨安裝,也可以在 Visual Studio 安裝器中勾選相應選項安裝。
- (Windows 11)SDK 調試工具,版本 10.0.26100.3323 或更高。Chrome 使用了大頁面 PDB 文件(支持超過 4 GiB 的 PDB 文件),需要這個版本的調試工具。如果當前 SDK 安裝中未包含調試工具,可以按以下路徑安裝:
控制面板 -> 程序和功能 -> Windows 軟件開發工具包 [版本] -> 更改 -> Windows 調試工具。
如果是在 ARM64 Windows 上構建 Chromium,無論構建的是 x64 還是 ARM64,都需要從另一台機器上手動複製 Debuggers\x64 目錄,因為該目錄不會在 ARM64 上自動安裝,但卻是必要的。
警告: 在較舊版本的 Windows(1909 或更早)中,使用 26100 SDK 時,dawn 或相關組件可能因 D3D 相關錯誤而失敗。這是因為新 SDK 中的 d3dcompiler_47.dll 文件嘗試動態鏈接某些舊系統中默認缺失的 Universal C Runtime(UCRT)版本。如果遇到此類錯誤,可以選擇更新系統的 UCRT,或者安裝 22621 SDK,並使用其中的 d3dcompiler_47.dll 文件(該版本使用靜態鏈接的 UCRT)。
此問題也可能表現為 DLL 加載失敗,並出現 __CxxFrameHandler4 無法加載的錯誤。
安裝 Git
安裝 Git
如果你以前沒有直接安裝過 git,可以從 Git 官網下載最新版本的 Git for Windows 獨立安裝程序:
https://git-scm.com/download/win
有關 Git for Windows(它是一個獨立於 Git 的項目)的更多信息,請訪問:
https://gitforwindows.org
注意: 如果你是 Google 員工,請查看 go/building-chrome-win 上的 Git 安裝説明。
更新 Git
注意: 本節內容是關於更新直接安裝的 git,因為 depot_tools 很快將不再捆綁 git。
更新到最新版本的方法取決於你當前安裝的版本。首先,在 cmd.exe 命令行窗口中運行以下命令查看版本:
$ git version
| 當前版本 | 如何更新到最新版 |
|---|---|
2.14.1 或更早 |
需要手動卸載 Git,然後按照上面的安裝 Git説明重新安裝 |
2.14.2 到 2.16.1 |
在 cmd.exe 中運行:git update |
2.16.1(2) 及更高版本 |
在 cmd.exe 中運行:git update-git-for-windows |
安裝 depot_tools
在命令行窗口中,切換到你希望存放 depot_tools 的目錄,並克隆 depot_tools 倉庫。例如,如果你想克隆到 C:\src\depot_tools:
$ cd C:\src
$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
將 depot_tools 添加到系統 PATH 的開頭位置(必須位於任何 Python 安裝目錄之前。注意環境變量名稱不區分大小寫)。
- 假設你將倉庫克隆到了
C:\src\depot_tools,打開:
控制面板 → 系統和安全 → 系統 -
選擇要編輯的 PATH 變量:
- 如果你擁有管理員權限,可以編輯 系統級 PATH。點擊“高級系統設置” → “環境變量”,在“系統變量”中選擇
Path進行編輯。 - 如果你沒有管理員權限,可以編輯你的 用户級 PATH。搜索“為你的賬户編輯環境變量”,在“用户變量”中選擇
Path進行編輯。
- 如果你擁有管理員權限,可以編輯 系統級 PATH。點擊“高級系統設置” → “環境變量”,在“系統變量”中選擇
- 修改 PATH 變量,將
C:\src\depot_tools添加到最前面(至少要在任何已有的 Python 路徑前面)。
注意: 如果你只能修改用户級 PATH,而系統 PATH 中存在 Python 路徑,那麼你可能會遇到問題。
此外,還需要以同樣的方式添加一個名為 DEPOT_TOOLS_WIN_TOOLCHAIN 的環境變量,並將其值設置為 0,表示 depot_tools 使用本地安裝的 Visual Studio(默認情況下它會嘗試使用 Google 內部版本)。
你可能還需要設置一個名為 vs2022_install 的變量,指定你的 Visual Studio 2022 安裝路徑,例如:
set vs2022_install=C:\Program Files\Microsoft Visual Studio\2022\Professional
在 cmd.exe 命令行窗口中運行:
$ gclient
首次運行時,gclient 會安裝所有在 Windows 上使用代碼所需的內容,包括 msysgit 和 python。
- 如果你不是從
cmd.exe運行gclient(例如使用 cygwin 或 PowerShell),雖然看起來運行正常,但 msysgit、python 以及其他工具可能不會被正確安裝。 - 如果你在第一次運行
gclient時遇到文件系統相關的奇怪錯誤,建議關閉 Windows 索引功能。
檢查 Python 安裝
運行 gclient 之後,打開命令提示符,輸入以下命令確認 depot_tools 中的 python3.bat 優先於系統中其他 python3.exe:
where python3
如果沒有優先設置,使用 gn 構建時可能會導致過度構建(overbuilding),詳見 crbug.com/611087。
App 執行別名 可能與系統中其他 Python 安裝衝突。建議禁用 “App Installer” 創建的 python.exe 和 python3.exe 別名,方法如下:
- 打開控制面板中的 App execution aliases。
- 找到
python.exe和python3.exe,取消勾選“App Installer”旁邊的選項。
獲取代碼
首先配置 Git:
$ git config --global user.name "My Name"
$ git config --global user.email "my-name@chromium.org"
$ git config --global core.autocrlf false
$ git config --global core.filemode false
$ git config --global core.preloadindex true
$ git config --global core.fscache true
$ git config --global branch.autosetuprebase always
雖然不是強制要求,但建議啓用長路徑支持(支持超過 Windows 的 MAX_PATH 限制):
git config --global core.longpaths true
創建一個用於檢出 Chromium 代碼的目錄並進入該目錄。該目錄名稱和路徑可以自定義,只要路徑中不包含空格。不過,Google 員工若將其放在 C:\src\ 下會有性能優勢(參考:為什麼構建變慢?)。
$ mkdir chromium && cd chromium
使用 depot_tools 中的 fetch 工具來獲取代碼和所有依賴:
$ fetch chromium
如果你不需要完整的提交歷史,可以加 --no-history 參數加快速度:
$ fetch --no-history chromium
注意:即使在快速網絡環境下也可能耗時超過一小時,慢速網絡可能需要數小時。建議關閉電腦的睡眠和休眠功能以避免中斷。如遇到獲取子倉庫失敗的錯誤,可以重新開始,也可以進入 chromium/src 目錄執行以下命令嘗試修復:
$ gclient sync
fetch 完成後,會生成一個 .gclient 文件和一個名為 src 的目錄。之後的命令都假設你已進入該 src 目錄:
$ cd src
可選: 若希望構建過程中訪問某些 Google 服務,可以配置 API 密鑰,但大多數開發和測試場景下不需要。
設置構建環境
Chromium 使用 Ninja 作為構建工具,配合 GN 生成 .ninja 文件。你可以創建多個構建目錄,適配不同配置:
$ gn gen out\Default
説明:
- 每個構建目錄只需運行一次該命令,Ninja 會根據需要更新構建文件。
- 可以將
Default替換為其他名稱,但必須是out的子目錄。 - 如需瞭解發佈構建、使用其他 VS 版本等配置,請查看 GN 構建配置。
- 默認生成的是一個調試版、組件化構建(debug component build)。
查看更多 GN 信息可運行:
gn help
或參考 GN 快速入門。
加快構建速度的建議
- 將構建目錄從殺毒軟件和 Windows 索引中排除。
- 構建目錄應位於高速磁盤(如 SSD)上。
- CPU 核心越多越好(20+ 並不算多),內存越多越好(64 GB 也不誇張)。
建議使用以下 GN 參數優化構建速度,可在運行 gn gen 時添加 --args,或使用 gn args out\Default 進入編輯器設置:
gn gen out\Default --args="is_component_build=true enable_nacl=false blink_symbol_level=0 v8_symbol_level=0 symbol_level=1"
各參數含義如下:
is_component_build = true:使用更多但較小的 DLL,可能避免頻繁 relinkchrome.dll。enable_nacl = false:禁用 Native Client,本地構建通常不需要。target_cpu = "x86":生成 x86 構建,速度可能稍快。但需搭配enable_nacl=false,否則構建時間反而更長。blink_symbol_level = 0:關閉 Blink 的源碼調試信息,適用於不調試 Blink 的情況。v8_symbol_level = 0:關閉 V8 的源碼調試信息,適用於不調試 V8 的情況。-
symbol_level = 1或0:加快鏈接速度:symbol_level = 1:保留源碼行號,無變量類型信息。-
symbol_level = 0:不保留源碼調試信息,但函數名可用於堆棧追蹤。更改該參數需重新編譯所有內容。
使用 Ninja 構建時,指定 chrome 作為目標可避免構建所有測試目標:
$ autoninja -C out\Default chrome
使用 Reclient
此外,Google 員工應使用 Reclient,這是一種分佈式編譯系統。相關的 gn 參數為:
use_remoteexec = true
Google 員工可以訪問 go/building-chrome-win#setup-remote-execution 獲取更多信息。對於外部貢獻者,Reclient 不支持 Windows 構建。
使用 SCCACHE
你也許可以通過啓用以下參數,使用 sccache 來加速構建過程:
cc_wrapper = "sccache"—— 假設sccache可執行文件已加入%PATH%中
為什麼構建很慢?
構建速度慢可能由多種原因引起,Windows Defender 減緩進程啓動是一個常見問題。你是否確保整個 Chromium 的 src 目錄已被排除在殺毒掃描之外(在 Google 的設備上,這意味着將其放在某個磁盤根目錄下的 src 目錄中)?你是否嘗試了上面列出的不同設置,包括不同的鏈接設置和 -j 參數?你是否在 chromium-dev 郵件列表中詢問過,看看你的構建是否比同配置的機器預期更慢?
如果你懷疑 Defender 導致構建變慢,可以使用微軟的 Microsoft Defender Antivirus 性能分析器 進行深入分析。
接下來是收集數據。如果你設置環境變量 NINJA_SUMMARIZE_BUILD 為 1,autoninja 將執行三件事。首先,它會設置 NINJA_STATUS 環境變量,使得 ninja 在構建過程中輸出更多信息,包括當前運行的構建進程數、已完成的構建步驟數、每秒完成的構建步驟數以及構建已運行的時間,如下所示:
$ set NINJA_SUMMARIZE_BUILD=1
$ autoninja -C out\Default base
ninja: Entering directory `out\Default'
[1 processes, 86/86 @ 2.7/s : 31.785s ] LINK(DLL) base.dll base.dll.lib base.dll.pdb
這樣可以立刻發現是否進程創建過慢,並快速判斷構建是否比平常慢。
此外,設置 NINJA_SUMMARIZE_BUILD=1 後,autoninja 會在構建完成時打印構建性能摘要,顯示最慢的構建步驟和構建步驟類型,如下:
$ set NINJA_SUMMARIZE_BUILD=1
$ autoninja -C out\Default base
最長的構建步驟:
0.1 加權秒 來構建 obj/base/base/trace_log.obj(耗時 6.7 秒)
0.2 加權秒 來構建 nasm.exe, nasm.exe.pdb(耗時 0.2 秒)
0.3 加權秒 來構建 obj/base/base/win_util.obj(耗時 12.4 秒)
1.2 加權秒 來構建 base.dll, base.dll.lib(耗時 1.2 秒)
各類構建步驟耗時:
0.0 秒加權時間來生成 6 個 .lib 文件(總耗時 0.3 秒)
0.1 秒加權時間來生成 25 個 .stamp 文件(總耗時 1.2 秒)
0.2 秒加權時間來生成 20 個 .o 文件(總耗時 2.8 秒)
1.7 秒加權時間來生成 4 個 PEFile(鏈接)文件(總耗時 2.0 秒)
23.9 秒加權時間來生成 770 個 .obj 文件(總耗時 974.8 秒)
26.1 秒加權時間(總耗時 982.9 秒,37.7 倍並行度)
完成了 839 個構建步驟,平均每秒 32.17 個
“加權”時間是每個構建步驟的耗時除以並行運行的任務數量。這很好地反映了一個步驟的“重要性”。如果鏈接過程是串行執行的,那麼其加權時間與實際耗時接近;而一個與 999 個其他編譯並行運行的編譯過程,其加權時間會非常小。
你也可以在構建後手動運行腳本來生成這些報告:
$ python depot_tools\post_build_ninja_summary.py -C out\Default
最後,設置 NINJA_SUMMARIZE_BUILD=1 會讓 autoninja 向 ninja 傳遞 -d stats 參數,讓它報告自身開銷,這在分析由於 clang-cl 不在排除目錄下導致殺毒軟件干擾、進程創建緩慢(在 StartEdge 指標中體現)等問題時非常有用:
$ set NINJA_SUMMARIZE_BUILD=1
$ autoninja -C out\Default base
metric count avg (us) total (ms)
.ninja parse 3555 1539.4 5472.6
canonicalize str 1383032 0.0 12.7
canonicalize path 1402349 0.0 11.2
lookup node 1398245 0.0 8.1
.ninja_log load 2 118.0 0.2
.ninja_deps load 2 67.5 0.1
node stat 2516 29.6 74.4
depfile load 2 1132.0 2.3
StartEdge 88 3508.1 308.7
FinishCommand 87 1670.9 145.4
CLParser::Parse 45 1889.1 85.0
你還可以使用 ninjatracing 生成可視化的構建性能報告。它會將 .ninja_log 文件轉換為 .json 文件,可通過 chrome://tracing 加載查看:
$ python ninjatracing out\Default\.ninja_log >build.json
編譯 Chromium
使用 Ninja 編譯 Chromium(“chrome”目標),命令如下:
$ autoninja -C out\Default chrome
autoninja 是一個封裝工具,會自動為 ninja 提供最優參數。
你可以通過運行 gn ls out\Default 來獲取所有其他構建目標的列表。要編譯某個目標,只需將 GN 標籤傳給 Ninja,不需要前綴的 //(例如,對於 //chrome/test:unit_tests,使用 autoninja -C out\Default chrome/test:unit_tests)。
編譯單個文件
Ninja 支持一種特殊的 語法 ^,可以通過指定源文件來編譯單個目標文件。例如,ninja -C out/Default ../../base/logging.cc^ 會編譯出 obj/base/base/logging.o。
使用 autoninja 時,需要加上 ^^ 來保留結尾的 ^:
$ autoninja -C out\Default ..\..\base\logging.cc^^
除了支持 foo.cc^^,Siso 也支持 foo.h^^ 語法來編譯對應的 foo.o(如果存在的話)。
如果你使用 bash shell,可以使用下面的腳本來簡化編譯過程:
#!/bin/sh
files=("${@/#/..\/..\/}")
autoninja -C out/Default ${files[@]/%/^^}
該腳本假設你在 src 目錄中運行,輸出目錄為 out/Default;它調用 autoninja 來編譯所有給定文件。若你將該腳本放入 $PATH 並命名為 compile,可以這樣使用:
$ pwd # 僅用於説明運行位置
/c/src
$ compile base/time/time.cc base/time/time_unittest.cc
...
[0/47] 5.56s S CXX obj/base/base/time.obj
...
[2/3] 9.27s S CXX obj/base/base_unittests/time_unittest.obj
...
運行 Chromium
構建完成後,你可以直接運行瀏覽器:
$ out\Default\chrome.exe
(命令中的 “.exe” 後綴其實是可選的)
運行測試目標
測試根據類型和所在目錄被劃分為多個測試目標。要查看某個單元測試或瀏覽器測試文件對應的目標,可以使用以下命令:
$ gn refs out\Default --testonly=true --type=executable --all chrome\browser\ui\browser_list_unittest.cc
//chrome/test:unit_tests
在上述示例中,目標是 unit_tests。可以通過以下命令構建該二進制文件:
$ autoninja -C out\Default unit_tests
你可以直接運行該測試二進制文件來執行測試。也可以使用 --gtest_filter 參數來限制運行的測試,例如:
$ out\Default\unit_tests.exe --gtest_filter="BrowserListUnitTest.*"
你可以在 GitHub 頁面 瞭解更多 GoogleTest 的信息。
構建安裝包
構建 mini_installer 目標可以生成一個自包含的安裝器。該安裝器包含在一台機器上安裝瀏覽器所需的全部內容:
$ autoninja -C out\Default mini_installer
更多信息請參考:
更新源碼
要更新現有源碼目錄,可以運行:
$ git rebase-update
$ gclient sync -D
第一條命令會更新 Chromium 主源碼倉庫,並將你的本地分支 rebase 到主分支的最新代碼(即 Git 分支 origin/main)。如果你不想使用該腳本,也可以直接使用 git pull 或其他 Git 命令更新倉庫。
第二條命令會同步所有子倉庫到合適的版本,刪除不再需要的子倉庫,並根據需要重新運行 hooks。
在 Visual Studio IDE 中編輯和調試
你可以使用 Visual Studio IDE 來編輯和調試 Chrome,可以選擇是否開啓 Intellisense 支持。
使用 Visual Studio Intellisense
如果你希望在開發 Chromium 時使用 Visual Studio 的 Intellisense,請在執行 gn gen 生成輸出目錄時添加 --ide 參數。如下是一個例子,假設你的 Chromium 路徑是 C:\src\chromium,輸出目錄為 out\Default:
$ gn gen --ide=vs --ninja-executable=C:\src\chromium\src\third_party\ninja\ninja.exe out\Default
$ devenv out\Default\all.sln
這將生成一個 all.sln 解決方案文件,可在 Visual Studio 中打開。雖然實際編譯仍由 Ninja 完成,但你仍然可以使用 IDE 的大部分功能(Chromium 不支持 Visual Studio 的原生編譯方式)。
注意事項:
- 如果你再次手動執行
gn gen,需要重新傳遞--ide參數; - 通常 GN 會在構建過程中自動保持解決方案文件更新;
- 生成的解決方案包含數千個項目,加載會非常緩慢。
為了優化加載速度,可使用 --filters 限制只生成你關心的代碼目錄的項目文件。例如,只關心 chrome 目錄:
$ gn gen --ide=vs --ninja-executable=C:\src\chromium\src\third_party\ninja\ninja.exe --filters=//chrome --no-deps out\Default
你還可以添加多個目錄過濾器,例如:
--filters=//chrome;//third_party/WebKit/*;//gpu/*
使用 gn help gen 可查看更多相關選項。
不使用 Intellisense 使用 Visual Studio
你也可以不生成 .sln 文件,直接用 Visual Studio 進行調試。例如:
$ devenv /debugexe out\Debug\chrome.exe <你的參數>
這樣做的好處是避免了龐大的解決方案加載開銷。不過代碼導航等功能將無法使用。
可通過安裝 VsChromium 插件 彌補這一限制。它提供:
- 代碼瀏覽器;
- 全局代碼搜索;
- 快速跳轉等功能。
你可以通過 文件 -> 添加 -> 現有項目 添加多個二進制(例如 unit_tests.exe、browser_tests.exe)到解決方案中,然後右鍵設置為啓動項目。
若需設置命令行參數或調試屬性,可在 解決方案資源管理器 中右鍵點擊項目 -> 屬性 進行配置。
調試所有子進程
默認情況下,Visual Studio 僅調試主瀏覽器進程。要調試所有子進程,請安裝:
同時確保 以管理員身份 啓動 Visual Studio,否則會無法附加部分子進程,且不會提示錯誤。
提升 git 命令性能
啓用 untracked cache(緩存未跟蹤文件)
運行以下命令進行測試:
$ git update-index --test-untracked-cache
如果輸出結果最後是 OK,可開啓緩存提升性能:
$ git config core.untrackedCache true
啓用 fsmonitor(文件系統監控器)
fsmonitor 可極大加快大倉庫(如 Chromium 和 V8)中 git status 等命令速度:
$ git config core.fsmonitor true
反檢測指紋瀏覽器系列教程源碼存放地址:https://github.com/itbrowser-net/undetectable-fingerprint-browser
原文地址:https://github.com/chromium/chromium/blob/main/docs/windows_build_instructions.md