談一談iOS事件的產生和傳遞

談一談iOS事件的產生和傳遞

1.事件的產生

• 發生觸摸事件後，系統會將該事件加入到一個由UIApplication管理的事件隊列中.

• UIApplication會從事件隊列中取出最前面的事件，並將事件分發下去以便處理，一般，先發送事件給應用程序的主窗口（keyWindow）。

• 主窗口會在視圖層次結構中找到一個最合適的視圖來處理觸摸事件，這也是整個事件處理過程的第一步

2.事件的傳遞

1. 首先判斷主窗口（keyWindow）本身是否能接受觸摸事件

2. 判斷觸摸點是否在本身身上

3. 子控件數組中從後往前遍歷子控件，重複前面的兩個步驟（所謂從後往前遍歷子控件，就是首先查找子控件數組中最後一個元素，而後執行一、2步驟

4. view，好比叫作subView，那麼會把這個事件交給這個subView，再遍歷這個subView的子控件，直至沒有更合適的view爲止

5. 若是沒有符合條件的子控件，那麼就認爲本身最合適處理這個事件，也就是本身是最合適的view

UIView不能接收觸摸事件的三種狀況：

• 不容許交互：userInteractionEnabled = NO

• 隱藏：若是把父控件隱藏，那麼子控件也會隱藏，隱藏的控件不能接受事件

• 透明度：若是設置一個控件的透明度<0.01，會直接影響子控件的透明度。alpha：0.0~0.01爲透明。

注 意:默認UIImageView不能接受觸摸事件，由於不容許交互，即userInteractionEnabled = NO，因此若是但願UIImageView能夠交互，須要userInteractionEnabled = YES。發生在事件傳遞的時候。

總結

1. 點擊一個UIView或產生一個觸摸事件A，這個觸摸事件A會被添加到由UIApplication管理的事件隊列中（即，首先接收到事件的是UIApplication）。

2. UIApplication會從事件對列中取出最前面的事件（此處假設爲觸摸事件A），把事件A傳遞給應用程序的主窗口（keyWindow）。

3. 窗口會在視圖層次結構中找到一個最合適的視圖來處理觸摸事件。（至此，第一步已完成）

 

若是想讓某個view不能接收事件（或者說，事件傳遞到某個view那裏就斷了），那麼能夠經過剛纔提到的三種方式。好比，設置其userInteractionEnabled = NO;那麼傳遞下來的事件就會由該view的父控件處理。

例如，不想讓藍色的view接收事件，那麼能夠設置藍色的view的userInteractionEnabled = NO;那麼點擊黃色的view或者藍色的view所產生的事件，橙色的view就會成爲最合適的view。事件都會由橙色的veiw處理。

因此，無論視圖能不能處理事件，只要點擊了視圖就都會產生事件，關鍵看該事件是由誰來處理！也就是說，若是藍色視圖不能處理事件，點擊藍色視圖產生的觸摸事件不會由被點擊的視圖（藍色視圖）處理！

注意：若是設置父控件的透明度或者hidden，會直接影響到子控件的透明度和hidden。若是父控件的透明度爲0或者hidden = YES，那麼子控件也是不可見的！

3.如何尋找最合適的view

應用如何找到最合適的控件來處理事件？

1. 首先判斷主窗口（keyWindow）本身是否能接受觸摸事件

2. 觸摸點是否在本身身上

3. 從後往前遍歷子控件，重複前面的兩個步驟（首先查找數組中最後一個元素）

4. 若是沒有符合條件的子控件，那麼就認爲本身最合適處理

詳述：

一、主窗口接收到應用程序傳遞過來的事件後，首先判斷本身可否接手觸摸事件。若是能，那麼在判斷觸摸點在不在窗口本身身上

二、若是觸摸點也在窗口身上，那麼窗口會從後往前遍歷本身的子控件（遍歷本身的子控件只是爲了尋找出來最合適的view）

三、遍歷到每個子控件後，又會重複上面的兩個步驟（傳遞事件給子控件，1.判斷子控件可否接受事件，2.點在不在子控件上）

四、如此循環遍歷子控件，直到找到最合適的view，若是沒有更合適的子控件，那麼本身就成爲最合適的view。

