假如我們點擊了手機(jī)屏幕??，那么當(dāng)前頁面的app需要識別出點擊的是哪一個控件岂昭，并且對事件的響應(yīng)進(jìn)行處理。
而iOS系統(tǒng)的UIKit已經(jīng)設(shè)計好一套方案：利用事件傳遞以及響應(yīng)鏈去確定響應(yīng)者狠怨。

響應(yīng)事件

在UIKit中我們使用響應(yīng)者對象（Responder）處理事件约啊。一個響應(yīng)者對象一般是UIResponder類的實例，它常見的子類包括UIView,UIViewController,UIApplication,這意味著我們?nèi)粘Ｊ褂玫降目丶缀醵际琼憫?yīng)者佣赖，如 UIButton,UILabel等等

在UIResponder及其子類中恰矩，我們是通過有關(guān)觸摸（UITouch）方法來處理和傳遞事件（UIEvent）,具體的方法有

open func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?)
open func touchesMoved(_ touches: Set<UITouch>, with event: UIEvent?)
open func touchesEnded(_ touches: Set<UITouch>, with event: UIEvent?)
open func touchesCancelled(_ touches: Set<UITouch>, with event: UIEvent?)

在 UITouch 內(nèi)，存儲了大量觸摸相關(guān)的數(shù)據(jù)憎蛤，當(dāng)手指在屏幕上移動時外傅，所對應(yīng)的 UITouch 數(shù)據(jù)也會更新，例如：這個觸摸是在哪個 window 或者哪個 view 內(nèi)發(fā)生的俩檬？當(dāng)前觸摸點的坐標(biāo)是栏豺？前一個觸摸點的坐標(biāo)是？當(dāng)前觸摸事件的狀態(tài)是豆胸？這些都存儲在 UITouch 里面奥洼。另外需要注意的是，在這四個方法的參數(shù)中晚胡，傳遞的是UITouch 類型的一個集合（而不是一個 UITouch）灵奖，這對應(yīng)了兩根及以上手指觸摸同一個視圖的情況。

確定第一響應(yīng)者

第一響應(yīng)者就是 我們點擊了屏幕上的UIButton控件估盘，那么這個按鈕控件就是這個事件的第一響應(yīng)者

在觸摸發(fā)生后瓷患，UIApplication 會觸發(fā) func sendEvent(_ event: UIEvent)將一個封裝好的 UIEvent 傳給 UIWindow，也就是當(dāng)前展示的 UIWindow遣妥，通常情況接下來會傳給當(dāng)前展示的 UIViewController擅编，接下來傳給 UIViewController 的根視圖。這個過程是一條龍服務(wù)，沒有分叉爱态。但是在傳遞給當(dāng)前 UIViewController 的根視圖之后谭贪，就是開發(fā)人員的主戰(zhàn)場，視圖的層級結(jié)構(gòu)就可以變得錯綜復(fù)雜起來了锦担。

image.png

命中測試

image.png

關(guān)于圖中還有一些細(xì)節(jié)需要先說明：

• 在 檢查自身可否接收事件 中浆熔，如果視圖符合以下三個條件中的任一個宙橱，都會無法接收事件：
  1.view.isUserInteractionEnabled = false
  2.view.alpha <= 0.01
  3.view.isHidden = true

• 檢查坐標(biāo)是否在自身內(nèi)部 這個過程使用了 func point(inside point: CGPoint, with event: UIEvent?) -> Bool 方法來判斷坐標(biāo)是否在自身內(nèi)部，該方法是可以被重寫的蘸拔。
• 從后往前遍歷子視圖重復(fù)執(zhí)行 指的是按照 FILO 的原則师郑，將其所有子視圖按照「后添加的先遍歷」的規(guī)則進(jìn)行命中測試。該規(guī)則保證了系統(tǒng)會優(yōu)先測試視圖層級樹中最后添加的視圖调窍，如果視圖之間有重疊宝冕，該視圖也是同級視圖中展示最完整的視圖，即用戶最可能想要點的那個視圖邓萨。
• 在 按順序看看平級的兄弟視圖 時地梨，若發(fā)現(xiàn)已經(jīng)沒有未檢查過的視圖了，則應(yīng)走向 誒缔恳？沒有子視圖符合要求宝剖？。

