关于这份调研报告，不是从技术角度深入探索，重点是从产品本身分析，通俗易懂才是重点。主要是为了锻炼平时做技术调研和竞品分析的能力，以及业务拓展的技术储备。内容有点多，下面 **X5 **内核调研报告将分为三个环节：Why – What – How 描述。

按照经典的 2W1H 的策略描述

WHY

一、Android 端为什么需要考虑浏览器内核问题？

**一言以蔽之：你是要搞定一个 X5 上的兼容性问题，还是要搞定几百台安卓手机上的兼容性问题。**下面就从多个维度来分析兼容性问题：

系统内置浏览器内核差异化

对于 Android 系统，通常以下面四个节点作为重要划分依据，分析浏览器内核的差异性先系统差异性说起，下面是目前 Google 最新统计数据：

系统版本	设备占比
Android 4.0以下	0.9%
Android 4.0 – Android 4.4	11.0%
Android 4.4	20.0%
Android5.0及以上	68.1%

从上面数据来看，当前绝大多数 Android 手机使用的都是 Android 4.4 或以上的系统，这也是System WebView 内核大变更的分界线。 在 Android 4.4版本中，原本基于 Android WebKit 的 WebView 实现被换成基于Chromium的实现，新的 Chromium 实现专注于提供一致性的接口（为了兼容以前的应用），而内部的渲染引擎改为使用基于 Blink/Content 内核的引擎，这实现不管是从功能上还是性能来讲，都带来巨大的提升。

Chromium是一个由Google主导的开源浏览器工程，Chrome浏览器会选择在它的某一个稳定版本进行开发和发布。除了Chrome浏览器，Chrome OS也是基于Chromium开发的。

从 Android 5.0 开始，Google 把 Chromium blink内核 webview 作为 apk 单独从系统抽离出去，可以在应用市场上面接收安装更新。应用可以直接使用该webview内核，Google也可以及时发布更新，不用再通过更新系统才能更新浏览器内核，也避免部分了 Android 系统碎片化问题。

Android 平台碎片化

关于 Android 碎片化问题集中表现在下面几个方面：

设备繁多，硬件配置参差不弃，设备性能各异，差距很大
品牌众多，厂商标准不一致，定制化系统体验不同
版本各异，国内外系统环境差异巨大
分辨率不统一，各种类型尺寸众多

下图是 OpenSignal 在 2015 年 8 月发布的基础统计数据，针对市场上常见的 1294 种手机品牌进行了市场占有率统计，可以看出机型分布非常零碎。

下图是关于 Android 设备分辨率的分布图，可以看出 Android 设备各种类型尺寸众多，开发者需要进行适配的难度非常大。

特别是在 Android 系统开源但 Google 提供的基础服务在国内无法使用的情况下，国内厂商往往抛弃了 Google 既有的规范，对系统进行了大量的定制，导致设备ROM 与原生 Android 系统环境差异性巨大。

对于浏览器内核也是如此，即便是Google推出了基于 Chromium blink 内核实现的 WebView，但是很多国内厂商对其进行了精简或替代，导致 WebView 内核也是碎片化问题严重，这让开发者直接使用系统浏览器内核进行开发产生了众多顾虑，不同机型适配难度也大大增加。

二、目前移动端 H5 适配已有的问题是什么？

** 一言以蔽之：设备碎片化和UI风格的自定义（动画特效等）性能差。** 由于Android本身碎片化问题严重，不同设备上的体验差异性太大，开发者很难全面适配。虽然Google在不断引入行业中领先的技术改善体验，但是短时间内很难覆盖，况且开源特性也导致很难统一各厂商对系统定制化的取舍。

在一些旧机型上面，就算h5页面中图片与文本信息并不多,但在WebView中展示的时候都会出现拖拽不流畅，切换留白、窗口闪烁等的现象，这是 WebView 自身渲染能力不强的问题所致。

又比如Html5的Video控件播放视频，iOS点击视频部分，会用系统自带的浏览器全屏播放视频，体验效果佳；而Android的WebView无法全屏，体验效果差一些。对于页面加载慢，偶尔内存泄露，不同 Android 系统版本采用了不同内核的兼容问题等等，这些都是使用原生 webview 组件进行开发时常会遇到的问题。

因此目前面临的首要问题就是：如何解决当前描述的移动端生态乱象。

三、为什么要用 X5 内核来改善效果？（替腾讯浏览服务 X5 内核官网介绍背书）

