나무's 블로그

각각의 기능으로 분리되어 있는 프로젝트들은 공통의 리소스를 가질 수 있다.

Color, Image, Lottie의 JSON 등을 포함한다.

각각의 프로젝트들은 공통의 리소스를 사용하여 개발해야 하기 때문에, 리소스 Framework를 만들어 관리할 수 있다.

중복되는 이미지도 없고, 리소스 Framework를 import만 하면 된다.

Image, Color를 리소스 Framework으로 관리

먼저 리소스 Framework를 만든다. 그리고 이미지를 Images.assets에 추가한다.

해당 이미지들은 외부에서 코드로 불러와 사용하는 경우가 있기 때문에, 이미지를 외부에서 접근할 수 있는 코드를 만든다.

Resource Framework는 R 이라는 타입으로 접근하여 사용할 것이다.

먼저 R 타입을 만들자.

Framework로 만들었기 때문에, 이미지를 불러올 때 Resource Framework의 Bundle 위치를 알기 위해 내부에서 사용할 Bundle을 만들었다.

이제 이미지를 외부에서 접근할 수 있는 코드를 R.Image.[이미지이름] 형태를 따르도록 만든다.

이제 외부에서는 다음과 같이 이미지를 불러올 수 있다.

Color도 Image와 마찬가지로 만들 수 있다.

Storyboard, Xib를 리소스 Framework에서 관리

iOS 개발시, 항상 논쟁이 되는 주제가 있다. 바로 View를 Storyboard vs Xib로 작성하는 것이다.

Storyboard 파일을 갖기 위해서는 Dynamic Framework를 만들어야하는데, 각 기능마다 Framework로 만들게 되면 Framework 개수가 빠른 속도로 늘어날 뿐만 아니라, 기능을 더 작게 나눠 한 화면을 Framework로 만들면 어마어마할 것이다.

따라서 Storyboard, Xib를 리소스 Framework에서 관리하면 된다.

리소스 Framework에서 관리하면 화면 단위의 Framework를 Static으로 만들어도 Bundle의 위치가 리소스 Framework이기 때문에 문제가 없다.

그리고 Storyboard, Xib에서 이미지와 Color를 지정해도 Framework 자신의 내부에서 가져오기 때문에 문제가 없다.

그렇다면 다른 Framework에 있는 UIViewController Class와 ViewController View를 어떻게 연결할까?

위 사진처럼 Module을 선택하고 해당 UIViewController Class 선택하면 된다.

사용은

Framework

• 코드(클래스, 프로토콜, 컴포넌트)/리소스들을 모듈화한 모음
• 사용하는 주체와 IoC(제어의 역전) 관계
• 특정 개념들의 추상화를 제공하는 여러 클래스나 컴포넌트로 구성되어 있다.
• 컴포넌트들은 재사용 가능
• 고수준에서 조작 가능
• iOS에서 제공하는 Cocoa Touch 프레임워크가 존재한다.

Library

• Application이 연결할 수 있는, 패키징된 객체 파일들의 모음
• 사용하는 주체가 기능을 요청하며 사용한다.
• 즉, 개발자가 만든 클래스에서 직접 호출해서 사용

차이점

제어의 흐름에 대한 주도성이 누구에게 있는가에 달렸다.

즉, Application의 Flow를 누가 쥐고 있는가?

• 프레임워크는 전체적인 흐름을 스스로가 쥐고 있고, 사용자는 그 안에서 코드를 넣는다.
• 라이브러리는 사용자가 전체적인 흐름을 만들고, 라이브러리를 필요한 곳에서 가져다 쓴다.

다시 말해, "라이브러리는 라이브러리를 사용하는 측에 주도성이 있고, 프레임워크는 그 틀안에 주도성을 갖고 있다" 고 볼 수 있다.

제어의 역전(IoC)

어떠한 일을 하도록 만들어진 프레임워크에 제어의 권한을 넘김으로써, 클라이언트 코드가 신경쓰는 것을 줄이는 전략

내가 라이브러리의 메소드를 사용하는 것은 쉽게 이해할 수 있다.

결국, 프레임워크의 메소드가 사용자의 코드를 호출한다... 인데

어떻게 프레임워크가 내 메소드를 호출하는가?

1. 쉬운 방법 : 프레임워크의 event, delegate에 나의 메소드를 등록시키는 것
2. DI : 프레임워크에 정의된 protocol 을 나의 코드에서 구현, 상속한 후에 프레임워크에 넘겨준다.
   1. 이는 객체를 프레임워크에 주입하는 것이다.

