Chromium on Android: Recognize Chromium WebView

An important update for Android KitKat is that WebView uses the Chromium/blink rendering engine, which briefly describes the main features of the new version of WebView, where further improvements are needed, and the code structure of WebView.

WebView Past Life

WebView is a very important system component on the Android platform that embeds a widget view of a display Web page into the application and provides a set of API interfaces that allow developers to customize the behavior of page loading and drawing, such as response to changes in page loading status and popup JavaScript dialog box requests and so on. Since the release of Android 1.0, WebView has been widely used in applications, the most typical of which is the stock browser, which is a browser program based on WebView development. For a detailed description of the document, please refer to the official documentation for WebView.

Early WebView (before Android 4.4) was implemented based on WebKit and could be simply understood as adding a branch directly to the WebKit code base. Solve the specific page rendering of Android platform and bridge the functionality of WebKit through the JNI interface to the Java Layer API interface. In graphics, like the Android platform, WebView is using the Skia graphics library, but hardware acceleration is not enabled, rendering performance is very bad, which is one of the many users often complain of the criticism.

With the launch of the Android 4.4 (KitKat) platform, WebView, based on chromium open source projects, has become a major highlight of the KitKat platform. The new WebView features the same blink rendering engine as the Chrome browser, V8 JavaScript engine, network library, and memory allocator, which not only maintain a higher level of consistency with chrome in HTML5 feature support, It also compensates for the poor rendering performance of older WebView. All applications using WebView on the Android platform will seamlessly and transparently benefit from the new WebView feature support and performance improvements.

Currently, the WebView on Android KitKat is based on chromium 30.0.0.0, and the chromium open source project has been evolving rapidly over a 6-week iteration cycle, Google's official does not give a clear plan when and how to upgrade the WebView component, perhaps through the GMs, but nonetheless, in the current situation, the new version of WebView can only be used on Android 4.4 system. This means that currently a large number of Android 4.3 or previous devices are not able to use the new version of WebView, not to enjoy the benefits of the new webview introduced. Why is it not available on other devices that are not 4.4? The main reason is that chromium webview must be compiled with AOSP (Android Open source Project) source code, and cannot be compiled separately from the chromium code base for a standalone package.

Key Features

• Supports more HTML5 features such as Web sockets, Web Worker, FileSystem API, Page Visibility API, Cssfilter, and more. The results of the html5test.com run were 448 points, very close to the Chrome browser.

• Added support for remote debugging features. Any application that uses WebView has the remote debugging feature turned on by default, a USB cable to the development host, and a chrome://inspect on the host's Chrome browser to directly debug the WebView loaded page on the development host. Developers can also call setwebcontentsdebuggingenabled to turn this feature on or off. This is definitely a boon for the vast majority of HTML5 application developers.

• A more intelligent memory management strategy. Legacy WebView requires the application to explicitly call the Freememory method to release the memory resources that WebView consumes when the system is out of memory. In the new version of WebView, Freememory This method has been marked as "deprecated", that is, the application does not need to release the memory itself, WebView's internal implementation has taken into account the system low memory runtime response, once the system is found in low memory running state , WebView will actively adjust the memory allocation policy to free up some of the memory resources that have been consumed.

• Supports software rendering and hardware acceleration modes. Android applications can specify hardwareaccelerated values in the manifest file to indicate whether to start hardware acceleration, and to be compatible with applications that use WebView earlier, the new WebView supports both software rendering and hardware rendering modes.

the shortcomings

• There are still some heavyweight HTML5 features that are not supported, such as WEBGL,WEBRTC, which is because WebGL has a high demand for graphics graphics, and the hardware capabilities of each vendor are not the same at the moment, and all the support that aggressively opens WebGL can lead to platform consistency. That is, the same HTML5 application on different devices upstream inconsistent, some can run, and some hang out.

• There are still some lightweight but useful HTML5 APIs that are not yet supported. There are two typical, one is the full-screen fullscreen API, the other is the network information API.

• Canvas 2D does not turn on hardware acceleration mode. There is still a gap between the performance of canvas2d and the Chrome browser, which is because the hardware-accelerated canvas 2D backend Ganesh in the Skia library can cause WebView to crash.

• All operations to the GPU in hardware-accelerated rendering mode occur in the main thread. The UI main thread is too busy, and if you can create a thread specifically for GPU operations, like chrome, performance can be further improved.

Update: The latest chromium WebView has added WEBGL,WEBRTC and accelerated support for canvas 2D.

Code Structure

To be exact, webview in AOSP consists of three parts of code:

650) this.width=650; "src=" http://img.blog.csdn.net/20140113222657312 "align=" Middle "alt=" WebView Code Structure "width=" 410 "height=" 234 "/>

• Chromium Code : Included in the external/chromium_org directory, where the android_webview/directory contains the internal implementation code of WebView and the corresponding Java class package;

• Java Bridging Code : Included in the Framework/webview/java directory, provides chromium-based Webviewprovider implementation class Webviewchromium, This class will be dynamically loaded by the Android system as the internal implementation of Android.webkit.WebView;

• Android Platform Support code : This part of the code is small but critical. In hardware-accelerated mode, the WebView must be able to directly access the memory of the Android system and perform GL operations on the Hardwarecanvas, while accessing the video memory and the operation of the Hardwarecanvas does not have the appropriate SDK or NDK support. Only the AOSP code can be called directly. This is also the reason why the WebView must be compiled with AOSP as mentioned earlier.

compiling webview from Aosp

If you compile a full version of WebView, you need to download the entire AOSP code first, run the source build/envsetup.sh and Lunch <target> command, go to Framework/webview directory to execute mm – J8 compiles the WebView module and, finally, will now get libchromiumwebview.so and libwebkit_plat_support.so two dynamic link libraries to copy the two so files to the target device/system/ In the Lib directory, you can use your own compiled WebView after restarting the device.

compiling webview from chromium

In fact, the WebView is also compiled directly from the chromium code base, but this webview is not a complete webview. As mentioned earlier, WebView also includes the Android platform support Code, and the chromium code base does not contain this part of the code, so the compiled WebView only pure software rendering mode. As a result, it is useful to help verify a webview functionality problem and only compile from AOSP for optimized rendering performance.

According to chromium.org official documentation, download the Chromium code base, configure the environment to run:

$ . build/android/envsetup.sh
$ android_gyp
$ ninja–c out/release android_webview_apk

After the compilation is successful, the out/release/ In the APKs directory there will be a file generation called androidwebview.apk, which is a shell program that provides a simple UI that allows developers to verify the core functionality of WebView, but androiewebview.apk does not directly use Android.webkit . WebView, but based on WebView core class awcontents implementation, view manifest file you will find it set android:hardwareaccelerated to false, which means the application does not turn on hardware acceleration, Accordingly WebView also works only in software rendering mode. If you force android:hardwareaccelerated to True, this shell program will not display the Web page properly, it is expected that the hardware accelerated rendering mode must be compiled with AOSP to have.

Reference Resources

[1] WebView SDK,http://developer.android.com/reference/android/webkit/WebView.html

[2] Web program migration,http://developer.android.com/guide/webapps/migrating.html

[3] WebView for Android, https://developers.google.com/chrome/mobile/docs/webview

[4] remote debugging for Android, https://developers.google.com/chrome-developer-tools/docs/remote-debugging

[5] Android compilation chromium, https://code.google.com/p/chromium/wiki/AndroidBuildInstructions

This article is from the "Hong Bo Technical column" blog, please be sure to keep this source http://hongbo.blog.51cto.com/4699661/1548482

Chromium on Android: Recognize Chromium WebView