主题：【原创】漫谈浏览器大战 -- （构架篇） -- Highway
=========================================
看到JavaScript，人们的第一个反应就是“这丫是Java的表弟还是连襟，是亲戚吗？”
事实上，JavaScript和Java既不沾亲也不带故，纯粹是当初市场运作的产物。JavaScript的原名是LiveScript，是当年的NetScape推出的（1995年）。当时Netscape在跟微软死磕，Sun呢也再跟MS在掐架。基于“敌人的敌人就是朋友”的原则，NetScape和Sun联手了，歃血之后，Sun允许NetScape把那玩意叫JavaScript，NetScape呢同意在Navigator浏览器中带上Sun的Java。
没过多久NetScape就黄了，但是JavaScript却保留下来了。成了Web编程Client端使用最广泛的一种语言。（当时微软也搞了俩类似的东西叫JScript和VBScript跟在里面搅）。
虽然JavaScript的足迹那儿那儿都是，但它始终是个敲边鼓跑龙套的，没人把它当颗葱。所以找网页编程的工作，会ASP/ASP.NET成，会JSP/Serverlet成，会JavaScript就不灵了。
真正把JavaScript开脸扶正，带入厅堂的是Google。这也是风云际会时事使然。
Google的霸权战略思想很简单，就是把所有的东西都挪到网上来。所以Google一直在不遗余力的鼓吹操作系统压根不重要，桌面应用也过时候了，浏览器+Web App才是人心所向大势所趋。你的数据都放在天上（Cloud），你的应用都从天而降（Download），一开浏览器什么烦恼就都没了。。。
把这个概念推销给亿万人民群众有一个问题，那就是WebApp要和现在的桌面应用有得一比。功能要相同，性能要相似，如果不是更快的话。
Google干的很玩命，也真用JavaScript写出了一些以前别人不敢想的东西。但是越往大写，JavaScript的问题就越显得明显，那就是 -- 太慢！
JavaScript是解释性语言，不像编译型语言那样是在CPU硬件上跑，而是在Interpreter软件里面跑，也就是由一个软件来执行你的软件。所以为了完成一统网络的大任，Google必须解决这个JavaScript的性能问题。于是Google就纠集了一帮人马，准备把这个JavaScript重新来过。Google的这个班子在丹麦，这个项目的代号是"V8".
问题的关键是JavaScript是一个高度动态的语言，是Prototype-based的语言，Object的Properties的Get/Set操作以及函数调用都是现场动态查找（在HashMap里面不停的找）。如果JavaScript能像Java那样有个Class就好办了。每个Properties和函数的地址就是敲定的了，不用一次次的在HashMap里找了。
V8的一个创新之处就是引入一个"Hidden class"的概念，也就是在执行JavaScript的时候，悄悄的创建一个个的hidden class。以后的对象呢，想办法往hidden class上套，如果对上了，那么JavaScript就好象是static typed的语言了，譬如说Java。
虽然JavaScript是一个高度动态的，但实践中他们发现90%的object还是有pattern的，所以Hidden class派上用场的机会极大。那些套不上的只是少数，那点性能损失认了也罢。
我认为Hidden class这个东西盘活了JavaScript。因为它使JavaScript变得像Java了。这个桥梁一旦建立起来，那么Java这么多年在程序优化上面的东西就不是就可以“借鉴”了吗？
事实上，Google从Sun挖了好多人，它现在的执行总裁Eric Schmidt就是原先Sun搞Java出身的，另外Java的大拿Josh Bloch也被Google挖去了。所以JavaScript一旦通过Hidden Class和Java搭上桥，那剩下的事情就好办了。
如果你留心一下V8（最新的版本叫做Crankshaft）的主要Feature，那它和和Java的关系就一目了然了。
1. 一个简单但是快速的编译器（借用的WebKit的）把JavaScript先编译成机器代码，这一步不要求什么优化，但是要快，延迟要越小越好（Java不太一样，一开始是不编译的，而是解释执行）
2. 一边运行，一边profiling，发现热点程序段。（注意，从现在开始，以下部分就和Java的HotSpot VM原理一模一样了）
3. 对"热点"程序段进行重新编译，这次要结合现有的Profile知识并用一切可能的优化手段重新生成机器代码（（譬如loop-invariant code motion, linear-scan register allocation and inlining）），并且允许根据现有知识进行一些猜测。
4. 如果第三步优化的程序在后面遇到了新的情况无法handle了，那么扔掉优化程序，按第一步产生的“笨”code来执行，以保证正确性。
5. Heap管理采用和Java一样的Generational heap。分为Young和Old两代。年轻的一代Heap要时不时的clean，而老一代呢，则尽量不动，如果需要动的时候，也要根据情况决定是大动还是小动（就是Clean完Garbage以后要不要compact heap），尽可能的减少执行的停顿。
6. 为了加速JavaScipt VM的启动速度，将一个标准的Heap镜像存放到文件中。这样当一个新的JS VM启动的时候，直接load现成的那个镜像文件，而不用将那些基本的JavaScript Library Load进来，从Hidden class那里再从头做起（Chrome的JavaScript库函数也都是JavaScript写的）。大家可能觉得这个feature似曾相识。对喽，，这个就是Java的Class Data Sharing(CDS)的JS版。
当然了，除了这些，Google还在其它方面下了些功夫。比如改写了很多以前的Library,重新设计和编写了了JavaScript的Regular Expression部分。经过这一系列的努力，新一代的JavaScript比原先的JS有了质的飞跃，速度要快10-20倍左右。士别三日，真是得刮目相看了。
Google在忙活的时候，别人也没闲着。FF阵营的人也对JavaScipt下了很大气力。他们的项目代码很有趣，叫做SpiderMonkey，TraceMonkey,JaegerMonkey。。。不知道什么时候能用上我们的“金丝猴”。
一开始，FF使用的是Tracing JIT，而不是Method-based JIT。也就是说它不是见到一个Method就给它JIT成机器码（Just-in-time Compile），而是先解释执行并跟踪其动向。如果发现某段程序Hot，那么再编译。也就是说，FF的JavaScript更像是Java的做法。
但是呢，这种做法呢在实践中有一些问题，就是在解释执行和编译执行这两种状态之间切换的时候很不平滑，问题较多。所以呢，新一代的JaegerMonkey也变成Method-based的JIT了。上来就先编译，然后接着跟踪，遇到热点再进行二次编译。
IE呢，在这个问题上动手最晚，功夫下的也不是很够。IE9的JS比以前是快了很多，但和Chrome一比，差距还是很明显的。运行SunSpider测试程序还行，当我运行Kraken benchmark程序的时候，Chrome和FF都很顺利的完成了，而IE几乎死掉。恨不得过了100万年才完成，
从.NET 1.0开始，微软的VM (叫做Rumtime)就是Method-based JIT。在第一次碰到函数的时候将他编译成机器代码（你可以使用nGen将MSIL预编译成机器码），之后就一直使用这机器码，不再做任何优化了。事实上，Java和.NET的VM在程序执行一段时间以后，有无穷多的信息，可以做出C++做梦都不敢想的优化来。可惜啊。微软从来没在这个领域有任何举动，令人扼腕。
从理论上讲，Managed code (Java，C#这一类）性能上可以超过传统意义上Unmanaged code的，因为那些语言只能作静态优化，而Java和.NET呢，可以在运行时根据程序运行的具体情况作出新的优化，比如inline virtual function，这是C++永远做不到的。
既然微软在.NET的主战场上都没能有二次优化的能力，那么我认为它在JavaScript的战场上也不可能胜过Google甚至是FF。我看过微软搞IE9负责人的几个专访节目，从口气里听出他们已经怯阵了。他们反复强调不要只盯着JS一个方面看，要注意浏览器的其他方方面面给用户带来的综合感受云云，最后挺了半天算是来了句硬话 -- 到IE9正式发布的时候，我们JS的性能一定和对手们“可比”。世界头号软件巨头居然如此窝囊，可叹啊！！！
============================
（待续）
本帖一共被 1 帖 引用 (帖内工具实现)
个人最喜欢chrome，随着硬件性能的提升，进程多一点不是问题，异常隔离才是最重要的。
safari本来就占据所有苹果用户的市场，还有chrome出来时候似乎还是IE7。
至少没有好到让我switch的地步。
不过在Iphone和Ipad上天天用它，除了不支持Flash以为，倒也还能用。Safari用的是Webkit这个开源的大学，JavaScript engine叫做Nitro，也是Webkit的一部分。据称也是很快的。不过我没怎恶魔把玩过，就不做评论了。
不管浏览器本身是怎么实现的，眼下来看，从用户的角度，FF4似乎没有比FF3有更特别的东西。
比较显著的一个变化，是status bar的内容被转移显示到上方的地址栏中。这倒是一个好主意，不过目前的实现来看，颜色太淡，看不清楚。估计考虑是怕和地址栏中的内容混淆。如果不能加深颜色，也可以考虑用不同的颜色来实现。这样，既能够显眼，也能够和地址栏的内容区分开来。
Chrome 的界面实在是太简单了，简洁到找东西找不到。估计是朝着浏览器替代操作系统，变成用户直接操作界面的方向去了。不久的将来，手持设备，开机就是浏览器界面，也不是不可能吧。
html5和javascript的一个主要方向是给用户在浏览器内提供高效的音频和视频内容。甚至是将来可以在浏览器内玩3D游戏。
同样的，flash做这些已经是很好了。从客户端来看，从实现的角度，javascript的引擎和flash的 plug in，本质上似乎没有太大的区别。你提到的这些，按理，flash应该也可以去做。区别大概是在于，javascript的引擎，不同浏览器可以不同的实现方式，有利于竞争发展，flash的，可能只能由adobe来做了。
不过，从开发者的角度来看，javascript的一个缺陷，我觉得很明显的，是代码能够被人看的一清二楚，是不是会很容易被人抄？flash至少还可以保留代码为私有。
如果有一种可能性，javascript也可以以某种伪代码的形式出现，而不是完全的源代码，也许会更好一些？
微软也跟在后面起哄。为什么呢？因为他们都不愿意看到Flash做大，成为新一代的边准（Flash现在已经基本算是了）
所以Apple拼命的给Flash扣帽子泼脏水，说是Leak Memory,Use too much battery power, crash browser...并且冒着得罪用户的危险就是不在iPhone和iPad上支持Flash，算是狠的了。
微软也想搞垮Flash，所以他支持HTML5。但是他自己还有个和Flash类似的东西，Sliverlight。所以如果HTML5做成了，那么他的Sliverlight也就给Flash陪葬了。
苹果和微软反对，毫不意外的Google就站出来支持Flash了。所以这基本上不是一个技术问题，而是一个“谁想吃掉谁”的商业垄断和反垄断的问题。都是乌鸦，都TNND的黑。
你说的那个JavaScript的缺陷是很明显的。基本上没什么好办法。就算是搞成某种伪代码也没有，马上就有工具给你还原伪代码。Java的Bytecode和.NET的IL都算是某种“伪代码”，一样给decompiler和reflector给还原的真真切切的。
但是Google似乎从来不担心这个问题。client side的小伎俩你们抄去也无妨，他的好东西都在server端呢。所以你看谁能把Google map和Gmail的技术给偷去。
作为一个程序员，有时候我也反编译一下别人的code，不过有把别人的code吃透搞清的功夫，还不如自己来呢。所以到现在为止，Java和.NET阵营中对反编译都不是很以为然。
古狗地图本身没啥了不起的技术，就是服务器群阵容强大，反应速度快而已。所有的地图都是事先做好的256乘256的图像文件，下载到客户端拼接起来而已。
前些日子我用Silverlight做了一个prototype，就是下载古狗或雅虎地图的图像文件，在客户端拼接成一个完整的地图，满足缩放和漫游的功能。
悲剧的是有一个插件不支持。
它并不是简单的把一些图片下载到客户端，然后由JavaScript给拼在一起。它有地图数据（应该是矢量数据），航片，卫片，Street Live-view等图像数据，用这些东西合成出3D实地景观来，就好象你人在那里一样，不是很容易的事情。另外还要把所有的街道名称，周围的商业店铺，公共服务设施等等都集成起来给用户最终给用户一个简单易用的界面，不是那么简单的事情的。
另外，你查询Direction的时候，它给出的路径大多还真是最优的。如果你有什么特殊要求，可以用鼠标在地图上设计你想要走的路线，它马上就能重新计算更新过了，很快很准。
当然，它也有问题，也有Bug。比如一次我办一个去英国的签证，要到某个政府部门办一个手续。按着Google map给出的方向就是死活没有，眼看时间就到了，我都有些急了，赶紧在手机上看了一下微软的Bing Map，才算是找到了地儿。。。
就要象OSX一样把OS9包在iOS里面，因为原来flash在苹果机上run在MAC－OS9里。要是你，你也不愿意这样干啊！干嘛要把老掉牙的OS9搂着抱着的，上哪儿都带着？况且iPhone，iTouch，iPAD都是轻装型的机器。
http://developer.apple.com/library/ios/#referencelibrary/GettingStarted/URL_iPhone_OS_Overview/
Flash其实也是一个Script语言，有一个VM，只要有为Mac OS X/i OS专用的VM，Flash就应该没问题。苹果的OS是当年一个Unix上发展起来的，如果Linux上能有Flash，那么苹果OS上就不应该不可以！
Flash在Apple的机器上是有一些问题，远不如Windows上的稳定，但完全是一个技术问题，可以解决的。现在Steve Jobs把门彻底给人家堵上了。这一来，只好逼着人们走黑道了。几个月前hacker已经把Flash给放到iPhone上去了（名曰Frash），就是下载一个11M的package就搞定了，所以嘛，根本就不是一个技术问题。
Adobe是想让苹果把原来的老code带上。Adobe很懒的，Photoshop的memory leak一直到photoshop8都没有fix。后来苹果把flash的“门彻底给人家堵上了”，Adobe也说过，我们会把flash移植到iPAD上面去（NYT用flash做视频，苹果在iPAD的发布会上的NYT demo是两边连夜赶做的！—— 但还是露馅了，有的视频不能 run！）。
你看，到底还是
Adobe 是懒到家鸟！
Jobs 顶牛是顶在这里。
BTW，LINUX 和 OSX 的 kernels 很不一样，shell 都是 UNIX，模样看着象。UNIX 分好多家，OSX 跟 BSD（Berkeley Software Distribution, Berkeley Unix）是近亲，Sun Solaris 和 SGI Irix 是近亲。所以，如果Flash的VM是建在贴近kernel的low level上，就不能直接把在LINUX上的VM移植到OSX上，要多少改动一点。
虽然没有FF那么多插件，但是感觉很多用户友好的设计都是从opera上先发现的。
比如鼠标手势，再比如用拖曳的方式进行界面布局。比如新建空页面里面的快捷方式(speed dial)
还有，opera的回收站是我觉得最喜欢的回收站，因为经常顺手干掉的页面，以后还得用到。。。直接在回收站找就行了。
以后有机会再向您慢慢请教吧。
Adobe自己的问题也很多，说是真的也还就是这个Flash比较干净。为什么呢？因为Flash不是Adobe的产品，是Macromedia做出来的，后来给Adobe收购过去了。
我认为Flash不会触及kernel，除了IE以为还没见谁改动Kernel呢？你见谁安装完浏览器或plug-in需要重启的吗？
有意思的是Flash是为浏览器定制的，并不共用。比如我现在装了FF, Chrome和IE三个浏览器。对应的，我有三个Flash plug-in在我的计算机里面。
1. gcswf32.dll -- Google Chrome用的Flash
2. NPSWF32.dll -- FireFox 用的Flash
3. Flash10l.ocx -- IE 用的Flash
如果是在Kernel里，那么高一个就够了不是。
比如像铁手说的STATUS BAR在上方会不好 . 其余还有什么不好的地方么. 我个人认为还有很多问题, 比如BOOKMARK功能用起来很麻烦. 如果是改进微软的浏览器, 不从技术问题上来讲, 光从功能上来看, 大家有什么建议和要求呢?