Understand WebKit and Chromium: Chromium WebView in Android 4.4

 

# OVERVIEW

I believe you have noticed that in the latest Android 4.4 Kitkat version, the WebView implementation based on Android WebKit was replaced with the WebView implementation based on Chromium. In the previous chapter, the author also introduced that the chrome-based WebView implementation will become the default implementation method on the Android system. I have always been looking forward to this major change, and now it has actually happened. Previously, applications based on the WebView interface can even work directly on this implementation without any special changes. For example, the default browser on the Android system (the browser in AOSP) can work on the new implementation without any changes.

WebView is an embedded programming interface that provides Java interfaces for developers to use this module to render Web pages. The current WebView is only an interface class. With some internal design changes, the specific implementation can be switched between the previous Android WebKit and Chromium. The new Chromium implementation focuses on providing consistent interfaces (to be compatible with previous applications), and the internal rendering engine is changed to the Blink/Content-based engine, in terms of functionality and performance, this has brought about a huge improvement. Chromium has made many changes to support WebView working methods, such as the process model and rendering method mentioned above. We will introduce them one by one.

 

# Chromium WebView

In Android 4.4, the chrome-mium project-based WebView started to work. In order to support the interfaces left over from history, Chromium has made great changes and let the author explain the basic process by combining the hierarchical structure.

There are four main parts, of which WebView is related to the above three parts. The first is the WebView interface, which provides external programming interfaces, and its internal implementation can be based on the bridge code, that is, the second part. The code of the bridge part has two main functions: one is to implement the WebView interface to call the implementation, and the other is to call the code at the following layer, an important part here is the two function arrays that need to be set for AwContents for drawing. This is an introduction in the rendering section. Its code can be found in the frameworks/webview/chromium section. The above two parts are part of the AOSP code, and the third part is that AwContents is in the Chromium project, mainly to build the interface used by the bridge code, this part is mainly based on the Content interface, there are many different implementations than Chrome. In order to compile the open source code of Android, code 30 of Chromium version is directly included in the external/chromium_org directory. Interested readers can view it on their own.

 

# Comparison with Chrome

Compared with Chrome browsers, Chromium WebView is very different in many parts, such as open source or not, HTML5 functions, version support, process model, and rendering mode. The following table analyzes the main differences between the two.

 

	Chromium WebView	Chrome (Android)
Open source?	All open-source, including the kernel and bridge layer	The code at the Java layer, including the code on the user interface, is closed-source. That is to say, developers cannot customize a new browser based on the Chrome browser. They can only create a new browser based on the Content layer.
HTML5 Functions	Currently, WebGL, WebRTC, and WebAudio are not supported.	Most HTML5 functions, including WebGL, WebRTC, and WebAudio
Version	It can only work on Android4.4 and depends on internal functions of the system. It can only be compiled with Android AOSP. It is currently in Chromium 30.	Can work in> = Android 4.0, and does not need to rely on functions in the Android system. Chromium follows the latest code.
Process Model	Single process only	Support for multi-process and single-process (however, there are still some problems with single-process operations)
Rendering Method	Supports software rendering and hardware accelerated rendering.	Currently, it is only a hardware accelerated rendering method.

 

# Rendering Method

The Chromium implementation used in WebView is hardware accelerated rendering or software rendering, which is still complicated here. According to the Android View structure, the content of WebView needs to be drawn through an onDraw (Canvas c. To draw the results of Chromium rendering web pages to the Canvas, two groups of drawing function groups are required. The first group is used for software rendering, and the second group is used for hardware accelerated rendering. These two groups of functions need to use Android internal functions, which determines that currently WebView can only be compiled together with Android AOSP code, rather than the same as the application, it only depends on Android SDK/NDK for compilation. It is the basic process of drawing when the user interface or webpage needs to be drawn.

Here, the Chromium synthesizer has two capabilities: Software Renderer supporting software rendering and hardware accelerated rendering. When the canvas corresponding to the user interface is accelerated by hardware, hardware rendering is used internally. If hardware acceleration is not used, software rendering is used. When the user interface is set to hardware acceleration (the developer can go to the AndroidManifest. if the property android: hardwareAccelerated = true is set in xml, the canvas corresponding to the user interface will be accelerated by hardware; otherwise, the canvas will be rendered by software. Therefore, the specific method used by Chromium WebView depends on the setting method of the WebView application.

It is worth noting that the hardware acceleration mechanism here is inconsistent with the hardware acceleration mechanism of the Chrome browser, because the Chrome browser uses the SurfaceView of Android to render the webpage, according to the instructions of the Android system, SurfaceView can be drawn in different threads, because Chrome first obtains the Surface object handle (ID) of SurfaceView ), the GPU thread of Chrome browser is used to draw web pages. In this way, the rendering of web pages is completely isolated from the main thread, and the user interface response will not be blocked by the rendering of web pages.

In the implementation of Chromium WebView, because WebView is not based on the SurfaceView class (due to historical issues), the content to be drawn must be operated in the main thread. Therefore, these rendering work can only work on the main thread, which may hinder the response of the user interface to some extent.

Because WebView uses a single-process rendering method, it can save some memory usage space, and interested readers can perform some analysis.

 

# References

1. https://developers.google.com/chrome/mobile/docs/webview/overview

2. https://android.googlesource.com/platform/external/chromium_org/