腾讯浏览服务（TBS）
腾讯浏览服务是将X5内核进行深入整合，用一个应用或一个小的SDK就可以将X5内核集成到APP中的能力。这对于X5内核在安全性、稳定性和HTML5能力增强方面有很强优势。
目前我们的X5内核已经在微信、QQ等公司内外超过1000个APP上被使用，内核覆盖度超过97%。
内核演进
X5内核最早是在QQ浏览器中集成和推出的。早在android2.2、2.3时代就推出了自有的内核。这个内核一方面主要是解决各种加载、渲染性能问题，另一方面也是希望推动优化方面的一些体验，以此不断完善浏览体验的过程。
到了android4.2的时候，JB版本内核做了一个升级，支持了硬件加速，内核性能得到了较大提升。这个内核还是基于传统的Webkit内核。
在去年年初的时候，我们将整体内核架构切换到了Blink内核上，后来还在不断加快内核的迭代。目前大家在线上使用的是基于Blink m53的版本。我们希望通过不断的版本迭代和性能优化来推动业务的发展，减少用户在业务上遇到的问题，同时应用到最新的内核能力。
内核需要做哪些优化
对于一个页面，我们要从网络上把页面加载下来，对它进行解析排版，最后渲染。
我们要求页面加载速度要快，给用户愉快的体验，使用户更好地去消费产品。
页面交互要流畅地完成，也是内核需要做的一个重点工作。
网页加载优化网页加载特点
网页加载通常为突发的大小量文件下载。网页的加载速度随着带宽的增加，在一开始时会有所提升；到后来无论带宽提升到多少，加载速度都不会有明显提升。
在加载一个文件或资源的时候，延迟和页面加载速度是线性的关系。延迟越低，加载速度也会变得越低。
内核所要做的优化就是降低页面在加载过程中，每个连接请求、每次内核工作的延迟。
页面加载速度优化指标
页面加载速度“快”其实是用户主观体验，经过一些摸索，我们定义了以下指标：
1、首字——页面最初有内容的时候。
2、首屏——页面铺满全屏的状态。
3、全部完成时间。
目前重点关注的是首屏铺满时间，首屏铺满时间越快，用户体验越好。
加载速度优化
尽快加载资源，减少内核、网络加载资源延迟。
网络层优化：
DNS缓存：DNS是一个比较耗费时间的阶段，如果能把DNS缓存做得更好，就能大范围减少连接的延迟。
资源Socket并发控制、预连接：通过Socket并发控制和预连接技术，一方面提升Socket重用率，另一方面也是让Socket连接保持活跃状态。这样就可以让页面在加载过程中保持高速状态。
资源优先级：我们希望在首屏内的资源可以快速加载下来，首屏外的资源优先级可以低一些，往后做一些延迟。
透明代理：透明代理主要是为了解决在移动网络下不同运营商环境以及CDN部署不合理出现的一些情况，避免带来很大的网络延迟。通过后台合理的透明代理，可以解决这些不合理的应用情况，优化整体延迟。在终端上我们主要做的是在协议方面的协议优化。最早我们用的是HTTP的透明代理，后来改用了SPDY，目前也在尝试HTTP2，未来也可能去尝试最新的QUIC。
优化效果
如图是未经优化的网络和经过了优化的网络对比。可以看到未经优化的时候每个链路请求都会比较长，用户的并发性并不是很好，整体耗时长。
优化后每个链路的连接时间或解析时间会减少，大部分时间都是下载资源的时间，连接请求都处于并发状态，这样是最有利于用网络进行加载的。
前端推荐工具
PageSpeedInsight和Webpage Test这两个工具可以帮助大家定位自己的站点在加载方面有哪些性能问题，甚至能为CDN不合理的方面提供一些建议。我建议大家可以利用这些工具去衡量自己页面的加载速度方面是否有更多的优化空间。
在内核的发展过程中，根据我们对行业的观察来看，目前在Hybrid APP发展较快的情况下，很多时候并不支持加载一个网页，而是把页面当成APP的表现形式去展示。
内核后续优化方向
在Hybrid APP阶段，对加载速度提出了更高的要求。
更加贴近Native APP的加载方式。
基于ServiceWorker的加载
允许APP提前将业务的资源放入到内核缓存，跳过shouldInterceptRequest，手机QQ上的个别业务上首屏性能有25%左右的提升。
首屏标签
在首屏位置插入首屏标签，内核解析到首屏标签立即中止解析并排版和上屏。
<html><meta name=”x5-pagetype” content=”optpage”><body>…<first-screen/>…-
</body></html>
关键子资源缓存
关键子资源是影响首屏性能的关键（阻塞）资源。
我们希望在事先就能知道页面有哪些关键的子资源是会阻塞它的加载进程。目前内核通过统计的方式去看用户常用的子资源有哪些，并将这些子资源加入预缓存名单。之后在Web的规范化方面也会做更多突破。
页面渲染优化页面交互优化
页面交互的流畅涉及到页面的滚动、缩放，页面上动画的播放是否流畅，是否能快速响应交互。
如何做到流畅
在渲染过程中，渲染速度受多种条件制约，渲染管线各阶段耦合紧密。
内核要想优化渲染的过程，要解耦渲染管线，让渲染管线之间没有太强的联系，避免重复绘制。
当前的渲染架构
内核会通过硬件加速和图层混合来减少渲染的节点或任务。图层混合就是把一些相关的元素放在同一层，非相关的元素放在另外的层去汇总。
优点
Layer的内容变化，只需要更新所属的GraphicsLayer的缓存即可。
CPU绘制内容，GPU混合GraphicsLayer。
分层依据：CSS Transform&Opacity、Fixed、Overflow-scroll、特殊元素（canvas、webgl）。
如何分层才是渲染最优？
分层的目的主要是减少重绘，当元素有位置变化时适合分层。
虽然分层能够减少浏览器的重绘，但是物极必反。分层太多会导致浏览器遍历和计算的耗时变长，分层面积过大会导致渲染所用内存增大。
可视区域内分层太多且需要绘制面积太大，渲染性能非常差，甚至达到无法正确显示的地步。
静止的元素周围的内容频繁变化的元素需要单独分层。
分层原则
分层原则是减少渲染重绘面积与减少分层个数和分层总面积。
元素只有相对位置变化的需要分层。
元素更新频繁需要分层。
较长较大的页面注意总的分层个数。
避免某一块区域分层过多，面积过大。
后续展望
Web发展趋势
HybridAPP和Web APP对于Web发出了新的挑战。现在的页面不再是网页，而是变成一个真正由APP承载的界面。
前端有很多框架来优化性能。
在终端，最近比较火的是微信小程序架构，Google也在推广他们的Progressive Web APP架构，也是为了解决在新的挑战下Web所遇到的瓶颈。
内核会通过性能提升和更丰富的能力扩展来进行优化。
这是Google对于内核发展方向给出的简要示意图。
以后大家使用的不是单一的内核状态，而是把内核的加载、网络渲染甚至js引擎，都可以作为一个独立的service对Web提供服务的能力。通过解耦让Web得到更多能力的扩充。
WebAssembly
Chrome、Firefox、Safari、Edge共同推动定制的一套标准。2017年2月28日，一致宣布MVP版本完成，chrome M57和iOS 11支持。
执行效率方面更高效。执行效率约是JavaScript的2-3倍，Native的60%以上。
WebAssembly与JavaScript可互相调用，并支持C/C++编码。
WebAR
VR是一个新的领域，无论是资源还是使用过程都存在一些问题，也期待大家一起尝试探讨，怎样推动VR的实际使用。