循序渐进: HTML5在海量业务上的深度运用

陈子舜，腾讯Web前端研发专家。先后负责QQ空间、开放平台、SNS应用产品的Web前端研发工作和团队管理；业界笔名Puterjam，著名博客平台PJBlog作者；长期专注于海量服务业务的Web前端架构设计、运营优化、创新解决方案研究，同时也是多终端移动互联网技术研究和实践的先驱者。<<

讲座PPT下载及现场视频在线

HTML5早在2004年就开始被WHATWG提出。历经8年时间的发展，HTML5技术已经不再是纸上谈兵。目前W3C 的HTML Group中已有76个公司参与新的标准制定、贡献力量。未来前端开发的责任和前景非常重要，HTML5技术可以给我们的产品体验带来更多的机会，那么我们如何升级现有的胖子业务？ 8月21日晚，腾讯Web前端研发专家陈子舜，在腾讯大讲堂为大家带来了腾讯海量业务前端底层架构的详细解析，以及用户体验和我们该如何进行新技术的蜕变。在中国特殊情况下，要使用这些新技术并非一帆风顺、仍有很多困扰： 1. IE族（6 7 8 9）整体支持不济，其中IE6用户占了绝大多数； 2. HTML5技术发展非常迅速，我们该从何开始？ 3. 这些技术是否只能用在手机上？ 4. 如果用到我们项目中, 该如何开展？ ......

这些问题或许成为我们的障碍，但绝对不会影响到我们对HTML5技术的热情！对于一个真正的前端架构师，这些障碍只是浮云。首先，HTML5是解决众多旧Web时代前端问题的革新解决方案集合。其次，实战HTML5不能以‘仅在项目中用到’为目标，而是应该以更加前瞻的眼光去看这些技术背后、其诞生和繁衍到底经历了什么。最后，要看不同的HTML5技术能解决我们工作中的什么问题，更要看这些问题还有没有其他解决方案。带着疑问回到项目中去思考，游走于HTML5各种技术背后的原因。非同源资源的共享在分享开始，子舜带大家一起回顾，2004年web界诞生的一个非常伟大的请求解决方案 -- AJAX

这个方案的出现，让我们体验到了前后端数据交换不刷新页面带来的快感，给产品带来了更好的体验。但是新技术的普及并不那么顺利，这里也让我们遇到了很多问题, 其中在AJAX的实现中最麻烦的事情就是跨域问题（跨域问题的主要产生场景是由于很多大型Web站点，采用动静分离的资源部署方式，往往前端HTML页面和需要交互的Web接入端动态资源使用不同的域名，便于运营）。由于当时环境比较差、用户的硬件设备也比较糟糕，所以我们最早的proxy跨域解决方案并不成熟。 “请求数过多，页面渲染慢，proxy页面维护成本过高” 在以前QQ空间复杂的网络环境下，每个iframe的创建和渲染的成本都在0.5s左右，这是一笔非常昂贵的开销。

随后，我们意识到XMLHttpRequest的局限，升级成为现在常用的JSONP的方式。 JSONP看起来是一个不错的方案，解决了Proxy带来的各种问题。在腾讯的前端应用中， JSONP请求组件也经历了多代演化（[keyName]_callback隔离方式，htmlFile组件隔离方式，documentFragment隔离方式，iframe+js:隔离方式），但这些方式是否完美呢？本着不完美主义的技术追求者，我们也对JSONP提出了很多苛刻的挑战。JSONP越来越不能满足我们对海量业务的要求，我们希望更多去控制、去了解请求的过程。而JSONP无法满足，每次请求都在页面上花费很多script标签（尤其在多请求并发的情况下），服务端不可用、网络异常、数据损坏导致JSON格式破坏的几种情况，无法非常方便得区分监控，给用户提供高可用的服务只能靠开发人员的经验来做勉强的保证。

一个web业务，在异步请求过程中无法更好的关注和控制请求本身的状态，其实在很多方面，体验和解决方案都会变得非常不可控；柔性可用原则也无法达到最大化贯彻，技术的瓶颈和长时间的习惯，导致大家可能越来越少去关注这些问题。虽然对于这些问题都有不同的解决方案，但我们觉得这些解决方案并非完美。 HTML5为了解决现有技术方案背后的一系列原因和问题，提出了XmlHttpRequset 2.0 。新的标准给我们带来了更多的优化机会。

