---

當我們在應用微信等對象，點擊掃一掃，就可以翻開二維碼掃描視圖。在我們點擊屏幕的時刻，iphone OS獲得到了用戶停止了“單擊”這一行動，操作體系把包括這些點擊事宜的信息包裝成UITouch和UIEvent情勢的實例，然後找到以後運轉的法式，逐級尋覓可以或許呼應這個事宜的對象，直到沒有呼應者呼應。這一尋覓的進程，被稱作事宜的呼應鏈，以下圖所示，不消的呼應者以鏈式的方法尋覓

事宜呼應鏈

1、呼應者

在IOS中，可以或許呼應事宜的對象都是UIResponder的子類對象。UIResponder供給了四個用戶點擊的回調辦法，分離對運用戶點擊開端、挪動、點擊停止和撤消點擊，個中只要在法式強迫加入或許來電時，撤消點擊事宜才會挪用。

UIResponder的點擊事宜

在自界說UIView為基類的控件時，我們可以重寫這幾個辦法來停止點擊回調。在回調中，我們可以看到辦法吸收兩個參數，一個UITouch對象的聚集，還有一個UIEvent對象。這兩個參數分離代表的是點擊對象和事宜對象。

1、事宜對象
IOS應用UIEvent表現用戶交互的事宜對象，在UIEvent.h文件中，我們可以看到有一個UIEventType類型的屬性，這個屬性表現了以後的呼應事宜類型。分離有多點觸控、搖一搖和長途操作（在IOS以後新增了3DTouch事宜類型）。在一個用戶點擊事宜處置進程中，UIEvent對象是獨一的
2、點擊對象
UITouch表現單個點擊，其類文件中存在列舉類型UITouchPhase的屬性，用來表現以後點擊的狀況。這些狀況包含點擊開端、挪動、停滯不動、停止和撤消五個狀況。每次點擊產生的時刻，點擊對象都放在一個聚集中傳入UIResponder的回調辦法中，我們經由過程聚集中對象獲得用戶點擊的地位。個中經由過程- (CGPoint)locationInView:(nullable UIView *)view獲得以後點擊坐標點，- (CGPoint)previousLocationInView:(nullable UIView *)view獲得上個點擊地位的坐標點。
為了確認UIView確切是經由過程UIResponder的點擊辦法呼應點擊事宜的，我創立了UIView的種別，偏重寫+ (void)load辦法，應用method_swizzling的方法交流點擊事宜的完成

+ (void)load
  Method origin = class_getInstanceMethod([UIView class], @selector(touchesBegan:withEvent:));
  Method custom = class_getInstanceMethod([UIView class], @selector(lxd_touchesBegan:withEvent:));
  method_exchangeImplementations(origin, custom);
 
  origin = class_getInstanceMethod([UIView class], @selector(touchesMoved:withEvent:));
  custom = class_getInstanceMethod([UIView class], @selector(lxd_touchesMoved:withEvent:));
  method_exchangeImplementations(origin, custom);
 
  origin = class_getInstanceMethod([UIView class], @selector(touchesEnded:withEvent:));
  custom = class_getInstanceMethod([UIView class], @selector(lxd_touchesEnded:withEvent:));
  method_exchangeImplementations(origin, custom);
}
 
- (void)lxd_touchesBegan: (NSSet *)touches withEvent: (UIEvent *)event
{
  NSLog(@"%@ --- begin", self.class);
  [self lxd_touchesBegan: touches withEvent: event];
}
 
- (void)lxd_touchesMoved: (NSSet *)touches withEvent: (UIEvent *)event
{
  NSLog(@"%@ --- move", self.class);
  [self lxd_touchesMoved: touches withEvent: event];
}
 
- (void)lxd_touchesEnded: (NSSet *)touches withEvent: (UIEvent *)event
{
  NSLog(@"%@ --- end", self.class);
  [self lxd_touchesEnded: touches withEvent: event];
}

在新建的項目中，我分離創立了AView、BView、CView和DView四個UIView的子類，然後點擊隨意率性一個地位：

項目構造圖

在我點擊上圖綠色視圖的時刻，掌握台輸入了上面的日記（日期部門曾經去除）：

CView --- begin
CView --- end

因而可知在我們點擊UIView的時刻，是經由過程touches相干的點擊事宜停止回調解理的。

除touches回調的幾個點擊事宜，手勢UIGestureRecognizer對象也能夠附加在view上，來完成其他豐碩的手勢事宜。在view添加單擊手勢以後，本來的touchesEnded辦法就有效了。最開端我一向以為view添加手勢以後，原本的touches系列辦法全體有效。然則在測試demo中，發明view添加手勢以後，touchesBegan辦法是有停止回調的，然則moved跟ended就沒有停止回調。是以，在體系的touches事宜處置中，在touchesBegan以後，應當是存在著一個調劑後續事宜（nextHandler）處置的辦法，小我猜想事宜調劑的處置年夜致以下圖示：

事宜調劑

2、呼應鏈傳遞

下面曾經引見了某個控件在吸收到點擊事宜時的處置，那末體系是怎樣經由過程用戶點擊的地位找隨處理點擊事宜的view的呢？
在上文我們曾經說過了體系經由過程赓續查找下一個呼應者來呼應點擊事宜，而一切的可交互控件都是UIResponder直接或許直接的子類，那末我們能否可以在這個類的頭文件中找到症結的屬性呢？

