【转】webqq实现

谁说腾讯不创新

    2010-12-09 11:37    总点击量:160     总评论数:2

        谁说腾讯不创新?WEB2.QQ就是个挺强悍的反击。咋一看到时我不禁摸摸头,难道这就是传说中的QQ OS?

【总体体验】

电脑上国内普及的1M网速,首次加载2s,登录加载3s,大部分用户的体验应该都优于这个。3G体验也近似于这种水准。

算上各种因素(带宽被占用等),就算以20K/S的网速来看,首次加载的时间10s,而登录加载15秒,这是GPRS能达到的顶级体验。

或许,从门户站点的体验上来看,这并不是特别难以实现的事情;然而这是个应用,对比起许多应用程序的几秒乃至几十秒的启动速度而言,这种体验已经非常优秀。

【架构鸟瞰】跨平台:

先看HTML标签,它有着如下class:

class= “javascriptEnabled win win6_1 firefox firefox3_6 gecko gecko20100914_0 flash flash10_0″

可以看到,它把环境都记录在了这里面,包括操作系统、浏览器、渲染引擎、FLASH版本等等。

我们大可以猜想,web2.qq是有对各个浏览器做相关HACK的。

但是,可以看到web2.qq里基本没用HTML5,UI用的是CSS绝对定位的九宫格负外边距圆角,相当不语义化的解决方案……更甚者,其中有些应用还是只有IE下才能使用……从这点看来,开发团队显然认为IE才是国内最大的用户群使用的浏览器。

JavaScript:

可以从request上看到,WEBQQ2用的JS基础库是JET(http://code.google.com/p/j-et/)。这玩意儿挺不给力呀,文档少得可怜,但从那点可怜的文档上看来,它其实是个黏合剂:把各种JS库给无冲突地黏合起来,以达到多框架并用的开发

这个框架主要分为三个层:

最底层:JS扩展功能与代码组织功能,用于增强JS对多框架开发的黏合能力。 中间层:跨浏览器扩展模块,及其它可选模块比如选择器等。似乎,选择器、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最集中体现了前两者的使用。让我们从 HTTP Request 的角度分析下 web2.qq.com 的加载:

HTML的流量大小基本可以忽略,主要重量在JS上面。从这点上看,跨浏览器的脚本已经成为WEB开发的难点与重点。 首次载入页面的JS预加载:jet.all.js库80K,webqq.main.js库100K。而且,只有JET放在了head里加载,而webqq.main.js是放在div#desktop后面加载的,所以,时间线上到把页面展示出来并可以点击“登录键”,只有100K左右的HTML/CSS/JS,剩下的都是应用栏及任务栏等的加载,然后就是那一堆图片的加载与默认应用的加载。 永远不会进行自动登录。一是保证了网页沙箱上的安全性,二也不会让浏览器一次承担500K以上的加载负担,保证了体验的平滑过渡。相信用户也都能接受没有自动登录功能的WEBQQ。 点击登录后再次加载不超过300K的JS。这里俺有点困惑,因为真的需要300K来实现主要的QQ功能么?毕竟很多的应用其实都是基于网页实现,并不要求直接脚本实现。估计,这里还是有优化空间的。 所有控件使用独立的JS。模块化的体现。中间或许难免会有重造轮子的事情,但却是大型团队开发所难以避免的。 腾讯一惯强大的服务器支撑能力。这点其实非常重要,否则加上每次加载的延迟与缓慢的速度,甚至偶尔还来个404什么的,体验绝对不会是现在这个样子。 CSS文件上的加载基本与JS相对应,也就是一个JS一个CSS。同理,模块化的开发。会造成冗余但却足够实用和敏捷。 貌似没启用GZIP?有可能是会对服务器端性能造成影响?粗略估计,使用了GZIP后首次加载的180K的JS会变成50K左右,不过,有没这个必要呢? 【展望】

最近在翻译《HTML5 for Web Designer》,也的确像上面写的那样,HTML5/CSS3的工作只是把原本很流行的、却需要HACK或是需要脚本的东西—迁移到了较为定义式的语言上罢了。

所以,腾讯发力了,腾讯证明了,一站式的体验也能在WEB上实现,而且用的不是新标准的东西,而仍然是WEB2.0的东西—在IE下都能正常地使用,虽然不那么流畅。

但是随着腾讯的WEB2.QQ及社区开放平台等的相继出现,有个依然没太大改变的地方是,接口依旧相当封闭。这点依然让我比较不满呀。

就像是,腾讯走的是比较像APPSTORE的道路:开放了这个平台给你,但你只能用这个平台,而不能用其它平台。

但的确的,腾讯在用户体验与IT应用上,都是在国内处于领航地位的。虽然一家独大的确比较让人苦闷。也期待国内其它IT企业在腾讯的压力下能迎头赶上,把国内的web与标准化真正推动起来。

也继续期待HTML5时代的真正来临,尤其是离线与同步应用上上。

JET代码范例及API  SVN地址 http://j-et.googlecode.com/svn/truck/

关键字(Tags): webQQ JET

上一篇U盘终结者网丫场掀云计算应用的革命热潮
下一篇中科院研究生院利用ipv6代理实现免流量费上网方法

#2发表时间:2010-12-9 16:38:05 引用 回复

Web QQ算是web应用的尝试,此文也仅仅写了一些界面的东西,而且WebQQ还有一个Sliverlight版本

Web QQ的核心应该是消息服务这块,不知怎么实现的。下面贴一个网上的分析:

Web QQ的原理大概如下:
客户端的JavaScript建立连接后,发起一个长连接。如果服务器端没有收到更新或消息,这个HTTP连接就一直不会返回任何数据,直到超时(一般不会超过60秒),超时会发回一个数据,指示客户端再次发起长连接;如果服务器端有数据,那么服务器端也会发送数据,并指示立刻断开这个连接,客户端收到数据,对应更新浏览器页面,还是会再次发起长连接。如此长连接不断,直到退出。简单说,客户端JavaScript就是一个循环创建连接查询的过程,当然还需要加入错误异常(譬如网络异常)的处理。
而服务器端的Cometd实现,我猜是使用epoll或者又叫NIO的技术,原理基本上是收到HTTP连接,不再是单独创建一个线程来处理,而是直接把连接放归epoll或NIO的框架接管,只有需要读数据或者需要写数据时,再通过epoll或 NIO的API进行通知。epoll或NIO可以看作一个单独线程,而这个线程里面所有数据处理基本都是跟网络有关,不会堵塞,所以可以同时接管1万到几十万的连接数据读写(最近通过dbanotes看到50万连接的极端案例)。所以这种框架下的Cometd服务器端,实际线程数小,开销很小,只要网卡够快,内存够大,CPU够快,程序够稳定,就可以轻松支撑万计的长连接。
如果按照一台服务器支持1万的长连接来看,只需要100台服务器就可以支持100万的web QQ在线了。而服务器的均衡可以在JavaScript端稍作处理,或者外加一台服务器做均衡即可实现。而以腾讯在服务器均衡、服务器群部署方面的经验来说,这些早是小儿科了。
我猜测web QQ要么有自己很成熟的Cometd服务器框架,要么就自己专门针对web QQ开发他们自己的Cometd服务器。直接使用Apache + PHP或者已有的服务器,估计很难达到高性能高稳定性。而重新开发一款Cometd服务器,对于有经验的开发人员和设计人员,花个把月时间,应该可以完成。
上述这些理解,主要是基于我自己开发web MSN/Gtalk/Facebook Chat/Yahoo Messenger网页聊天服务( http:/webuzz.im/ )的理解。相比较web QQ而言,我开发的网页聊天还需要从服务器端再连接其他服务器(譬如MSN/Gtalk的官方服务器),服务器端还需做很多其他方面优化。我使用的 Cometd服务器是自己定制开发的,使用的通信协议则是Java2Script的Simple RPC/Pipe( http:/j2s.sourceforge.net/ ),不是JSON相关的协议。以前看到web QQ出来,我也过去瞅一下他们具体如何保持连接,基本原理都一样。当然我相信他们的服务器端是绝对的强。


Total views.

© 2013 - 2018. All rights reserved.

Powered by Hydejack v6.6.1