無標題文檔

初瞥 Google Chrome Frame

三天前,你说下面的图是 PS 的,我信。而今天,这的的确确是张截图 -- 是的,这已经 不是梦想,是现实 -- 但实现梦想的不是微软,是 Google 。

https://friable.rocks/_/2009_11_05/8510781cf887.jpg

今天收到的最好的消息就是 Google Chrome Frame 发布 。Google Chrome Frame 通过 IE 的插件接口直接将 Trident 引擎 替换成 WebKit( 近些年浏 览器也流行双核了? )。

那个曾经开玩笑的言语 ,Google 「帮助」微软先实现了。作为竞争对手,Google 竟然帮助「改善」微软的产品,这看似玩笑的 背后,Google 会不会暗藏其他的野心?然而肯定的是,这时 IE 开发团队看见 Google Chrome Frame 这个产品, 保证会很尴尬。

说正题,目前 Google Chrome Frame 支持 IE6-8 系列浏览器。当用户安装好 Google Chrome Frame 后,在地址前加 cf: 即可使用 WebKit 核心浏览 页面,例如:

cf:http://www.taobao.com/

当然,如果你想直接让装了 Google Chrome Frame 的 IE 用户直接使用 WebKit 核心, 则在 head 中加入 meta 标记

<meta http-equiv="X-UA-Compatible" content="chrome=1">

即可。

顺便八卦下,这点看得出 Google 的幽默。 在 IE8 中定义了同样的 meta 名称,用于兼容 IE7 模式

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

然后看下随 Google Chrome Frame 提 供的 Javascript 文件 ,有个判断 Google Chrome Frame 是否已经安装的脚本:

// Look for CF in the User Agent before trying more expensive checks
var ua = navigator.userAgent.toLowerCase();
if (ua.indexOf("chromeframe") >= 0 || ua.indexOf("x-clock") >= 0) {
  cachedAvailable = true;
  return cachedAvailable;
}

if (typeof window['ActiveXObject'] != 'undefined') {
  try {
    var obj = new ActiveXObject('ChromeTab.ChromeFrame');
    if (obj) {
      cachedAvailable = true;
    }
  } catch(e) {
    // squelch
  }
}
return cachedAvailable;

https://friable.rocks/_/2009_11_05/9136981d22a8.jpg

看得出 Google Chrome Frame 有更改浏览器 user-agent 的计划。而从实际安装的版本看 ,user-agent 似乎没做更改,和 Chrome 浏览器如出一辙。

https://friable.rocks/_/2009_11_05/2703281d2978.jpg

更正,原来在安装好了 Google Chrome Frame 后,其会将更改原生 IE 的 user-agent ,例如本人机子上的 IE6 会更改成如上图(该死,我的 IE user-agent 又变长了)。

https://friable.rocks/_/2009_11_05/1866981d22a6.jpg

https://friable.rocks/_/2009_11_05/5255381d22a7.jpg

其他方面,查看源代码、界面和脚本的调试查看工具、甚至控件的样式都和其他基于 WebKit 的浏览器一模一样。或许以后我们可以将其认为是继 Safari、Chrome 后的第三大主流 WebKit 用户代理来看待。

https://friable.rocks/_/2009_11_05/7207781d22a6.jpg

不过目前 Google Chrome Frame 似乎不是非常稳定。经过上午的测试使用,发现稳定性还是 需要继续提高,同时部分页面的鼠标滚轮发现无法使用。

本人很看好 Google Chrome Frame。对于用户而言,装个浏览器插件比安装个新的浏览 器更为可以接受。同时根据国内的情况,在普遍脱离不了 IE 的大环境下,开发者能够切换 浏览器的内核更好的呈现页面,这将是件非常棒的事情。

妄想下,加以时日等此产品普及后,IE 可能就真的成了一具皮囊了…

-- EOF --

改造笔记本的散热系统

该死的惠普,有时候也是「实惠但不靠谱」,特别是散热方面。终于忍受不了我笔记本的散热 问题了,决定非要搞定这事。

