JS闭包与事件冒泡-优快云博客

本文链接：https://blog.youkuaiyun.com/xd_805799766/article/details/12908451

1、闭包，作用域链、内存回收

闭包主要涉及到js的几个其他的特性:作用域链,垃圾(内存)回收机制,函数嵌套.

作用域链就是函数在定义的时候创建的,用于寻找使用到的变量的值的一个索引,而他内部的规则是,把函数自身的本地变量放在最前面,把自身的父级函数中的变量放在其次,把再高一级函数中的变量放在更后面,以此类推直至全局对象为止.当函数中需要查询一个变量的值的时候,js解释器会去作用域链去查找,从最前面的本地变量中先找,如果没有找到对应的变量,则到下一级的链上找,一旦找到了变量,则不再继续.如果找到最后也没找到需要的变量,则解释器返回undefined.

我们再来看看js的内存回收机制,一般来说,一个函数在执行开始的时候,会给其中定义的变量划分内存空间保存,以备后面的语句所用,等到函数执行完毕返回了,这些变量就被认为是无用的了.对应的内存空间也就被回收了.下次再执行此函数的时候,所有的变量又回到最初的状态,重新赋值使用.但是如果这个函数内部又嵌套了另一个函数,而这个函数是有可能在外部被调用到的.并且这个内部函数又使用了外部函数的某些变量的话.这种内存回收机制就会出现问题.如果在外部函数返回后,又直接调用了内部函数,那么内部函数就无法读取到他所需要的外部函数中变量的值了.所以js解释器在遇到函数定义的时候,会自动把函数和他可能使用的变量(包括本地变量和父级和祖先级函数的变量(自由变量))一起保存起来.也就是构建一个闭包,这些变量将不会被内存回收器所回收,只有当内部的函数不可能被调用以后(例如被删除了,或者没有了指针),才会销毁这个闭包,而没有任何一个闭包引用的变量才会被下一次内存回收启动时所回收.

也就是说,有了闭包,嵌套的函数结构才可以运作,这也是符合我们的预期的.然后,闭包还有一些特性,却往往让程序员觉得很难理解.

看看下面一段代码.

var result=[];

