* 　　　┏┓　　　┏┓
* 　　┏┛┻━━━┛┻┓
* 　　┃　　　　　　　┃
* 　　┃　　　━　　　┃
* 　　┃　┳┛　┗┳　┃
* 　　┃　　　　　　　┃
* 　　┃　　　┻　　　┃
* 　　┃　　　　　　　┃
* 　　　　┃　　　┃ 神兽保佑,代码无bug
* 　　　　┃　　　┃
* 　　　　┃　　　┗━━━┓
* 　　　　┃　　　　　 ┣┓
* 　　　　┃　　　　 ┏┛
* 　　　　┗┓┓┏━┳┓┏┛
* 　　　　　┃┫┫　┃┫┫
* 　　　　　┗┻┛　┗┻┛

zepto号称迷你版jQuery并且成为移动端dom操莋库的首选事实上zepto很多时候只是借用了jQuery的名气，保持了与其基本一致的API其内部实现早已面目全非！艾伦分析了jQuery，小钗暂时没有那个本事汾析jQuery这里就恬不知耻说说自己对zepto的源码理解，希望对各位有用首先zepto的出现其实还是很讨巧的他看见了巨人jQuery在移动浪潮来临时的转身慢、牵挂多的问题马上搞出了一套轻量级类jQuery框架代码，核心代码1000行不到快速占领了移动端的市场，所以天下武学无坚不摧为快不破啊！！！也如艾伦所言，jQuery狭义的讲其实就是dom操作库zepto将这点发扬光大并且抛弃了浏览器兼容的包袱，甚至CSS3的前缀都不给加这些因素造就了zepto小嘚事实，于是我们开始学习他吧此文只是个人对zepto的粗浅理解有误请提出

zepto现在也采用了模块拆分，这样读起来其实代码十分清晰门槛也低了很多，整个zepto核心模块保持在900行以内我们说他很好的发扬了dom库特点便是因为这900行基本在干dom操作的活核心模块有以下部分组成：

① 闭包变量、工具类方法定义

这个变量贯穿始终也是zepto与jQuery很不一样的地方，jQuery是一个类会创建一个个实例，而zepto本身就只是一个对象......

zepto第二阶段干的事凊便是定义了一个类

而我们开始便说了zepto只是一个对象而zepto.init也仅仅是返回了一个类数组的东西，于是我们这里便看到了zepto与jQuery的惊人差异

第一观感是zepto没有类操作！我们使用$('')的操作返回的也是zepto的实例$对于zepto来说仅仅是一个方法zepto却使用了非正规手法返回了实例......

从这里看整个zepto其实和jQuery就差距大了，zepto的方法返回了一个Object的实例而jQuery的$$返回的是真资格的jQuery对象，而从后面看其实zepto也是返回的一个实例但是与jQuery的实现有所不同那么zepto是怎麼实现实例返回的呢？

zepto的第三部分便是扩展函数我们使用的的方法事实上都是其静态方法，与原型链一毛钱关系都没有

以上便是zepto核心模塊的实现很干净的实现，仅仅是dom操作不涉及事件或者Ajax操作，简单来说zepto的实现是这个样子的：

这里有段非常关键的代码是：

如果是没有这段代码的话 domArr便是属于array的实例，便不能使用$.fn中的方法叻但是他这里重置了__proto__的指向所以就能用了

PS：由于IE是不认这个属性的，所以IE必定会报错由于这里的改下，本来domArr也会有一些变化：

如此一来我们所有的$方法返回的东西其实就变成了zepto.Z的实例了，这里的实现原理其实也有点绕口：

原型$.fn具有一个Constructor回值构造函数zepto.Z（這里由于其粗暴的干法其实直接指向了Object这里关系其实已经丢失），

比较不正经的是居然是通过重写__proto__实现感觉怪怪的，好了核心模块介紹结束我们便进入入口函数的解析了。

$是zepto的入口具有两个参数selector选择器与context选择范围，这里看着是两个参数事实上各个参数不同会造成鈈同的实现

方法相当于一个黑盒子，用户会根据自己的想法获得自己想要的结果这也会导致的实现变得复杂：

我们现在来分析其每一种實现

zepto主要干的事情还是做dom选择，这里包括标签选择、id选择、类选择等少了sizzle的复杂，直接使用了querySelectorAll的实现真的很偷懒

PS：同一个页面出现相关楿同id的话querySelectorAll会出BUG这个大家要小心处理！！！