모듈화

하나의 프로젝트에 모든 기능들을 넣어서 개발하다보면 어느 순간 단점들이 생긴다.

1. 컴파일 속도
2. 하나의 코드를 고쳤을 때, 발생하는 사이드 이펙트

따라서 모듈화를 통해 결합도를 낮추고, 응집도를 높히는 작업

• Module : 라이브러리를 가진 프로젝트로, 특정 역할(네트워크, Custom UI 등)을 수행, 외부에는 정의한 protocol을 통해 호출가능하게 한다. 
• Module Package : 모듈들을 관리, 모듈들의 결합으로 기능을 확장
• Service : 특정 도메인, 서비스를 관리하는 프로젝트
• Common Service : 인증, 보안 등 다른 서비스에서 공통으로 사용되는 서비스
• Main Service : 각 서비스들을 호출 및 연결
• Application : UIApplication에서 제공하는 기능을 받아서 처리

장점

1. 메인 프로젝트에서의 라이브러리 의존성이 사라짐
2. Widget, Watch 등을 개발할 때, 모듈을 쉽게 사용할 수 있음
3. Clean Build시에는 빌드가 느리지만, Rebuild시에는 해당 수정 부분만 컴파일되므로 훨씬 빨라짐

iOS에서 View의 Layout과 Content Update

iOS를 개발하다보면 View의 Layout과 Content와 관련된 이슈를 자주 접하게 된다.

실제로 UIView가 언제 Update되는지 모르기 때문에 발생한다.

View가 언제 Update 되는지 알기 위해서는 iOS App's Run Loop 를 이해하고 그것이 UIView가 제공하는 메서드들과 어떤 관계를 갖고 있는지 파악해야 한다.

iOS App's Run Loop

iOS App의 Main Run Loop는 유저로부터 모든 input Event를 받고, 응답을 담당한다.

유저가 발생한 모든 상호작용은 Event Queue에 추가된다.

아래의 사진처럼 App 객체는 Event Queue로부터 Event를 하나씩 꺼내서 App의 다른 객체들에게 전달한다.

App 객체는 유저로부터 input Event를 해석하고 그에 상응되는 App의 Core 객체들 안에 있는 Handler를 호출해준다.

또한 이러한 Handler는 개발자들이 만들어놓은 코드를 실행한다.

이러한 메서드들이 반환되면 다시 Main Run Loop로 돌아가 Update Cycle이 다시 시작된다.

Update Cycle은 View들을 배치하고 다시 그리는 역할을 한다.

Update Cycle

Update Cycle은 App이 유저로부터의 모든 Event Handling Code를 수행하고 다시 Main Run Loop로 컨트롤을 반환하는 지점

바로 이 지점에서 시스템은 우리의 View들을 배치하고(layout), 보여주고(display), 제약(contraints)한다.

만약 우리가 Event Handler들을 처리하는 과정에서 어떤 UIView에 변화를 준다면, 해당 UIView는 다시 그려져야 한다고 표시됨

다음 Update Cycle에서 시스템은 이 UIView의 모든 변화를 수행한다.

유저가 상호작용하는 것과 Layout이 변하는 시간의 Gap은 유저가 인지하지 못한다.

iOS App은 60 FPS이고, Update Cycle은 이 중 1 프레임에 해당된다.

이렇게 빠르게 Update되기 때문에, 유저는 UI와 상호작용 간의 차이를 느끼지 못한다.

그러나 이벤트가 처리되는 시점과 실제로 View가 다시 그려지는 시점의 차이가 존재하기 때문에, View는 우리가 View를 Update하기 원하는 Run Loop의 특정 시점에 Update되지 않을 수도 있다.

이는 다음과 같은 위험을 초래한다.

만약 우리가 View의 마지막 Layout이나 Content에 대해 계산을 해야하는 시점이라면, 예전 정보를 갖고 View를 조작할 가능성이 생긴다.

Layout

• UIView의 Layout은 화면에서 UIView의 크기와 위치를 의미한다.
• 모든 View의 frame을 갖고 있고, 이는 SuperView의 좌표계에서의 위치와 크기를 나타낸다.
• UIView는 시스템에게 Layout이 변했다고 알려줄 수 있는 메서드
• View의 Layout이 다시 계산되는 시점에 특정 작업을 실행할 수 있게 오버라이드 가능한 콜백 메서드를 제공