1. 数据移植性: a. JSON在应用中使用已经非常广泛，但是我们还是因为旧有JSONP方式的关系，需要把用以触发JSONP调用的_callback( )外套剔除，剩下的纯JSON结构，可以更灵活的用在更多场景，不局限于浏览器JS引擎。 2. 数据可控性: a. XHR一直都可以在请求的时候定制化很多个性的HTTP request头信息，不需要增加自己希望的额外信息到query string。例如：现有的静态资源服务器端按需合并，因为没有使用XHR（目前是JSONP），只能把希望在Web服务器上按需合并的文件的文件列表在URL query string上用某种我们自创的协议列出来，看上去比较迷惑。 b. XHR2.0标准，给到数据控制行为可以在数据发起前，加载中、加载后进行多种时间点的判断，甚至可以给到用户准确的加载时间，更好的控制和监控数据状态帮助我们更精确的实现系统柔性可用。甚至可以控制数据是否需要中断请求，以及告诉后端什么时候发起200或304响应。 3. 多样化的数据提交方式: a. XHR未来是一个趋势，可以统一web业务上所有的请求方式，使web业务对网络的方案一致化； b. POST有专门的对象统一处理； c. 文件和二进制流也可以直接发送；技术预言随后伴随着实践，我们希望 “业务后面可以回归到使用XHR进行请求的方式”。所以我们在朋友网上做了一些技术尝试，这次尝试主要还是先从跨域的方案开始实践。早在3月份，腾讯海量httpserver QZHTTP已经支持了XHR 2.0的CORS方案。同时从发布后的数据分析来看，节约掉的iframe开销可以获得 0.5~0.6 秒的提升。
其实部署并非顺利，跨域方案在IE8/IE9下其实还是存在明显的技术缺陷。微软认为跨域的请求是不应该带cookie信息的，微软的IE10才能真正支持到XHR 2.0的cookie授权信息。所以现阶段在PC上要使用跨域的CORS还是不能做到非常彻底的部署。团队成员开始回归最初的思考：与其更加较劲这些细节，为何不开始部署不跨域的服务？

进行同域的部署，有非常多可选方案，并且很多方案都非常成熟。通过各种代理，动态加速的方案，可以减少前端在请求方面的做的过多的兼容性问题，从而从底层解放开发在不同请求方式的选型。把时间更加专注在业务功能上。另一方面，前端开发在实际工作中除了一直在追求方案的极致优化，架构的模块化等语言成面的极致，同时也是海量业务的护航者。所以前端的监控和性能的测量也是我们一直关注的方向，子舜提出：“测量是优化的第一步”。为了提供更好的服务，我们需要对各个环节的网络情况、硬件情况进行了解。所以HTML5也是为了解决这个问题，提供了更加详细的监控手段。

HTML5的Timing，提供了更多细致的监控能力。从本地缓存读取，到DNS解释时间；从TCP连接建立花费，到浏览器首页渲染的时间。都可以非常精准地提供更多业务的监控方式。同时，未来的时间点监控也将会更高精度超越毫秒的时间戳。目前，这一系列的数据已经在公司很多业务都开始进行测量，给后端运营同学提供更多有意义的数值参考，更加及时，精准得发现我们的业务在不同地区，不同运营商中更加精细的业务数据。

在分享的下半场，子舜带来了更有意思的分享内容：

长期以来我们一直都非常关注用户的网络情况，而且也在这方面做了非常多的实践。随着中国带宽的不断优化和提升，网络问题会得到越来越多的改善。但优化工作是否就可以告一段落？反之，我们的前端优化将会迎来更多更深入的挑战。
例如，我们的业务，特别是社交业务，功能越来越复杂，用户对业务的要求也越来越高。同时也开始有很多业务开始终端化，硬件条件将会带来前所未有的挑战。我们开始思考：是否要像客户端开发一样、做更加深入的性能优化思考？

QQ空间今年最大的一个突破就是开始用可观的数据开始反映业务性能问题。 QQ空间的用户平均停留在30分钟以上的用户接近35%。这些用户都是实实在在得长期挂在空间，并且他们也是一直在忍受着我们业务因为功能逻辑复杂，导致使用过程中页面渲染性能效率低下的背景下，非常艰难地使用我们的产品。
接下来，第一件事情就是解决用户CPU的问题。

浏览器没有获取CPU的接口，但是我们有办法模拟出CPU的曲线。浏览器的setTimeout和setInterval，很多时候我们都用来做延迟处理，但由于浏览器的引擎单线程性，这两个接口都是一个非常不稳定的存在。如果在浏览器CPU资源消耗过高，并且js api处理时间过长，前端的定时器都是无法准确在我们期望的时间点上进行执行的，很多时候都是会延迟，而这个延迟可以被我们利用做成一个差值比例。通过这个比例，我们可以绘制出和当前CPU比较吻合的曲线。

