寻找解决 chromium 源代码的方法

发布于 2024-12-03 21:42:27 字数 200 浏览 0 评论 0 原文

我刚刚检查了 chromium 的来源，但我迫切需要学习如何绕过这个怪物。

我如何搜索实现我感兴趣的行为/功能的代码部分？

假设我想看看在地址栏中输入 URL 后会发生什么。我如何找到那段代码？

或者，我想看看在解析 HTML 时到达某个标记时会发生什么。

我面前有大量的源代码，但没有导航它们的技巧。我如何学习这项技能？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

ゝ偶尔ゞ 2024-12-10 21:42:27

我建议深入了解 http://code.google.com/p/chromiumembedded 的源代码/。

它是 Chrome 的精简版本，如果你查看它具体使用的文件，要么包含在其源代码树中，要么包含来自 Chromium 存储库的文件。 Chromium 代码库包含大量内容，其中大部分实际上并不在浏览器中。有大量从第三方存储库中提取的代码，然后在构建过程中进行归结，或者 Chromium 的实现位于树中的其他位置，有很多副项目（虽然很有趣，并且是广泛的很棒的资源）东西）将阻止您实现专门磨练浏览器实现及其如何组合在一起的目标。

CEF 很棒，因为您可以看到有人已经完成了将所有这些内容整合在一起以构建一个非常专门针对浏览器视图的项目的过程，而没有其他任何事情。您可以轻松地看到哪些部分主要源自 webkit，您可以看到与 Google 的实现交叉的地方，并且您可以很容易地看到 V8 是如何融入其中的。

我确实用相对术语说“容易”，因为我们仍然在讨论大量的代码。 CEF 会将您置于需求的中心，但是这些东西仍然从树的其余部分中引入大量各种东西。在一台拥有 12 GB 内存和 8 个内核的非常好的计算机上编译它大约需要一个小时，生成的文件大约需要 6-10 GB，具体取决于情况。

至少，不会有任何快速跳入浅水区来零碎地挑选一些东西。浏览器必然是极其复杂的工程，因为它们必须包含如此大量的单独功能，然后将它们组合到共享上下文中。您可能会找到您正在寻找的东西，但您会发现它是类库的一部分，该类库可能由数十或数百个文件组成，而这些文件又依赖于一百多个此类库来处理每项任务，所以要真正拿走一些东西，你必须花时间去吸收比任何给定的信息更多的东西。

编辑：哦，也是你的具体例子。

src 是根 http://src.chromium.org/viewvc/chrome/trunk/src

/chrome

http://src.chromium.org/viewvc/chrome/trunk/src/chrome “chrome”树主要包含直接实现（虽然很多东西不在那里，甚至大部分，但这是起点）。这与 chromeos 重叠（chromeos 是一种极端的 chromium 浏览器）

/chrome/browser http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/

让您接近您想要的地方。您开始看到对可以与浏览器匹配的事物的具体引用，例如选项卡和诸如此类的东西（忽略实际浏览器实现本身的巨大大象，这占据了所有这些东西的大部分思维空间）

/chrome/浏览器/用户界面 http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser /ui/

将您带到浏览器的大部分 ui 代码所在的位置。当存在交叉或内容迁移时，可能会令人困惑，比如根 src 目录中有一个“ui”，它有一些交叉。

最后 http://src.chromium.org/viewvc/chrome/trunk /src/chrome/browser/ui/omnibox/

其中的代码量惊人地少。但这就是你发现的很多东西。这里的代码是在其他地方构建的许多类的实现。对于非 webview gui 组件，您会发现它们主要指向根“ui”和本机小部件，如果我没记错的话，这就是大部分实际事件处理代码所在的位置。

My recommendation for sort of diving in is to take a look at the source for http://code.google.com/p/chromiumembedded/.

It's sort of the condensed version of Chrome and if you look at the files it specifically uses, either ones included in its source tree, or files included therein from the Chromium repo at large. The Chromium code base is a huge amount of stuff, most of which isn't actually in the browser. There's a ton of pulled in code from third party repos which are then boiled down in the build process or Chromium's implementation is located somewhere else in the tree, there's a lot of side projects that (while interesting and an awesome resource for a wide breadth of stuff) will prevent you from achieving your goal of specifically honing in on the browser implementation and how that fits together.

CEF is great because you can see someone who's already done the process of pulling all that stuff together to build a project very specifically scoped at the browser view and nothing else. You can see which parts are primarily derived from webkit easily, you can see where the crossover comes in with Google's implementations, and you can see pretty easily how V8 gets tossed into the mix.

I do say "easily" in relative terms because we're still talking a huge amount of code overall. CEF will put you smack in the center of the requirements, but that stuff is still pulling in the massive amount of various things from the rest of the tree. Compiling it takes me about an hour on a really good computer with 12 gigs of ram and 8 cores, and the generated files take up like 6-10 gigs depending.

At the very least, there's not going to be any sort of quick jump into the shallow end to pick something here or there piecemeal. Browsers are incredibly complex pieces of engineering necessarily, because they have to subsume such a huge amount of individual pieces of functionality and then combine them into a shared context. You may find the one thing you're looking for, but you'll find that it's part of a class library that likely is composed of dozens or hundreds of files, which in turn relies on a hundred more of these libraries to handle each task, so to really take something away you'll have to commit time to taking in a lot more than any given piece of information.

Edit: oh also as your specific example.

src is root http://src.chromium.org/viewvc/chrome/trunk/src

/chrome http://src.chromium.org/viewvc/chrome/trunk/src/chrome

The "chrome" tree largely contains the direct implementations (a lot of stuff isn't in there though, most of it even, but that's the starting point). This has overlap with chromeos (chromeos is kind of chromium browser taken to a crazy extreme)

/chrome/browser http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/

Is getting you to close to where you want to be. You start to see specific references to things that you can match to the browser, like the tabs and whatnot (ignoring the giant elephant of the actual browser implementation itself which is what takes up the majority of the mindspace in all this stuff)

/chrome/browser/ui http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/

Brings you to where most of the ui code is for the browser. It can be confusing when there's crossover or when stuff migrates, like there's a "ui" in the root src directory which has some crossover.

And finally http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/omnibox/

Which has a surprisingly small amount of code in it. But this is what you find a lot. The code here is an implementation of a number of classes that are built up elsewhere. For non-webview gui component you'll find them mostly pointing back to the root "ui" and the native widgets stuff there, which is where the bulk of the actual event handling code is if I remember correctly.

回复收藏 0 原文