| x5内核 | 原生webview | |
|---|---|---|
| 内核版本 | 统一Blink内核(基于chromium) | 4.4以下WebKit，4.4以上chromium |
| sdk体积 | 大 | 不占用 |
| js拦截 | 全部方式(待测试) | 全部方式 |
| 浏览增强 | 支持office 、音视频 | 无 |
| 功能扩展 | 有(上传下载) | 无 |
| 效能 | 极速，省流 | 低效 |
| 兼容 | 较好 | 无兼容问题 |
| HTML5能力 | webGL, canvas优化 | 无 |
| 内核共享 | 多app共用1内核 | 无此机制 |
| 弹窗广告 | 有 | 无 |
一、webView绘制相关
渲染方式
至于WebView内部所使用的Chromium实现是采用硬件加速渲染还是软件渲染，这里还是比较复杂的。根据Android的View结构，WebView的内容需要通过一个onDraw(Canvas c)来完成绘制。为了将Chromium渲染网页的结果绘制到该Canvas中，需要两组绘图函数组，第一组用来软件渲染，第二组用来硬件加速渲染。而这两组函数需要使用Android内部函数，这决定了目前WebView只能同Android AOSP代码一起编译，而不能像应用程序一样，只是依赖于Android SDK/NDK来编译。下图是当用户界面或者网页需要绘制的时候，绘图的基本过程。
这里Chromium的合成器具有两种能力，就是包含支持软件渲染的软件渲染器和硬件加速渲染的渲染器。当用户界面所对应的画布（canvas）是硬件加速的话，那么内部采用硬件渲染机制。如果不是硬件加速的话，那么采用软件渲染机制。当用户的界面设置为硬件加速的时候（开发者可以在应用程序的AndroidManifest.xml中设置属性android:hardwareAccelerated="true"），那么用户界面对应的画布即为硬件加速，否则即为软件渲染方式。所以，具体Chromium WebView采用什么样的方式，取决于调用WebView的应用程序的设置方式。
值得提出的是，这里的硬件加速机制同Chrome浏览器的硬件加速机制是不一致的，因为Chrome浏览器为渲染网页使用的控件是Android的SurfaceView，根据Android系统的说明，SurfaceView是可以在不同的线程来绘制的(One of the purposes of this class is to provide a surface in which a secondary thread can render into the screen)，请读者阅读这里了解背后的原理http://developer.android.com/reference/android/view/SurfaceView.html。由此，Chrome浏览器是首先获取SurfaceView的Surface对象的句柄（ID），然后由Chrome浏览器的GPU线程来绘制网页。这样，网页的渲染工作同主线程完全隔离开来了，不会因为网页的渲染而阻碍用户界面的响应。
而在Chromium WebView的实现中，因为WebView不是基于SurfaceView类的（因为历史遗留问题），所以，绘制内容到画布上必须在主线程来操作，有鉴于此，这些渲染任务只能在主线程上工作，可能在某种程度上会阻碍用户界面的响应，这是一个重大缺陷。根据笔者的数据来看，目前它的性能同Chrome浏览器/Content Shell也有一定的差距，考虑使用它的读者可能需要权衡一下。
因为WebView采用单进程的渲染方式并省略了一些共享内存和进程间通信的基础设备，所以可以节省一些内存使用空间，Chromium的官方也给出了一些数据，例如打开一个空白页，WebView目前只是需要33MB内存，而Chrome浏览器需要大概49MB，而单进程模式的Chrome浏览器需要大概45MB内存，还有更多详细的数据，有兴趣的读者可以进行参考和一些分析。
https://www.cnblogs.com/xiaowangba/archive/2012/04/12/6313871.html
二、兼容性相关