腾讯浏览服务由QQ浏览器团队出品，致力于优化移动端webview体验的整套解决方案，使用QQ浏览器X5内核SDK和X5云端服务，解决移动端webview使用过程中出现的一切问题，优化用户的浏览体验。

X5 SDK是通过调用微信/手机QQ/空间的X5内核，解决系统webview兼容性差、加载速度慢、功能缺陷等问题，开发接入便捷，大小只有253K，仅需几行代码，即可解决一切令开发者们头疼的问题，为用户提供最优秀的浏览体验。

其相对于系统webview，具有下述明显优势：

速度快：相比系统webView的网页加载速度有近30%的提升。
省流量：云端优化技术使流量节省20%
更安全：24小时安全问题解决机制
更稳定：经过亿级用户的使用考验，CRASH率0.15%
集成强大的视频播放器，支持各种视频格式直接打开
适屏排版、字体设置等浏览增强功能的提供
Html5更完整支持。
无系统内核的碎片化问题，更少的兼容性问题 X5云端服务是通过云端技术保证用户在未装QQ浏览器的情况下同样可以使用X5内核提供的优秀服务，包括云加速、云安全、云转换三大功能。

四、小结

关于 Why 这个部分，主要通过分析当前市场环境和开发者所面临的问题，引出使用 x5 内核必要性讨论。对于前端开发同学而言，考虑如何更加有效的适配尽可能多的设备，兼容更多的用户环境，打造趋于一致的用户体验，在保证高度可用性的情况下，提供更多丰富的交互体验。腾讯对 x5 内核的介绍看上去似乎是相当可靠的，但它是什么，接下来还得一步一步讨论关于浏览器内核。

WHAT

一、关于浏览器内核是什么？

关于浏览器内核的讨论可以分成两部分：渲染引擎(layout engineer 或者 Rendering Engine)和 JS 引擎。 渲染引擎负责取得网页的内容（HTML、XML、图像等等）、整理讯息（例如加入 CSS 等），以及计算网页的显示方式，然后会输出至显示器或打印机。浏览器的内核的不同对于网页的语法解释会有不同，所以渲染的效果也不相同。 JS 引擎则是解析 Javascript 语言，执行 javascript 语言来实现网页的动态效果。最开始渲染引擎和 JS 引擎并没有区分的很明确，后来 JS 引擎越来越独立，内核就倾向于只指渲染引擎。浏览器内核主要的作用是将页面转变成可视化的图像结果，整个过程可以简化描述成如下步骤：

2013 年以前，常见的浏览器内核代表有 Trident（IE），Gecko（firefox），Webkit（Safari chrome 等）以及 Presto（opera)。2013 年，谷歌开始研发 blink 引擎，chrome 28 以后开始使用，而 opera 则放弃了自主研发的 Presto 引擎，投入谷歌怀抱，和谷歌一起研发 blink 引擎，国内各种 chrome系的浏览器（360、UC、QQ、百度等等）也纷纷放弃 webkit，投入 blink 的怀抱。

目前国内主流浏览器内核，如UC的U3内核、QQ浏览器的X5内核以及百度的T5内核在之前的版本都是基于开源内核 Webkit 开发，所以是在 Webkit 的基础上进行二次优化，在功能与性能上大同小异。而后随着 chrome 的发展，也逐渐转为了 blink 内核。

浏览器内核渲染引擎的基础结构

从内核整体结构上看，渲染引擎可以概括为主要包括HTML解释器、CSS解释器、布局和JavaScript引擎、绘图等：

HTML解释器：解释HTML文本的解释器，主要作用是将HTML文本解释成DOM(文档对象模型)树，DOM是一种文档的表示方法.
CSS解释器：级联样式表的解释器，主要作用是为DOM中各个元素对象计算出样式信息，从而为计算最后网页的布局提供基础设施。
布局：在DOM创建之后，WebKit需要将其中的元素对象同样式信息结合起来，计算他们的大小位置等布局信息，形成一个能够表示这所有信息的内部表示模型。
JavaScript引擎：使用JavaScript代码可以修改网页的内容，也能修改CSS的信息，JS引擎能够解释JS代码并通过DOM接口和CSSOM接口来修改网页内容和样式信息，从而改变渲染的结果。
绘图：使用图形库将布局计算后的各个网页的节点绘制成图形结果。

关于Android 浏览器内核

前面介绍有提到，在 Android 4.4版本中，原本基于 Android WebKit 的 WebView 实现被换成的Chromium实现，新的 Chromium 内部的渲染引擎改为使用基于 Blink/Content 内核的引擎。