正好存在著這麼一個辦法：- (nullable UIResponder *)nextResponder，經由過程辦法名我們不難發明這是獲得以後view的下一個呼應者，那末我們重寫touchesBegan辦法，逐級獲得下一呼應者，直到沒有下一個呼應者地位。相干代碼以下：

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
  UIResponder * next = [self nextResponder];
  NSMutableString * prefix = @"".mutableCopy;
 
  while (next != nil) {
    NSLog(@"%@%@", prefix, [next class]);
    [prefix appendString: @"--"];
    next = [next nextResponder];
  }  
}

掌握台輸入的一切上級事宜呼應者以下：

AView
--UIView
----ViewController
------UIWindow
--------UIApplication
----------AppDelegate

固然成果異常有條理，然則從體系逐級查找呼應者的角度下去說，這個輸入的次序是恰好相反的。為何會湧現這類成績呢？我們可以看到輸入中存在一個ViewController類，解釋UIViewController也是UIResponder的子類。然則我們可以發明，controller是一個view的治理者，即使它是呼應鏈的成員之一，然則依照邏輯來講，掌握器不該該是體系查找對象之一，經由過程nextResponder辦法查找的這個思緒是不准確的。

後來，發明在UIView的頭文件中存在這麼兩個辦法，分離前往UIView和BOOL類型的辦法：

- (nullable UIView *)hitTest:(CGPoint)point withEvent:(nullable UIEvent *)event;  // recursively calls -pointInside:withEvent:. point is in the receiver's coordinate system
- (BOOL)pointInside:(CGPoint)point withEvent:(nullable UIEvent *)event;  // default returns YES if point is in bounds

依據辦法名，一個是依據點擊坐標前往事宜能否產生在本視圖之內，另外一個辦法是前往呼應點擊事宜的對象。經由過程這兩個辦法，我們可以猜到，體系在收到點擊事宜的時刻經由過程赓續遍歷以後視圖上的子視圖的這些辦法，獲得下一個呼應的視圖。是以，持續經由過程method_swizzling方法修正這兩個辦法的完成，而且測試輸入以下：

UIStatusBarWindow can answer 1
UIStatusBar can answer 0
UIStatusBarForegroundView can answer 0
UIStatusBarServiceItemView can answer 0
UIStatusBarDataNetworkItemView can answer 0
UIStatusBarDosBat target=_blank class=infotextkey>BatteryItemView can answer 0
UIStatusBarTimeItemView can answer 0
hit view: UIStatusBar
hit view: UIStatusBarWindow
UIWindow can answer 1
UIView can answer 1
hit view: _UILayoutGuide
hit view: _UILayoutGuide
AView can answer 1
DView can answer 0
hit view: DView
BView can answer 0
hit view: BView
hit view: AView
hit view: UIView
hit view: UIWindow
...... //上面是touches辦法的輸入

最下面的UIStatusBar開首的類型年夜家能夠沒見過，然則無妨礙我們猜到這是狀況欄相干的一些視圖，詳細可以查找蘋果的文檔中間（Xcode中快捷鍵shift+command+0翻開）。從輸入中不好看出體系先挪用pointInSide: WithEvent:斷定以後視圖和這些視圖的子視圖能否能吸收此次點擊事宜，然後在挪用hitTest: withEvent:順次獲得處置這個事宜的一切視圖對象，在獲得一切的可處置事宜對象後，開端挪用這些對象的touches回調辦法

經由過程輸入的辦法挪用，我們可以看到呼應查找的次序是： UIStatusBar相干的視圖 -> UIWindow -> UIView -> AView -> DView -> BView（體系在事宜鏈傳遞的進程中必定會遍歷一切的子視圖斷定能否可以或許呼應點擊事宜），以本文demo為例，我們可以得失事件呼應鏈查找的圖示以下：

呼應者查找流程

那末在下面的查找呼應者流程完成以後，體系會將本次事宜中的點擊轉換成UITouch對象，然後將這些對象和UIEvent類型的事宜對象傳遞給touchesBegan辦法，you

不只如斯，從下面輸入的nextResponder來看，一切的呼應者都是在查找中前往可呼應點擊的視圖。是以，我們可以推想出UIApplication對象保護著本身的一個呼應者棧，當pointInSide: withEvent:前往yes的時刻，呼應者入棧。

呼應者棧

棧頂的呼應者作為最優先處置事宜的對象，假定AView不處置事宜，那末出棧，移交給UIView，以此下去，直到事宜獲得了處置或許達到AppDelegate後照舊未呼應，事宜被摒棄為止。經由過程這個機制我們也能夠看到controller是呼應者棧中的破例，即使沒有pointInSide: withEvent:的辦法前往可呼應，controller照舊可以或許入棧成為UIView的下一個呼應者。

三、呼應鏈運用

既然曾經曉得了體系是怎樣獲得呼應視圖的流程了，那末我們可以經由過程重寫查謀事件處置者的辦法來完成不規矩外形點擊。最多見的不規矩視圖就是圓形視圖，在demo中我設置view的寬高為200，那末重寫辦法事宜以下:

- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event
{
  const CGFloat halfWidth = 100;
  CGFloat xOffset = point.x - 100;
  CGFloat yOffset = point.y - 100;
  CGFloat radius = sqrt(xOffset * xOffset + yOffset * yOffset);
  return radius <= halfWidth;
}

終究的後果圖以下：

以上就是本文的全體內容，願望對年夜家的進修有所贊助。

【iOS開辟之事宜傳遞呼應鏈】的相關資料介紹到這裡，希望對您有所幫助！ 提示：不會對讀者因本文所帶來的任何損失負責。如果您支持就請把本站添加至收藏夾哦！