Interface-oriented programming is a means of effectively isolating changes in OOP, and requires developers to effectively abstract the problem. Chrome in order to compatible with AOSP WebView and chromium Android WebView, in the implementation of a lot of abstraction, fully do the upper layer only rely on the principle of interface (dependency inversion), can effectively compatible with different WebView implementation, isolate its internal changes.
The following is the decomposition of the webview to the content layer. Just started to read Chrome's code, has not been carefully organized, and then gradually improve.
Webviewfactory is a top-level class (singleton), WebView is to get different webviewprovider through it to create a different webviewchromium (that is, the core implementation of WebView. This design is designed to be compatible with AOSP WebView. If we need to provide a completely different webview implementation, we can implement a new Webviewprovider and Webviewchromiumfactoryprovider to complete.
Android WebView in order to operate different WebView implementations, the specific implementation is then passed through the Webviewprovider interface encapsulation, called the WebView back end (backend). For chromium Android WebView, it interacts with the chromium content layer through awcontents. If it is another kind of webview implementation logic can be separated here. Such as:
Further down, awcontents interacts with the native class of the content API through the content API's Java wrapper class.
After the content native layer, in addition to a business logic processing, more important is the interaction with render. In addition to using delegate/observer monitoring, you also provide the same mechanism for use in the upper layer.
Reprint Please specify Source: http://blog.csdn.net/horkychen
[Chrome] About interface-oriented programming applications