关于 WebKit 和 Chromium 的区别，关键在于Google 放弃了之前由 Apple 主导的开源 WebKit，可以说 WebKit 是以前维系 Google 和 Apple 一个技术交流的重要纽带。Chromium 是从一个 WebKit 分支基础上逐渐走上了自研的道路，其采用了自研的 Blink 渲染引擎和 V8 JavaScript 引擎作为新内核重要支撑。

下面基于高低Android系统版本的两台测试机型的实际表现，对 WebView 内核在不同系统版本中的性能差异性进行简单量化：

从对比测试来看，在 Android 4.4 以上系统中基于 Chromium 内核的开发的WebView对比旧版本的 WebKit 性能和兼容性方面有了显著的提升，与之相对的是 Chromium 多进程的特性导致内存占用变大，而且库文件也达到了 28M 左右。下图是 Chromium 的架构和主要模块示意图，从图上可知 Blink 只是其中的一个模块，和它并列的还有众多的 Chromium 模块，包括 GPU/CommandBuffe r(硬件加速架构)、V8 JavaScript 引擎、沙箱模型、CC(Chromium合成器)、IPC、UI等

二、关于x5 内核有什么优劣，是否有其他成熟解决方案？

腾讯浏览器服务 TBS —— X5内核

腾讯浏览服务 TBS 在 2.3 版本中，其 X5 内核就是基于 Android 5.0 WebView Blink内核（M37版本）适配定制优化。

X5 内核号称适配 Android 全部主流平台，可以在所有 Android 手机上使用Blink的技术能力，具有更好的 H5/CSS3 支持和性能。设备有安装微信、手机QQ、QQ空间即可使用最新的 TBS2.3Blink 内核。其官网提供了x5内核相关参数信息：

实际对比测试表现：下面是在同一设备下，QQ 浏览器和 Google Chrome 浏览器在 H5 支持度对比数据。 设备：华为 Nexus 6p Android 7.1 测试平台：https://html5test.com 左：QQ Browser 7.2 X5 内核右：Chrome Dev 55 Chromium 内核

从实际测试对比来看，对比Chromium 内核实际数据，X5 内核的表现并不及预期。当然测试依据主要是从兼容性和 H5 支持度这些技术指标，主要是从技术的维度来考察的。考虑到实际开发场景中主要是兼容性问题比较突出，跑分不是最终目的，所以统一场景才是最重要的。下面看看 x5 的特点，可以做些什么。

典型行业解决方案介绍——白鹭引擎

目前针对HTML5游戏的解决方案已经非常多，针对成熟的技术类产品对比，通常有多个维度进行对比，不仅仅是技术层面，还有许多非技术层面的内容，这里不展开比较。

之所以选择白鹭引擎来介绍，不仅仅是因为白鹭引擎拥有众多成熟的产品可以一站式解决而受开发者热捧，关键在于它还跟腾讯 X5 浏览器有深度合作，其好处不言而喻，恐怕会是微信游戏开发不二之选。白鹭Egret引擎是一个开源免费的游戏框架，用于构建二维游戏、演示程序和其他图形界面交互应用等。Egret使用TypeScript脚本语言开发。当游戏完成最终的打包后，可以将程序转换为HTML5游戏。实现跨平台特性。

Egret Runtime 是白鹭一款支持3D的HTML5游戏加速器，解决低端机对HTML5标准支持不佳、体验差的弊端，适配不同的系统让HTML5游戏效果媲美原生游戏。跟腾讯浏览器 x5的合作，直接支持了H5游戏运行所需的底层功能，从根本上解决了碎片化和性能问题。

腾讯浏览器 X5 已经解决了 HTML5 游戏在各个应用场景的运行问题，而跟合作白鹭 Egret Runtime 又可以大幅优化终端体验。根据官网介绍，在有 Egret Rumtime 加速的情况下，HTML5游戏会有3-5倍的性能提升，对比 PhoneGAP 方案约有30倍的性能提升，从而使 HTML5 游戏接近原生游戏的体验。

HOW

一、如何借助 x5 内核来进行实践？

通过腾讯浏览服务官网提供的 X5 内核接入指南，将提供的内核服务的sdk集成到应用中。由于 x5 内核是在 Android 原生 WebView 基础上的二次开发，所以其提供的在开发者调用接口上和原生保持一致，兼容原生 webview 的各种属性设置，如果之前使用原始 webview 的几乎时可以无缝替换。