从 Google 那儿得知原来 这款机子设计上有问题 , CPU 芯片和 GPU 芯片不在同一水平线上,因此 GPU 的散热无法直接通过金属散热片。更要 命的是惠普还用海绵将 GPU 和散热片垫起来(是怕压坏?),从而造成 GPU 的散热更加的 困难。

PC 的优势就这样发挥出来了, 三下五除二就用把螺丝刀将笔记本大卸八块 。拆开那销魂的主 板,发现事实果然如此。

https://friable.rocks/_/2009_11_05/456648171061.jpg

中间的灰色物质便是海绵垫,看得出其实惠普是给 GPU 留个散热片的位置,但不过间隙实 在太大,因此没派上用场。

https://friable.rocks/_/2009_11_05/897398170c3b.jpg

再来看看这块捣蛋鬼,现在 GPU 的发热量不比 CPU 低多少,难熬的还是用户自己。

去数码城搞定了散热硅胶以及相关的工具,里面的间隙我用的是硬币慢慢用锉刀和砂纸打磨 而成(别告发我破坏人民币呀)。

https://friable.rocks/_/2009_11_05/007738170a85.jpg

垫上打磨好的硬币,加上导热硅胶,使 GPU 直接和散热片接触(上面张为图例), 这样据说这样就能解决问题了。

重新装回去,这花了我不少的时间,到最后还多出四颗小螺丝、少了三颗大螺丝。 测试了下温度,发现平时稍微跑个大型程序 GPU 温度就能狂飙 100 摄氏度的情况大有改善。基本上一晚 上按照平时的使用情况,GPU 的温度始终没有超过 70 摄氏度。

https://friable.rocks/_/2009_11_05/470848170a74.jpg

垫了块硬币就能直接降温三四十度?!我对这个结果感到很惊讶 -- 惠普不会穷得连每 台机子加个硬币的成本都没有把,我文明用语。

好吧,总结下今晚折腾的心得

  • 将笔记本风扇清理干净,能让耳根清静不少
  • 硬币一定要打磨光滑,尽可能大的增加与芯片的接触面积(我用的是 800 号的砂纸)。
  • 最好是人民币一毛钱,因为它是铝制的。不过近些年的一毛钱硬币都是合金的了,所以最好用前几年的(铝制硬币要相对灰暗些,当然那如果你不差钱,用银币那更好)。
  • 拆机的时候要记住螺丝的位置呀,否则要像我一样现在总想着要从哪里拆三颗螺丝下来。
  • IBM 不做 PC 了,现在买什么牌子的 PC 笔记本真的很让人纠结。
  • 买惠普一定要买商务机,不要像我贪便宜搞了台家用机活受罪。

最后,笔记本的散热问题一定要早解决,否则烤大腿是小事,影响子孙后代的质量可就是大 事了。

-- EOF --

Mini,又个 Javascript 选择器

Javascript 选择器(selector engine)似乎从 jQuery 流行以来就大行其道,改变了原有 Javascript 选择 DOM 节点的方式。

目前 Javascript 选择器也有众多的选择,包括能列举出来的就有 PeppySizzle 以及 Sly 等,它们都实现了所有的 CSS3 选择器 并且性能不俗。

https://friable.rocks/_/2009_11_05/241818145cd9.jpg

而此次特别要推荐 Mini 的因素有很多。其最大的亮点就是从实用主义出发,简单高效的完成任务。

实用主义

jQuery 的作者 John Resig 曾经统计 jQuery 框架常用的几个选择器 。 很惊讶的发现用户其实常用 tagName、className 以及 id 就能完成 95% 以上的工作。

而 Mini 就从实用出发,它并没有标榜自己实现了全部 CSS3 的所有选择器,只是实现了下面的选择器及其变种:

  • div
  • .example
  • body div
  • div, p
  • div, p, .example
  • div p
  • div > p
  • div.example
  • ul .example
  • title

  • h1#title
  • div #title
  • ul.foo > * span

是的,虽然不多,但是相信在日常中已经足够使用。

https://friable.rocks/_/2009_11_05/601198145f37.jpg