在页面渲染的测量上，我们做了非常大胆的尝试，同时也给在前端的各种功能添加以及优化给出了更多有效的数据举证；给业务的按需加载有了更加具体的数值参考。前端一直以来的按需加载能力将会成为平衡CPU高峰的重要工具，相辅相成。
回到主题，那HTML5在我们的业务是否也会有CPU优化的更多方案思考？答案显而易见！HTML5在更加底层的方式做了更多的优化能力，而这里最具潜力的是，GPU加速。

在分享的最后环节，子舜给大家带来了页面渲染在GPU中的优化方案。首先，在大家常用的chrome/webkit浏览器中，GPU是在另外一个线程上处理的，这也就和以前的浏览器渲染单线程带来了一个非常好的优化。 GPU处理渲染和合成，其实会让web页面渲染得到更加合理的分配，GPU在处理动画及图片上有非常强的优势，同时也可以减少遗忘在CPU中处理整个页面带来的内存消耗问题。但我们可以把所有渲染都交给GPU么？答案是不能！GPU虽然在图像和动画处理上有先天的优势，但也有很多不足，比如文字处理和合成、页面树的合成，CPU还是会比GPU更加擅长。为了可以在业务中更好得利用到GPU，我们需要知道浏览器到底会在什么时候使用到GPU合成技术。如下图所示：

很多很熟悉的字眼，其实大家在经常使用css3的时候已经潜移默化在使用到浏览器提供的GPU能力了（小Tips: 但是这些也需要非常小心，特别是重构的同学，不要在一些没有动画的dom上加太多css3的动画处理或者带有css集成的dom。因为会增加前期dom树在渲染上不必要的GPU负担) 那我们如何更好得利用这个资源，子舜也给大家提供了一些HTML5 GPU 加速的银弹。

GPU在合适的时间去使用，HTML5的这些动画能力是作为局部动画使用，会给网页动画带来惊人的效率和帧数的提升。
分享中，舜子带来了一个非常常见的拖拽案例，这个拖拽案例分别在普通的left和top计算，以及css3 transform的差别。

通过chrome的timeline曲线可以看到，前面的Left/Top位移，带来了非常多的rendering和 painting成本，这些工作都是在CPU的帮助下完成的工作，而这些工作如果换在终端上实现，大部分的终端CPU都无法顺利完成这一个任务。而右边的曲线，可以看到render工作基本上就不存在了，同时浏览器页把paint的工作交给了GPU处理，从FPS线也可以看到移动速度是有很大的提升稳定在30~60之间。可以看到GPU确实在发挥其优势，同时我们可以更好得开始去利用这些资源。但CSS3动画是否可以取代js动画？以前setTimeout不准的情况在我们进入HTML5领域需要做游戏的朋友是否会有障碍呢？这个问题已有专家提出过，CSS3无法取代JS动画，但目前JS动画都依赖setTimeout，其实是一个死胡同。因为setTimeout单线程的不准确性，如果setTimeout超过16ms又会给设备带来超过25%的能耗浪费，CPU也会因此带来更多的资源浪费。所以为了解决这个问题，HTML5的专家也提出为JS动画，以及canvas游戏专门提供一个可以让浏览器知道开发需要进行动画处理的方式。requestAnimationFrame

继续刚才的拖拽实验, 如果在GPU和RAF的加速下，在曲线图上可以看到很多时候曲线是在60FPS之上的，而且这个曲线峰值也会出现更多超过60FPS的数值。

可以看到浏览器页开始准确得获知我们希望做的事情，从而更大程度上平衡CPU的资源，以及页面渲染和线程之间的资源，给页面动画让出合理的资源，减少了堵塞问题。在分享的最后，子舜也给大家带来一些学习HTML5的建议。

Q: 为啥jsonp不支持post？

A:JSONP是个泛的叫法，在舜子刚才的讲解中，意思应该是说，在跨域的场景下不方便简单高效的做出响应形式为JSONP的POST请求，但是依赖代理页面还是可以做到的，不过这是传统做法，应用HTML5 CORS会有更好的解决方案。

Q：HTML5是否会加速桌面操作系统的变化?chrome是否会成为google os的承载平台?有联系吗?

A：随着未来3年HTML5的飞速发展以及带宽的提高，基于HTML5技术的WebOS必将更加凸显出实用的意义，而对于传统桌面OS，将可以使用HTML5技术来构建本地应用和在线应用！

Q：跨域？

A：跨域通信请求的通用方案可以参考这篇文章：http://url.cn/7PYImM

Q：通过xhr清本地文件缓存，对于图片文件不知是否可行？

A：图片可以的，其实就是用XHR发一个显式设置no-cache header的request，URL一定要和你被cache的资源的url一致。不过XHR在不跨一级域的情况下，这样的事情笔记哦好做，传统方式用代理页搞定，如果跨一级域，可能要依赖CORS或者IE8+的XDR（不过XDR限制很多，一言难尽）