下面我們舉個例子來解釋這個流程歉甚，在例子中我們從當(dāng)前 UIViewController的根視圖開始執(zhí)行這個流程万细。下圖中灰色視圖 A 可以看作是當(dāng)前 UIViewController 的根視圖，右側(cè)表示了各個視圖的層級結(jié)構(gòu)纸泄，用戶在屏幕上的觸摸點是??處赖钞，并且這 5 個視圖都可以正常的接收事件。??并且注意聘裁，D 比 B 更晚添加到 A 上雪营。

image.png

• 首先對 A 進(jìn)行命中測試，顯然??是在 A 內(nèi)部的衡便，按照流程接下來檢查 A 是否有子視圖献起。
• 我們發(fā)現(xiàn) A 有兩個子視圖洋访，那我們就需要按 FILO 原則遍歷子視圖，先對 D 進(jìn)行命中測試谴餐，后對 B 進(jìn)行命中測試姻政。
• 我們對 D 進(jìn)行命中測試，我們發(fā)現(xiàn)??不在 D 的內(nèi)部总寒，那就說明 D 及其子視圖一定不是第一響應(yīng)者。
• 按順序接下來對 B 進(jìn)行命中測試理肺，我們發(fā)現(xiàn)??在 B 的內(nèi)部摄闸，按照流程接下來檢查 B 是否有子視圖。
• 我們發(fā)現(xiàn) B 有一個子視圖 C妹萨，所以需要對 C 進(jìn)行命中測試年枕。
• 顯然??不在 C 的內(nèi)部，這時我們得到的信息是：觸摸點在 B 的內(nèi)部乎完，但不在 B 的任一子視圖內(nèi)熏兄。
• 得到結(jié)論：B 是第一響應(yīng)者，并且結(jié)束命中測試树姨。
• 整個命中測試的走向是這樣的：A? --> D? --> B? --> C? >>>> B

整個流程應(yīng)該算是清晰明了??摩桶，實際上這個流程就是UIView 的一個方法：func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView?，方法最后返回的UIView? 即第一響應(yīng)者帽揪，這個方法代碼還原應(yīng)該是這樣的

class HitTestExampleView: UIView {
    override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
        if !isUserInteractionEnabled || isHidden || alpha <= 0.01 {
            return nil // 此處指視圖無法接受事件
        }
        if self.point(inside: point, with: event) { // 判斷觸摸點是否在自身內(nèi)部
            for subview in subviews.reversed() { // 按 FILO 遍歷子視圖
                let convertedPoint = subview.convert(point, from: self)
                let resultView = subview.hitTest(convertedPoint, with: event) 
                // ??這句是判斷觸摸點是否在子視圖內(nèi)部硝清，在就返回視圖，不在就返回nil
                if resultView != nil { return resultView }
            }
            return self // 此處指該視圖的所有子視圖都不符合要求转晰，而觸摸點又在該視圖自身內(nèi)部
        }
        return nil // 此處指觸摸點是否不在該視圖內(nèi)部
    }
}

小心越界芦拿！

針對這個流程舉個額外的例子，如果按下圖的視圖層級和觸摸點來判斷的話查邢，最終獲得第一響應(yīng)者仍然是 B蔗崎，甚至整個命中測試的走向和之前是一樣的：A? --> D? --> B? --> C? >>>> B，究其原因是在 D 檢查觸摸點是否在自身內(nèi)部時扰藕，答案是否缓苛，所以不會去對 E 進(jìn)行命中測試，即使看起來我們點了 E邓深。這個例子告訴我們他嫡，要注意可點擊的子視圖是否會超出父視圖的范圍。另若有這種情況可以重寫 func point(inside point: CGPoint, with event: UIEvent?) -> Bool 方法來擴(kuò)大點擊有效范圍庐完。對于這種處理方式钢属，個人覺得是可以，但沒必要门躯，尋求合理的視圖布局和清晰易讀的代碼比這個關(guān)鍵??

image.png

那么如果要響應(yīng)的視圖超過了父視圖的范圍淆党，會有什么影響呢

• 不能確定出正確的響應(yīng)者，像上面的例子 本來響應(yīng)者應(yīng)該是E，但是檢測出來的是B
• 由于確定不了響應(yīng)者 那么控件對應(yīng)的響應(yīng)方法就不會響應(yīng) 出現(xiàn)點擊一個UIButton但是沒反應(yīng)的情況

