[UIKit] hitTest(_: with: ) - 터치이벤트에 반응할 view 찾기, first responder

이전글에서 UIResponder에 대해서 공부하다가 hitTest에 대한 개념이 등장했다.
https://didu-story.tistory.com/286

[UIKit] UIResponder (feat. Responder, Responder Chain, FirstResponder)

✅ UIKit은 뷰 기반의 hit-testing을 사용하여 터치이벤트가 어디서 발생했는지 결정한다. UIView의 hitTest(_:with: ) 메서드는 view 계층을 돌아다니면서 이벤트가 발생한 터치 지점을 포함하고 있는 view의 계층 가장 최하단 subView를 찾고, 그것을 touch이벤트의 first responder로 지정한다. 만약 터치 이벤트가 발생한 위치가 view의 bounds 밖에 있다면, hitTest(_:with: )은 해당 뷰와 서브뷰를 모두 무시한다.

아, 터치가 발생하면 hitTest가 그 터치이벤트에 받아서 반응할 뷰를 찾아주는구나? 라고 생각할 수 있다. 더 구체적으로 톺아보자. (톺아보다: 샅샅이 톺아 나가면서 살피다. 크크크크 새로운 단어를 알게되었다 ^__^ )

---

 

🔵 hitTest(_: with: ) 개념 살펴보기

🔹 공식문서

우선 공식문서를 살펴보자.
https://developer.apple.com/documentation/uikit/uiview/1622469-hittest

Apple Developer Documentation

 

UIView의 인스턴스 메소드이다. 그리고 아래처럼 정의하고 있다.

✅ Returns the farthest descendant of the receiver in the view hierarchy (including itself) that contains a specified point.

→ 지정된 점을 포함하는 보기 계층 구조에서 receiver의 가장 먼 하위 항목을 반환한다.
그냥 터치이벤트를 받아들이는 인스턴스이구나 ~ 라고생각만 되지만, 제대로된 이해가 되지 않는다. 왜 가장 먼 하위 항목을 반환하지??

 

🔹 개념 살펴보기

app 내부에서 터치 이벤트가 발생하면 어떻게 될까? 그 이벤트를 받아서 반응할 객체에 '터치이벤트'가 전달되어야할 것이다. Hit-Testing은 point가 화면에 그려진 객체 (UIVIEW 등)와 만나는지에 대한 여부를 결정하는 프로세스이다.
즉, 간단하게 말해서 터치 이벤트가 발생한 뷰를 찾는 것인데, 터치 이벤트가 발생한 포인트에 있는 뷰들 중 최상단뷰를 찾는 것이다. 보통 그렇게 찾은 뷰가 이벤트를 처리할 수 있는 First Responder가 된다.

🔹 메소드

hitTest의 메소드는 CGPoint타입의 파라미터 point와 UIEvent 타입의 Event를 받는 메소드이다. 그리고 UIView를 리턴한다. (이벤트를 처리할 수 있는 뷰를 찾는다고 했으니까 당연히 UIView를 반환하겠지!)

• point : receiver의 로컬 bounds(좌표계)로 지정된 point(점)
• event : 이 메소드에 대한 호출을 담당(?)하는 이벤트이다. 이벤트 처리코드 외부에서 이 메소드를 호출하는 경우에 nil 을 지정할 수 있다. (옵셔널)
• 리턴값 UIView : 이벤트를 받아서 처리하는 view가 있을 수도 없을수도 있으니 옵셔널값으로 리턴한다.

지금까지 이렇게 공식문서에 나온 개념들만 살펴봤는데 전혀 이해가 되지 않는다. 예제코드와 함께 살펴보자 (출처는 맨 마지막에 적어둠)

🔹 공식문서의 Discussion 해석

This method traverses the view hierarchy by calling the point(inside:with:) method of each subview to determine which subview should receive a touch event. If point(inside:with:) returns true, then the subview’s hierarchy is similarly traversed until the frontmost view containing the specified point is found. If a view does not contain the point, its branch of the view hierarchy is ignored. You rarely need to call this method yourself, but you might override it to hide touch events from subviews.

This method ignores view objects that are hidden, that have disabled user interactions, or have an alpha level less than 0.01. This method does not take the view’s content into account when determining a hit. Thus, a view can still be returned even if the specified point is in a transparent portion of that view’s content.
Points that lie outside the receiver’s bounds are never reported as hits, even if they actually lie within one of the receiver’s subviews. This can occur if the current view’s clipsToBounds property is set to false and the affected subview extends beyond the view’s bounds.

