Table of Contents generated with DocToc

转眼2015年已经过去，不知不觉加入艺龙已有9个月时间。回过头来总结这9个月在艺龙工作的收获和感悟，有遗憾但也有惊喜。这九个月时间的工作带给我的，除了将我从传统的前端开发模式中带入到标准化工程化的开发模式中之外，还让我看到了前端正在经历的深刻变化，让我在身处这样的变化中时不断地自我反思。这九个月也在参与公司和团队的一些业务项目的过程中积累了不少的经验，很多应用到的技术甚至是从零开始，这让我收获颇多，但也因为之前类似项目经验的匮乏让我遇到了不少的问题。但我相信自己已经适应了这种时刻伴随着挑战的工作方式，也很享受这种不断突破自我的过程。

在团队协作的很多情况下，某个js的函数会根据不断增加的需求进而不断增加功能，如果功能需求累积过多，我们就很难把控自己在这个函数中新定义的变量会不会覆盖掉之前的定义。如：

1
2
3
4
5
6

function action(){
	console.log(1);
	console.log(2);//新增需求1
	console.log(3);//新增需求2
	......//一直增加就很难保证下面的代码不会与之前的代码产生冲突
}

而如果我们为新增的需求重新定义一个同名的js方法，那后来定义的方法又会将之前定义的方法覆盖，这当然也不是我们想要的结果。如：

1
2
3

function action(){console.log(1);}
function action(){console.log(2);}//新增需求1
function action(){console.log(3);}//新增需求2

执行结果：3

那么有没有什么办法可以让我们的函数分别执行，并且互不影响呢？是的，你一定想到了js事件。

随着webpage可以承载的表现形式更加多样化，通过webpage来实现更多交互功能，构建web应用程序已经成为很多产品的首要选择。这种方式拥有非常明显的优势：跨平台、开发便捷、便于部署和维护等等，但随着功能的不断积累，web应用程序也会变得越来越复杂。但是，我们仍然想要在webpage支持丰富的呈现形式的同时，让页面效果能够达到>=60fps(帧)/s的刷新频率以避免出现卡顿，就需要我们使用一些比较直观的方式来分析衡量页面的性能问题，为性能优化方案提供依据。

为什么是60fps?
我们的目标是保证页面要有高于每秒60fps(帧)的刷新频率，这和目前大多数显示器的刷新率相吻合(60Hz)。如果网页动画能够做到每秒60帧，就会跟显示器同步刷新，达到最佳的视觉效果。这意味着，一秒之内进行60次重新渲染，每次重新渲染的时间不能超过16.66毫秒。

一、扯淡部分

回想当年，在摆脱写页面时js全靠从各种DEMO中copy出来然后东拼西凑的幽暗岁月之后，毅然决然地打算放弃这种处处“拿来主义”的不正之风，然后开启通往高大上的“前端攻城狮”的飞升之旅。想想都有些小激动呢~然而人生不如意者十之八九，刚踏上征程就经常会被各种Error虐到体无完肤，有时候甚至会被在现在看来很低级的bug折磨得生不如死。但没有一种成长是不需要付出代价的，也就是那段刚跳入泥潭的日子开启了让自己成为一名真正的JSer的大门，也使自己在奔向高大上的路上让“见招拆招、兵来将挡”成为常态，以至于后来都慢慢觉得，做一个东西不遇上几个bug心里就没有稳妥扎实的安全感。再后来也就学着不断去安慰自己：踩到脚底下的bug越多，离翻过那座墙也就不远了~

目前公司产品的无线站点已经实现了业务平台组件化，所有业务组件的转场都是通过路由来完成，而各个模块是通过requirejs进行统一管理，在灰度测试时会通过grunt进行打包操作，虽然工程化的开发流程已经大大提升了效率，但是为了满足不同平台在任意业务入口页面一键注入业务脚本即可进行测试的实际需求，团队尝试通过chrome拓展来进行实现。由于我本人是第一次开发chrome拓展插件，所以开发的过程中遇到不少坑，某些功能的实现方式也未必是最好，但还是有很多难得的收获。接下来就围绕“拦截与注入”的功能点，详细介绍一下开发过程。

页面的性能问题一直是产品开发过程中的重要一环，很多公司也一直在使用各种方式监控产品的页面性能。从控制台工具、Fiddler抓包工具，到使用DOMContentLoaded和document.onreadystatechange这种侵入式javascript代码方式来检测DOM事件发生和结束的时间，再到使用第三方工具如WebPagetest、Pingdom等通过在不同的浏览器环境和地域进行测试来寻求优化建议等等，这些方式不仅麻烦，而且测量的指标比较单一。如果有一些可以帮我们直接获取页面性能信息的API出现，并且成为标准被被浏览器厂商支持，那性能监控会不会又是另一幅蓝图？

HAR（HTTP档案规范），是一个用来储存HTTP请求/响应信息的通用文件格式，基于JSON。这种格式的数据可以使HTTP监测工具以一种通用的格式导出所收集的数据，这些数据可以被其他支持HAR的HTTP分析工具（包括Firebug、httpwatch、Fiddler等）所使用，来分析网站的性能瓶颈。

目前HAR规范最新版本为HAR 1.2。HAR文件必须是UTF-8编码，有无BOM无所谓。如下是一个HAR文件的详细介绍。

副标题: 为何getElementsByTagName()比querySelectorAll()快100倍

昨天,我在雅虎的同事 Scott Schiller (斯科特·席勒, 同时也是SoundManager创造者) 发Twitter询问为何 getElementsByTagName("a") 在所有浏览器上都比 querySelectorAll("a") 要快好多倍。 有一个 专门的 JSPerf测试页面, 通过对比就能发现两者的速度差异相当明显。 比如作者在Windows XP下使用的 Firefox 3.6.8 浏览器, querySelectorAll("a") 比 getElementsByTagName("a") 的运行速度要低98%. 我和 Scott, 以及 YUI团队的 Ryan Grove 有一个活跃的Twitter-sation， 关于这种现象的原因,以及情理之中让人沮丧的结果。 我想好好地解释说明下到底为什么会发生这种情况,以及为什么未来也可能不会改变。

在深入细节之前需要了解这两个方法间一个非常重要的区别,我想说的并不是他们接收的参数一个是标签名,另一个是整个CSS选择器。 而其最大的区别在于返回值的不同: getElementsByTagName() 方法返回一个动态的(live) NodeList, 而 querySelectorAll() 返回的是一个静态的(static) NodeList. 理解这一点是非常必要的.

概述

有时，我们需要浏览器处理网页，但并不需要浏览，比如生成网页的截图、抓取网页数据等操作。PhantomJS的功能，就是提供一个浏览器环境的命令行接口，你可以把它看作一个“虚拟浏览器”，除了不能浏览，其他与正常浏览器一样。它的内核是WebKit引擎，不提供图形界面，只能在命令行下使用，我们可以用它完成一些特殊的用途。

PhantomJS是二进制程序，需要安装后使用。

1

$ npm install phantomjs -g

使用下面的命令，查看是否安装成功。

1

$ phantomjs --version