Chrome & Webkit overview

Wekkit & chromiumPierr Chen

13年5月2日星期四

webkit

webkit

webcore

JavaScriptCore



how webpage is displayed


layer


layer created when

It's the root object for the page • It has explicit CSS position properties (relative, absolute or a

transform)• It is transparent• Has overflow, an alpha mask or reflection • Has a CSS filter• Corresponds to <canvas> element that has a 3D (WebGL) context or an

accelerated 2D context• Corresponds to a <video> element


Trees


Rendering Path

from back layer to font layer

for each layer, start from the root renderObject , traversal down to the child object and stop at object that belong to another layer

draw by using GraphicContext ,generating a bitmap


from wekkit to screen(SW path)


HW compositor

client = render process


reference

http://www.youtube.com/watch?v=RVnARGhhs9w (rendering in wekkit)

http://www.charlesbryant.com/index.php/342/yo-check-my-reflow/

http://www.youtube.com/watch?v=JFzC_Gx76E8&feature=relmfu (chromium webkit API)

http://www.youtube.com/watch?v=xuMWhto62Eo (webkit in your living room - netflix)

http://blog.csdn.net/spacetiller/article/details/5784475

http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome

http://www.chromium.org/developers/design-documents/graphics-and-skia


http://www.youtube.com/watch?v=RVnARGhhs9w






http://www.youtube.com/watch?v=xuMWhto62Eo

http://www.youtube.com/watch?v=xuMWhto62Eo









chrome overview --- Qian Qian de


misc


process model

process-per-site-instance (site+tab)

process-per-site (site)

process-per-tab (tab)

single process (whatever)


multiprocess architecture


Browser process


renderViewHost// A RenderViewHost is responsible for creating and talking to a RenderView// object in a child process. It exposes a high level API to users, for things// like loading pages, adjusting the display and other browser functionality,// which it translates into IPC messages sent over the IPC channel with the// RenderView. It responds to all IPC messages sent by that RenderView and// cracks them, calling a delegate object back with higher level types where// possible.//// The intent of this interface is to provide a view-agnostic communication// conduit with a renderer. This is so we can build HTML views not only as// WebContents (see WebContents for an example) but also as views, etc.


RenderViewHostImpl(.h)

// This implements the RenderViewHost interface that is exposed to// embedders of content, and adds things only visible to content.//// The exact API of this object needs to be more thoroughly designed. Right// now it mimics what WebContentsImpl exposed, which is a fairly large API and// may contain things that are not relevant to a common subset of views. See// also the comment in render_view_host_delegate.h about the size and scope of// the delegate API.//// Right now, the concept of page navigation (both top level and frame) exists// in the WebContentsImpl still, so if you instantiate one of these elsewhere,// you will not be able to traverse pages back and forward. We need to determine// if we want to bring that and other functionality down into this object so it// can be shared by others.

????????


RenderViewHostDelegate

//// RenderViewHostDelegate//// An interface implemented by an object interested in knowing about the state// of the RenderViewHost.//// This interface currently encompasses every type of message that was// previously being sent by WebContents itself. Some of these notifications// may not be relevant to all users of RenderViewHost and we should consider// exposing a more generic Send function on RenderViewHost and a response// listener here to serve that need.


RenderThread

// The RenderThreadImpl class represents a background thread where RenderView// instances live. The RenderThread supports an API that is used by its// consumer to talk indirectly to the RenderViews and supporting objects.// Likewise, it provides an API for the RenderViews to talk back to the main// process (i.e., their corresponding WebContentsImpl).//// Most of the communication occurs in the form of IPC messages. They are// routed to the RenderThread according to the routing IDs of the messages.// The routing IDs correspond to RenderView instances.


RenderView(Impl.h)

//// RenderView is an object that manages a WebView object, and provides a// communication interface with an embedding application process

//


IPC

a named pipe is created for each render process for communication with the browser process


the render process

Each renderer has two threads ,The render thread is where the main objects such as the RenderView and all WebKit code run. When it communicates to the browser, messages are first sent to the main thread, which in turn dispatches the message to the browser process.


layers


WebKit: Rendering engine.The Port is a part of WebKit that integrates with platform dependent system services such as resource loading and graphics.

• Glue: Converts WebKit types to Chromium types. This is our "WebKit embedding layer." It is the basis of two browsers, Chromium, and test_shell (which allows us to test WebKit).

