【Chromium】源碼結構和模塊關係

Top-level projects

When you check out Chromium, you will notice a number of top-level directories. These projects are as follows:

• android_webview: experimental. provides a facade over src/content suitable for integration into the android platform. NOT intended for usage in individual android applications (APK).
• apps: Chrome packaged apps.
• base: Common code shared between all sub-projects. This contains things like string manipulation, generic utilities, etc. Add things here only if it must be shared between more than one other top-level project. 
• breakpad: Google's open source crash reporting project. This is pulled directly from Google Code's Subversion repository.
• build: Build-related configuration shared by all projects.
• cc: The Chromium compositor implementation.
• chrome: The Chromium browser (see below).
• chrome/test/data: Data files for running certain tests.
• components:  directory for components that have the Content Module as the uppermost layer they depend on.
• content: The core code needed for a multi-process sandboxed browser (see below). More information about why we have separated out this code.
• googleurl: Google's open source URL parsing and canonicalization library. This is pulled directly from Google Code's Subversion repository.
• net: The networking library developed for Chromium. This can be used separately from Chromium when running our simpletest_shell in thewebkit repository. See alsochrome/common/net.
• sandbox: The sandbox project which tries to prevent a hacked renderer from modifying the system.
• skia: Google's Skia graphics library developed for Android. This is a copy from Android's tree. Our additional classes inui/gfx wrap Skia.
• sql: Our wrap around sqlite.
• testing: Contains Google's open-sourced GTest code which we use for unit testing.
• third_party: A bunch of external libraries such as image decoders and compression libraries. There are also some Chrome-specific third-party libraries inchrome/third_party.Adding new packages.
• tools
• ui/gfx: Shared graphics classes. These form the base of Chromium's UI graphics.
• ui/views: A simple framework for doing UI development, providing rendering, layout and event handling. Most of the browser UI is implemented in this system. This directory contains the base objects. Some more browser-specific objects are in chrome/browser/ui/views.
• v8: The V8 Javascript library. This is pulled directly from Google Code's Subversion repository.
• webkit: All of Chromium's Webkit-related stuff:
  • appcache:
  • base:
  • blob:
  • build: Project files and configurations for the rest of the projects.
  • data: Most of the directories contain data used by unit tests of our porting layer. thelayout_tests directory is WebKit's layout test suite that we pull directly from Apple.
  • glue: The glue layer is the embedding layer. It converts between Webcore types and our application's types (mostly STL), and provides more convenient methods that mirror a lot of Webcore's objects we need access to.
  • tools
    • layout_tests: Scripts for running WebCore's layout tests.
    • merge: Scripts for helping merge to WebKit's tree.
    • npapi_layout_test_plugin: A special plug-in used by some of our tests to exercise the plugin layer.
    • test_shell: A very simple standalone browser. This allows testing of our glue and port code without having to compile and run the very large Chromium application.

Here's a diagram of the dependencies. A module that is lower can't include code from a higher module directly (i.e. content can't include a header from chrome), but talks to it using embedder APIs.

Quick reference for the directory tree under "content/"

• browser: The backend for the application which handles all I/O and communication with the child processes . This talks to the renderer to manage web pages.
• common: Files shared between the multiple processes (i.e. browser and renderer, renderer and plugin, etc...). This is the code specific to Chromium (and not applicable to being in base).
• gpu: Code for the GPU process, which is used for 3D compositing and 3D APIs.
• plugin: Code for running browser plugins in other processes.
• ppapi_plugin: Code for the Pepper plugin process.
• renderer: Code for the subprocess in each tab. This embeds WebKit and talks to browser for I/O.
• utility: Code for running random operations in a sandboxed process.  The browser process uses it when it wants to run an operation on untrusted data.
• worker: Code for running HTML5 Web Workers.

Quick reference for the directory tree under "chrome/"

• app: The "app" is the most basic level of the program. It is run on startup, and dispatches to either the browser or renderer code depending on which capabilities the current process is in. It contains the projects forchrome.exe and chrome.dll. You won't generally need to change this stuff except for resources like images and strings.
  • locales: Projects for building localized DLLs.
  • resources: Icons and cursors.
  • theme: Images for the theme of the window.
• browser: The frontend including the main window, UI, and the backend for the application which handles all I/O and storage. This talks to therenderer to manage web pages.
  • ui model, view and controller code for UI features and functionality
• common: Files shared between the browser and the renderer that is specific to the Chrome module.
  • net: Some Chromium-specific stuff on top of the net top-level module. This should be merged withbrowser/net.
• installer: Source files and projects for making the installer (MSI package).
• renderer: Chrome specific code that runs in the renderer process.  This adds Chrome features like autofill, translate etc to the content module.
• test:
  • automation: Used by tests to drive the browser UI, for example, intest/ui,test/startup, etc. This communicates withbrowser/automation in the browser.
  • page_cycler: Code for running page cycler tests (for performance measurement). Seetools/perf/dashboard.
  • reliability: Reliability tests for distributed testing of page loads for reliability metrics and crash finding.
  • selenium: Code for running the selenium tests, which is a third-party test suite for Ajaxy and JavaScript stuff. Seetest/third_party/selenium_core.
  • startup: Tests for measuring startup performance. See tools/perf/dashboard and tools/test/reference_build.
  • ui: UI tests for poking at the browser UI, opening tabs, etc. It usestest/automation for doing most operations.
  • unit: The base code for the unit tests. The test code for individual tests is generally alongside the code it is testing in a*_unittest.cc file.
• third_party: Third party libraries that are specific to Chromium. Some other third party libraries are in the top-levelthird_party library.
• tools
  • build: Tools and random stuff related to building.
    • buildbot: Buildbot configuration. Buildbot manages our automated build system. Seethird_pary/buildbot.
    • win: Windows build stuff, including some .vsprops files used for project properties and scripts.
  • memory: Tools for memory stuff. Currently includes gflags for setting page heap options.
  • perf/dashboard: Code for converting performance logs (for exampletest/startup_test) into data and graphs.
  • profiles: Generator for random history data. Used to make test profiles.