layoutSubviews()

• View와 SubView들의 위치와 크기를 재조정한다.
• 현재 View와 모든 SubView들의 위치와 크기를 제공한다.
• 이 메서드는 재귀적으로 모든 SubView들의 layoutSubviews까지 호출되기 때문에, 부하가 크다.
• 이 메소드를 직접 호출하면 안된다
  • 대신, layoutSubviews를 시스템이 호출하도록 유도하는 방식 존재
    • 이 방식은 모두 run loop가 돌아가는 동안 layoutSubviews가 실행되는 시점이 모두 다르다. 
  • setNeedsLayout() 호출 or 즉시 업데이트를 원하면 layoutIfNeeded() 메소드 호출
• layoutSubviews가 완료될 때, View를 소유한 VC의 viewDidLayoutSubviews가 호출된다.
  • layoutSUbviews는 View의 layout이 변화했다는 callback이기 때문에, layout 관련 로직은 오래된 layout을 사용하는 것을 방지하기 위해 viewDidLoad/viewWillAppear가 아닌 viewDidLayoutSubviews에 호출해야 한다.

자동 refresh triggers

다음과 같은 이벤트들은 자동으로 View가 그것들의 layout에 변화가 생겼다는 것을 인지하여, 시스템에서 layoutSubviews가 다음 update Cycle에서 호출된다.

• View를 Resizing
• SubView 추가
• UIScrollView 스크롤 시, UIScrollView와 그것의 부모뷰에 layoutSubviews가 호출됨
• Device를 회전
• View의 Constraint를 변경

위와 같은 방법들은 자동으로 시스템이 알아채어 layoutSubviews를 호출해준다.

그러나 layoutSubviews를 직접 호출할 수 있는 방법들도 존재한다.

setNeedsLayout()

layoutSubviews를 가장 적은 부하로 호출할 수 있는 메서드이다.

setNeedsLayouts는 시스템에게 이 View의 Layout이 재계산되어야 한다고 알린다.

setNeedsLayouts는 즉시 반환되고, 실제로 View Update를 해주는 것은 아니다.

대신, 시스템이 다음 Update Cycle에서 layoutSubviews를 View와 SubView들에게 호출하게 한다.

실제로 setNeedsLayouts가 호출되는 시점과 View가 다시 그려지는 시점은 정확하지는 않지만, 유저가 인지할 수는 없다.

layoutIfNeeded()

layoutIfNeeded는 UIView가 layoutSubviews를 호출하도록하는 명시적인 메서드이다.

layoutSubviews가 다음 UpdateCycle에서 호출되는 것이 아니라, View의 Layout의 변경사항이 있다면 즉시 호출한다.

만약 layoutIfNeeded를 setNeedsLayout를 호출한 직후나 자동으로 layoutSubviews를 호출하는 방법 직후에 호출한다면,

layoutSubviews는 뷰에 즉시 호출된다.

그러나 우리가 layoutIfNeeded를 호출했는데 View에 변경사항이 없다면 호출되지 않는다.

layoutIfNeeded는 주로 COnstraints를 애니메이션하는 상황에 유용하다.

애니메이션 시작전에 새로운 Constraints를 설정하고, 애니메이션 클로저안에 layoutIfNeeded를 호출한다.

 layoutIfNeeded()과 setNeedsLayout()의 차이를 보여준다.

Display

Layout이란 것이 View의 위치와 크기를 의미한다면, Display는 View의 속성 중 크기/위치나 SubView들에 대한 정보를 갖지 않는 속성을 포함한다.

ex) 색, 텍스트, 이미지, Core Graphics 등이 있다.

Display는 Layout 과정과 유사한데, 시스템이 자동으로 업데이트가 되게 하는 방식과 우리가 명시적으로 업데이트를 하는 방법이 존재

draw(_ rect:)

뷰에서 CGRect 직사각형으로 특정된 영역에 대해 다시 뷰를 그리는 등의 업데이트를 할 때, 호출되는 메서드

UIView의 draw 메서드는 Layout Update 과정에서의 layoutSubviews와 같은 역할을 한다.

차이점은 draw 메서드는 SubView들의 draw까지 호출하지 않는다는 것이다.

직접 draw 메서드를 호출하면 안된다.

내부 인자

rect는 업데이트되어야 하는 영역을 가지고 있따.

해당 rect의 범위는 업데이트 되는 뷰의 bounds 비율이 된다