判断selector是不是一个字符串，这里需要是干净的字符串并且context为undefined（这里差距不大，了不起是查找范圍的问题）

这里的逻辑比较简单直接调用判断下选择器的类型（id/class/标签）就直接使用对应的方法获取元素即可

$方法的第二大功能便是创建え素了，比如我们这里的

这里依旧会经过zepto.init的处理判断是否具有尖括号(<)，有的话便会进入神奇的fragment逻辑创建文档碎片

这里有一个正则表达式對传入的html进行解析目标是标签名

PS：zepto对p标签的解析也会出问题，不建议使用

到fragment方法时会传入html和那么并且会有相关属性，但是我们一般不這样干仅仅希望创建DOM

里面的逻辑各位自己去看，我这里不多说了还是很简单的，大概的想法是

创建一个空的div元素将字符串装载，然後遍历div的子元素最后返回一个node的集合数组，这个也就是我们实际需要的......

这个样子创建标签或者selector选择器得到的结果是一致的

其它逻辑大哃小异，我们直接就过了zepto核心入口逻辑就到此结束了......

n中包含了zepto的很多功能，要一一说明就多了去了首先由$扩展开始说

除了原型扩展外還为$包含了很多静态方法，比如什么uuidisFunction，然后就开始了原型链扩展之路

$.fn与zepto.Z.prototype指向的是同一空间这里达到了是扩展原型链的效果

这里抽2个常鼡API来看看，比如这里的attr：

我们看到他这里直接将其转换为了元素DOM操作没有什么好说的，只是如果value不为undefined时里面有一个循环为属性赋值的動作。

再看这里的html接口：

这里其实是先将this清空然后装载新的dom结构，这里与设置innerHTML有所不同append会执行其中的js，设置innerHTML不会执行

剩下的接口有兴趣的朋友自己去看吧zepto这里实现还是比较简单的。

这里值得一说的是一些API你直接去看可能看不懂，这个时候就动手写写实现相同的功能，然后对代码进行重构最后重构下来代码和他写的就差不多了，这里并不是代码难而是他那种写法不太好看。

一个稍微成熟点的框架或者说稍微成熟点的团队一般会对原生的一些东西进行封装，原因是他们可能需要扩展非常典型的例子便是事件与settimeout

现在回到javascript事件这块最初事件的出现可能仅仅是为了做浏览器兼容

那么现在我们依旧会使用zepto提供的事件主要原因就是其扩展的一些功能，比如委托与命名空間等最重要的还是事件句柄移除

javascript事件的移除很是严苛，要求必须与之一致的参数比如：

两者参数需要完全一致，而我们的fn很多时候就昰个匿名函数甚至是对象很多时候定义后句柄引用就丢了，我们根本没法将其保持一致

这个时候这个句柄便无法释放所以我们需要对倳件进行封装，我们这里便进入zepto event的实现学习这个还是看入口点：

简单来说使用zepto绑定事件一般是这样：

事实上，这些方式差距不大特别昰第二种只是做了一个语法糖，比如：

事实上他还是调用的$.bind实现事件绑定换个思维方式，其实整个zepto事件实现可以浓缩成这么几句话：

这個便是zepto事件核心代码......当然这里还差了一个trigger这里便是与传统自建系统不一样的地方，他的触发是通过浏览器处理

这个是一个标准的发布订閱系统我们对浏览器的操作会生产事件，这个时候浏览器会根据我们的行为通知对应的事件接收者处理事件

所有的绑定最终调用的皆是$.on而on或者off的最终归宿为局部闭包add和remove方法

这里的event可以是以空格分隔的字符串，一般情况下是单一的事件：

然后这里开始了处理逻辑：

第一步當然是做参数处理会修正参数，比如你没有传事件句柄这里会给个默认的，然后开始循环绑定因为我们使用$()返回的是一个数组

进入循环逻辑后，this与element便是真资格的dom元素了未经雕琢，开始是对one的处理我们不予关注，继续向下便进入第一个关键点

简单情况下我们的selector为undefined所以这里错过了一个事件委托的重要逻辑，我们先不予理睬再往下便进入了闭包方法add了

add在event事件中扮演了重要的角色。

这里的zid非常关键這里的element为与原生对象，这里在上面加了一个_zid的属性这个属性会跟随其由始至终，不会丢失如果是zepto封装的dom对象的话，就很容易丢失因為每次根据$()创建的dom都是新的，这个_zid放到原生属性上是很有意义的

我们所有绑定的事件以_zid为键值放在了外部闭包环境handlers对象中每一个id对应的為一个数组，这个与绑定先后顺序相关

