Microsoft WPF/E vs Adobe Apollo
2006-12-17 18:53 Cat Chen 阅读(7007) 评论(27) 编辑 收藏 举报整个.NET社区都在庆祝WPF/E开始CTP,且慢,看看河对面的Flash社区好像也在举行隆重的庆典哦。
AVM2开放源代码
这几个星期发生在Flash社区的震撼事件,包括Adobe将ActionScript Virtual Machine 2(AVM2)的核心源代码捐献给Mozilla组织,变成了一个叫做Tamarin的开源项目。Tamarin的目标是实现一个高效的ECMAScript 4th edition(ES4)引擎,它会成为现在Firefox中代号为SpiderMonkey的JavaScript引擎的新核心,同时也用于运行ActionScript3的AVM2。
如果你想知道Tamarin有多震撼,先来看Tamarin和现有SpiderMonkey的执行效率对比,其中强类型代码(Typed Code)模式是指将JavaScript转换为ActionScript3,并且将function与prototype转换为class:
(摘自:Tamarin vs. javascript Performance)
看到这样的执行效率比较,再想一想IE那个执行效率比FF还要低得多的JavaScript引擎,或许将来Apollo应用的配置要求这样写:四核处理器加Internet Explorer或双核处理器加Mozilla Firefox,哈哈……我的意思是,如果你一定要用IE你就要多投资金到处理器上换取等效的JavaScript执行效率。
Tamarin开放源代码的战略意义是很实在的,这样Adobe就可以让开源社区服务于它的Flash Player了。Tamarin作为一个标准的ES4引擎,虽然现今只有AVM2和SpiderMonkey基于它,但这也足够形成一个强大的战略同盟——Adobe或Mozilla社区对Tamarin的改进都会让双方同时受惠。将来可能有更多软件考虑引入基于ES4的脚本语言支持,如果选用Tamarin的话将会让其开发者社区便得越来越壮大。哪天再出来一个神通把它tune up一下的话,其执行效率将可能远远抛离IE,这时候同样的脚本应用只在Flash或FF中流畅运行,你想不放弃IE都不行。
Adobe Apollo
另一个震撼的事件是Adobe的Apollo即将来临,这家伙将有十足的实力在全平台上与WPF/E对抗。
首先Apollo支持Just In Time(JIT)编译,这样其跨硬件平台能力就可以和Java/.NET比了。.NET所谓的跨平台是狭隘的,JIT主要是指跨硬件平台,软件平台则直到WPF/E才真正肯跨出了第一步,提供对MacOSX的支持。Apollo在挑选浏览器引擎时却费尽了心思,就为了选一个将来容易跨越更多软件平台的。
Apollo最终选中的浏览器引擎是开源的Webkit。Adobe官方宣布明年上半年正式发布的Apollo 1.0将支持Windows和MacOSX,但如果你了解一下Webkit这东西就发现它其实有足够的潜力实现大小平台通吃。Webkit本身作为Safari的核心,所以确保了MacOSX平台的支持;其次它也是KDE上KHTML浏览器的核心,进军Linux也应该没问题;最后它连Symbian Series 60(S60)也都支持,Adobe只需要去和Nokia握握手或许就能让Apollo进驻S60的智能手机,要知道在智能手机上S60的市场占有率可比Windows Mobile(WM)多得多。
反过来看看WPF/E,估计也是2007年上半年能够发布1.0正式版,官方支持的平台也是Windows和MacOSX,但MS已经支持其Linux的支持将依靠第三方来实现,也就是不会用官方的WPF/E for Linux支持。至于移动设备,将来就算能支持估计还是仅支持WM,这样适用范围还是受到了很大的限制。