ex) 뷰가 그려지는 첫 시점에는 직사각형은 그 자체가 전형적으로 현재 뷰로부터 보이는 전체 영역이 된다.

그러나, 부분적인 그리기 연산이 수행될 때, rect는 해당 뷰의 특정부분이 될 수도 있다

역할

전달된 사각형(rect) 내에서 receiver(수신자)의 이미지를 그립니다.

Core Graphics 및 UIKit 과 같은 기술을 사용하여 뷰의 내용을 그리는 하위 클래스는 draw 메서드를 재정의해야한다.

하지만, 이외의 방법으로 직접 컨텐츠를 설정하는 경우에는 재정의할 필요가 없다.

UIView를 직접 하위클래스로 만들면, super를 호출할 필요가 없다.

다른 View 클래스를 하위 클래스화 하는 경우, 적당한 위치에서 super를 호출해야 한다

이 메소드를 직접 호출하면 안된다 -> setNeedsDisplay() or setNeedsDisplay(_:) 를 호출하라

setNeedsDisplay()

setNeedsLayout과 유사하다.

View의 Content가 Update되게 하는 flag를 활성화시키고, 실제로 View가 다시 그리기 전에 메서드는 반환한다.

그러면 다음 Update Cycle에 시스템은 flag가 활성화된 View들의 draw를 호출한다.

우리가 만약 View의 일부분만 다시 그려지길 원한다면, setNeedsDisplay(_ rect:)를 통해 rect 범위만 그릴 수 있다.

대부분 View의 UI Component를 Update하는 것은 View의 dirty flag를 활성화시켜서 우리가 명시적으로 setNeedsDisplay를 호출하지 않아도 다음 Update Cycle에 View가 다시 그려지도록 유도한다.

그러나, 만약 UI Component와 직접적으로 연관되어 있지 않지만, 매 Update Cycle마다 다시 View를 그려줘야 하는 속성이 있다면,

didSet 감시자를 설정하여 setNeedsDisplay()를 명시적으로 호출할 수 있다.

Constraints

Auto Layout 세계에서는 Layout하고 Draw하는 것에 대한 3단계 과정이 존재한다.

1. Constraints를 Update한다
   1. 시스템이 View에 필요한 COnstraints들을 계산하고 설정한다.
2. Layout 단계
   1. Layout 엔진이 View들의 Frame과 SubView들의 Frame을 계산하고 배치한다.
3. Display 단계
   1. View의 Content를 다시 그릴 필요가 있다면, draw 메서드를 호출한다.

updateConstraints

이 메서드는 Auto Layout을 이용하는 View의 COnstraints를 동적으로 변경할 때 사용된다.

Layout 단계에서 layoutSubviews나 Display단계에서 draw처럼, updateConstraints는 오직 오버라이딩되어야 하며 직접 호출해서는 안된다.

우리는 보통 updateConstraints에서 동적으로 변하는 Constraints들을 구현한다.

정적인 Constraints들은 IB나 View의 생성자나 viewDidLoad에서 정의되어야 한다.

일반적으로, Constraints를 활성화/비활성화하거나 Constraint의 우선순위나 constant를 변경하거나, View를 계층에서 삭제하는 것은 updateConstraints를 다음 Update Cycle에서 호출하게 한다.

그러나 이 역시 명시적으로 호출하는 방법이 존재한다.

setNeedsUpdateConstraints

setNeedsUpdateConstraints를 호출하는 것은 다음 Update Cycle에서 Constraints가 Update되는 것을 보장한다.

setNeedsLayout과 setNeedsDisplay와 비슷하다.

updateConstraintsIfNeeded

updateConstraintsIfNeeded는 layoutIfNeeded와 유사하다.

그러나 AutoLayout을 사용하는 View에서만 유효하다.

Constraint Update Flag를 검사하여서, Update가 필요하다면 updateConstraints를 즉시 호출한다.

invalidateIntrinsicContentSize

Auto Layout을 사용하는 몇몇 View들은 intrinsicContentSize 속성을 갖고 있다.

View가 갖고 있는 Content의 크기를 의미한다.

intrinsicContentSize는 전형적으로 View가 갖고 있는 요소들의 Constaints로 결정되지만,  Override하여 Custom이 가능하다.

그렇다면 이것들을 어떻게 연결시키는가?

View의 Layout과 Display 그리고 Constaints는 Run Loop에서 다른 시점에 어떻게 Update되고, 명시적으로 Update할 수 있는 지에 대해 유사한 패턴을 갖는다.

