谁说腾讯不创新

    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出来，我也过去瞅一下他们具体如何保持连接，基本原理都一样。当然我相信他们的服务器端是绝对的强。