이 메소드의 각 하위 view의 point(inside: with: )를 호출하여 View계층을 탐색하고 어떤 하위 View가 터치이벤트를 받아야하는지 결정한다.

👉 point(inside: with: ) ?????

UIView의 인스턴스 메서드이고, 파라미터를 보면 point와 event로 'hitTest'와 동일하다. 다른 점은 반환값인데, 리시버 bounds(좌표계)내부에 지정된 point가 포함되어있는지에 대한 여부를 boolean값으로 리턴해주는 메서드이다.

다시 hitTest로

point(inside: with: )가 true를 반환하면, 하위 view계층구조는 지정된 포인트를 포함하는 가장 앞에 있는 View (frontest view)가 발견될 때까지 하위 View계층구조가 비슷하게 가로지른다. (similarly traversed) View에 점이 없으면, View계층구조의 해당 분기가 무시된다. 이 메서드는 직접 호출할 필요가 없지만, 하위 View에서 터치이벤트를 숨기려면 이 메서드를 재정의할 수 있다.
이 메서드는 hidden이거나, 사용자 상호작용을 비활성화 하거나, 알파값이 0.01 미만인 view객체를 무시한다. 이 메서드는 'hit'을 결정할 때 view의 콘텐츠를 고려하지 않는다. 따라서 지정된 point가 해당 view컨텐츠의 투명한 부분에 있어도 view가 계속 반환 될 수 있다.
Receiver bounds 외부에 있는 point는 실제로 receiver하위 view 중 하나에 속하더라도, hit이라고 보지 않는다. 이 문제는 현재 view의 clipsToBounds 프로퍼티가 false로 설정되고, 영향ㅇ르 받는 하위 View가 범위를 벗어나는 경우 발생할 수 있다.

뭐... 대충 내가 생각하기로는 터치이벤트가 발생한 딱 그부분, 그 포인트 그지점에서의 가장 최상단뷰를 찾아주는 것이 hitTest인 것 같다..라고 대충 이해가...되는데... 도대체 어떤 상황을 예시를 들어서 이해해야할지 감이 오지 않았다.

🔵 Hit Test는 언제 실행될까

출처: http://smnh.me/hit-testing-in-ios/

위 그림에서 가장 마지막 부분에 Hit-testing이 완료되고, 최상단뷰가 결정되었다. 이렇게 찾으면 그 다음엔 뭘할까?
touch event 시퀀스의 모든 단계 (began, moved, ended, canceled)에 대한 UITouch 객체와 연동되고, hit-test view가 일련의 touch event를 받기 시작한다. (그니까 그 뷰와 터치가 연결된다는 뜻!!!)
참고해야할 것은, 손가락이 hit-test view의 bound 밖으로 다른 view로 이동하더라도, hit-test view는 touch event 시퀀스가 ㄲ트날때까지 (ended가 올때까지!!) 모든 터치를 받는다.
(손가락으로 A위치를 터치하고, 손가락을 떼지않고 동그라미를 그리고, A가 터치이벤트를 받는 UIView객체일때 A의 손가락 위치는 벗어났지만, A는 계속 그 터치이벤트를 받는다는 의미!!! 우리가 평소에 앱사용할 때 터치하고 손안떼도 그거 터치되잖아!! 위 그림은 이 행위를 묘사한 다이어그램이다)

🔵 이벤트에 반응할 UIView 객체는 어떻게 찾을까

hit-testing은 view를 탐색할 때, reverse pre-order DFS 알고리즘 방법을 사용한다. (가장 깊은 뷰를 찾고, 탐색을 중단해야하기때문에 깊이우선탐색을 진행한다!) → ✅ 개념보러가기
가장 먼저 root node를 방문한 다음, 하위 인덱스로 하위 트리를 순회하는 방식이다. 이러한 종류의 순회를 통해서 순회 반복횟수를 줄이고, 터치 포인트를 포함하는 첫번째 가장 깊은 하위 view가 발견되면 탐색을 중지하는 방식을 채택한다.
이것은 usbView가 항상 superView앞에 렌더링되고, sibling view(형제뷰)가 항상 하위 인덱스가 있는 형제뷰 앞 subView 배열에 렌더링되기 때문이다. 따라서 여러 개의 겹치는 view에 특정 포인트가 포함된 경우, 맨 오른쪽 하위 트리에서 가장 깊은 view가 frontmost view(hit test가 찾는 가장 맨앞 뷰)가 된다.

