这个故事是从老板发现bug开始的说起的。。。
第一章：故事描述
第一回合：老板发现bug
早上，老板的朋友告诉老板，你家的App(微微信)在聊天的时候，消息总是发不出去，老板回到公司，找到微微信的项目负责人，把bug告诉了他，然后他就去找IM模块的负责人，让他把bug修掉，自然的IM负责人又会去找实际这个一问题产生的人，然后最终找到了今天的主人公Perter(没错，又是他，他又面临要被fire掉的危险了)
第二回合：Perter改bug
Perter被告知有bug，心里不是滋味，翻开了陈年代码，努力的去改，改着改着，又发现这个问题还会导致另外一个问题，但是Perter能力有限改不了，只好找牛B的IM模块负责人了改了。
第三回合：bug改完，继续做其他，坐等其他bug
终于把这个bug改完，Perter也继续做其他事情，随时等着再有bug，再改，一直循环。
第二章：图片描述
用图来描述这个过程是这样的：
第一回合：老板发现bug
老板
| 因为这个是微微信的bug，所以去找微微信负责人
---------
| |
其他项目负责人 微微信负责人
| 因为这个是IM的bug，所以去找IM模板负责人
---------
| |
其他模块负责人 IM模板负责人
| 最终找到这个bug是Perter弄出来的，就是他的责任
---------
| |
其他同事 Perter
第二回合：Perter改bug
Perter(修改bug改到一半，发现需要牛B的IM模块负责人帮忙)->IM模块负责人(也在修改bug)
第三回合：bug改完，继续做其他，坐等其他bug
bug List(有新来的bug就排队吧，前面还有很多bug要给Perter改呢，亲)
___
|bug|
-----
|bug|
----- 老板拿最先进来的bug
|bug| ---------------------->老板在分配任务了------>然后又到回合一了。
-----
那么最后看起来会是这样的。
bug List(有新来的bug就排队吧，前面还有很多bug要给Perter改呢，亲)
___
|bug|
-----
|bug|
----- 老板拿最先进来的bug
|bug| ---------------------->老板在分配任务了
| 因为这个是微微信的bug，所以去找微微信负责人
---------
| |
其他项目负责人 微微信负责人
| 因为这个是IM的bug，所以去找IM模板负责人
---------
| |
其他模块负责人 IM模板负责人
| 最终找到这个bug是Perter弄出来的，就是他的责任
---------
| |
其他同事 Perter
Perter(修改bug改到一半，发现需要牛B的IM模块负责人帮忙)->IM模块负责人(也在修改bug)
第三章：iOS描述
Event Queue(有新来的Event就排队吧，前面还有很多Event要给App处理改呢，亲)
______
|Event|
-------
|Event|
------- UIApplication拿最先进来的Event
|Event| ---------------------->UIApplication在分配任务了
| 因为是一个触摸事件，所以把Event给UIWindow
---------
| |
其他UIWindow Key UIWindow
| 通过hitTest:withEvent:发现是点在了UIView上
---------
| |
其他View UIView
| 通过hitTest:withEvent:发现是点在了UITableView上
---------
| |通过hitTest:withEvent:发现没有其他View比自己更合适处理了，所以就自己来处理Event
其他View UITableView
UITableView(调用touchesMoved:withEvent:处理Event，然后调用super的touchesMoved:withEvent:让父View(准确应该是nextResponder，有可能是UIViewController)也处理一下这个Event)->父View(调用touchesMoved:withEvent:处理Event)
总结
其实iOS上的事件机制主要分为2点：
- 找到点中的View
- 从点中的View开始处理事件，然后看一下是否需要父View也需要处理事件。（递归上去）
其实还有些细节没说，比如hitTest:withEvent:内部调pointInside:withEvent:看看是否点中在自己身上来确定，Event一直往上传传回给UIApplication就不处理了，这些都是能够处理事件的都是UIResponder的子类，其实这个是一个责任链模式等等。
