Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OVERVIEW: Chromium Source Tree

Rough study log #1. Overview of Chromium SourceTree.

OVERVIEW: Chromium Source Tree

  1. 1. Chromium Source Tree Overview
  2. 2. Chang W. Doh <hi> </hi> GDG Korea WebTech Organizer HTML5Rocks/KO Contributor/Coordinator
  3. 3. CAUTION! Many documents being mentioned from this slide are outdated. Don’t believe everything. =)
  4. 4. Overall Top-Projects
  5. 5. Simplified top-projects Project Description android_webview Integration of /content into android. base Common code shared between all sub-projects. build Build Configurations shared by all projects cc chrome Compositor implementations components components for Content Module layer content Core code for multi-process sandboxed browser net Network libraries for Chromium sandbox Sandbox for preventing hacked renderer from modified system. skia skia Graphics library, some classes in ui/gfx wrap skia third_party External libaries such as blink, decoders, compression, ... ui ● /gfx: Shared graphics lib, base of Chromium UI grp. ● /views: frameworks for UI; rendering, layout, event handling. ○ ALSO CHECK! chrome/browser/ui/view v8 V8 JavaScript Engine webkit WebKit glues & some web features
  6. 6. Historical changes of Chromium Dependency Diagram
  7. 7. Dependency diagram: V1 /chrome /net /webkit WebKit API /base /third_party//webkit /V8
  8. 8. Dependency diagram: V2 /chrome /content /net /webkit Content API /base /third_party//webkit /V8 WebKit API
  9. 9. Dependency diagram: V3 /chrome OR /android_webview OR ... /components /content /net /webkit Content API /base /third_party//webkit /V8 WebKit API
  10. 10. Dependency diagram: V3 /chrome OR /android_webview OR ... /components /content /net /webkit Chromium browser implementation Content API /base /third_party//webkit /V8 WebKit API Network libraries for Chromium Common code to be shared between all sub-projects WebKit glue. NEED RESEARCH SOMEMORE Shared codes between browser implemetations Blink PART All the web platform features, HW acc. except Chrome features
  11. 11. Overview of Top-level projects
  12. 12. /android_webview ● Facades over src/content to integrate into Android ○ References ■ Java Resource on Android ● http://www.chromium.org/developers/design-documents/java-resources- on-android ■ JNI on Chromium for Android ● http://www.chromium.org/developers/design-documents/ android-jni ● WARNING! Use jar_file_jni_generator.gypi for generating JNI of system classes instead of system_classes_jni_generator.gypi ■ Organization of code for Android WebView
  13. 13. /base ● Common code shared betweeen sub-projects ○ e.g. String manipulations, file, … ● Guideline ○ Adding things under /base, only if that code must be shared between more than 1 other top-level project.
  14. 14. ● Build-related configuration shared by all projects ○ NOTE: ■ gyp_chromium ● Wrapper of gyp for chromium build ■ all.gyp ● Everything starts at here!!! ■ android ● jni_generator.gypi ○ JNI generator for user-defined class ● jar_file_jni_generator.gypi ○ JNI generator for system class /build
  15. 15. /cc ● Chrome compositor implementations ○ References: ■ GPU Accelerated Compositing in Chrome ● http://www.chromium.org/developers/design-documents/gpu-accelerated- compositing-in-chrome ■ Compositing in Blink/Webcore [slide] ● https://docs.google. com/presentation/d/1dDE5u76ZBIKmsqkWi2apx3BqV8HOcN f4xxBdyNywZR8/edit#slide=id.gccb6cccc_0709 ■ Compositor Thread Architecture ● http://www.chromium.org/developers/design-documents/ compositor-thread-architecture NOTE: Implementations in ‘cc’ don’t have whole part in above references.
  16. 16. /chrome ● Chromium browser implementations ○ e.g. Extensions, NaCl, ChromeFrame, SpellCheck, Autofill, Sync, Prerendering, Safe Browsing, Translate, ... ● See also: ○ chrome.gyp ○ chrome_browser.gypi ○ chrome_browser_ui.gypi ○ chrome_browser_ui_views.gypi ○ chrome_android.gypi
  17. 17. /components ● Features for reusing across # of targets ○ for browser features, NOT the web! ■ e.g. Bookmarks, autofill, autocomplete, search engine, history, … ● Guidelines ○ By default, depend only on the lower layers of the Chromium codebase( /base, /net, etc) ■ Individually, allow additional dependencies on the content API and IPC
  18. 18. /components ● Guidelines ○ Directory & Subdirectories ■ Directory could have ● DEPS : Dependencies such as rules, include_dir, ... ● OWNERS ● {DIR}.gypi ■ subdirectories ● Components need to live in different processes should separate the code into different subdirectories. components/foo DEPS, OWNERS, foo.gypi components/foo/browser Code that needs the browser process components/foo/renderer IPC constants, ... components/foo/common Code that needs renderer process
  19. 19. /components ● Guidelines ○ Directory & Subdirectories (cont’d) ■ Subdirectory should have DEPS file ● with the relevant restrictions in place ○ i.e. only components/*/browser should be allowed to #include from content/public/browser. ○ Naming conventions ■ namespace = the name of the component. ● e.g. //components/foo ○ code should be in the foo:: namespace
  20. 20. /components ● Guidelines ○ Android ■ 'android' subdirectory with a Java source ● SHOULD BE: code structure = package name components/foo/android/OWNERS components/foo/android/DEPS components/foo/android/java/src/org/chromium/components/foo/browser/ components/foo/android/javatests/src/org/chromium/components/foo/browser/ ● Reference ○ http://www.chromium.org/developers/design-documents/ structure-of-layered-components-within-the- chromium-codebase
  21. 21. /components ● References ○ Structure of layered components ■ http://www.chromium.org/developers/design-documents/ structure-of-layered-components-within- the-chromium-codebase ○ Life of a browser component ■ https://docs.google.com/viewer? a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRld nxneDoxNzgxYjJjMTI0YjBkNTk1
  22. 22. /content ● Core code for multi-process sandboxed browser. ○ The core code needed to render a page using a multi-process sandboxed browser. ○ Includes all the web platform features and GPU acceleration except Chrome features. ● The goal ○ Being able to build a browser by starting with content, and then pick and choose Chrome features.
  23. 23. /content ● Historical motivation ○ Consensus was reached to move the core Chrome code into srccontent. ■ Hard to figure out what the "best" way, because the APIs and features were together in the same directory. ■ To add a clear separation between the core pieces of the code that render a page using a multi-process browser ■ Not chrome features!!
  24. 24. /ipc ● IPC(Inter-Process Communication) module for communcation between chromium processes. ● Reference ○ Multi-process architecture ■ http://www.chromium.org/developers/design-documents/ multi-process-architecture
  25. 25. /mojo ● New project for isolating components of chromium multi-process architecture that are concerned with ‘Process management’, ‘Sandboxing’, ‘IPC’. ○ 3Q 2013, started & in progress ○ Similar with ‘IDL’ based generating & binding system. ● Currently, out of our focus :)
  26. 26. /net ● The neworking library developed for Chromium ○ can be used seperately from Chromium. ■ see also: chrome/common/net ○ Mostly single-threaded cross-platform library primarily for resource fetching http://www.chromium.org/developers/design-documents/network-stack
  27. 27. /net ● Code layout Directory Descriptions base net utilities. e.g. host resolution, cookies, network change detection, SSL. disk_cache Cache for web resources. websockets WebSockets implementation. url_request URLRequest, URLRequestContext, URLRequestJob implementations. spdy SPDY implementation. socket_stream socket streams for WebSockets socket Cross-platform implementations of TCP sockets, "SSL sockets", and socket pools. proxy Proxy (SOCKS and HTTP) configuration, resolution, script fetching, etc.
  28. 28. /sandbox ● To prevent a hacked renderer from modifying system ○ C++ library for the creation of sandboxed processes ■ processes that execute within a very restrictive environment. ■ The only resources sandboxed processes can freely use are CPU cycles and memory. ● e.g. Chromium renderers are sandboxed processes. http://www.chromium.org/developers/design-documents/sandbox
  29. 29. /skia ● Google’s skia graphics library ○ /skia has configurations only. ■ Skia implemetation is located in ● /third_party/skia ○ https://code.google.com/p/skia/ ○ See also: some wrappers in /ui/gfx
  30. 30. /third_party ● All third-party libraries that Chrome used. ○ /third_party/webkit ■ webkit fork, known as ‘blink’ ○ /third_party/webrtc ○ /third_party/webgl ○ /third_party/libc++ ○ /third_party/flac ○ … ● Not only C/C++, Java libraries ○ You can find js project or python tools in this directories. :)
  31. 31. /ui ● Contains discrete components used to build Chromium’s user interfaces ○ each subdir has to have isolated component. ■ 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. ○ Contains the base objects. ● See also: ○ /chrome/browser/ui/views.
  32. 32. /v8 ● Google JavaScript Engine ○ except Chrome for iOS ■ The iOS security model does not allow an app to execute native code from writeable memory. ■ Memory is either writeable or executable (but read-only). ■ However, V8 is a pure compiler, and doesn't have an interpreter. ○ Project Home: ■ https://code.google.com/p/v8/
  33. 33. /webkit ● All of Chromium's Webkit related stuff ○ But, currently there’re quite many actions are that moving to out of ‘/webkit’ ■ e.g. /content, /chrome, … ○ Will be deprecated? Maybe?!

×