实用主义虽然让 Mini 提供的功能有限,但从个侧面带来的优势就是 性能方面非常的理想 。 当然这还有与它的内部实现有关。

简单至上

Mini 的代码很简单,甚至不用恐惧于如何去读懂 Sizzle 这样的每行源代码。先从它的调用函数 _find 看起,往下阅读几行,你就发现它性能的秘密

if (!simple && context.querySelectorAll) {
    return realArray(context.querySelectorAll(selector));
}

很多的现代浏览器(包括 Gecko、WebKit 等)都 提供了原生的 Javascript 选择器支持 。 Mini 充分得利用了这点,从而将大部分的工作交给了浏览器(也免除了日后的维护之忧)。这点非常值得称道, 也是我们以后写 Javascript 应该走的方向 -- 要基于浏览器提供的功能而非类型进行对应的开发。

_find 其后的逻辑非常的简单,使用几个正则将提供的选择器解析出来,分别根据 getElementsByClassName、 getElementsByClassName 以及 getElementById 获取节点。

继续根据上面的思路,由于陈旧的 IE 没有既没有提供 querySelectorAll 也没有提供 getElementsByClassName, 那么它只能走到 else 的尽头,使用 filterByAttr 函数。

取到对应 className 以及 tagName 后,还得根据选择器获取其与其相符的节点,那么就轮到 filterParents 干活了。

filterParents 这个函数也是相对 _find 比较核心的函数,而且也是主要的性能消耗点。filterParents 其实要做的和 _find 类似,唯一不同的是它根据关系符向上剔除未满足条件的节点。

通过上面两个函数所得到的节点,通常已经是满足选择符条件的节点了。 但是可能的情况就是有重复的节点,这时就该 unique 函数上场,顾名思义剔除重复的节点。

这里要提到的就是 unique 函数做了个简单的 memoization 实现 , 作者的用心可谓从细节方面体现得淋漓尽致。还有个小技巧就是

var uid = +new Date();

竟然可以用这样直接返回时间戳,俏皮的代码让人再次感到犹如嚼了口薄荷糖,非常的清新(好吧,我火星了)。

读码到最后,有一点思考就是为何每次都要使用 realArray 函数强制将 NodeList 转换成 Array?虽然使用 querySelectorAll 返回的是 NodeList ,但是也是可以使用 Array 操作迭代。作者这样的做法我推测,可能是出于返回数据类型一致的缘故。

观点

说说到我的个人观点,这可能会让这篇文章前后矛盾。Javascript 选择器(selector engine)我个人不是非常推荐使用。

原因主要有两点,其一就是性能,其二就是会让写出来的代码过于的依赖于 DOM 结构。但能读到如 Mini 这样的代码,窥其内部运作机制,未尝不是件非常让人愉悦的事情。

http://james.padolsey.com/wp-content/uploads/me.jpg

最后,说说 Mini 的作者 James Padolsey 。我本人也很难相信,他竟然只有 19 岁!更难 得的是在 他 Blog 上的 About me 页面 中写道

What services do I currently offer?
- Everything JavaScript!

同时, 他也是 jQuery Cookbook 的作者 。 「小小年纪」能够有这样的心态以及成就,让我们这帮「前端老古董」感到唏嘘不已 :^)

Bang 兄 已对 Mini 的代码做了更为详尽的解析,有兴趣的可以参看 他的相关 Blog

我的照片

嗨!我叫「明城」,八零后、码农、宁波佬,现居杭州。除了这里,同时也欢迎您关注我的 GitHubTwitterInstagram 等。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 要知道作为码农取名是件很难的事情,所以不想在取名这事情上太费心思。

作为八零后,自认为还仅存点点可能不怎么被理解的幽默感,以及对平淡生活的追求和向往。 为了避免不必要的麻烦,声明本站所输出的内容以及观点仅代表个人,不代表自己所服务公司或组织的任何立场。

如果您想联系我,可以发我邮件 `echo bWluZ2NoZW5nQG91dGxvb2suY29tCg== | base64 -d`

分类

搜索

文章