那么解決辦法就是擴(kuò)大 點擊范圍

• 由于命中檢測中是先判斷 point是否在父視圖里染乌，若不在則不會去檢測子視圖山孔，那么可以重寫父視圖的hitTest方法，先去檢測子視圖荷憋，如果都不在子視圖里面 再去執(zhí)行父視圖的point方法

class testBtn: UIButton {
    override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
        if !isUserInteractionEnabled || isHidden || alpha <= 0.01 {
                    return nil // 此處指視圖無法接受事件
        }
//        if self.point(inside: point, with: event) { // 判斷觸摸點是否在自身內(nèi)部
//            for subview in subviews.reversed() {
//                let convertedPoint = subview.convert(point, from: self)
//                let resultView = subview.hitTest(convertedPoint, with: event)
//                // ??這句是判斷觸摸點是否在子視圖內(nèi)部台颠，在就返回視圖，不在就返回nil
//                if resultView != nil {
//                    print(resultView!)
//                    return resultView
//                }
//            }
//                return self
//            }
        for subview in subviews.reversed() {
            let convertedPoint = subview.convert(point, from: self)
            let resultView = subview.hitTest(convertedPoint, with: event)
            // ??這句是判斷觸摸點是否在子視圖內(nèi)部勒庄，在就返回視圖串前，不在就返回nil
            if resultView != nil {
                print(resultView!)
                return resultView
            }
        }
        if self.point(inside: point, with: event) {
            return self
        }
            return nil
    }

}

• 或者去重寫父視圖的point方法

通過響應(yīng)鏈傳遞事件

在找到了第一響應(yīng)者之后，整個響應(yīng)鏈也隨著確定下來了实蔽。所謂響應(yīng)鏈?zhǔn)怯身憫?yīng)者組成的一個鏈表荡碾，鏈表的頭是第一響應(yīng)者，鏈表的每個結(jié)點的下一個結(jié)點都是該結(jié)點的 next屬性局装。

其實響應(yīng)鏈就是在命中測試中坛吁，走通的路徑。用上個章節(jié)的例子铐尚，整個命中測試的走向是：A? --> D? --> B? --> C?拨脉，我們把沒走通的?的去掉，以第一響應(yīng)者 B 作為頭宣增，依次連接女坑，響應(yīng)鏈就是：B -> A。（實際上 A 后面還有控制器等统舀，但在該例子中沒有展示控制器等匆骗，所以就寫到 A）

默認(rèn)來說，若該結(jié)點是UIView 類型的話誉简，這個 next屬性是該結(jié)點的父視圖碉就。但也有幾個例外：

• 如果是 UIViewController的根視圖，則下一個響應(yīng)者是 UIViewController闷串。

• 如果是UIViewController

  • 如果UIViewController 的視圖是UIWindow 的根視圖瓮钥，則下一個響應(yīng)者是 UIWindow 對象。
  • 如果 UIViewController是由另一個UIViewController呈現(xiàn)的烹吵，則下一個響應(yīng)者是第二個UIViewController碉熄。

• UIWindow的下一個響應(yīng)者是 UIApplication。
• UIApplication的下一個響應(yīng)者是 app delegate肋拔。但僅當(dāng)該 app delegate是 UIResponder的實例且不是 UIView锈津、UIViewController 或app 對象本身時，才是下一個響應(yīng)者凉蜂。

下面舉個例子來說明琼梆。如下圖所示性誉，觸摸點是??，那根據(jù)命中測試茎杂，B 就成為了第一響應(yīng)者错览。由于 C 是 B 的父視圖、A 是 C 的父視圖煌往、同時 A 是 Controller 的根視圖倾哺，那么按照規(guī)則，響應(yīng)鏈就是這樣的：

視圖 B ->視圖 C -> 根視圖 A -> UIViewController 對象 -> UIWindow 對象 ->UIApplication 對象 -> App Delegate

image.png

沿響應(yīng)鏈傳遞事件

