谁说腾讯不创新?WEB2.QQ就是个挺强悍的反击。咋一看到时我不禁摸摸头,难道这就是传说中的QQOS?。电脑上国内普及的1M网速,首次加载2s,登录加载3s,大部分用户的体验应该都优于
这个。3G体验也近似于这种水准。算上各种因素(带宽被占用等),就算以20K/S的网速来看,首次加载的时间10s,而登录加载15秒,这是GPRS能达到的顶
级体验。或许,从门户站点的体验上来看,这并不是特别难以实现的事情;然而这是个应用,对比起许多应用程序的几秒乃至几十秒的启动速度而言,这种体验已经非常
优秀。先看HTML标签,它有着如下class:。class="javascriptEnabledwinwin6_1firefoxfirefox3_6geckogecko20100914_0flashflashexplorer
10_0
分析webQQ20分析笔记●interner。可以看到,它把环境都记录在了这里面,包括操作系统、浏览器、渲染引擎、FLASH版
本等等。我们大可以猜想,web2.qq是有对各个浏览器做相关HACK
的。但是,可以看到web2.qq里基本没用HTML5,UI用的是CSS绝对定位的九宫格负外边距圆角,相当不语义化的解决方案更甚者,其中有些应用还是只有IE下才能使用从这点看来,开发团队显然认为IE才是国内最大的用户群使用的浏
览器。可以从request上看到,WEBQQ2用的JS基础库是JET(http://code.google.com/p/j-et/)。这玩意儿挺不给力呀,文档少得可怜,但从那点可怜的文档上看来,它其实是个黏合剂:把各种JS库给无冲突地黏合起来,以达到多框架并用的开发。这个框架主要分为三个层:最底层:JS扩展功能与代码组织功能,用于增强JS对多框架explorer
开发的黏合能力
分析webQQ20分析笔记●interner。中间层:跨浏览器扩展模块,及其它可选模块
比如选择器等。似乎,选择器、AJAX、JSON、基础UI及交互等功能是放在这个层面的。应用层:UI组件、实
时动画、游戏引擎等。大块头就放这里,而这些估计都不是初次加载的东西。而未经GZIP压缩的jet.all.js大小为80K,只比jQuery略大一点点,那么我们大可以假设:web2.qq用的是jQuery,加上一些如JSON、基础
交互的实现。web2.qq用的是jQuery的一个子集,加上基础UI组件、所使用到的交互等功
能模块。个人看来,第一种情况
不太可能。因为里面包含了大量的UI交互,如弹窗、自动贴齐、拖曳、九宫格圆角、PNG半透明等等。我不信WEBQQ会把这些轮子在每个APP上都重造。所以,使用jet的理由就很明显了:webqq团队需要一个胶水,把各种选用的框架给粘在一起,而且开发成本与学习成本都要足够低。所以,就选用了jet,和一堆流行的框架。而就个人看来,它核心库里应该包含的实现有
:jet核心。
sizzle选择器。
xhr/ajax。基础动画、拖曳、贴齐、弹窗、窗口大小调整
等交互。嗯,好像也没看出WEB2.QQ里有多少动画。尺寸、swf、css、数据等等一堆杂七杂
八的小东西。曾经有考虑过使用jQuery与jQueryUI里的交互部分来作为应用的支撑库,但jQuery+uicore+interactive加起来将有150K的大小,显然web2.qq用了个
更轻量的解决方案。所有的大型应用都得考虑模块加载问题,如何保持模块间的相互独立及良好通信等等。在页面内容的加载问题上,其实之前都已经有了比较多的解决方案:预加载:某些大块头的东西应该在用户驻留在
页面上的空隙进行加载。懒加载:该加载时才加载,而优先加载用户可
能操作的部分。CACHE:其实这个在网页上比较难实现,但也不是没有办法:使用AIR/HTML5或是内嵌页面的瘦客户
端。严格来说,除了HTML5之外的解决方案,都不能算在标准的范畴。而WEBQQ2最集中
体现了前两者的使用。让我们从HTTPRequest的角度分析下web2.qq.com的加载:HTML的流量大小基本可以忽略,主要重量在JS上面。从这点上看,跨浏览器的脚本已经成为WEB开发的难点与重点。首次载入页面的JS预加载:jet.all.js库80K,webqq.main.j
s库100K。而且,只有JET放在了head里加载,而webqq.main.js是放在div#desktop后面加载的,所以,时间线上到把页面展示出来并可以点击"登录键",只有100K左右的HTML/CSS/JS,剩下的都是应用栏及任务栏等的加载,然后就是那一堆图片的加载与默认应用的加载。
永远不会进行自动登录。一是保证了网页沙箱上的安全性,二也不会让浏览器一次承担500K以上的加载负担,保证了体验的平滑过渡。相信用户也都能接受没有自动登录功能的WEBQQ。点击登录后再次加载不
超过300K的JS。这里俺有点困惑,因为真的需要300K来实现主要的QQ功能么?毕竟很多的应用其实都是基于网页实现,并不要求直接脚本实现。估计,这里还是有优化空间的。所有控件使用独立的J
S。模块化的体现。中间或许难免会有重造轮子的事情,但却是大型团队开发所难以避免的。腾讯一惯强大的服务器
支撑能力。这点其实非常重要,否则加上每次加载的延迟与缓慢的速度,甚至偶尔还来个404什么的,体验绝对不会是现在这个样子。CSS文件上的加载基本与JS相对应,也就
是一个JS一个CSS。同理,模块化的开发。会造成冗余但却足够实用和敏捷。貌似没启用GZIP?有可能是会对服务器端性能造成影响?粗略估计,使用了GZIP后首次加载的180K的JS会变成50K左右,不过,有没这个必要
呢?。最近在翻译《HTML5forWebDesigner》,也的确像上面写的那样,HTML5/CSS3的工作只是把原本很流行的、却需要HACK或是需要脚本的东西-迁移到了较为定义式的语言
上罢了。所以,腾讯发力了,腾讯证明了,一站式的体验也能在WEB上实现,而且用的不是新标准的东西,而仍然是WEB2.0的东西-在IE下都能正常地使用,
虽然不那么流畅。但是随着腾讯的WEB2.QQ及社区开放平台等的相继出现,有个依然没太大改变的地方
是,接口依旧相当封闭。这点依然让我比较不满呀。就像是,腾讯走的是比较像APPSTORE的道路:开放了这个平台给你,但你只能用这个平台,而不能用其它
平台。但的确的,腾讯在用户体验与IT应用上,都是在国内处于领航地位
的。虽然一家独大的确比较让人苦闷。也期待国内其它IT企业在腾讯的压力下能迎头赶上,把国内的web与标准化真正推动起来。也继续期待HTML5时代的真正来临,尤其
是离线与同步应用上上。
分析webQQ20分析笔记(转)
转载本文章为转载内容,我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题,欢迎原作者联系我们进行内容更正或删除文章。
提问和评论都可以,用心的回复会被更多人看到
评论
发布评论
相关文章
-
UltraCompare v21.00分析
UltraCompare v21.00 使用后,就喜欢上了对于经常对比代码和文件夹的我来说,UltraCompare真是太方便了美中不足的是,只能试
UltraCompare 导出函数 打印日志 下载地址