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
8. Dependency diagram: V2
/chrome
/content
/net /webkit
Content API
/base /third_party//webkit
/V8
WebKit API
9. Dependency diagram: V3
/chrome OR /android_webview OR ...
/components
/content
/net /webkit
Content API
/base /third_party//webkit
/V8
WebKit API
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
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. /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. ● 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. /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.
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. /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. /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. /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. /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. /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. /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. /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. /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. /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. /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. /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. /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. /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. /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. /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. /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?!