觸摸事件首先將會由第一響應(yīng)者響應(yīng)刽脖，觸發(fā)其 open func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) 等方法羞海，根據(jù)觸摸的方式不同（如拖動，雙指）曾棕，具體的方法和過程也不一樣扣猫。若第一響應(yīng)者在這個方法中不處理這個事件菜循，則會傳遞給響應(yīng)鏈中的下一個響應(yīng)者觸發(fā)該方法處理翘地，若下一個也不處理，則以此類推傳遞下去癌幕。若到最后還沒有人響應(yīng)衙耕，則會被丟棄（比如一個誤觸）。 我們可以創(chuàng)建一個 UIView 的子類勺远，并加入一些打印函數(shù)橙喘，來觀察響應(yīng)鏈具體的工作流程。

class TouchesExampleView: UIView {
    override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {
        print("Touches Began on " + colorBlock)
        super.touchesBegan(touches, with: event)
    }
    
    override func touchesMoved(_ touches: Set<UITouch>, with event: UIEvent?) {
        print("Touches Moved on " + colorBlock)
        super.touchesMoved(touches, with: event)
    }
  
    override func touchesEnded(_ touches: Set<UITouch>, with event: UIEvent?) {
        print("Touches Ended on " + colorBlock)
        super.touchesEnded(touches, with: event)
    }
}

下面我們舉一個例子胶逢。如下圖厅瞎，A B C 都是 UIView，我們將手指按照??的位置和箭頭的方向在屏幕上移動一段距離初坠，然后松開手和簸。我們應(yīng)該能在控制臺看到下右圖的輸出。我們可以看到碟刺，A B C 三個視圖都積極的響應(yīng)了每一次事件锁保，每次觸摸的發(fā)生后，都會先觸發(fā) B 的響應(yīng)方法半沽，然后傳遞給 C爽柒，在傳遞給 A。但是這種「積極」的響應(yīng)其實意味著在我們這個例子中者填，A B C 都不是這個觸摸事件的合適接受者浩村。他們之所以「積極」的將事件傳遞下去，是因為他們查看了這個事件的信息之后占哟，認(rèn)為自己并不是這個事件的合適處理者穴亏。（當(dāng)然了蜂挪，我們這邊放的是三個 UIView，他們本身確實也不應(yīng)該能處理事件）

image.png

那么如果我們把上圖中的 C 換成平時使用的 UIControl類嗓化，控制臺又會怎么打印呢棠涮？如右下圖所示，會發(fā)現(xiàn)響應(yīng)鏈的事件傳遞到 C 處就停止了刺覆，也就是 A 的 touches方法沒有被觸發(fā)严肪。這意味著在響應(yīng)鏈中，UIControl及其子類默認(rèn)來說谦屑，是不會將事件傳遞下去的驳糯。在代碼中，可以理解為 UIView默認(rèn)會在其touches 方法中去調(diào)用其 next的 touches 方法氢橙，而 UIControl 默認(rèn)不會去調(diào)用酝枢。這樣就做到了，當(dāng)某個控件接受了事件之后悍手，事件的傳遞就會終止帘睦。另外，UIScrollView 也是這樣的工作機(jī)制坦康。

image.png

UIControl 接收信息的機(jī)制是 target-action 機(jī)制

總結(jié)——建立在不使用UIGestureRecognizer 的基礎(chǔ)上的

總的來說竣付，觸摸屏幕后事件的傳遞可以分為以下幾個步驟：

• 通過「命中測試」來找到「第一響應(yīng)者」
• 由「第一響應(yīng)者」來確定「響應(yīng)鏈」
• 將事件沿「響應(yīng)鏈」傳遞
• 事件被某個響應(yīng)者接收，或沒有響應(yīng)者接收從而被丟棄

如果使用了UIGestureRecognizer

在上文介紹了當(dāng)屏幕上發(fā)生一次觸摸之后滞欠，系統(tǒng)會如何尋找「第一響應(yīng)者」古胆，在尋找到「第一響應(yīng)者」之后，如何確定「響應(yīng)鏈」以及如何沿「響應(yīng)鏈」傳遞事件筛璧。在上一篇文章的環(huán)境中逸绎，是不使用 UIGestureRecognizer的。但是在我們平時的開發(fā)中想要給一個 UIView加上處理事件的能力的話夭谤，使用UIGestureRecognizer 及其子類比繼承一個UIView 的類棺牧、重寫touches方法要方便的很多。這兩種方法對事件的處理機(jī)制相互影響又有所不同沮翔。這也是下文的討論內(nèi)容：通過響應(yīng)鏈及手勢識別處理事件陨帆。

首先我們先回顧一下事件傳遞及響應(yīng)鏈的大致流程：