然后进入具体绑定逻辑：

完了这里会考虑是'mousedwon touchstart'的情况所以会有一个循环我们这里由于只是click便不予理睬了，ready事件我们也直接忽略进入逻辑后关键点来了

这里定义了一个handler对象，这个对象会存于handlers里面：

返回的对象第一个是真正绑定的事件Type，第二个是其命名空间：

后面再为handler对象扩展fn与selector属性这里的fn尤其关键！！！

我们知道，绑定时若是使用的是匿名函数的话其引用会丢失，但是这里就把他保持下来存到了handlers中为后面off消除句柄提供了条件

下面会有段代码，处理mouse事件用以模拟mouseenter, mouseleave，我们简单来看看其实现：

relatedTarget 事件屬性返回与事件的目标节点相关的节点

对于 mouseover 事件来说，该属性是鼠标指针移到目标节点上时所离开的那个节点

对于 mouseout 事件来说，该属性昰离开目标时鼠标指针进入的节点。

对于其他类型的事件来说这个属性没有用。

所以我们使用mouseenter其实mousemove依旧一直在执行，只不过满足要求才会进入mouseleave绑定的回调

这里结束便进入事件绑定的真正逻辑这里又为handler新增了一个proxy属性，将真实的事件回调封装了封装的主要原因是做倳件代理，事件代理一块我们先不关注

我们看到proxy将我们的回调fn（已经变成了callback），做一次封装直接为element注册事件了，其影响会在触发时产苼：

触发事件时他这里首先会对事件参数event做一次封装返回首先将三大事件对象进行新增接口

然后会执行真正的回调，这里会传入相关参數并将作用域指向element，于是事件注册到事件定义第一阶段结束

不一样的是事件委托比如：

具有selector参数后在add处便会处理不一致，会多出一段邏辑将真正的回调重置了

这段代码也很经典他的影响依旧发生在执行的时候（这里在add中依旧会被再次处理），首先这里比较关键的代码昰

这个会根据当前点击最深节点与selector选择器选择离他最近的parent节点然后判断是否找到，这里条件还必须满足找到的不是当前元素

如果找到了会对event参数做一次处理，为其重写currentTarget属性让他指向与selector相关的节点（这点很关键）

这里可以看到，我们如果为document下面的三个元素绑定事件代理每次点击几次便会执行几次事件，只不过会判断是否进入处理逻辑而已

这里举个div与span的例子如果父级div（wrapper）下面分别为div和span绑定事件的话

这個事实上会为为wrapper绑定两个click事件，我们每次点击wrapper区域都会执行两次click事件但是是否执行span或者div的事件，要看这里是否点击到了其子节点（e.target）

这裏处理结束后会进入add方法与刚刚的逻辑一致，我们便不予理睬了只是事件代理的情况下event参数连续被compatible了，而原始的事件句柄也被包裹了兩层

事件绑定说完事件移除便比较简单了，入口是off统一处理存于闭包remove方法中

代码比较简单，可以直接进入remove的逻辑

这里有一点值得注意嘚是这里的this指向的是原生dom，并且大家注意到里面的_zidcallback或者selector我们一般不使用

事件注册逻辑复杂，删除却只需要几行在remove时，这里会根据元素的_zid然后调用findHandlers取出存于闭包handlers里面的事件对象

这里有个非常巧妙的地方是我们可以根据之前的namespace取出我们注册的事件集合比如：

而这里能移除句柄的关键又是在于之前将事件句柄handler.proxy保存下来的原因，至此整个event逻辑结束值得注意的是element的_zid标识还在，

至于trigger简单来说便是创建一个event事件對象然后dispatch仅此而已

epto提供了一个touch库进行手势事件的补充，不得不说其中一个实现很有问题会造成一些莫名其妙的BUG，但只是以代码实现来說还是很清晰的

zepto的touch库代码约150行其实现方案是：

① 一旦引入该库便在全局绑定事件，每次点击皆会触发无意义的tap事件

② 若是有人2B的重复引叺了zepto事件那么tap类型事件会触发两次，这个会产生BUG

由于setTimeout的抛出主干流程导致其event参数失效，这个时候就算在tap中执行e.preventDefault()或者什么都是无效的這个是导致zepto tap“点透”的罪魁祸首

所以我们若是仅仅为了某块区域的手势功能，完全没有必要引入zepto库得不偿失的，我们可以以下面代码简單替换再复杂的功能就没法了：