function foo(){

var i= 0;

for (;i<3;i=i+1){

result[i]=function(){

alert(i)

}

};

foo();

result[0](); // 3

result[1]();// 3

result[2]();// 3

这段代码中,程序员希望foo函数中的变量i被内部循环的函数使用,并且能分别获得他们的索引,而实际上,只能获得该变量最后保留的值,也就是说.闭包中所记录的自由变量,只是对这个变量的一个引用,而非变量的值,当这个变量被改变了,闭包里获取到的变量值,也会被改变.

解决的方法之一,是让内部函数在循环创建的时候立即执行,并且捕捉当前的索引值,然后记录在自己的一个本地变量里.然后利用返回函数的方法,重写内部函数,让下一次调用的时候,返回本地变量的值,改进后的代码:

var result=[];

function foo(){

var i= 0;

for (;i<3;i=i+1){

result[i]=(function(j){

returnfunction(){

alert(j);

};

})(i);

}

};

foo();

result[0](); // 0

result[1]();// 1

result[2]();// 2

2、mvc

• Model(模型) “数据模型”（Model）用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“模型”有对数据直接访问的权利，例如对数据库的访问。

• View(视图) 视图层能够实现数据有目的的显示（理论上，这不是必需的）。在视图中一般没有程序上的逻辑。为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里注册。

• Controller(控制器) 控制器起到不同层面间的组织作用，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据模型上的改变。

3、前端mvc

• Model负责保存view需要的数据以及数据处理逻辑(读写，更新，删除，验证，转换等)，以及和后端服务器和View的数据交互

• View负责接收显示Model提供的数据以及接收用户输入，响应事件，Model更新后及时将更新反馈给用户

• Controller处理业务逻辑、事件逻辑(包括用户触发的事件和model数据发生改变的事件)和管理history hash

4、php数据库

mysql_connect("localhost","peter","abc123");

mysql_query() 函数执行一条 MySQL 查询。

mysql_fetch_assoc()函数从结果集中取得一行作为关联数组。返回根据从结果集取得的行生成的关联数组

mysql_fetch_row() 函数从结果集中取得一行作为数字数

mysql_fetch_array()函数从结果集中取得一行作为关联数组，或数字数组，或二者兼

5、事件冒泡

一.事件冒泡与事件捕获

事件捕获：由外向内寻找事件源的过程。当你使用事件捕获时，父级元素先触发，子级元素后触发

事件冒泡：事件从事件源由内向外传播的过程，当你使用事件冒泡时，子级元素先触发，父级元素后触发

事件的发生顺序

这个问题的起源非常简单，假设你在一个元素中又嵌套了另一个元素

-----------------------------------

| element1 |

| ------------------------- |

| |element2 | |

| ------------------------- |

| |

-----------------------------------

：并且两者都有一个onClick事件处理函数(event handler)。如果用户单击元素2，则元素1和元素2的单击事件都会被触发。但是哪一个事件先被触发？哪一个事件处理函数会被首先执行？换句话说，事件的发生顺序到底如何？

两种模型

不出所料，在那些“不堪回首”（浏览器大战）的日子里，Netscape和微软有两种截然不同的处理方法：

· Netscape主张元素1的事件首先发生，这种事件发生顺序被称为捕获型

· 微软则保持元素2具有优先权，这种事件顺序被称为冒泡型

这两种事件顺序是截然相反的。Explorer浏览器只支持冒泡事件，Mozilla，Opera7和Konqueror两者都支持。而更古老的opera和iCab两者都不支持

捕获型事件

当你使用捕获型事件时

| |

---------------| |-----------------

| element1 | | |

| -----------| |----------- |

| |element2 \ / | |

| ------------------------- |

| Event CAPTURING |

-----------------------------------

：元素1的事件处理函数首先被触发，元素2的事件处理函数最后被触发

冒泡型事件

当你使用冒泡型事件时

/ \

---------------| |-----------------

| element1 | | |

| -----------| |----------- |

| ------------------------- |

| Event BUBBLING |

-----------------------------------

：元素2 的处理函数首先被触发，元素1其次

W3C 模型

W3c明智的在这场争斗中选择了一个择中的方案。任何发生在w3c事件模型中的事件，首是进入捕获阶段，直到达到目标元素，再进入冒泡阶段

| | / \

-----------------| |--||-----------------

| -------------| |--| |----------- |

| -------------------------------- |

| W3C event model |

------------------------------------------

为一个web开发者，你可以选择是在捕获阶段还是冒泡阶段绑定事件处理函数，这是通过addEventListener()方法实现的，如果这个函数的最后一个参数是true，则在捕获阶段绑定函数，反之false，在冒泡阶段绑定函数。

假设你要做

element1.addEventListener('click',doSomething2,true)

element2.addEventListener('click',doSomething,false)

如果用户单击元素2，则接下来会发生：

（事件在这里就像一个观光客，由外至内游览，逐渐接近被触发的主要元素，然后又反向离开）

1. 单击事件首先进入捕获阶段开始（逐渐接近元素2的方向）。查看元素2的祖先元素中是否有在捕获阶段有onclick处理函数的

2. 发现元素1有一个，于是doSomething2被执行

3. 事件检查到目标自己（元素2），捕获阶段没有发现更多的处理函数了。事件开始进入冒泡阶段，想当然执行doSomething()，这个绑定于元素2冒泡阶段的函数。

4. 事件向远离元素2的方向，查看是否有任何祖先元素在冒泡阶段绑定了一个处理函数。没有这样的情况，所以什么也没有发生

相反的情况是：

element1.addEventListener('click',doSomething2,false)

element2.addEventListener('click',doSomething,false)

现在如果用户点击元素2会发生：

1. 单击事件进入捕获阶段。查看元素2的祖先元素中是否有在捕获阶段有onclick处理函数的，结果一无所获

2. 事件检查到目标自己。事件开始进入冒泡阶段，并且执行绑定于元素2冒泡阶段的函数。doSomething()

3. 事件开始远离目标，检查元素2的祖先元素中是否有在冒泡阶段绑定了处理函数的

4. 发现了一个，于是元素1的doSomething2()被执行

兼容性和传统模式

在支持w3c dom(文档对象模型) 的浏览器中，传统的事件绑定方法是

element1.οnclick= doSomething2;

默认被视为在绑定于冒泡阶段

使用冒泡型事件

很少的开发人员会有意识的去使用冒泡型事件或者捕获型事件。在他们今天制作的网页中，没有必要让一个事件因为冒泡而被好几个函数处理。但是有时用户通常会很疑惑，因为在他们只点击了一次鼠标之后出现了许多种情况（多个函数被执行，因为冒泡）。而大多数情况下你还是希望你的处理函数相互独立的。当用户点击了某一个元素，发生什么，点击另一个元素，又对应发生些什么，相互独立，而不因为冒泡连锁。

一直在发生

首先你要明白的是事件捕获或者冒泡一直在发生。如果你给整个页面文档的定义一个通用onclick处理函数

document.οnclick= doSomething;

if (document.captureEvents)document.captureEvents(Event.CLICK);

//第二句话我也不知道什么意思，初学者，希望有能人能解释

在页面上单击任何元素的单击事件，最终会冒泡至页面最高文档层，因此触发那个通用的处理函数，除非之前一个处理函数明确的指出终止冒泡，这样才冒泡才不会传播到整个文档层面

用法（这一小节翻译的不好，因为没有实战，我也不是很理解，可以在留言中补充，我会更新）

因为任何事件传播终止于页面文档（这个最高层），这使默认的事件处理函数变得可能，假设你有这样一个页面

------------------------------------

| document |

| --------------- ------------ |

| --------------- ------------ |

| |

------------------------------------

element1.οnclick= doSomething;
element2.onclick = doSomething;
document.onclick = defaultFunction;

现在如果用户单击元素1或者元素2，doSomething()将被执行。如果你愿意的话，如果你不想让事件冒泡至执行defaultFunction()，你可以在这里阻止事件冒泡向上传播，。但是如果用户点击页面上的其他部位，defaultFunction()还是会被执行。这样的效果或许有时能用的上。

设置页面——使处理函数有范围较大的触发面积，在“拖拽效果”脚本中是必须的。一般来说在某一个元素层上发生 mousedown事件意味着选择了这个元素，并且使它能够响应mousemove事件。虽然mousedown通常绑定于这个元素层上以避免浏览器bug，但是其他两者的事件函数的范围必须是整个页面（？）

记住浏览器学的第一法则（First Law of Browserology）是：一切皆有可能（anything can happen），并且是在你起码有点准备的时候。所以有可能发生的是，用户拖拽时，大幅度在页面上移动他的鼠标，脚本却不能在大幅度中做出反应，以至于鼠标也就不再停留在元素层上了

· 如果onmouseover处理函数绑定在元素层上，这个元素层不会再对鼠标的移动有任何反应，这会让用户觉得奇怪

· 如果onmouseup处理函数绑定在元素层上，事件也不能被触发，后果是，用户想放下这个元素层后，元素层持续对鼠标移动做出反应。这会引起（用户）更多的迷惑（？）

所以在这个例子中，事件冒泡非常的有用，因为将你的处理函数放在页面层能保证他们一直能被执行

把它给关了

但是一般情况下，你会想关了所有的冒泡和捕获以保证函数之间不会打扰到对方。除此之外，如果你的文档结构相当的复杂（许多table之间相互嵌套或者诸如此类），你也会为了节省系统资源，而关闭冒泡。此时浏览器不得不检查目标元素的每一个祖先，看是否它有一个处理函数。即使一个都没有找到，刚刚的搜索同样花费不少时间

在微软的模型中，你必须设置事件的cancelBubble的属性为true

window.event.cancelBubble= true

在w3c模型中你必须调用事件的stopPropagation()方法

e.stopPropagation()

这会阻止所有冒泡向外传播。而作为跨浏览器解决方案应该这么作：

function doSomething(e)

{
if (!e) var e =window.event;

e.cancelBubble = true;

if (e.stopPropagation) e.stopPropagation();

}