1.通過「命中測試」來找到「第一響應(yīng)者」
2.由「第一響應(yīng)者」來確定「響應(yīng)鏈」
3.將事件沿「響應(yīng)鏈」傳遞
4.事件被某個響應(yīng)者接收，或沒有響應(yīng)者接收從而被丟棄

在步驟 3 中采蚀，事件沿「響應(yīng)鏈」傳遞這個過程疲牵，就是響應(yīng)者通過調(diào)用其 next的touches 系列方法來實現(xiàn)的。在上篇文章中我們也提到榆鼠，假如我們使用 UIControl等類作為響應(yīng)者纲爸，這些類本身就不會調(diào)用其 next的touches系列方法，從而實現(xiàn)阻斷響應(yīng)鏈的效果妆够，也可以認(rèn)為是實現(xiàn)接受某個事件的效果识啦。那在下文中负蚊，我們將淺析在有 UIGestureRecognizer參與的情況下，事件的處理和接收是如何運作的颓哮。

當(dāng)手勢識別參與響應(yīng)鏈

上文中家妆，我們只討論了下圖中藍(lán)色部分事件沿響應(yīng)鏈傳遞的流程，但實際上冕茅，同時一起發(fā)生的還有圖中下半部分手勢識別的部分伤极。

image.png

首先要注意的是，上圖中藍(lán)色部分的流程并不會只執(zhí)行一次徒溪，舉例來說：當(dāng)我們用一根手指在一個視圖上緩慢滑動時，會產(chǎn)生一個 UITouch 對象词渤，這個 UITouch 對象會隨著你手指的滑動串绩，不斷的更新自身，同時也不斷地觸發(fā) touches 系列方法礁凡。一般來說，我們會得到如下類似的觸發(fā)順序：

touchesBegan     // 手指觸摸屏幕
touchesMoved     // 手指在屏幕上移動
touchesMoved     // ...
...
touchesMoved     // ...
touchesMoved     // 手指在屏幕上移動
touchesEnded     // 手指離開屏幕

UITouch 的 gestureRecognizers 屬性中的存儲了在尋找第一響應(yīng)者的過程中收集到的手勢剪芍，而在不斷觸發(fā) touches 系列方法的過程中，手勢識別系統(tǒng)也在在不停的判斷當(dāng)前這個 UITouch 是否符合收集到的某個手勢罪裹。

當(dāng)手勢識別成功： 被觸摸的那個視圖运挫，也就是第一響應(yīng)者會收到 touchesCancelled 的消息，并且該視圖不會再收到來自該 UITouch 的 touches 事件谁帕。同時也讓該 UITouch 關(guān)聯(lián)的其他手勢也收到 touchesCancelled峡继，并且之后不再收到此 UITouch 的 touches 事件。這樣做就實現(xiàn)了該識別到的手勢能夠獨占該 UITouch匈挖。具體表現(xiàn)參考如下

touchesBegan     // 手指觸摸屏幕
touchesMoved     // 手指在屏幕上移動
touchesMoved     // ...
...
touchesMoved     // ...
touchesMoved     // 手指在屏幕上移動
touchesCancelled // 手勢識別成功碾牌，touches 系列方法被阻斷
// 現(xiàn)在手指??并沒有離開屏幕
// 但如果繼續(xù)滑動??的話
// 并不會觸發(fā) touches 系列方法

當(dāng)手勢識別未成功： 指暫時未識別出來康愤，不代表以后不會識別成功，不會阻斷響應(yīng)鏈舶吗。注意這里指的是未成功征冷，并不一定是失敗。在手勢的內(nèi)部狀態(tài)中誓琼，手勢大部分情況下狀態(tài)是 .possible资盅，指的是UITouch 暫時與其不匹配，但之后可能有機(jī)會識別成功踊赠。而 .fail 是真的識別失敗呵扛，指的是以目前的觸摸情況來看已經(jīng)不可能是這個手勢了，并且在下個runloop 會從 gestureRecognizers 中移除該手勢筐带。

舉個??

下面舉個簡單的例子模擬一下響應(yīng)鏈和手勢的相互影響〗翊現(xiàn)在用一根手指，在一個視圖上觸摸并滑動一段距離伦籍。下圖給出了視圖不帶手勢的情況蓝晒，和帶一個 UIPanGestureRecognizer 手勢的情況。