• Renderer / Render host: This is Chromium's "multi-process embedding layer." It proxies notifications and commands across the process boundary.

• WebContents: A reusable component that is the main class of the Content module. It's easily embeddable to allow multiprocess rendering of HTML into a view.

• TabContentWrapper: Contains a single WebContents, and is the connection point for all the additions ("TabHelpers") that Chrome wants to keep in 1:1 relation with the WebContents.

• Browser: Represents the browser window, it contains multiple TabContentsWrappers.


Chrome-specific code are provided in platform-specific source files that live in platform/graphics/chromium.


build androidhttp://code.google.com/p/chromium/wiki/AndroidBuildInstructions

cd $SRC; sudo ./install_build-deps-andriod.sh

. build/android/envsetup.sh

android_gyp

sudo make -j4 content_shell_apk

sudo make -j4 //多编译chrome下面⼀一些东西和unittest


http://code.google.com/p/chromium/wiki/AndroidBuildInstructions




build system

.gyp/.gypi.mk

gyp

antgcc

.so .jar/.apk

each target in the gyp will generate a mk file

.mk.mk.mk

make


gyp

generate your project


ant


adb shell am start -a android.intent.action.VIEW -n org.chromium.content_shell/.ContentShellActivity -d "www.html5test.com"

Content Shell .apk on Android

make -j4 content_shell_apk

adb install -r ContentShell-debug.apk

app_148 24364 109 546084 53448 ffffffff 00000000 S org.chromium.content_shellapp_148 24391 109 555500 68540 ffffffff 00000000 S org.chromium.content_shell:sandboxed_process0


http://www.html5test.com

http://www.html5test.com

content_shell_apk

content.gyp:content_java

copy_and_strip_so ant xxx

shell/android/*.javashell/res/*lib.java/chromium_base.jarlib.java/chromium_content.jarlib.java/chromium_media.jarlib.java/chromium_net.jarlibcontent_shell_content_view.so

common_aidl

libcontent_shell_content_view

actiontarget

1

2

3

make content_shell_apk

depend

net.gyp:net_javabase.gyp:base_java

content_common

content shell apk

javanative

java


content_shell_content_view.so

content_shell_jni_header

conent_shell_pakcontent_shell_lib.a

content_render

1

xxx

target name in gyp

./content

+port/browser+public/browser+browser

content_plugincontent_utilitycontent_worker

shell

depend

cotent_browser(.a) lots of ...(.a)

depend

link all the .a

check libcontent_shell_content_view.target.mk search (OBJS) ,around line 201$(obj).target = src/out/Debug/obj.targetyour could rm the library thenmake -j4 libwebkit

$(obj).target/third_party/WebKit/Source/WebKit/chromium/libwebkit.a

make libcontent_shell_content_view


chrome_xx.jar

lib.java/chromium_base.jarlib.java/chromium_content.jarlib.java/chromium_media.jarlib.java/chromium_net.jar

base/base_java.target.mk

content/content_java.target.mk

media/media_java.target.mk

net/net_java.target.mk

build/android/ant/ant.xml

build/android/ant/chromium-jars.xml

use

base/android/java/*.java

2


chrome/android_webview

Webview <--android

WebiewProvider <--android

AwContents <----chrome/android_webview

CotentViewCore <---chrome/content


jni_generator

1. out/Debug/obj/gen/content/shell/jni/ShellManager_jni.h

2. content/shell/android/shell_manager.cc

3. content/shell/android/java/src/org/chromium/content_shell/ShellManager.java

4. out/Debug/obj/gen/content/shell/jni/ContentViewCore_jni.h

5. content/browser/android/content_view_core_impl.cc

6. content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java

4,5 -> libcontent_browser.a

3,6 -> chromium_content.jar

1,2 -> libcontent_shell_content_view.so(*)

*libcontent_shell_content_view.so depend on libcontent_browser.a , so 4,5 are

consisted in the .so as well.

~/chromium/src/base/android/jni_generator


content android nativeapp

common

browser


Gesture handling

Recognizing use framework GestureDetector and ScaleGestureDetector

handling in the native (CContentViewCore)

ContentViewGustureHandlerContentViewGustureHandler.MotionEventDelegateZoomManager


reference


http://www.ericdlarson.com/misc/chrome_command_line_flags.html






Software

Chrome & Webkit overview