陈子舜，腾讯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连接建立花费，到浏览器首页渲染的时间。都可以非常精准地提供更多业务的监控方式。
同时，未来的时间点监控也将会更高精度超越毫秒的时间戳。目前，这一系列的数据已经在公司很多业务都开始进行测量，给后端运营同学提供更多有意义的数值参考，更加及时，精准得发现我们的业务在不同地区，不同运营商中更加精细的业务数据。
活动下半场内容 活动答疑总结 | 