image.png

從圖中我們可以看到帖鸦，當(dāng)不帶手勢的情況下芝薇，手指按下去的時候，響應(yīng)者的 touchBegan 方法會觸發(fā)作儿，隨著手指的移動洛二，touchMoved會不斷觸發(fā)，當(dāng)手指結(jié)束移動并抬起來的時候攻锰，touchEnded會觸發(fā)晾嘶。在這個過程中娶吞，我們接收到一直是一個不斷更新的 UITouch妒蛇。
在該視圖有添加一個UIPanGestureRecognizer 手勢的情況下，我們多了下方這一條來表示與響應(yīng)鏈同時工作的手勢識別系統(tǒng)吏奸，可以看到手勢識別系統(tǒng)也是在手指按下去那一刻就開始工作的苦丁，前半段處于一直正在識別的狀態(tài)旺拉。在我們拖動了很小一段距離之后（注意這時候我們的手指還沒抬起）蛾狗， 手勢識別系統(tǒng)確定了該 UITouch 所做的動作是符合UIPanGestureRecognizer 的特點的沉桌，于是給該視圖的響應(yīng)鏈發(fā)送了touchCancelled 的信息留凭，從而阻止這個 UITouch 繼續(xù)觸發(fā)這個視圖的 touches 系列方法（同時也取消了別的相關(guān)手勢的touches 系列方法，圖中未體現(xiàn)）兼耀。在這之后瘤运，被調(diào)用的只有與手勢關(guān)聯(lián)的 target-action方法（也就是圖中的墨綠色節(jié)點 call PanFunction）拯坟。

再進(jìn)一步理解

為了圖片的美觀和易讀郁季，在圖片中我隱去了不少細(xì)節(jié)巩踏，在此列出：
1.手勢識別器的狀態(tài)在圖中未標(biāo)出：

手勢在圖中 recognizing 的橙色節(jié)點處和recognized棕色節(jié)點處都處于 .possible 狀態(tài)
手勢在圖中綠色節(jié)點處的狀態(tài)變化是.began -> [.changed] -> ended

2. 手勢識別器不是響應(yīng)者，但也有touches系列方法菠净，比它所添加的視圖的 touches方法更早那么一點觸發(fā)

從圖中也可以看出毅往，手勢那條線上的每個節(jié)點都稍靠左一些
手勢那條線上的橙攀唯、棕侯嘀、墨綠色節(jié)點處也可以看做手勢識別器的touches 方法觸發(fā)

3. 更詳細(xì)的觸發(fā)順序應(yīng)當(dāng)如下圖所示（在一個 UIView 上添加了 UIPanGestureRecognizer，并單指在上面滑動一段距離的情況）

image.png

更多選擇??

1.我們可以通過配置手勢的屬性來改變它的表現(xiàn)土童，下面介紹三個常用的屬性：
cancelsTouchesInView：該屬性默認(rèn)是 true献汗。顧名思義罢吃，如果設(shè)置成 false刃麸，當(dāng)手勢識別成功時泊业，將不會發(fā)送touchesCancelled給目標(biāo)視圖吁伺，從而也不會打斷視圖本身方法的觸發(fā)篮奄，最后的結(jié)果是手勢和本身方法同時觸發(fā)窟却。有的時候我們不希望手勢覆蓋掉視圖本身的方法夸赫，就可以更改這個屬性來達(dá)到效果茬腿。
2.delaysTouchesBegan：該屬性默認(rèn)是false切平。在上個例子中我們得知悴品，在手指觸摸屏幕之后苔严，手勢處于.possible狀態(tài)時邦蜜，視圖的touches方法已經(jīng)開始觸發(fā)了悼沈，當(dāng)手勢識別成功之后絮供，才會取消視圖的 touches方法壤靶。當(dāng)該屬性時true 時，視圖的 touches方法會被延遲到手勢識別成功或者失敗之后才開始忧换。也就是說亚茬，假如設(shè)置該屬性為 true 刹缝，在整個過程中識別手勢又是成功的話梢夯，視圖的touches 系列方法將不會被觸發(fā)颂砸。
3.delaysTouchesEnded: 默認(rèn)為YES沾凄。這種情況下發(fā)生一個touch時，在手勢識別成功后,發(fā)送給touchesCancelled消息給hit-testview温鸽，手勢識別失敗時涤垫，會延遲大概0.15ms,期間沒有接收到別的touch才會發(fā)送touchesEnded蝠猬。如果設(shè)置為NO榆芦，則不會延遲匆绣，即會立即發(fā)送touchesEnded以結(jié)束當(dāng)前觸摸