虽然对于主流移动应用开发模式的讨论已经是老生常谈，之前热议的 Hybrid 混合开发模式也被现在 ReactNative 、Weex 抢了风头。关键还是越来越多的场景需要高度动态化的内容，保持对用户友好且统一的体验同时，考虑更多的轻便快捷交互、快速迭代更新的特性。

脱离实际的应用场景来讨论哪一种开发模式孰优孰劣没有意义，关键还是要贴合场景选择最适合的，所以这里对三种开发模式的相关细节不展开讨论，只针对开发有 Web 类场景需求的情况进行考虑：

相比Native App，Web 体验中受限于以上5个因素：网络环境，渲染性能，平台特性，受限于浏览器内核，系统限制。

因此解决这些问题的关键在于提供一个良好的基础运行环境和一个成熟的完整解决方案。借助 x5 内核可以改善运行环境，到达交互趋于一致性。

关于“一致性”经常被理解为同一个应用在各种平台和场景下要有一致性的体验。但是在移动平台开发过程中，“一致性”应该是App视觉和交互习惯与其运行平台的习惯保持一致，用户整体体验保持一致。而 Web 开发“一次开发，跨平台运行”的特性与此存在一定程度上的冲突是合理的。

如上所述，借助 x5 内核的来进行实践的目的也就是如此。下面就按照这个设计思路就来进行具体的 x5 嵌入实施过程，从技术角度切入后，通过编写Demo试验比对实际效果，来判断带来怎样效益的提升。

二、要怎样进行具体的实施过程，解决那些已有的问题？

具体实施过程大致分为嵌入集成和实际功能应用两个部分。

集成 X5 内核

腾讯浏览服务 TBS 官网提供了 X5 内核SDK分为完整版和精简版。精简版不可独立下载x5内核，只能共享使用微信或手Q的x5内核，JAR包约190Kb。而完整版可独立下载x5内核，也可共享使用微信或手Q的x5内核，JAR包约280Kb。

由于X5内核的API接口和系统的保持高度一致，因此实际的使用方式与使用原生进行开发一样。关于实际的编码过程不展开描述，具体参照官方的接入文档进行。

x5集成过程中发现了下面有几个特点：

如果有安装QQ 或微信（国内发布的版本），并且已经打开过内置- web，下拉网页顶部空白处会出现了由x5内核提供技术，表示应用是可以使用共享的x5内核。
如果没有安装qq微信，应用不可以可以共享使用微信或 QQ 中的 x5 内核，但是不能共享使用其他集成了x5应用的内核，只能使用完整版内核sdk包。
有些设备首次启动无法启用 x5 内核，需要进程重启或首次启动长耗时等待以后才能正常使用 x5 内核。
当无法使用 x5 内核，腾讯浏览服务 TBS SDK 会默认使用系统内置的webview，两者接口保持高度一致。
x5对视频播放的支持很好，可全屏效果控制方便，腾讯也提供了配套的sdk后台服务。

实际功能应用（X5EngineDemo 示例程序）

用QQ浏览器 X5 内核SDK和 X5 云端服务，解决移动端 webview 使用过程中出现困扰开发者需要适配兼容性的问题，提升性能的同时优化用户的浏览体验，有利于统一用户设备基础环境。

带来的效益，主要是减少适配难度，提升产品兼容性和表现效果。成熟的产品和广泛的用户人群，提升保障同时减少出现不必要的麻烦，降低开发成本。

在开放中有使用Html5的Video控件来播放视频的情况，为了举例说明使用 x5 可以带来的效益。下面就从展示网页这个角度切入，对比看看 X5 内核能带来的什么样的效果：

从上图测试可以看出，对于首次加载网页，使用systemWebView进行网页加载耗时要优于x5，针对有开启缓存的情况喜爱，多次打开相同网页情况，x5的耗时是略比系统的少。

H5 游戏测试

如下图所示，在测试全屏H5游戏效果时，对比发现两者在高硬件配置的设备上体验差异不大，x5的帧率比较稳定。在某些低配置和低版本系统上运行时，x5的表现要优于系统浏览器内核，而且适配性更强。

播放网页视频

如下图所示，测试腾讯视频网站，发现使用系统 WebView 存在视频加载错误的问题，而使用了 X5 内核的则是可以正常播放。

但是，接入 x5 内核的成本也是需要考虑，开发者对于 X5 的评价也褒贬不一。下面测试哔哩哔哩弹幕网站的效果，在使用系统 webview 的情况下，是采用了哔哩哔哩带有弹幕的播放器，可以正常播放的同时也支持弹幕的显示。而采用了X5内核进行播放时，则自动替换成 x5 自带的播放器，可以看到loading显示的也是x5提供的界面，所以导致弹幕无法正常展示。