각 Component들은 layoutSubviews, draw, updateConstraints와 같은 실제로 Update를 하는 메서드를 갖는다.

이 메서드들은 직접 호출되면 안되기 때문에, 유도할 수 있는 방법이 존재한다.

이러한 메서드들은 Run Loop의 마지막에 View의 해당 Flag가 활성화되어 있으면, 시스템이 호출해주는 방식이다.

Layout과 Constraints의 Update는 즉시 Update할 수 있는 메서드가 존재한다.

다음 표는 Update Cycle과 Event Loop 그리고 위의 메서드들이 Cycle 동안 어떻게 호출되는지를 설명하는 표이다.

우리는 layoutIfNeeded / updateConstraintsIfNeeded를 Run Loop의 어디서든 즉시 호출가능하다.

Loop의 끝은 Update Cycle이다. Update Cycle은 Constraints, Layout, Display를 Flag가 활성화된 View를 Update한다.

Q) 근데 항상 View들의 속성을 변경해줬을 때, setNeedsDisplay() 호출 없이도 잘만 업데이트되던데...?

A) 시스템 자체적으로 호출되고 있다, 거의 모든 표준 UI 구성요소 View의 프로퍼티가 수정될 때마다, 내부적으로 setNeedsDisplay()가 트리거된다.

예)

1. View를 부분적으로 가리고 있던 다른 View이동 및 제거
2. hidden 프로퍼티를 No로 설정하여, 이전에 숨겨진 View를 다시 볼 수 있게 만들기
3. View를 화면 밖으로 스크롤한 다음, 화면으로 다시 이동하기

이 3가지 상황에서는 내부적으로 setNeedsDisplay()가 호출되고 있다

Q) 그럼 언제 사용해?

A) 나 자신만의 View를 만들고, 자체 draw메소드를 구현하고, 무언가가 변경되면 호출!

HitTest

이전 포스팅 Responder에 대해서 공부할 때, 잠깐 나왔던 개념이다.

정의는

Returns the farthest descendant of the receiver in the view hierarchy (including itself) that contains a specified point
지정된 점(point)을 포함하는 View 계층에서 리시버의 가장 먼 자손을 리턴한다.

라고 한다.

메소드이다.

point = 리시버의 bounds로 지점된 점

event = 메소드에 대한 호출을 보증하는 이벤트이다. 이벤트 처리코드 외부에서 이 메소드를 호출하는 경우에는 nil을 지정할 수 있다.

리턴 타입이 UIView?로 옵셔널이다.. nil이 반환될 수도 있다는 건데 -> 잠시 후에 알아보자

Discussion

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

point 메소드의 파라미터는 hitTest와 같고, 반환타입만 다르다.

• hitTest = 해당 point를 통해 리시버로부터 가장 먼 SubView를 반환
• point = 해당 point가 리시버의 Bounds 내에 존재하는가?

point가 true를 반환하면, 하위 View 계층구조는 지정된 point를 포함하는 가장 앞에 있는 View를 찾을 때까지 재귀적으로 찾는다.

point가 false를 반환하면, View 계층 구조의 해당 분기가 무시된다.

(분기? -> hitTest는 Reverse DFS 방식으로 찾는다.)

ex) 

해당 View 계층일 때,

MainView -> View C -> View C.2 -> View C.1 -> View B ... 

순서로 찾게 된다.

왜? DFS면 DFS지 Reverse가 붙어?

-> iOS View 체계에서는 SubView가 SuperView보다 위(사용자에게 가까이)에 놓여진다.

-> 같은 SuperView를 가진 형제 View들의 경우에는 index가 늦은 View가 위에 놓여진다.

따라서, Reverse로 탐색할 때, hitTest가 성공한 최하단 SubView = 가장 위에 놓여진 View 가 된다.

hitTest 메소드의 동작 조건

• hidden = false
• alpha > 0.01
• userInterationEnabled = true

리시버 Bounds 외부에 있는 point는 실제로 리시버 하위 View중 하나에 속하더라도, hit이 아니다.

-> Responder Chain에서의 GreenView와 같은 현상

hitTest 구현부

- (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;
    }
}

조건문에 있듯이 hitTest의 동작 조건에 반하는 조건들이 if문에 걸려있다.

Why?

왜 hitTest를 알아야 하나?

Responder Chain 포스팅에서도 적었 듯

HitTest 테스트 포스팅

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