找到最合適的view後，就會調用該view的touches方法處理具體的事件。因此，只有找到最合適的view，把事件傳遞給最合適的view後，纔會調用touches方法進行接下來的事件處理。找不到最合適的view，就不會調用touches方法進行事件處理。

注意：之因此會採起從後往前遍歷子控件的方式尋找最合適的view只是爲了作一些循環優化。由於相比較之下，後添加的view在上面，下降循環次數。

3.1.尋找最合適的view底層剖析

兩個重要的方法：

hitTest:withEvent:方法

pointInside方法

3.1.1.hitTest：withEvent：方法

何時調用？

只要事件一傳遞給一個控件,這個控件就會調用他本身的hitTest：withEvent：方法

做用

尋找並返回最合適的view(可以響應事件的那個最合適的view)

注 意：無論這個控件能不能處理事件，也無論觸摸點在不在這個控件上，事件都會先傳遞給這個控件，隨後再調用hitTest:withEvent:方法

攔截事件的處理

• 正由於hitTest：withEvent：方法能夠返回最合適的view，因此能夠經過重寫hitTest：withEvent：方法，返回指定的view做爲最合適的view。

• 無論點擊哪裏，最合適的view都是hitTest：withEvent：方法中返回的那個view。

• 經過重寫hitTest：withEvent：，就能夠攔截事件的傳遞過程，想讓誰處理事件誰就處理事件。

• 事件傳遞給誰，就會調用誰的hitTest:withEvent:方法。

注 意：若是hitTest:withEvent:方法中返回nil，那麼調用該方法的控件自己和其子控件都不是最合適的view，也就是在本身身上沒有找到更合適的view。那麼最合適的view就是該控件的父控件。
因此事件的傳遞順序是這樣的：
　　產生觸摸事件->UIApplication事件隊列->[UIWindow hitTest:withEvent:]->返回更合適的view->[子控件 hitTest:withEvent:]->返回最合適的view

　　

事件傳遞給窗口或控件的後，就調用hitTest:withEvent:方法尋找更合適的view。因此是，先傳遞事件，再根據事件在本身身上找更合適的view。

無論子控件是否是最合適的view，系統默認都要先把事件傳遞給子控件，通過子控件調用本身的hitTest:withEvent:方法驗證後才知道有沒有更合適的view。即使父控件是最合適的view了，子控件的hitTest:withEvent:方法仍是會調用，否則怎麼知道有沒有更合適的！即，若是肯定最終父控件是最合適的view，那麼該父控件的子控件的hitTest:withEvent:方法也是會被調用的。

技巧：想讓誰成爲最合適的view就重寫誰本身的父控件的hitTest:withEvent:方法返回指定的子控件，或者重寫本身的hitTest:withEvent:方法 return self。可是，建議在父控件的hitTest:withEvent:中返回子控件做爲最合適的view！

緣由在於在本身的hitTest:withEvent:方法中返回本身有時候會出現問題。由於會存在這麼一種狀況：當遍歷子控件時，若是觸摸點不在子控件A本身身上而是在子控件B身上，還要要求返回子控件A做爲最合適的view，採用返回本身的方法可能會致使尚未來得及遍歷A本身，就有可能已經遍歷了點真正所在的view，也就是B。這就致使了返回的不是本身而是觸摸點真正所在的view。因此仍是建議在父控件的hitTest:withEvent:中返回子控件做爲最合適的view！

例如：whiteView有redView和greenView兩個子控件。redView先添加，greenView後添加。若是要求不管點擊那裏都要讓redView做爲最合適的view（把事件交給redView來處理）那麼只能在whiteView的hitTest:withEvent:方法中return self.subViews[0];這種狀況下在redView的hitTest:withEvent:方法中return self;是很差使的！

// 這裏redView是whiteView的第0個子控件 

#import "redView.h"

@implementation redView

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event{ 

    return self;

}

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 

    NSLog(@"red-touch");

}@end

// 或者

#import "whiteView.h"

 

@implementation whiteView

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event{ 

    return self.subviews[0];

}

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{ 

    NSLog(@"white-touch");

}

@end

hit:withEvent:方法底層會調用pointInside:withEvent:方法判斷點在不在方法調用者的座標系上。

