浅析JavaScript执行顺序
JavaScript执行顺序
之前从JavaScript引擎的解析机制来探索JavaScript的工作原理，下面我们以更形象的示例来说明JavaScript代码在页面中的执行顺序。如果说，JavaScript引擎的工作机制比较深奥是因为它属于底层行为，那么JavaScript代码执行顺序就比较形象了，因为我们可以直观感觉到这种执行顺序，当然JavaScript代码的执行顺序是比较复杂的，所以在深入JavaScript语言之前也有必要对其进行剖析。
1.1 按HTML文档流顺序执行JavaScript代码
首先，读者应该清楚，HTML文档在浏览器中的解析过程是这样的：浏览器是按着文档流从上到下逐步解析页面结构和信息的。JavaScript代码作为嵌入的脚本应该也算做HTML文档的组成部分，所以JavaScript代码在装载时的执行顺序也是根据脚本标签<script>的出现顺序来确定的。例如，浏览下面文档页面，你会看到代码是从上到下逐步被解析的。
<script>
alert("顶部脚本");
</script>
<html><head>
<script>
alert("头部脚本");
</script>
<title></title>
</head>
<body>
<script>
alert("页面脚本");
</script>
</body></html>
<script>
alert("底部脚本");
</script>
如果通过脚本标签<script>的src属性导入外部JavaScript文件脚本，那么它也将按照其语句出现的顺序来执行，而且执行过程是文档装载的一部分。不会因为是外部JavaScript文件而延期执行。例如，把上面文档中的头部和主体区域的脚本移到外部JavaScript文件中，然后通过src属性导入。继续预览页面文档，你会看到相同的执行顺序。
<script>
alert("顶部脚本");
</script>
<html>
<head>
<script src="head.js"></script>
<title></title>
</head>
<body>
<script src="body.js"></script>
</body>
</html>
<script>
alert("底部脚本");
</script>
1.2 预编译与执行顺序的关系
在Javascript中，function才是Javascript的第一型。当我们写下一段函数时，其实不过是建立了一个function类型的实体。
就像我们可以写成这样的形式一样：
functionHello() {
alert("Hello");
}
Hello();
varHello = function() {
alert("Hello");
}
Hello();
其实都是一样的。
但是当我们对其中的函数进行修改时，会发现很奇怪的问题。
<scripttype="text/javascript">
functionHello() {
alert("Hello");
}
Hello();
functionHello() {
alert("Hello World");
}
Hello();
</script>
我们会看到这样的结果：连续输出了两次Hello World。而非我们想象中的Hello和Hello World。
这是因为Javascript并非完全的按顺序解释执行，而是在解释之前会对Javascript进行一次“预编译”，在预编译的过程中，会把定义式的函数优先执行，也会把所有var变量创建，默认值为undefined，以提高程序的执行效率。也就是说上面的一段代码其实被JS引擎预编译为这样的形式：
<scripttype="text/javascript">
varHello = function() {
alert("Hello");
}
Hello = function() {
alert("Hello World");
}
Hello();
Hello();
</script>
我们可以通过上面的代码很清晰地看到，其实函数也是数据，也是变量，我们也可以对“函数“进行赋值（重赋值）。当然，我们为了防止这样的情况，也可以这样：
<scripttype="text/javascript">
functionHello() {
alert("Hello");
}
Hello();
</script>
<scripttype="text/javascript">
functionHello() {
alert("Hello World");
}
Hello();
</script>
这样，程序被分成了两段，JS引擎也就不会把他们放到一起了。
当JavaScript引擎解析脚本时，它会在预编译期对所有声明的变量和函数进行处理。
做如下处理：
1. 在执行前会进行类似“预编译”的操作：首先会创建一个当前执行环境下的活动对象，并将那些用var申明的变量设置为活动对象的属性，但是此时这些变量的赋值都是undefined，并将那些以function定义的函数也添加为活动对象的属性，而且它们的值正是函数的定义。
2. 在解释执行阶段，遇到变量需要解析时，会首先从当前执行环境的活动对象中查找，如果没有找到而且该执行环境的拥有者有prototype属性时则会从prototype链中查找，否则将会按照作用域链查找。遇到var a = ...这样的语句时会给相应的变量进行赋值（注意：变量的赋值是在解释执行阶段完成的，如果在这之前使用变量，它的值会是undefined）
所以，就会出现当JavaScript解释器执行下面脚本时不会报错：
alert(a); // 返回值undefined
var a =1;
alert(a); // 返回值1
由于变量声明是在预编译期被处理的，所以在执行期间对于所有代码来说，都是可见的。但是，你也会看到，执行上面代码，提示的值是undefined，而不是1。这是因为，变量初始化过程发生在执行期，而不是预编译期。在执行期，JavaScript解释器是按着代码先后顺序进行解析的，如果在前面代码行中没有为变量赋值，则JavaScript解释器会使用默认值undefined。由于在第二行中为变量a赋值了，所以在第三行代码中会提示变量a的值为1，而不是undefined。
同理，下面示例在函数声明前调用函数也是合法的，并能够被正确解析，所以返回值为1。
f(); // 调用函数，返回值1
function f(){
alert(1);
}
但是，如果按下面方式定义函数，则JavaScript解释器会提示语法错误。
f(); // 调用函数，返回语法错误
var f = function(){
alert(1);
}
这是因为，上面示例中定义的函数仅作为值赋值给变量f，所以在预编译期，JavaScript解释器只能够为声明变量f进行处理，而对于变量f的值，只能等到执行期时按顺序进行赋值，自然就会出现语法错误，提示找不到对象f。
再见一些例子：
<script type="text/javascript">
/*在预编译过程中func是window环境下的活动对象中的一个属性，值是一个函数，覆盖了undefined值*/
alert(func); //function func(){alert("hello!")}
var func = "this is a variable"
function func(){
alert("hello!")
}
/*在执行过程中遇到了var重新赋值为"this is a variable"*/
alert(func); //this is a variable
</script>
<script type="text/javascript">
var name = "feng";
function func(){
/*首先，在func环境内先把name赋值为undefined，然后在执行过程中先寻找func环境下的活动对象的name属性，此时之前已经预编译值为undefined，所以输出是undefined，而不是feng*/
alert(name); //undefined
var name = "JSF";
alert(name); //JSF
}
func();
alert(name); //feng
</script>
虽然变量和函数声明可以在文档任意位置，但是良好的习惯应该是在所有JavaScript代码之前声明全局变量和函数，并对变量进行初始化赋值。在函数内部也是先声明变量，然后再引用。
1.3 按块执行JavaScript代码
所谓代码块就是使用<script>标签分隔的代码段。例如，下面两个<script>标签分别代表两个JavaScript代码块。
<script>
// JavaScript代码块1
var a =1;
</script>
<script>
// JavaScript代码块2
function f(){
alert(1);
}
</script>
JavaScript解释器在执行脚本时，是按块来执行的。通俗地说，就是浏览器在解析HTML文档流时，如果遇到一个<script>标签，则JavaScript解释器会等到这个代码块都加载完后，先对代码块进行预编译，然后再执行。执行完毕后，浏览器会继续解析下面的HTML文档流，同时JavaScript解释器也准备好处理下一个代码块。
由于JavaScript是按块执行的，所以如果在一个JavaScript块中调用后面块中声明的变量或函数就会提示语法错误。例如，当JavaScript解释器执行下面代码时就会提示语法错误，显示变量a未定义，对象f找不到。
<script>
// JavaScript代码块1
alert(a);
f();
</script>
<script>
// JavaScript代码块2
var a =1;
function f(){
alert(1);
}
</script>
虽然说，JavaScript是按块执行的，但是不同块都属于同一个全局作用域，也就是说，块之间的变量和函数是可以共享的。
1.4 借助事件机制改变JavaScript执行顺序
由于JavaScript是按块处理代码，同时又遵循HTML文档流的解析顺序，所以在上面示例中会看到这样的语法错误。但是当文档流加载完毕，如果再次访问就不会出现这样的错误。例如，把访问第2块代码中的变量和函数的代码放在页面初始化事件函数中，就不会出现语法错误了。
<script>
// JavaScript代码块1
window.onload = function(){ // 页面初始化事件处理函数
alert(a);
f();
}
</script>
<script>
// JavaScript代码块2
var a =1;
function f(){
alert(1);
}
</script>
为了安全起见，我们一般在页面初始化完毕之后才允许JavaScript代码执行，这样可以避免网速对JavaScript执行的影响，同时也避开了HTML文档流对于JavaScript执行的限制。
注意
如果在一个页面中存在多个windows.onload事件处理函数，则只有最后一个才是有效的，为了解决这个问题，可以把所有脚本或调用函数都放在同一个onload事件处理函数中，例如：
window.onload = function(){
f1();
f2();
f3();
}
而且通过这种方式可以改变函数的执行顺序，方法是：简单地调整onload事件处理函数中调用函数的排列顺序。
除了页面初始化事件外，我们还可以通过各种交互事件来改变JavaScript代码的执行顺序，如鼠标事件、键盘事件及时钟触发器等方法，详细讲解请参阅第14章的内容。
1.5 JavaScript输出脚本的执行顺序
在JavaScript开发中，经常会使用document对象的write()方法输出JavaScript脚本。那么这些动态输出的脚本是如何执行的呢？例如：
document.write('<script type="text/javascript">');
document.write('f();');
document.write('function f(){');
document.write('alert(1);');
document.write('}');
document.write('</script>');
运行上面代码，我们会发现：document.write()方法先把输出的脚本字符串写入到脚本所在的文档位置，浏览器在解析完document.write()所在文档内容后，继续解析document.write()输出的内容，然后才按顺序解析后面的HTML文档。也就是说，JavaScript脚本输出的代码字符串会在输出后马上被执行。
请注意，使用document.write()方法输出的JavaScript脚本字符串必须放在同时被输出的<script>标签中，否则JavaScript解释器因为不能够识别这些合法的JavaScript代码，而作为普通的字符串显示在页面文档中。例如，下面的代码就会把JavaScript代码显示出来，而不是执行它。
document.write('f();');
document.write('function f(){');
document.write('alert(1);');
document.write(');');
但是，通过document.write()方法输出脚本并执行也存在一定的风险，因为不同JavaScript引擎对其执行顺序不同，同时不同浏览器在解析时也会出现Bug。
Ø 问题一，找不到通过document.write()方法导入的外部JavaScript文件中声明的变量或函数。例如，看下面示例代码。
document.write('<script type="text/javascript" src="test.js">
</script>');
document.write('<script type="text/javascript">');
document.write('alert(n);'); // IE提示找不到变量n
document.write('</script>');
alert(n+1); // 所有浏览器都会提示找不到变量n
外部JavaScript文件（test.js）的代码如下：
var n = 1;
分别在不同浏览器中进行测试，会发现提示语法错误，找不到变量n。也就是说，如果在JavaScript代码块中访问本代码块中使用document.write()方法输出的脚本中导入的外部JavaScript文件所包含的变量，会显示语法错误。同时，如果在IE浏览器中，不仅在脚本中，而且在输出的脚本中也会提示找不到输出的导入外部JavaScript文件的变量（表述有点长和绕，不懂的读者可以尝试运行上面代码即可明白）。
Ø 问题二，不同JavaScript引擎对输出的外部导入脚本的执行顺序略有不同。例如，看下面示例代码。
<script type="text/javascript">
document.write('<script type="text/javascript" src="test1.js">
</script>');
document.write('<script type="text/javascript">');
document.write('alert(2);')
document.write('alert(n+2);');
document.write('</script>');
</script>
<script type="text/javascript">
alert(n+3);
</script>
外部JavaScript文件（test1.js）的代码如下所示。
var n = 1;
alert(n);
在IE浏览器中的执行顺序如图1-6所示。
图1-6 IE 7浏览器的执行顺序和提示的语法错误
在符合DOM标准的浏览器中的执行顺序与IE浏览器不同，且没有语法错误，如图1-7所示的是在Firefox 3.0浏览器中的执行顺序。
图1-7 Firefox 3浏览器的执行顺序和提示的语法错误
解决不同浏览器存在的不同执行顺序，以及可能存在Bug。我们可以把凡是使用输出脚本导入的外部文件，都放在独立的代码块中，这样根据上面介绍的JavaScript代码块执行顺序，就可以避免这个问题。例如，针对上面示例，可以这样设计：
<script type="text/javascript">
document.write('<script type="text/javascript" src="test1.js"></script>');
</script>
<script type="text/javascript">
document.write('<script type="text/javascript">');
document.write('alert(2);') ; // 提示2
document.write('alert(n+2);'); // 提示3
document.write('</script>');
alert(n+3); // 提示4
</script>
<script type="text/javascript">
alert(n+4); // 提示5
</script>
这样在不同浏览器中都能够按顺序执行上面代码，且输出顺序都是1、2、3、4和5。存在问题的原因是：输出导入的脚本与当前JavaScript代码块之间的矛盾。如果单独输出就不会发生冲突了。
资源文件查找顺序
资源文件查找顺序
之所以说Struts 2.0的国际化更灵活是因为它可以能根据不同需要配置和获取资源（properties）文件。在Struts 2.0中有下面几种方法：
- 使用全局的资源文件，方法如上例所示。这适用于遍布于整个应用程序的国际化字符串，它们在不同的包（package）中被引用，如一些比较共用的出错提示；
- 使用包范围内的资源文件。做法是在包的根目录下新建名的package.properties和package_xx_XX.properties文件。这就适用于在包中不同类访问的资源；
- 使用Action范围的资源文件。做法为Action的包下新建文件名（除文件扩展名外）与Action类名同样的资源文件。它只能在该Action中访问。如此一来，我们就可以在不同的Action里使用相同的properties名表示不同的值。例如，在ActonOne中title为“动作一”，而同样用title在ActionTwo表示“动作二”，节省一些命名工夫；
- 使用<s:i18n>标志访问特定路径的properties文件。使用方法请参考文章《常用的Struts 2.0的标志（Tag）介绍》。在您使用这一方法时，请注意<s:i18n>标志的范围。在<s:i18n name="xxxxx">到</s:i18n>之间，所有的国际化字符串都会在名为xxxxx资源文件查找，如果找不到，Struts 2.0就会输出默认值（国际化字符串的名字）。
上面我列举了四种配置和访问资源的方法，它们的范围分别是从大到小，而Struts 2.0在查找国际化字符串所遵循的是特定的顺序，如图3所示：
图3 资源文件查找顺序图
假设我们在某个ChildAction中调用了getText("user.title")，Struts 2.0的将会执行以下的操作：
- 查找ChildAction_xx_XX.properties文件或ChildAction.properties；
- 查找ChildAction实现的接口，查找与接口同名的资源文件MyInterface.properties；
- 查找ChildAction的父类ParentAction的properties文件，文件名为ParentAction.properties；
- 判断当前ChildAction是否实现接口ModelDriven。如果是，调用getModel()获得对象，查找与其同名的资源文件；
- 查找当前包下的package.properties文件；
- 查找当前包的父包，直到最顶层包；
- 在值栈（Value Stack）中，查找名为user的属性，转到user类型同名的资源文件，查找键为title的资源;
- 查找在struts.properties配置的默认的资源文件，参考例1;
- 输出user.title。
支持博主
关于邵珠庆博客
文章标签
记事邵珠庆博客
最近文章
最近评论
- 发表在《中国翻墙网民状况调查》
- 发表在《教你如何简单获取新浪微博短地址接口》
- 发表在《教你如何简单获取新浪微博短地址接口》
- 发表在《教你如何简单获取新浪微博短地址接口》
- 发表在《教你如何简单获取新浪微博短地址接口》
博客日历
| 一 | 二 | 三 | 四 | 五 | 六 | 日 |
|---|---|---|---|---|---|---|
| « 8月 | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | ||||
目录分类
文章归档
- 2022年8月 (2)
- 2022年7月 (1)
- 2022年3月 (1)
- 2021年10月 (3)
- 2021年1月 (1)
- 2020年4月 (3)
- 2020年3月 (3)
- 2020年2月 (2)
- 2020年1月 (3)
- 2019年12月 (2)
- 2019年11月 (3)
- 2019年10月 (2)
- 2019年9月 (2)
- 2019年8月 (4)
- 2019年7月 (2)
- 2019年6月 (2)
- 2019年5月 (2)
- 2019年4月 (3)
- 2019年3月 (2)
- 2019年2月 (3)
- 2019年1月 (2)
- 2018年12月 (2)
- 2018年11月 (2)
- 2018年10月 (3)
- 2018年9月 (2)
- 2018年8月 (2)
- 2018年7月 (1)
- 2018年6月 (2)
- 2018年5月 (3)
- 2018年4月 (2)
- 2018年3月 (6)
- 2018年2月 (7)
- 2018年1月 (3)
- 2017年11月 (2)
- 2017年10月 (2)
- 2017年9月 (5)
- 2017年8月 (4)
- 2017年7月 (8)
- 2017年6月 (5)
- 2017年5月 (14)
- 2017年4月 (8)
- 2017年3月 (5)
- 2017年2月 (2)
- 2017年1月 (1)
- 2016年12月 (1)
- 2016年11月 (5)
- 2016年10月 (3)
- 2016年9月 (2)
- 2016年8月 (1)
- 2016年7月 (2)
- 2016年6月 (2)
- 2016年5月 (5)
- 2016年4月 (5)
- 2016年3月 (2)
- 2016年2月 (1)
- 2016年1月 (2)
- 2015年12月 (2)
- 2015年11月 (1)
- 2015年10月 (3)
- 2015年9月 (2)
- 2015年8月 (4)
- 2015年7月 (5)
- 2015年6月 (6)
- 2015年5月 (3)
- 2015年4月 (8)
- 2015年3月 (6)
- 2015年2月 (4)
- 2015年1月 (5)
- 2014年12月 (2)
- 2014年11月 (5)
- 2014年10月 (5)
- 2014年9月 (1)
- 2014年8月 (2)
- 2014年7月 (4)
- 2014年6月 (1)
- 2014年5月 (9)
- 2014年4月 (5)
- 2014年3月 (1)
- 2014年2月 (1)
- 2014年1月 (5)
- 2013年12月 (4)
- 2013年11月 (12)
- 2013年10月 (6)
- 2013年9月 (7)
- 2013年8月 (8)
- 2013年7月 (15)
- 2013年6月 (9)
- 2013年5月 (12)
- 2013年4月 (8)
- 2013年3月 (11)
- 2013年2月 (9)
- 2013年1月 (21)
- 2012年12月 (8)
- 2012年11月 (7)
- 2012年10月 (19)
- 2012年9月 (16)
- 2012年8月 (13)
- 2012年7月 (10)
- 2012年6月 (11)
- 2012年5月 (11)
- 2012年4月 (8)
- 2012年3月 (8)
- 2012年2月 (11)
- 2012年1月 (8)
- 2011年12月 (18)
- 2011年11月 (32)
- 2011年10月 (17)
- 2011年9月 (18)
- 2011年8月 (11)
- 2011年7月 (55)
- 2011年6月 (1)
- 2011年5月 (4)
- 2011年4月 (2)
- 2011年3月 (1)
- 2011年1月 (3)
- 2010年12月 (1)
- 2010年11月 (6)
- 2010年9月 (5)
- 2010年8月 (2)
- 2010年7月 (3)
- 2010年6月 (7)
- 2010年5月 (3)
- 2010年4月 (4)
- 2010年3月 (8)
- 2010年2月 (2)
- 2010年1月 (2)
- 2009年12月 (2)
- 2009年11月 (1)
- 2009年10月 (1)
- 2009年8月 (1)
- 2009年7月 (2)
- 2009年5月 (1)
- 2009年4月 (1)
- 2009年3月 (1)
- 2009年2月 (1)
- 2009年1月 (1)
- 2008年12月 (1)
- 2008年11月 (2)
- 2008年10月 (1)
- 2008年8月 (5)
- 2008年7月 (2)
- 2008年6月 (1)
- 2008年5月 (3)
- 2008年4月 (11)
- 2008年3月 (1)
- 2008年2月 (1)
- 2008年1月 (1)
- 2007年12月 (1)
- 2007年11月 (3)
- 2007年10月 (1)
- 2007年9月 (1)
- 2007年8月 (1)
- 2007年7月 (1)
- 2007年6月 (1)
- 2007年5月 (1)