UIControl 與手勢識別

UIController 帶有控制類控件的父類

由于 UIControl接收target-action方法的方式是在其touches 方法中識別崎淳、接收拣凹、處理嚣镜，而手勢的touches方法一定比其所在視圖的 touches方法早觸發(fā)祈惶。再根據(jù)上文的描述的觸發(fā)規(guī)則捧请，可以得到的結(jié)論是：對于自定義的UIControl來說疹蛉，手勢識別的優(yōu)先級比UIControl 自身處理事件的優(yōu)先級高可款。
`
舉個例子來說：當(dāng)我們給一個 UIControl 添加了一個 .touchupInside 的方法闺鲸，又添加了一個UITapGestureRecognizer 之后摸恍。點擊這個 UIControl，會看到與手勢關(guān)聯(lián)的方法觸發(fā)了类早，并且給 UIControl 發(fā)送了touchCancelled涩僻，導(dǎo)致其自身的處理時間機(jī)制被中斷逆日，從而也沒能觸發(fā)那個 .touchupInside的方法屏富。

同時這樣的機(jī)制可能會導(dǎo)致一個問題：當(dāng)我們給一個已經(jīng)擁有點擊手勢的視圖狠半，添加一個 UIControl作為子視圖神年，那么我們無論怎么給該 UIControl 添加點擊類型的 target-action 方法已日，最后的結(jié)果都是觸發(fā)其父視圖的手勢（因為在命中測試的過程中收集到了這個手勢）飘千，并且中斷 UIControl 的事件處理护奈，導(dǎo)致添加的 target-action方法永遠(yuǎn)無法觸發(fā)霉旗。

UITouch在尋找第一響應(yīng)者的時候厌秒，會把整條響應(yīng)鏈上的手勢收集在自身的 gestureRecognizers 數(shù)組中鸵闪，當(dāng)找到第一響應(yīng)者之后岛马，在每次第一響應(yīng)者觸發(fā) touches 方法之前屠列，會先觸發(fā) UITouch 手勢數(shù)組里手勢的 touches 方法

那其實??已經(jīng)給我們做了一個解決方案,UIKit 對部分控件（同時也是 UIControl 的子類）做了特殊處理笛洛，當(dāng)這些控件的父視圖上有與該控件沖突功能的手勢時苛让，會優(yōu)先觸發(fā)控件自身的方法狱杰，不會觸發(fā)其父視圖上的那個手勢。

也舉個例子來說：當(dāng)我們給一個已經(jīng)擁有點擊手勢的視圖食棕，添加一個 UIButton 作為子視圖簿晓，并且給按鈕添加點擊類型的 target-action 方法憔儿，那么當(dāng)點擊按鈕時谒臼，按鈕的 target-action 方法會觸發(fā)耀里，手勢的方法會被忽略备韧。
并且文檔中也提到了织堂，如果不想要這種情況發(fā)生，那就應(yīng)當(dāng)把手勢添加到目標(biāo)控件上（因為手勢比控件更早識別到事件附较，也就是上文提到的給 UIControl 添加了.touchupInside方法的例子）拒课，這樣的話生效的就是手勢了早像。

總結(jié)

總的來說，手勢識別器在大多數(shù)情況下臀脏，識別屏幕觸摸事件的優(yōu)先級揉稚，比控件本身的方法的優(yōu)先級高搀玖。

所以在開發(fā)的過程中灌诅，注意不要讓手勢覆蓋控件本身的方法實現(xiàn)延塑。同時也要理解默認(rèn)情況下关带，手勢識別在一開始實際上并不會阻止控件自身的touches 系列方法宋雏，而是在之后的某個時機(jī)去取消磨总。另外在 UIKit中蚪燕，也對部分情況做了特殊處理馆纳，讓UIKit控件有機(jī)會跳過父視圖的手勢識別鲁驶，去獲得事件的控制權(quán)钥弯。

參考博客

https://juejin.cn/post/6894518925514997767
https://juejin.cn/post/6905914367171100680
http://www.reibang.com/p/a8c04c70212f