故事会【iOS】

发现bug到解决bug(iOS事件处理)

2016-04-29  本文已影响290人  xlL503721

这个故事是从老板发现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点:

  1. 找到点中的View
  2. 从点中的View开始处理事件,然后看一下是否需要父View也需要处理事件。(递归上去)

其实还有些细节没说,比如hitTest:withEvent:内部调pointInside:withEvent:看看是否点中在自己身上来确定,Event一直往上传传回给UIApplication就不处理了,这些都是能够处理事件的都是UIResponder的子类,其实这个是一个责任链模式等等。

上一篇下一篇

猜你喜欢

热点阅读