下面再看看全屏模式下的播放，x5 对比原生区别很明显。而在测试 H5 游戏时，x5是能够正常音画同步，而系统webview则没有正常背景音乐，帧率偶尔也会低了10左右，这些也都是很多开发者选择 x5 的重要因素。

Native与JS交互效果测试（JsBridge）

首先我们来了解一下为什么要使用JSBridge，在开发中，为了追求开发的效率以及移植的便利性，一些展示性强的页面我们会偏向于使用 H5 来完成，功能性强的页面我们会偏向于使用 Native 来完成。而一旦使用了 H5，为了在 H5 中尽可能的得到native的体验，我们 Native 层需要暴露一些方法给js调用，比如，弹Toast提醒，弹Dialog，分享等等，有时候甚至把h5的网络请求放着native去完成，而JSBridge做得好的一个典型就是微信，微信给开发者提供了JSSDK，该SDK中暴露了很多微信native层的方法，比如支付，定位等。

测试通过JsBridge进行webview中的js代码调用本地java接口的效果，试验进行辅助sdk开发的可行性。X5 内核也提供了js接口安全调研机制来保证webview本身的安全漏洞问题，而且也会及时响应 Google 对于浏览器内核漏洞的修复。

三、如何评判引入 x5 内核后带来的提升？

** 总的来说，关于 X5 引入带来的提升，可以从下面的维度去讨论。在之前的对比分析中依旧有描述相关特性，而且关于实际表现很难定性指标依据，这里不再重复介绍。具体可以参照 Demo 中的实际使用效果，对比 X5 内核带来的提升效果。**

页面加载速度（部分页面预加载缓存控制）
界面使用流畅度（游戏帧率，效果稳定性）
显示兼容性（页面兼容性，多机型适配，界面效果一致性，视频播放等）
交互和特性支持（js支持丰富友好程度，新的HTML特性）
稳定性和安全性（安全漏洞补丁修复）
可持续性（迭代更新支持）

总结

通过预研X5内核，梳理了浏览器内核相关的概念，按照典型的 2W1H 模型对比分析X5内核其技术特性和实际应用场景，在技术试验方面从多个维度来讨论可应用性。

其实从前面的描述可以知道，腾讯推出 X5 内核主要是为了解决Android终端设备的差异性所造成的前端页面适配和浏览体验问题，意在打造一个可以让开发者减少适配工作成本，提升用户体验的一致性，为移动应用提供基础浏览器服务。

根据调研过程中对浏览器内核技术的学习，以及对市场成熟应用场景的分析，基于 X5 内核sdk，我们可以做些什么？

如果考虑开发 H5 游戏引擎，这个行业中已经太多的成熟解决方案，而且用户普遍对H5游戏的接受程度还有待提高。像微信拥有很好的流量入口，本来是拓展H5游戏的好平台，但是自身加以了严格限制，禁止朋友圈公众号转发H5游戏之类的。

假设基于x5做二次封装，打造自己的sdk。但是 X5 跟系统 webview 接口保持高度一致，二次封装只能是增加开发者使用难度。而且浏览器内核相当难以维护，因为快速迭代导致直接整合的成本太高。

如果做集成辅助类sdk，类似微信的JS-SDK，这是微信公众平台面向网页开发者提供的基于微信内的网页开发工具包，目的是减少网页开发者使用 js 与微信App Native交互的成本。这里设想一个场景来考虑：比如有这样一个场景，一个网页开发者打算开发一款游戏或者应用，但是考虑到开发成本和效益，直接通过实现H5界面后包成壳后，作为 App 来上架发布。这样实现快速开发的同时，又可以进行动态化内容可以快速更新，减少传统 App 迭代更新的各种弊端。

现在有很多类似白鹭引擎之类的厂商提供了一整套的解决方案，但是链接 H5 和 Native相关的设想确并不是很多。比如 H5 开发者使用native平台本身的特性来进行交互设计的成本还是太大。虽然有类似 JsBridge 手段，但是同时兼顾js和native开发，需要网页开发者更大的成本，而怎么提供更丰富流畅的H5交互体验支持就是可以尝试去解决的问题。

总之，可以利用 x5 的适配性强的特点展开更多丰富交互设计和提升用户的设想，把浏览器内核这项基础性的底层服务应用得更好。