3.1.2.pointInside:withEvent:方法

pointInside:withEvent:方法判斷點在不在當前view上（方法調用者的座標系上）若是返回YES，表明點在方法調用者的座標系上;返回NO表明點不在方法調用者的座標系上，那麼方法調用者也就不能處理事件。

4. 事件的響應

4.1.觸摸事件處理的總體過程

1>用戶點擊屏幕後產生的一個觸摸事件，通過一系列的傳遞過程後，會找到最合適的視圖控件來處理這個事件2>找到最合適的視圖控件後，就會調用控件的touches方法來做具體的事件處理touchesBegan…touchesMoved…touchedEnded…3>這些touches方法的默認作法是將事件順着響應者鏈條向上傳遞（也就是touch方法默認不處理事件，只傳遞事件），將事件交給上一個響應者進行處理

4.2.響應者鏈條示意圖

響應者鏈條：在iOS程序中不管是最後面的UIWindow仍是最前面的某個按鈕，它們的擺放是有先後關係的，一個控件能夠放到另外一個控件上面或下面，那麼用戶點擊某個控件時是觸發上面的控件仍是下面的控件呢，這種前後關係構成一個鏈條就叫「響應者鏈」。也能夠說，響應者鏈是由多個響應者對象鏈接起來的鏈條。

響應者對象：能處理事件的對象，也就是繼承自UIResponder的對象

做用：能很清楚的看見每一個響應者之間的聯繫，而且可讓一個事件多個對象處理。

如何判斷上一個響應者

1. 若是當前這個view是控制器的view,那麼控制器就是上一個響應者

2. 若是當前這個view不是控制器的view,那麼父控件就是上一個響應者

3. 響應者鏈的事件傳遞過程:

事件處理的整個流程總結：

1. 觸摸屏幕產生觸摸事件後，觸摸事件會被添加到由UIApplication管理的事件隊列中（即，首先接收到事件的是UIApplication）。

2. UIApplication會從事件隊列中取出最前面的事件，把事件傳遞給應用程序的主窗口（keyWindow）。

3. 主窗口會在視圖層次結構中找到一個最合適的視圖來處理觸摸事件。（至此，第一步已完成)

4. 最合適的view會調用本身的touches方法處理事件

5. touches默認作法是把事件順着響應者鏈條向上拋。

事件的傳遞與響應：

1. 當一個事件發生後，事件會從父控件傳給子控件，也就是說由UIApplication -> UIWindow -> UIView -> initial view,以上就是事件的傳遞，也就是尋找最合適的view的過程。

2. 接下來是事件的響應。首先看initial view可否處理這個事件，若是不能則會將事件傳遞給其上級視圖（inital view的superView）；若是上級視圖仍然沒法處理則會繼續往上傳遞；一直傳遞到視圖控制器view controller，首先判斷視圖控制器的根視圖view是否能處理此事件；若是不能則接着判斷該視圖控制器可否處理此事件，若是仍是不能則繼續向上傳 遞；（對於第二個圖視圖控制器自己還在另外一個視圖控制器中，則繼續交給父視圖控制器的根視圖，若是根視圖不能處理則交給父視圖控制器處理）；一直到 window，若是window仍是不能處理此事件則繼續交給application處理，若是最後application仍是不能處理此事件則將其丟棄

3. 在事件的響應中，若是某個控件實現了touches…方法，則這個事件將由該控件來接受，若是調用了[supertouches….];就會將事件順着響應者鏈條往上傳遞，傳遞給上一個響應者；接着就會調用上一個響應者的touches….方法

如何作到一個事件多個對象處理：

由於系統默認作法是把事件上拋給父控件，因此能夠經過重寫本身的touches方法和父控件的touches方法來達到一個事件多個對象處理的目的。

(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event{

// 1.本身先處理事件...

NSLog(@"do somthing...");

// 2.再調用系統的默認作法，再把事件交給上一個響應者處理

[super touchesBegan:touches withEvent:event]; 

}

事件的傳遞和響應的區別：

事件的傳遞是從上到下（父控件到子控件），事件的響應是從下到上（順着響應者鏈條向上傳遞：子控件到父控件。

參考連接：http://www.jianshu.com/p/2e074db792ba