🔵 hit-test의 process

왼쪽 그림을 보면, mainView 가장 뒤에 하얀색 View가 있고, 그 위에 3개의 View가 존재한다. MainView입장에서는 세개의 view 모두 자식뷰이다.
위 3개의 View에서 빨간색 ViewA와 초록색 ViewB가 겹쳐져 있는 것을 볼 수 있다. 정확히 말하면, A와 B각각의 SubView인 ViewA.2와 ViewB.1이 겹쳐있다. 그림에서 볼수 있듯, ViewB.1이 인덱스가 더 높기 때문에 ViewA.2위에 위치하게 된다. 그럼 저 겹치는 부분을 터치하게 되면 가장 전면에 있는 frontmost view인 ViewB.1이 반환되겠지?

터치 이벤트가 발생하면, 오른쪽 화살표 방향대로 이벤트가 전달된다. UIWindow부터 시작해서 정말로 가장 먼 자손, 하지만 유저입장에서는 frontmost한 ViewB.1이 hit-test View가 되었다.
그럼 ViewC는 왜들렸다가 온걸까?
이벤트가 발생하면 가장 뒤에있는 인덱스부터 들릴 것인데 그래서 ViewC도 들린것이고, ViewC는 해당 point를 bounds(좌표계)에 갖고있지 않기 때문에 point(inside: with: )이 false를 리턴했을거고, 그래서 바로 ViewB로 넘어갓을 것이다.

🔹 hit-test의 구현부 코드를 살펴보자.

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event
{    
	if (self.hidden || !self.userInteractionEnabled || self.alpha < 0.01 || ![self pointInside:point withEvent:event] || ![self _isAnimatedUserInteractionEnabled]) {
    	return nil;    
    } else {
    	for (UIView *subview in [self.subviews reverseObjectEnumerator]) {
        	UIView *hitView = [subview hitTest:[subview convertPoint:point fromView:self] withEvent:event];
            if (hitView) {
            return hitView;            
            }
        }
    	return self;
    }
}

위 공식문서 discussion에서 봤듯이, hidden이거나, interact가 false이거나, alpha가 0.01 미만인 것은 nil을 반환한다.

이 그림을 다시 보면, 위에서 말했듯이 저 부분을 터치하면 ViewB.1이 hit-test view 가 된다. ViewA.2가 저 touch area를 포함하고 있어도 말이다.
그럼 혹시 대부분 그럴일은 없겠지만, 저부분을 터치했을때 ViewA.2가 터치된걸로 하고싶다면? (즉, ViewA.2가 hit-Test view가 되게끔 하려면?)
이럴때 hitTest를 override 해서 사용할 수 있다.

class ViewA: UIView {
	override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {        
		let hitView: UIView? = super.hitTest(point, with: event)        
		if (self == hitView) { return nil }        
		return hitView    
	}
}

hitTest받는애가 ViewB.2였는데, 해당 뷰에 이 코드를 작성해주면, nil을 반환하면서 자연스럽게 그 하위 view로 터치이벤트가 넘어간다.
즉, 이 코드를 ViewB.2의 클래스를 위에서 작성한 소스코드 커스텀 UIView로 지정해주고 실행하면, 터치 이벤트가 ViewA로 넘어가서 VIewA.2로 터치이벤트가 전달된다.
해당 코드를 사용한 더 자세한 예시, 직관적인 예시를 보고싶다면 해당 블로그를 방문해보자. → ✅ reference 바로가기

이렇게 hittest에 대해서 알아봤다. 이제 터치이벤트를 처리한는 뷰가 어떻게 전달되는지 알았고, first responder가 어떻게 선정되겟구나! 대략적으로 감이 오는것 같다.

📖 references

https://zeddios.tistory.com/536

iOS ) hitTest

https://lena-chamna.netlify.app/post/hit_testing_in_ios/

View 계층 탐색 알고리즘과 Hit-Testing in iOS


https://smnh.me/hit-testing-in-ios

Hit-Testing in iOS