iOS

Computer Science of iOS

💛 iOS

iOS 앱 실행 흐름

👉 iOS 앱은 Objective-C 기반으로 돌아가기 때문에 앱은 main 함수에서 시작함
　　👉 이때, iOS의 핵심 라이브러리인 UIKit framework가 main 함수를 관리하기 때문에 앱 개발자들이 직접 main 함수에 코드를 작성하지 않음
👉 UIKit은 main 함수를 다루는 과정에서 UIApplicationMain 함수를 호출
👉 UIApplicationMain 함수는 UIApplication 싱글톤 객체를 생성
　　👉 UIApplication 싱글톤 객체를 통해 앱 개발자는 앱의 실행에 부분적으로 관여할 수 있게 됨
👉 다음, Info.plist 파일에서 앱 구성에 필요한 데이터를 로드, Main Nib 파일을 사용하는 경우에는 이 과정에서 로드됨
👉 이후, AppDelegate 객체를 생성하고 Delegate를 위임한 후, Main Run Loop를 생성하는 등 앱 실행에 필요한 준비를 마무리
👉 준비가 완료되면, AppDelegate의 didFinishlaunchingWithOptions()를 호출

UIApplication

👉 UIApplication은 UIApplicationMain에서 만들어지는 싱글톤 객체
　　👉 UIApplication.shared 형태로 앱 전역에서 접근이 가능
　　👉 역으로, UIApplicationMain 함수는 UIApplication 싱글톤 객체를 만드는 함수
👉 Main Run Loop를 생성 및 실행하는 등의 역할을 담당

Main Run Loop

👉 유저가 일으키는 이벤트들을 처리하는 프로세스
👉 이 Loop를 통하여 View 관련 업데이트 및 이벤트를 처리함
👉 View와 관련이 되어 있기 때문에, Main Thread에서 실행됨
👉 이벤트 처리 과정
　　👉 버튼 터치와 같은 유저 이벤트 발생
　　👉 시스템을 통해 이벤트가 생성됨
　　👉 UIKit 프레임워크를 통해 생성된 port로 해당 이벤트가 앱에 전달됨
　　👉 이벤트는 앱 내부적으로 Queue의 형태로 정리되고, Main Run Loop에 하나씩 Mapping 됨
　　👉 UIApplication 객체는 이때 어떤 이벤트부터 처리할 지를 결정
👉 발생한 이벤트들을 모두 처리하고 권한이 다시 Main Run Loop로 돌아오는 시점을 update cycle이라 함
👋 Link

이벤트는 어떤 형태로 전달되며, 터치 이벤트는 다른게 있는지?

👉 이벤트는 UIEvent 객체로 전달됨
👉 터치 이벤트는 UITouch 객체로 관리되고 UIEvent 객체를 통해 접근할 수 있음
👉 UITouch 객체는 터치된 위치, 터치 강도, 움직임 등의 정보를 포함

UIControl

👉 사용자에게 보여지는 View가 사용자와 상호작용할 수 있게끔 능력을 부여해주는 클래스
👉 Target-Action 매커니즘을 이용해 사용자의 액션들을 앱에 전달하며, addTarget 메소드를 이용하여 구현
👉 addTarget의 파라미터 3가지
　　👉 target : 액션을 담당할 객체를 설정하는 파라미터, 주로 self
　　👉 action : 액션에 대한 행위를 정의한 메소드를 선택하는 파라미터, #selector(objc)
　　👉 controlEvents : 어떤 이벤트가 발생할 때마다 액션을 실행시킬 것인지 지정하는 파라미터

#selector

👉 런타임 시점에 함수 테이블에서 함수 이름을 참조하여 메서드를 선택해 실행하는 역할
👉 Objective-C와의 호환성을 위해 반드시 @objc 키워드를 붙여줘야 함
　　👉 @objc는 Swift로 작성한 메서드를 Objective-C로 인식하게 하는 역할

App LifeCycle

👉 App의 실행 및 종료 등 시스템이 발생시키는 Event에 의해 App의 상태가 전환되는 일련의 과정을 뜻함

👉 iOS 13 이후 (SceneDelegate.swift 있음)
scene life cycle 　　
　　👉 Unattached
　　　　👉 Scene이랑 연결되지 않은 상태
　　　　　　👉 앱이 실행되지 않은 Not Running과 차이가 있음
　　👉 Foreground Inactive
　　　　👉 실행 중이지만 이벤트를 받고 있지 않은 상태
　　　　👉 앱 실행 중 알림 등으로 화면이 덮여 실질적으로 이벤트를 받지 못하는 상태
　　　　　　👉 시리가 켜짐
　　　　　　👉 전화 수신
　　　　　　👉 배터리 부족 알림
　　👉 Foreground Active
　　　　👉 애플리케이션이 실질적으로 활동하고 있는 상태
　　👉 Background
　　　　👉 백그라운드 상태에서 실질적인 동작을 하고 있는 상태
　　　　👉 ex) 백그라운드에서 음악을 실행
　　👉 Suspend
　　　　👉 백그라운드 상태에서 활동을 멈춘 상태
　　　　👉 빠른 재실행을 위하여 메모리에 적재된 상태지만 실질적으로 동작을 하고 있지 않는 상태
　　　　👉 메모리가 부족할 때 시스템이 강제종료
　　⭐️ UISceneDelegate를 통해 Scene 기반 앱의 생명주기 이벤트를 처리함
　　👉 앱이 Scene을 지원한다면, UIKit은 생명주기 이벤트를 개별적으로 분리하여 전송함
　　👉 Scene : 실행되고 있는 하나의 앱 UI 인스턴스를 뜻하며 각자 개별적으로 자신의 생명주기를 가지고 있음
　　　　👉 각자의 생명주기를 갖고 있기 때문에 각자 다른 상태에 있을 수 있음
　　👉 Scene 기반 앱이더라도 부가적인 이벤트를 처리하기 위해서는 UIApplicationDelegate가 필요함
　　　　👉 앱 시작 및 종료 관련 이벤트

🔥 iOS 12 이전 (SceneDelegate.swift 없음)
app life cycle 　　
　　👉 Not Running
　　　　👉 실행되지 않았거나, 시스템에 의해 종료된 상태
　　👉 Inactive
　　　　👉 실행 중이지만 이벤트를 받고 있지 않은 상태
　　　　👉 앱 실행 중 알림 등으로 화면이 덮여 앱이 실질적으로 이벤트는 받지 못하는 상태
　　　　　　👉 시리가 켜짐
　　　　　　👉 전화 수신
　　　　　　👉 배터리 부족 알림
　　👉 Active
　　　　👉 애플리케이션이 실질적으로 활동하고 있는 상태
　　👉 Background
　　　　👉 백그라운드 상태에서 실질적인 동작을 하고 있는 상태
　　　　👉 ex) 백그라운드에서 음악을 실행
　　👉 Suspend
　　　　👉 백그라운드 상태에서 활동을 멈춘 상태
　　　　👉 빠른 재실행을 위하여 메모리에 적재된 상태지만 실질적으로 동작을 하고 있지 않는 상태
　　　　👉 메모리가 부족할 때 시스템이 강제종료
　　⭐️ UIApplicationDelegate를 통해 앱의 생명주기 이벤트를 처리함
👋 Link

AppDelegate 🆚 SceneDelegate (클래스)

👉 AppDelegate
　　👉 AppDelegate는 이름 그대로 앱과 시스템의 연결을 위해 필요한 Delegate 메소드를 담고 있음
　　👉 즉, 앱의 상태에 대응할 수 있는 메소드들이 들어있음
　　👉 UIResponder와 UIApplicationDelegate를 상속 및 참조
　　👉 iOS 13 이후, UI Lifecycle에 대한 역할을 담당하지 않음
　　　　👉 애플 푸쉬 알림 서비스와 같이, 실행 시 요구되는 모든 서비스를 등록하는 역할
　　　　👉 Session LifeCycle에 대한 역할이 추가 되었음
　　　　　　👉 Scene Session을 통해 앱에서 생성한 모든 Scene의 정보를 관리
　　　　　　　　👉 Scene Session
　　　　　　　　　　👉 Scene을 추적하는 Session 객체
　　　　　　　　　　👉 Session에는 고유한 식별자와 Scene의 구성 세부사항이 들어 있음
👉 SceneDelegate
　　👉 iOS 13 이후, AppDelegate의 역할 중 UI Lifecycle에 대한 역할을 SceneDelegate에서 담당하게 됨
　　👉 UIResponder와 UIWindowSceneDelegate를 상속 및 참조

앱 생명주기 관련 대표 메소드 + makeKeyAndVisible

👉 AppDelegate
　　👉 application:willFinishLaunchingWithOptions: 애플리케이션이 최초 실행될 때 호출되는 메소드
　　👉 application:didFinishLaunchingWithOptions: 애플리케이션이 실행된 직후 사용자의 화면에 보여지기 직전에 호출
　　👉 applicationWillTerminate: 애플리케이션이 종료되기 직전에 호출
👉 SceneDelegate
　　👉 scene(_ willConnectTo: options:): scene이 앱에 추가될 때 호출
　　👉 sceneDidBecomeActive(:): scene과의 상호작용이 시작될 때 호출
　　👉 sceneWillEnterForeground(:): scene이 Foreground로 진입할 때 호출
　　👉 sceneDidEnterBackground: scene이 Background에 진입한 후 호출
👋 makeKeyAndVisible : key window로 설정
　　👉 key window : window가 여러개 존재할 때, 가장 앞쪽에 배치된 window를 key window로 지칭

UIResponder

👉 Responder는 UIResponder의 인스턴스, UIKit에서 이벤트 처리의 중추 역할을 함
👉 이벤트가 발생하면 UIKit은 이를 처리하기 위해 Responder 객체에게 전달하여 처리하도록 함
　　👉 UIView, UIViewController 등 많은 UIKit의 핵심 객체들은 모두 UIResponder 인스턴스임
👉 주어진 Responder가 이벤트를 처리 하지 않을 경우, Responder Chain의 다음 Responder로 해당 이벤트를 전달
　　👉 Responder Chain
　　　　👉 UIKit이 모든 Responder를 엮어서 관리하는 체인
　　　　👉 UIkit은 미리 정의된 규칙을 사용하여 리스폰더 체인을 동적으로 관리하고 어떤 객체가 이벤트를 수신한 다음에 어떤 객체를 선택할 지 결정
　　　　👉 각 Responder는 next 프로퍼티로 자신의 다음 리스폰더를 참조하고 있음
　　　　👉 next 프로퍼티를 오버라이딩해서 다음 리스폰더를 임의로 변경할 수 있음
　　　　　　👉 becomeFirstResponder 메소드를 사용해서 특정한 뷰를 First Responder로 만들 수 있음
　　　　　　　　👉 해당 객체를 지금 윈도우의 First Responder로 만들어 줄 것을 요청하는 함수
　　　　　　　　　　👉 하지만, 무조건 First Responder가 되는 것을 보장하지 않음
　　　　　　　　👉 주로, 키보드를 올리는 액션을 취하기 위해 이 함수를 호출
　　　　　　👉 반대로 resignFirstResponder 메소드도 존재함
　　　　　　　　👉 해당 객체에게 지금 윈도우의 First Responder로서의 상태를 포기한다는 요청을 알리는 함수
　　　　　　　　👉 주로, 키보드를 내리는 액션을 취하기 위해 이 함수를 호출
　　　　👉 기본적으로 UIView ➡️ UIViewController ➡️ UIWindow ➡️ UIApplication ➡️ UIApplicationDelegate 순으로 이벤트가 전달됨
　　👉 First Responder
　　　　👉 이벤트를 처리하기에 가장 적절한 리스폰더 객체
　　　　👉 발생한 이벤트의 타입을 기준으로 First Responder를 결정

UIApplicationDelegate (프로토콜)

👉 UIApplication 객체의 작업에 개발자가 접근할 수 있도록 하는 메소드들을 담고 있음

UIWindowSceneDelegate (프로토콜)

👉 UIWindowSceneDelegate를 통해 Scene 기반 앱의 UI 생명주기 관련 이벤트를 처리함
👉 UISceneDelegate를 상속받는 서브클래스

UIWindow

👉 UIView의 하위 클래스로, 모든 View들의 컨테이너 역할을 함
👉 UI에 배경을 제공하고, 중요한 이벤트를 전달하는 매개체 역할
　　👉 ex) 화면 방향 전환

View

👉 UIView 클래스의 인스턴스
👉 화면의 직사각형 영역에 콘텐츠를 관리하고 보여주는 역할을 하는 UI의 기본 구성 요소
👉 UIbutton, UIImageView와 같은 모든 뷰 클래스의 상위 클래스

UIView Layer 객체

👉 UIView는 객체에 나타나는 콘텐츠들을 관리하는 CALayer 타입의 layer를 가지고 있음
👉 즉, UIView는 이미지나 애니메이션들은 직접 제어하지 않고, View에게 작업을 주면 View 내부의 Layer 객체에서 대신 처리

view(UIView) 🆚 layer(CALayer)

👉 view는 UIKit의 한 요소이고, layer는 Core Animation의 한 요소
👉 그래픽을 그리기 위해서는 그래픽 하드웨어(GPU)에 접근하여 직접 그리는 것(OpenGL)이 렌더링가 가장 속도가 빠르지만 코드의 양이 많아지는 단점이 존재
👉 따라서, 이를 보완하기 위해 애플은 Core Graphics < Core Animation < UIKit & AppKit 프레임워크를 만듦
　　👉 프레임워크가 저수준일수록 고수준에 비해 많은 기능을 제공하지만 전체적인 코드량이 많음
　　👉 프레임워크가 고수준일수록 저수준에 비해 유연성은 떨어지지만 사용이 간편하고 코드량이 적음
👉 즉, layer는 UIkit보다 많은 기능을 제공하지만, 몇 가지 기능에 대해서는 직접 구현하여 사용하여야 한다는 단점이 있음

UIViewController

👉 모든 View Controller 객체의 상위 클래스
👉 데이터 변경에 따라 뷰를 업데이트하고, 뷰에서 발생하는 사용자 이벤트와 상호작용하는 등의 역할을 갖고 있음
👉 UIViewController는 UIResponder를 상속하고, UIResponder는 NSObject를 상속
　　👉 NSObject는 대부분의 Objective-C 클래스의 계층 구조의 루트 클래스로, 하위 클래스에서 런타임 시스템 기능을 사용할 수 있도록 함
　　　　👉 런타임 시스템은 Objective-C 용 운영체제 같은 것으로, 객체 생성 및 해제에 따른 메모리 영역 관리 등의 역할을 함

UINavigationController

👉 iOS 네비게이션 스택에 화면들을 쌓아서 화면 간 이동을 관리하는 컨테이너
👉 네비게이션 바에서는 뒤로 가기 버튼과 커스터마이징한 버튼을 추가할 수 있음
👉 관련 개념
　　👉 navigationController?.navigationBar.prefersLargeTitles = true / false
　　　　👉 네비게이션 바 타이틀에 큰 글씨를 출력할 수 있게함을 설정하는 속성
　　　　👉 root에서 한 번만 설정 후, 각 화면에서 navigationItem.largeTitleDisplayMode로 지정
　　　　　　👉 navigationItem.largeTitleDisplayMode = .always / .never
　　　　　　　　👉 네비게이션 바 타이틀에 큰 글씨를 출력함 / 큰 글씨를 출력하지 않음
　　👉 Navigation Prompt
　　　　👉 navigation title 위쪽에 부가적인 설명을 할 수 있도록 설정하는 것

presentingViewController 🆚 presentedViewController

👉 ex) A에서 present B, B에서 present C를 한 경우
　　👉 B의 presentedViewController C
　　👉 B의 presentingViewController는 A

View LifeCycle

view life cycle 👉 viewDidLoad()
　　👉 뷰가 생성될 때, 가장 먼저 실행되는 메소드
　　👉 특별한 경우가 아니라면 단 한 번 실행되기 때문에 초기화 할 때 사용
　　　　🔥 super.viewDidLoad()를 제거하면?
　　　　　　👉 상위 클래스의 viewDidLoad를 호출하지 않아도 문제는 일어나지 X
　　　　　　👉 But, UIKit의 viewDidLoad가 언제 구현이 바뀔지 모르고, 내부에 중요한 초기화 코드가 들어갈 수도 있음
　　　　　　👉 So, 당장 영향이 없더라도 super.viewDidLoad를 호출하는 것이 바람직하다고 생각
👉 viewWillAppear()
　　👉 뷰가 생성되기 직전에 실행되는 메소드
　　👉 뷰가 나타나기 전에 실행해야 하는 작업을 처리할 때 사용
　　　　👉 뷰 업데이트 작업 처리 시
👉 viewDidAppear()
　　👉 뷰가 생성되고 난 뒤에 실행되는 메소드
　　👉 뷰가 나타난 후에 실행해야 하는 작업을 처리할 때 사용
　　　　👉 애니메이션 작업을 처리할 때 사용
　　👉 ViewWillAppear에 로직을 넣었다가 뷰에 반영이 안되는 경우가 있기 때문
👉 viewWillDisappear
　　👉 뷰가 사라지기 직전에 실행되는 메소드
👉 viewDidDisappear()
　　👉 뷰가 사라지고 난 뒤에 실행되는 메소드
👉 navigationController.pushViewController()

👉 present(), modalPresentationStyle = .default

👉 present(), modalPresentationStyle = .fullScreen

assign 🆚 weak (Objective-C 개념)

👉 assign(unowned in swift)
　　👉 객체의 retain count를 증가시키지 X
　　　　👉 retain count
　　　　　　👉 객체 하나가 다른 객체에 의해 참조되거나 소유된 횟수를 의미
　　　　　　👉 ARC가 없던 시절에는 개발자가 직접 메모리 관리를 했음
　　　　　　👉 메모리를 관리하는 방법에 retain/release 키워드를 직접 사용하였고, 이를 MRC(Manual Retain Counting)라고 함
　　　　　　　　👉 retain
　　　　　　　　　　👉 객체의 레퍼런스 카운트를 증가 시킴
　　　　　　　　　　👉 카운트되어 있으면 메모리에서 해제하지 않음
　　　　　　　　👉 release
　　　　　　　　　　👉 객체의 레퍼런스 카운트를 감소 시킴
　　　　　　　　　　👉 객체를 더 이상 사용하지 않거나 메모리에서 해제하고 싶을 때 이 함수를 호출하여 레퍼런스 카운트를 감소 시킴
👉 weak(weak in swift)
　　👉 assign과 거의 동일하지만, assign은 객체가 소멸되어도 포인터 값이 변하지 않는 반면, weak는 객체가 해제되는 시점에 포인터 값이 nil이 됨
　　👉 assign의 문제점은 객체가 해제되어도 포인터 값이 남아있어 접근하려다 에러가 발생하는 상황이 생김
　　👉 Objective-C는 기본적으로 nil에 접근할 때는 에러가 발생하지 X

순환 참조(강한 순환 참조(Strong Reference Cycle), 강한 참조)

👉 두 가지 이상의 객체가 서로에 대한 강한 참조 상태를 가지고 있어 메모리에서 해제되지 않는 상태
👉 Swift는 메모리를 자동으로 관리하기 위하여 ARC(Automatic Reference Counting)를 사용
　　👉 ARC
　　　　👉 메모리 영역 중 힙 영역을 자동으로 관리해주는 역할을 수행
　　　　👉 컴파일 시 코드를 분석해서 자동으로 retain, release 코드를 생성해 줌
　　　　👉 자동으로 Reference Count를 계산하여 Count가 0이 되면, 즉, 인스턴스가 더 이상 필요없을 때 메모리를 자동으로 해제
　　　　　　👋 Swift에서 클래스 인스턴스, 클로저 등 참조 타입의 값은 모두 자동으로 힙에 할당됨
　　　　　　👋 Swift는 ARC를 통해 힙에 할당된 메모리가 더 이상 참조되지 않으면 자동으로 해제해주기 때문에 free와 같이 따로 메모리 해제를 하지 않았던 것
　　　　　　👋 자동으로 RC를 관리해주기 때문에 메모리 해제에 대한 개발자의 부담을 덜어주는 것
　　　　👉 ex) let sodeul = Human(name: “Sodeul”, age: 26)
　　　　　　👉 지역 변수 sodeul은 스택에 할당되고, 실제 인스턴스는 힙에 할당되며, sodeul엔 힙에 할당된 인스턴스의 주소 값이 들어가게 됨
　　　　　　👉 인스턴스를 새로 생성할 때, 해당 인스턴스에 대한 RC가 증가하며, 힙에 같이 저장됨
　　　　👉 + ex) let clone = sodeul
　　　　　　👉 기존 인스턴스를 다른 변수에 대입할 때, 참조에 의해 인스턴스의 clone에 주소 값이 대입되며 RC가 증가하는 방식
👉 서로 강한 참조를 하고 있는 경우, Reference Count가 0이 될 수 없어 Memory가 해제되지 않는 일이 발생
👉 해결 방법
　　👉 두 객체 중 하나의 강한 참조를 변경해주면 됨
　　👉 강한 참조를 약한(weak) 참조 혹은 미소유(unowned) 참조로 변경하여 문제를 해결
　　　　👉 약한 참조(weak)
　　　　　　👉 인스턴스를 참조할 때 Reference Count를 증가시키지 않음
　　　　　　👉 인스턴스가 메모리에서 할당 해제된 경우, 자동으로 nil이 할당되어 메모리가 해제됨
　　　　　　　　👉 계속 객체를 추적하면서 객체가 사라지게 되면 nil로 자동 초기화
　　　　　　　　　　👉 즉, 무분별한 사용은 곧 런타임 오버헤드를 발생시킴
　　　　　　👉 옵셔널일 때 사용
　　　　👉 미소유 참조(unowned)
　　　　　　👉 인스턴스를 참조할 때 Reference Count를 증가시키지 않음
　　　　　　👉 인스턴스가 메모리에서 할당 해제될 때 nil로 초기화하지 않으며, nil이 되면 에러가 발생
　　　　　　👉 따라서, 에러를 발생하는 것을 방지하기 위해 되도록 약한 참조를 사용하는 것을 권장
　　　　　　👉 혹은, unowned로 가리키는 인스턴스가 먼저 메모리에서 해제될 일이 확실하게 발생하지 않을 때 사용할 것
👋 Link
👋 Link

Closure 강한 순환 참조 🔥

👉 클로저는 클래스의 인스턴스처럼 참조 타입
👉 클래스 인스턴스의 프로퍼티에 클로저를 할당할 때 클로저에 참조를 할당하기 때문에 강한 순환 참조가 발생할 수 있음
👉 클로저의 본문이 인스턴스를 캡쳐(capture)할 때 클로저가 self를 캡쳐하게 되면서 강한 순환 참조가 발생할 수 있음
　　👉 캡쳐
　　　　👉 클로저의 본문에서 인스턴스의 프로퍼티에 접근하거나 인스턴스의 메소드를 호출하는 것
👉 해결 방법
　　👉 클로저 본문의 선언부에서 캡쳐 목록을 정의하는 것으로 해결
　　👉 약한 참조 혹은 미소유 참조로 선언하여 정의
　　　　👉 캡쳐 목록
　　　　　　👉 클로저 본문에서 하나 이상의 참조 타입을 어떤 참조로 캡쳐할 지를 정의하는 리스트
　　　　　　👉 대괄호([]) 키워드를 사용하여 정의

GC(Java) vs ARC(Swift) 🔥

👉 GC 방식은 메모리 관리를 Garbage Collector가 프로그램 실행 중에 동적으로 감시하고 있다가, 더 이상 필요가 없다고 여겨지는 메모리를 삭제하는 방식
　　👉 즉, 키 포인트는 런타임에 동적으로 메모리 관리를 한다는 것
👉 ARC 방식은 메모리 관리를 프로그램이 실행 중에 동적으로 감시하는 것이 아니라, 코드를 빌드할 때 컴파일러가 프로그래머 대신 release 코드를 적절한 위치에 넣어주는 개념
　　👉 즉, 키 포인트는 컴파일 타임에 컴파일러가 메모리 관리를 도와주는 것
👉 런 타임, 컴파일 타임의 차이에서 발생하는 또 다른 차이
　　👉 GC 방식은 항상 메모리를 차지하고 감시해야하기 때문에 프로그램 자체 외에 메모리 사용량이 더 늘어날 수 밖에 없음
　　👉 또한, 지속적인 감시를 위해 CPU를 일부 사용해야만 함
　　👉 이에 비해, ARC 방식은 컴파일러가 대신 처리하는 방식이기에 이런 오버헤드에서 자유로움
　　👉 이는, 메모리와 CPU가 데스크탑에 비해 제한적인 모바일 기기에서 특히 더 중요한 문제이고 그만큼 성능 측면에서 이득
🔥 일반적으로 순환 참조가 메모리 누수로 이어지는 이유는 객체끼리 서로 참조하는데 각 객체로 접근하는 외부 참조가 사라져 이 순환 참조를 제거할 수 없기에 발생하는데, GC는 GC root로부터 reachable한 객체들을 살려놓고 나머지는 모두 해제하는 방식이기에, unreachable한 순환 참조가 발생해도 이는 메모리 누수 문제와 거리가 멈

Cocoa Framework

👉 macOS에서 구동되는 Application을 개발하기 위해 사용하는 통합 프레임워크

Cocoa Touch Framework

👉 iOS, iPadOS 등에서 구동되는 Application을 개발하기 위해 사용하는 통합 프레임워크

Foundation

👉 기본 자료형, 콜렉션 및 데이터 저장 등 앱의 기본적인 기능들을 제공하는 프레임워크

UIKit

👉 iOS 앱을 만들고, UI를 구성하는 데 필수적인 프레임워크
👉 UI 작업은 Main Thread 혹은 Dispatch Main Queue에서만 동작해야 함
　　👉 왜냐하면, UIKit는 Thread-safe 하지 않게 설계되지 않았기 때문
　　　　👉 UIKit과 같은 매우 큰 프레임워크의 모든 속성을 Thread-safe 하게 설계하는 것은 현실적으로 불가능하며, 느려짐과 같은 성능 저하가 발생할 수 있음
　　👉 결론적으로, 애플에서 그렇게 설계하였기 때문에 Main Thread 혹은 Main Queue에서만 동작해야 함
　　🔥 Main Run Loop가 뷰의 업데이트를 관리하는 View Drawing Cycle을 통해 뷰를 동시에 업데이트를 하는 매커니즘으로 설계하여 동작하고 있는데, Main Thread가 아닌 Background Thread가 각자의 Run Loop로 그런 동작을 하게 되었을때, 뷰가 자기 멋대로 동작할 수 있음

GCD(Grand Central Dispatch)

👉 Thread-Safe한 DispatchQueue를 통해 Multi-Threading을 지원하는 기술
　　👉 네트워킹 등 무거운 작업을 메인 스레드에서 실행시키면 앱이 많이 느려질 수 있음
　　👉 즉, 무거운 작업은 백그라운드 스레드에 맡기고 메인 스레드에서는 UI 관련 작업만을 처리하도록 하는 것이 앱에 효율적
👉 DispatchQueue에 작업을 추가하면 GCD는 작업에 맞는 스레드를 자동으로 생성 및 실행하고, 작업이 종료되면 스레드를 제거함
👉 DispatchQueue
　　👉 작업 항목의 실행을 관리하는 객체
👉 메인 스레드에서 DispatchQueue로 작업을 추가하는 2가지 방식
　　👉 sync
　　　　👉 큐에 작업을 추가하고 작업이 종료될 때까지 기다린 후 다음 작업 실행
　　👉 async
　　　　👉 큐에 작업을 추가하고 즉시 다음 작업 실행
　　👉 즉, 작업을 보내는 시점에서 보낸 작업이 끝나는 것을 기다릴지 혹은 말지에 대해 다루는 것
👉 큐의 특성 2가지
　　👉 Serial Queue
　　　　👉 하나의 스레드로만 작업을 분배하는 큐
　　　　👉 순차적으로 하나씩 작업을 실행하여 작업 순서 예측 가능
　　👉 Concurrent Queue
　　　　👉 여러개의 스레드로 작업을 분배하는 큐
　　　　👉 동시적으로 여러 작업을 실행하여 작업이 끝나는 순서를 알 수 없음
👉 실제 DispatchQueue의 종류 3가지
　　👉 MainQueue
　　　　👉 오직 하나만 존재
　　　　👉 Serial 특성을 가짐
　　　　👉 이곳에 할당된 작업은 메인 스레드에서 처리
　　　　　　👉 UI 관련 작업
　　　　🔥 코드 작성 시 별도의 처리가 없으면 모든 작업은 메인 스레드에서 일어남
　　　　　　🔥 모든 작업들이 메인 큐에 할당되는 것과 동일한 의미
　　👉 GlobalQueue
　　　　👉 Concurrent 특성을 가짐
　　　　👉 QoS(Quality Of Service)를 통해 작업의 중요도를 결정할 수 있음
　　　　　　👉 userInteractive : 사용자와 직접 상호작용하는 작업 // UI 업데이트, 애니메이션
　　　　　　　　👉 사용자 액션에 대한 즉각적인 반응이 기대되지만, 이를 메인 스레드에서 처리하면 많은 로드가 걸리는 작업들을 userIneractive에서 처리하여 바로 동작하는 것처럼 보이게 함
　　　　　　👉 userInitiated : 클릭할 때 작업을 수행하는 것과 같은 즉각적인 결과가 필요한 작업 // 저장된 문서 열기
　　　　　　　　👉 But, userIneractive보다 조금 오래걸릴 수 있고 유저가 이를 어느정도 인지하고 있음
　　　　　　👉 default : 일반적인 작업
　　　　　　👉 utility : 보통 progress bar와 함께 길게 실행되는 작업 // 데이터 다운로드
　　　　　　👉 background : 유저가 직접적으로 인지하지 않는 시간이 덜 중요한 작업 // 동기화 및 백업
　　　　　　👉 unspecified : QoS 정보가 없음을 나타냄 // 거의 사용 X
　　👉 CustomQueue
　　　　👉 기본적으로 Serial한 특성을 갖고 있지만, Concurrent로 설정 가능
　　　　👉 Qos 설정 가능

AutoLayout

👉 제약 조건(Constraints)에 따라 뷰의 크기와 위치를 동적으로 지정하는 것
　　👉 제약 조건
　　　　👉 다른 객체를 이용해 상대적인 제약을 주는 것
👉 코드를 이용하여 오토 레이아웃을 작성하는 이유
　　👉 Storyboard 방식은 Build 시간에 악영향을 미침
　　👉 XCode 자체 오류로 인해 Storyboard 내 View Controller가 Inspector 상에 제대로 보이지 않을 수 있음
👉 코드를 이용하여 오토 레이아웃을 작성하는 대표 방법
　　👉 SnapKit
　　　　👉 iOS에서 오토레이아웃을 스토리 보드 없이, 쉽고 간략하게 설정해줄 수 있는 기능을 가진 라이브러리
　　　　👉 snp.makeConstraint를 이용하여 오토레이아웃을 설정
👉 코드로 UI를 작성 시
　　👉 (private) lazy var
　　　　👉 항상 필요하지 않은 인스턴스를 다룰 때 사용
　　👉 (private) let
　　　　👉 항상 보여지게 되는 인스턴스를 다룰 때 사용해도 무방하지만, 되도록 lazy var를 이용하는 것이 좋음
　　　　　　👉 메모리 관리와의 연관성 (필요하지 않은데 let으로 선언하는 경우, 이는 결국 메모리 낭비이므로)

Storyboard

👉 시각적으로 뷰를 확인할 수 있어 오토 레이아웃이나 뷰의 구성을 쉽게 확인하고 수정할 수 있음
👉 But, 뷰의 재사용이 어렵고 화면이 많아지면 프로젝트를 로드하는 속도가 느려짐
👉 And, 협업 시 여러 사람이 스토리보드를 수정하게 되면 쉽게 충돌이 발생함

offset 🆚 inset (Snapkit)

👉 offset
　　👉 주로, element 와의 간격에 사용
　　👉 현재 뷰 constraint = 슈퍼뷰 constraint + offset 값, 보통 bottom과 right는 마이너스 부호를 갖게 됨
👉 inset
　　👉 주로, superView 와의 간격에 사용
　　👉 inset의 경우에는 UIEdgeInsets을 주었다고 생각하면 되기에, bottom과 right가 음수 값이 아니라 양수 값임을 유의

SafeArea

👉 상단의 노치 or 네비게이션 바나 하단의 홈바 or 탭바와 같은 이런 시스템에 의해 가려지지 않고 보여지게 되는 영역
👉 기본적으로 앱이 이 영역들을 침범하지 못하도록 SafeArea를 기준으로 오토레이아웃을 설정

Left(Right) 🆚 Leading(Trailing) Constraint

👉 Left(Right)
　　👉 좌측 및 우측의 제약
👉 Leading(Trailing)
　　👉 Text 시작 및 종료 지점의 제약
　　👉 대부분의 경우, 좌측에서 우측으로 문자가 표현됨
　　👉 아랍권의 경우, 우측에서 좌측으로 문자가 표현됨

(Content) Hugging 🆚 (Compression) Resistance

👉 (Content) Hugging
　　👉 최대 크기 제한 관련 속성
　　👉 hugging의 우선순위가 높을수록 자신의 크기를 유지하고 작을수록 크기가 늘어나게 됨
👉 (Compression) Resistance
　　👉 최소 크기 제한 관련 속성
　　👉 resistance의 우선순위가 높을수록 자신의 크기를 유지하고 작을수록 크기가 작아지게 됨

CustomView 생성 방법

👉 Xib 파일을 만들고 UIView를 상속받는 클래스를 생성해 둘을 연결하는 방법
👉 UIView를 상속받는 클래스를 만들고 코드로 정의해 내부에서 레이아웃까지 설정하는 방법

Autoresizing Mask

👉 Autoresizing mask는 SuperView의 프레임이 변경될 때, SubView의 프레임이 변경되는 방식

Frame 🆚 Bounds

👉 Frame
　　👉 슈퍼뷰의 좌표 시스템에서 뷰의 위치와 크기를 나타냄
　　👉 Frame의 origin은 슈퍼뷰의 원점에서 얼마나 떨어져 있는가를 나타냄
　　👉 Frame의 origin을 변경하면 자신의 위치가 이동
　　👉 Frame의 size는 슈퍼뷰에서 차지하고 있는 크기를 나타냄
　　　　👉 회전된 사각형을 생각
👉 Bounds
　　👉 자신의 좌표 시스템에서 뷰의 위치와 크기를 나타냄
　　👉 Bounds의 origin은 항상 (0, 0)임
　　👉 Bounds의 origin을 변경하면 viewport가 이동하기 때문에 서브뷰들이 이동하는 것 처럼 보이게 됨
　　　　👉 만약, 왼쪽으로 스와이프해서 스크롤하면 bounds의 x좌표가 증가함
　　　　👉 스크롤 뷰는 스크롤 될 때마다 스크롤 뷰의 Bounds를 업데이트하는 방식
　　👉 Bounds의 size는 자신 자체의 크기를 나타냄
👉 이러한 차이로, Frame은 뷰의 위치 및 크기를 설정할 때 사용, Bounds는 뷰의 실제 크기를 알고 싶을 때 사용함

Delegate 🆚 NotificationCenter

👉 객체끼리 데이터를 주고 받기 위해 사용하는 개념
👉 Delegate
　　👉 특정 객체에서 발생한 이벤트를 다른 객체에 전달할 수 있게 해주는 iOS 디자인 패턴
　　👉 프로토콜을 정의하고 대신 처리할 객체에서 이를 채택하고 구현하는 방식
　　👉 객체 간의 참조 타입을 주고받는 Delegate에 따로 처리가 없다면 retain 현상이 일어날 수 있어 weak로 선언하여 retain을 방지해야 함
　　　　👉 retain : 메모리 누수 현상
　　👉 주로 이벤트를 1:1로 전달할 때 많이 사용
　　👉 제 3의 객체를 필요로 하지 X, 확실한 처리 가능
　　👉 많은 양의 코드 필요, 다수의 객체에게 이벤트를 알리고 싶을 경우 비효율적
👉 NotificationCenter
　　👉 앱 내에서 아무데서나 메세지를 보내면 앱 내에서 아무데서나 메시지를 받을 수 있도록 하는 기능
　　👉 싱글톤 객체인 NotificationCenter를 통해 이벤트 발생 내용을 addObserver한 객체들에게 post하는 방식
　　👉 주로 이벤트를 1:N로 전달할 때 용이
　　👉 Delegate 보다 적은 양의 코드 필요, 다수의 객체에게 이벤트를 알리고 싶을 경우 효율적
　　👉 제 3의 객체를 반드시 필요로 함, 확실하게 처리 되었는지 알기 어려움

DataSource 🆚 Delegate

👉 DataSource
　　👉 Data를 받아 View를 그리는 역할을 함
　　👉 대표 관련 func : cellForRowAt, numberOfRowsInSection
👉 Delegate
　　👉 동작을 담당하는 역할을 함
　　👉 대표 관련 func : didSelectRowAt

TableView(CollectionView) DataSource 필수 메소드

👉 numberOfRowsInSection(numberOfItemsInSection)
　　👉 섹션마다 표시할 셀의 개수를 반환
👉 cellForRowAt(cellForItemAt)
　　👉 어떤 셀을 사용할지 반환
👉 code)

func tableView(UITableView, numberOfRowsInSection: Int)
func tableView(UITableView, cellForRowAt: IndexPath)

하나의 View Controller 코드에서 여러 TableView Controller 처리

👉 각 tableview에 따라 처리하도록 구현
👉 code)

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
    // indexPath : tablewView/collectionView의 행을 식별하는 인덱스 경로 : [a, b] 형태 (a : section, b : row/item)
    switch tableView {
    case firstTableView:
        let cell = firstTableView.dequeueReusableCell(withIdentifier: "firstCell") as! UITableViewCell
        cell.textLabel?.text = data1[indexPath.row]
        // indexPath.row : tableView 섹션 내의 를 위치를 식별하는 인덱스 경로
        // + indexPath.item : collectionView 섹션 내의 위치를 식별하는 인덱스 경로
        return cell

    case secondTableView:
        // ...
        
    default:
        return UITableViewCell()
    }
}

TableView 🆚 CollectionView

👉 Cell을 기반으로 여러 데이터를 표현할 수 있는 View
👉 TableView
　　👉 단일 열에 배열된 행을 사용해 데이터를 표시하는 뷰
　　👉 기본적으로 수직 스크롤 만이 가능
　　👉 간단한 목록으로 데이터를 표현할 때 사용할 때 유용
👉 CollectionView
　　👉 커스텀 가능한 레이아웃을 사용해 여러 데이터를 관리하고 표시하는 뷰
　　👉 테이블뷰에서 할 수 있는 기능을 전부 가지고 있으면서 여러 열과 행을 가질 수 있고 수직/수평 스크롤이 모두 가능
　　👉 데이터 표현 방식을 다양한 모습으로 커스터마이징할 때 사용할 때 유용
　　👉 cell의 위치와 배열을 원하는 대로 커스터마이징 할 수 있다는 장점

dequeueReusableCell()

👉 TableView, CollectionView의 셀을 생성할 때 메모리 효율성을 위하여 dequeueReusableCell(withIdentifier:) 메소드를 통해 셀을 재사용함
👉 dequeueReusableCell(withIdentifier:) 메소드는 객체를 반환하기 직전에 prepareForReuse() 메소드가 실행됨
👉 셀을 재사용 하면 이전에 설정한 속성이 그대로 남아있게 되는데, prepareForReuse()를 통해 이전의 속성을 초기화할 수 있음

UICollectionViewFlowLayout

👉 각 섹션의 item, Header, Footer와 같은 것들의 크기를 결정
👉 대표 관련 func : sizeForItemAt, insetForSectionAt

setNeedsDisplay 🆚 setNeedsLayout 🆚 displayIfNeeded 🆚 layoutIfNeeded

👉 setNeedsDisplay()
　　👉 뷰의 컨텐츠를 다시 그리고 싶을 때 호출하는 메소드
　　👉 View가 업데이트되어야 함을 명시적으로 시스템에 알리는 메소드
　　👉 바로 다시 그려지지 않고 다음 업데이트 주기가 되고 draw() 메소드가 자동으로 호출될 때 업데이트됨
👉 setNeedsLayout()
　　👉 뷰의 하위 뷰들의 레이아웃을 조정하고 싶을 때 호출하는 메소드
　　👉 레이아웃이 업데이트되어야 함을 명시적으로 시스템에 알리는 메소드
　　👉 이 메소드를 호출한 뷰는 재계산이 필요한 뷰라고 시스템에게 알려, 이후 update cycle에서 layoutSubviews() 메소드가 호출됨
　　　　👉 layoutSubview()
　　　　　　👉 UIView의 인스턴스 메소드
　　　　　　👉 이 메소드가 호출되면 해당 뷰와 하위 뷰들이 모두 연달아 호출됨
　　　　　　👉 이 메소드는 View의 값이 재계산되어야 하는 적절한 시점에 시스템에 의해 자동으로 호출됨
👉 displayIfNeeded()
　　👉 현재 업데이트가 필요한 것으로 표시된 경우, layer의 업데이트 프로세스를 시작하는 메소드
👉 layoutIfNeeded()
　　👉 즉시 레이아웃의 업데이트를 진행하는 메소드

reloadData()

👉 CollectionView 혹은 TableView의 모든 data를 reload 하는 메소드
👉 CollectionView 혹은 TableView를 한 번에 처음부터 다시 그리므로, 간단하게 코드 작성이 가능하다는 장점이 있지만, 그만큼 비용이 크다는 단점이 있음
　　👉 일부 업데이트 시에는 reloadRows(at:with:)이나 performBatchUpdates(_:completion)을 사용하는 것이 효율적

removeFromSuperview()

👉 해당 뷰와 상위 뷰의 연결을 해제하는 메소드

fatalError()

👉 메시지와 함께 에러를 발생시키며, 실행을 종료시키는 메소드

UI- 관련

👉 UILabel
　　👉 단순히 텍스트를 표시해주는 UI
👉 UISlider
　　👉 드래그(슬라이드)를 지원하는 UI
👉 UIActivityIndicatorView
　　👉 원의 형태로 빙글빙글 돌아가는 UI (로딩)
👉 UITextField
　　👉 텍스트를 편집하기 위한 객체
　　👉 사용자가 클릭하면 키보드가 등장하며 텍스트를 입력 및 수정할 수 있음
　　👉 여러 줄을 사용할 수 없고 한 줄로만 작성이 가능
👉 UITextView
　　👉 텍스트를 여러 줄로 사용하고, 편집하기 위한 객체
　　👉 사용자가 클릭하면 키보드가 등장하며 텍스트를 입력 및 수정할 수 있음
　　👉 Editable 속성을 false로 설정할 경우 편집이 불가능
　　👉 텍스트가 길어지면 자동으로 스크롤 기능을 제공
👉 UIBarButtonItem
　　👉 네비게이션 바 버튼 아이템
👉 UIPageViewController
　　👉 여러 개의 뷰를 옆으로 넘기며 화면 상에 출력할 때 사용하는 View Controller
👉 UIPageControl
　　👉 현재 페이지 위치를 표시해주는 UI (Ooooo / oOooo 같은 UI)
👉 UIActivityViewController
　　👉 내 앱에서 사용하고 있는 표준 서비스들을 다른 앱들에게 제공할 수 있게 해주는 View Controller
　　👉 ex) 공유하기 버튼을 클릭했을 때 출력되는 UI
👉 UIScrollView
　　👉 손가락에 움직임에 따라 화면의 위치가 변하는 View, 확대 및 축소도 가능함
👉 UISearchController
　　👉 SearchBar와의 상호 작용을 기반으로 검색 결과 표시를 관리하는 View Controller
👉 UIRefreshControl
　　👉 TableView 혹은 CollectionView를 포함한 모든 UIScrollView에 붙일 수 있는 표준 컨트롤
　　👉 스크롤이 가능한 뷰에 추가하여 컨텐츠를 새로고침할 수 있도록 함 (아래로 잡아 당기는 방식으로 작동)
👉 UITableViewHeaderFooterView
　　👉 커스텀 헤더 또는 푸터를 구현하기 위해 사용

textView.returnKeyType

👉 키보드의 파란 enter 키 버튼의 동작을 적용하는 속성
　　👉 ex) textView.returnKeyType = .done

view.endEditing(true)

👉 파라미터로 true를 전달할 경우 뷰의 First responder의 상태를 강제로 해제한다는 의미

override func touchesBegan(~)

👉 뷰나 화면에 터치가 일어났을 때 호출되는 메서드

UIImagePickerController

👉 갤러리에 접근하기 위해 사용하는 View Controller
　　👉 반드시 권한을 설정해야 함 // Info.plist; Privacy - Photo Library Usage Description
👉 code)

extension FeedViewController: UIImagePickerControllerDelegate, UINavigationControllerDelegate {
    // UINavigationControllerDelegate : 화면이 전환될 때의 동작을 지원하며, Image Picker에서 사진을 선택하거나, 취소했을 때 다시 원래 사용중이던 뷰로 돌아오는 작업을 처리함
    func imagePickerController(_ picker: UIImagePickerController, didFinishPickingMediaWithInfo info: [UIImagePickerController.InfoKey : Any]) {
        // UIImagePickerControllerDelegate(:didFinishPickingMediaWithInfo) : 사용자가 선택한 사진을 처리하는 메소드
        var selectImage: UIImage?
        
        if let editedImage = info[UIImagePickerController.InfoKey.editedImage] as? UIImage {
            selectImage = editedImage
        } else if let originalImage = info[UIImagePickerController.InfoKey.originalImage] as? UIImage {
            selectImage = originalImage
        }
        
        picker.dismiss(animated: true) { [weak self] in
            let uploadViewController = UploadViewController(uploadImage: selectImage ?? UIImage())
            let navigationController = UINavigationController(rootViewController: uploadViewController)
            navigationController.modalPresentationStyle = .fullScreen
            // modalPresentationStyle: 나타나는 형태 (사이즈st)
            // + modalTransitionStyle: 나타나는 효과 (애니메이션st)
            
            self?.present(navigationController, animated: true)
        }
    }
}

imageView contentMode

👉 UIImageView에 Image를 넣을 때 어떤 비율로 넣을지 정하는 속성
👉 대표 3가지 속성
　　👉 scaleAspectFit
　　　　👉 콘텐츠의 비율을 유지하면서 뷰의 사이즈에 맞게 이미지를 늘리는 옵션으로, 남는 영역은 투명처리
　　👉 scaleAspectFill
　　　　👉 콘텐츠의 비율을 유지하면서 뷰의 사이즈에 맞게 이미지를 꽉 채우는 옵션으로, 이미지의 일부 부분이 잘릴 수 있음
　　👉 scaleToFill
　　　　👉 전체 이미지가 다 나올 수 있도록, 필요 시 비율을 깨트리면서 뷰의 사이즈에 맞게 이미지를 꽉 채우는 옵션

이미지 리터럴(#imageLiteral)

👉 코드 상에서 이미지를 미리 확인할 수 있게 하는 기능

UserNotifications

👉 앱의 푸쉬 알림 기능을 구현하기 위해 사용하는 개념

UserDefaults

👉 기본적으로, 간단하게 많이 사용하는 iOS의 대표적인 저장 기능
👉 앱의 기본 데이터베이스에 영구적으로 데이터를 저장할 수 있는 기능
👉 key와 value 쌍으로 저장
👉 Singleton 패턴으로 설계되어 앱 전체에서 단 하나의 인스턴스만 존재함

PropertyListEncoder().encode & PropertyListDecoder().decode

👉 UserDefaults 관련하여 많이 볼 수 있는 코드
👉 UserDefaults에는 PropertyList만 저장되어야 하며, 그렇지 않으면 에러가 발생
👉 따라서, PropertyListEncoder, PropertyListDecoder 객체를 사용하여 인코딩 및 디코딩을 진행
　　👉 여기서, PropertyList는 plist를 의미

URLSession

👉 URLSession은 네트워크 통신을 제공하는 기본 프레임워크의 클래스
👉 커스터마이징을 할 수 없지만 제한된 기능만을 사용할 경우 유용하게 사용할 수 있음
👉 URLSession은 HTTP 통신과 마찬가지로 Request와 Response 구조를 가지고 있음
　　👉 Request의 두 가지 형태
　　　　👉 URL 인스턴스를 통해 직접 통신하는 형태
　　　　👉 URLRequest 인스턴스를 만들어 옵션을 설정하여 통신하는 형태
　　👉 Response도 두 가지 형태
　　　　👉 설정된 Task의 Completion Handler 형태
　　　　👉 URLSessionDelegate를 통해 지정된 메서드를 호출하는 형태
🔥 URLSession 진행 순서 (5단계)
　　👉 1. URLSessionConfiguration 결정
　　　　👉 default
　　　　　　👉 쿠키와 같은 저장 객체를 사용하는 기본 통신을 할 때 사용
　　　　👉 emphemral
　　　　　　👉 쿠키나 캐시를 저장하지 않는 정책을 사용할 때 이용
　　　　👉 background
　　　　　　👉 앱의 백그라운드에서 컨텐츠를 다운로드/업로드 할 때 사용
　　👉 2. Session 생성
　　　　👉 공유 세션(싱글톤)
　　　　　　👉 기본적인 데이터 전송만을 지원하는 세션
　　　　👉 default 세션
　　　　　　👉 기본적인 Session으로 디스크 기반 캐싱을 지원
　　　　👉 emphemral 세션
　　　　　　👉 어떠한 데이터도 저장하지 않는 형태의 세션
　　　　👉 background 세션
　　　　　　👉 앱이 종료된 이후에도 통신이 이뤄지는 것을 지원하는 세션
　　👉 3. 사용할 Task 결정 후 적절한 Response 메서드 작성
　　　　👉 URLSessionDataTask
　　　　　　👉 기본적인 데이터를 받는 경우 사용
　　　　　　👉 NSData 타입으로 데이터를 내려받기 때문에 로컬 저장소에는 저장하지 않음
　　　　👉 URLSessionUploadTask
　　　　　　👉 파일을 업로드할 때 사용
　　　　👉 URLSessionDownloadTask
　　　　　　👉 실제 파일을 다운받을 시 사용
　　　　　　👉 내려받은 파일은 temp 디렉토리에 저장되며, 따라서 백그라운드 세션을 지원함
　　👉 4. Task 실행
　　👉 5. Task 완료 후 Response 메서드 실행

Alamofire

👉 iOS, macOS를 위한 Swift 기반의 네트워킹 라이브러리
👉 URLSession을 기반으로 하고 있으며, URLSession 방식에 비해 쉽게 데이터에 접근할 수 있고 코드를 가독성이 높게 작성하는 것이 가능
👉 Request & Response 형태의 구조로 이뤄짐
　　👉 Request에 url과 method(get/post/delete/…) 및 파라미터와 헤더 등을 지정
　　👉 Response에 completion handler(@escaping) 코드 작성

KingFisher

👉 iOS에서 이미지를 간편하게 관리할 수 있도록 기능을 제공하는 오픈소스 라이브러리

CoreLocation

👉 기기의 위치, 고도, 방향 등을 알려주는 기능을 가진 프레임워크
👉 CLLocationManager 클래스 객체를 활용하여 CoreLocation 서비스를 구성하고, 시작하고 중지할 수 있으며, 권한을 반드시 받아야 함

MapKit

👉 애플 맵의 이동, 확대 및 축소 등 지도에 관한 여러 기능을 제공하는 프레임워크

DateFormatter

👉 날짜 혹은 문자열을 변환해주는 역할
👉 날짜 형식의 문자열을 Date 타입으로 혹은 Date 타입을 날짜 형식의 문자열로 변환할 때 사용하는 클래스

Test 관련 개념

👉 Why Test?
　　👉 개발자가 작성한 코드가 문제없이 의도한대로 잘 동작하는지 확인하기 위함
👉 XCTest
　　👉 애플에서 제공하는 Test 프레임워크
👉 Unit Test
　　👉 특정 함수의 동작이 문제없이 의도한대로 잘 동작하는지 확인하기 테스트
　　👉 ex code)

import XCTest
@testable import BookReview

class ReviewListPresenterTests: XCTestCase { // 테스트 하고자 하는 클래스에 XCTestCase 클래스를 상속받도록 함
    var sut: ReviewListPresenter! // 테스트 대상
    
    var viewController: MockReviewListViewController!
    var userDefaultsManager: MockUserDefaultsManager! // 테스트를 위한 Mock 생성
    
    override func setUp() { // 테스트 메서드들이 실행될 때마다 실행되는 함수
        super.setUp()
        
        viewController = MockReviewListViewController()
        userDefaultsManager = MockUserDefaultsManager()
        
        sut = ReviewListPresenter(
            viewController: viewController,
            userDefaultsManager: userDefaultsManager
        )
    }
    
    override func tearDown() { // 테스트 메서드들이 끝날 때마다 실행되는 함수
        sut = nil
        viewController = nil
        
        super.tearDown()
    }
    
    // 함수의 이름이 test로 시작한다면 테스트 함수라고 인식하게 되어 테스트 성공 여부를 알려줌  
    func test_viewDidLoad가_호출될_때() { // ReviewListPresenter의 viewDidLoad() 테스트
        sut.viewDidLoad()
        
        XCTAssertTrue(viewController.isCalledSetupNavigationBar)
        XCTAssertTrue(viewController.isCalledSetupViews)
    }
    
    func test_didTapRightBarButtonItem이_호출될_때() { // ReviewListPresenter의 didTapRightBarButtonItem() 테스트
        sut.didTapRightBarButtonItem()
        
        XCTAssertTrue(viewController.isCalledPresentToReviewWriteViewController)
    }
    
    func test_viewWillAppear가_호출될_때() { // ReviewListPresenter의 viewWillAppear() 테스트
        sut.viewWillAppear()
        
        XCTAssertTrue(userDefaultsManager.isCalledGetReviews)
        XCTAssertTrue(viewController.isCalledReloadTableView)
    }
}

final class MockReviewListViewController: ReviewListProtocol {
    var isCalledSetupNavigationBar = false
    var isCalledSetupViews = false
    var isCalledReloadTableView = false
    var isCalledPresentToReviewWriteViewController = false
    
    func setupNavigationBar() {
        isCalledSetupNavigationBar = true
    }
    
    func setupViews() {
        isCalledSetupViews = true
    }
    
    func reloadTableView() {
        isCalledReloadTableView = true
    }
    
    func presentToReviewWriteViewController() {
        isCalledPresentToReviewWriteViewController = true
    }
}

final class MockUserDefaultsManager: UserDefaultsManagerProtocol {
    var isCalledGetReviews = false
    var isCalledSetReview = false
    
    func getReviews() -> [BookReview] {
        isCalledGetReviews = true
        
        return []
    }
    
    func setReview(_ newValue: BookReview) {
        isCalledSetReview = true
    }
}

👉 UI Test
　　👉 UI Components의 표시와 동작이 문제없이 의도한대로 잘 동작하는지 확인하는 테스트
　　👉 ex code)

import XCTest

class MovieReviewUITests: XCTestCase {
    var app: XCUIApplication!
    
    override func setUp() {
        super.setUp()
        
        continueAfterFailure = false
        
        app = XCUIApplication()
        app.launch()
    }
    
    override func tearDown() {
        super.tearDown()
        
        app = nil
    }
    
    func test_navigationBar_title이_영화평점으로_설정되어_있는지() {
        let existNavigationBar = app.navigationBars["영화 평점"].exists
        XCTAssertTrue(existNavigationBar)
    }
    
    func test_searchBar가_존재하는지() {
        let existSearchBar = app.navigationBars["영화 평점"]
            .searchFields["Search"].exists
        XCTAssertTrue(existSearchBar)
    }
    
    func test_searchBar에_CancelButton이_존재하는지() {
        let navigationBar = app.navigationBars["영화 평점"]
        navigationBar.searchFields["Search"].tap()
        
        let existSearchBarCancelButton = navigationBar
            .buttons["Cancel"].exists
        XCTAssertTrue(existSearchBarCancelButton)
    }
    
    enum CellData: String {
        case existsMovie = "큐 볼"
        case nonExistsMovie = "라푼젤"
    }
    
    // BDD
    func test_특정_영화가_즐겨찾기_되어_있는지() {
        let existCell = app.collectionViews
            .cells.containing(.staticText, identifier: CellData.existsMovie.rawValue)
            .element
            .exists
        
        XCTAssertTrue(existCell, "\(CellData.existsMovie.rawValue)이라는 영화가 Cell에 존재합니다.")
    }
    
    func test_특정_영화가_즐겨찾기_되어_있지_않는지() {
        let existCell = app.collectionViews
            .cells.containing(.staticText, identifier: CellData.nonExistsMovie.rawValue)
            .element
            .exists
        
        XCTAssertFalse(existCell, "\(CellData.nonExistsMovie.rawValue)이라는 영화가 Cell에 존재하지 않습니다.")
    }
}

👉 Test Coverage(Code Coverage)
　　👉 프로젝트에서 몇 퍼센트의 코드에 대해서 테스트가 작성되어 있는지를 나타냄
　　👉 이를 통해, 테스트를 진행할 때 코드의 어떠한 부분이 테스트되었고, 테스트되지 않았는지를 알 수 있음
👉 Test 관련 라이브러리
　　👉 Nimble(lib), Stubber(lib)

BDD(Behavior Driven Development)

👉 시나리오를 기반으로 테스트 케이스를 작성하는 테스트 방법
👉 테스트 작성 구조(진행 흐름)
　　👉 Given(어떠한 상태에서) > When(어떠한 것이 실행될 때) > Then(어떤게 발생한다)
👉 ex)

func test_searchBar_textDidChange가_호출될_때_request가_성공하면() {
    movieSearchManager.needToSuccessRequest = true
    sut.searchBar(UISearchBar(), textDidChange: "")
        
    XCTAssertTrue(
        viewController.isCalledUpdateSearchTableView,
        "updateSearchTableView가 실행된다."
    )
}
    
func test_searchBar_textDidChange가_호출될_때_request가_실패하면() {
    movieSearchManager.needToSuccessRequest = false
    sut.searchBar(UISearchBar(), textDidChange: "")
        
    XCTAssertFalse(
        viewController.isCalledUpdateSearchTableView,
        "updateSearchTableView가 실행되지 않는다."
    )
}

의존성 주입

👉 어떠한 클래스에서 다른 클래스를 사용할 때 의존성이 생김
👉 필요한 객체를 직접 생성하는 것이 아닌 외부로부터 객체를 생성하여 주입 받아(생성자) 사용하는 것
　　👉 단순히 주입하는 것으로 끝나는 것이 아니라, 프로토콜을 이용하여 의존성을 분리한 것까지가 의존성 주입
　　👉 객체 간 의존성을 줄일 수 있으며, 유닛 테스트 및 유지 보수가 용이하다는 장점이 있음
　　　　👉 유지 보수가 용이하다 : (일반적으로)코드의 가독성이 높아지고, 재사용성이 높아진다는 뜻
👉 ex) Before DI

struct Eat {
    func coffee() {
        print("아메리카노")
    }

    func meal() {
        print("피자")
    }
}

struct Person {
    var todayEat: Eat
    // Eat에 변경이 생기면 Person도 변경해야 함
    
    func coffee() {
        todayEat.coffee()
    }
    
    func meal() {
        todayEat.meal()
    }
}

👉 ex) After DI

protocol Menu {
    func printCoffee()
    func printMeal()
}

class Eat: Menu {
    var coffee: String
    var meal: String
    
    init(coffee: String, meal: String) {
        self.coffee = coffee
        self.meal = meal
    }
    
    func printCoffee() {
        print("아메리카노")
    }
    
    func printMeal() {
        print("피자")
    }
}

struct Person {
    var todayEat: Menu
    
    func printCoffee() {
        todayEat.printCoffee()
    }
    
    func printMeal() {
        todayEat.printMeal()
    }
    
    mutating func changeMenu(menu: Menu) { // 의존성 주입
        self.todayEat = menu
    }
}

let menu1 = Eat(coffee: "아메리카노", meal: "피자")
let menu2 = Eat(coffee: "라떼", meal: "햄버거")

var kid = Person(todayEat: menu1)
kid.printCoffee() // 아메리카노
kid.printMeal() // 피자

kid.changeMenu(menu: menu2)
kid.printCoffee() // 라떼
kid.printMeal() // 햄버거

Nib 🆚 Xib

👉 Nib, Xib는 기능적으로는 동일하지만, Nib는 binary 기반이며, Xib는 xml 기반
　　👉 공통점 : 앱 개발에서 인터페이스 구성을 위해 사용되는 파일 형식
👉 Xib는 xml 기반의 플랫 파일이기에 소스 제어 관리 시스템에서 보다 쉽게 처리 가능
　　👉 플랫 파일 : 간단히 데이터를 저장하는 텍스트 파일
👉 추가적으로, iOS의 UI를 구성하는 대표적인 세 가지 방법으로 Storyboard & Xib(인터페이스 빌더) + Code가 있음
👉 인터페이스 빌더로 만드는 모든 UI 구성요소는 Xib 파일 형태로 만들어지며, 컴파일 시 바이너리 형태인 Nib 파일로 바뀌게 됨

Info.plist

👉 앱 구성에 관한 필수 설정 정보가 포함되어 있는 구조화된 텍스트 파일
👉 key와 value로 구성된 dictionary 형태, key 값을 이용하여 앱의 설정을 가져옴

Localization

👉 앱에 다양한 언어를 지원하는 것

Method Swizzling

👉 런타임 시점에 기존에 있는 메서드를 다른 메서드로 바꾸어 실행하는 것
👉 이미 정해진 iOS의 특정 메소드가 실행될 때, 해당 메서드 대신 다른 메서드가 실행되도록 바꾸는 것

App thinning

👉 앱이 설치될 때 디바이스의 특성에 맞게 앱을 설치하는 최적화 기술
👉 기술 요소 3가지
　　👉 슬라이싱
　　　　👉 앱이 지원하는 여러 디바이스에 대해 각각의 번들을 생성해놓고, 사용자의 디바이스에 가장 적합한 번들을 전달하는 기술
　　👉 주문형 리소스
　　　　👉 앱을 설치할 때 당장 필요한 기능만을 다운로드하고, 추후 사용자가 필요로 할 경우 다운로드하는 방식
　　👉 비트코드
　　　　👉 앱스토어에 앱을 올릴 때 바이너리 파일을 업로드 하는 것 아니라, 그 전 단계인 비트코드를 업로드 하는 방식
　　　　👉 비트코드를 사용해 업로드를 진행하면 Apple 측에서 이를 재컴파일하여 App binary를 생성
　　　　　　👉 비트코드를 사용하면 필요에 따라 재컴파일하게 되므로 그 때 최적화가 가능해짐
　　　　　　👉 비트코드를 사용하지 않으면 모든 디바이스 케이스를 바이너리로 생성하여 fat binary를 업로드

💚 Additional

Segueway

👉 화면 전환용 객체
👉 Storyboard에서 출발지와 목적지를 직접 지정하는 방식

@IBDesignable 🆚 @IBInspectable

👉 @IBDesignable
　　👉 스토리 보드에서 실시간으로 확인이 가능하게 만드는 키워드
👉 @IBInspectable
　　👉 스토리 보드에서 해당 프로퍼티 설정 값을 변경 시킬 수 있게 만드는 키워드

실제 디바이스 🆚 시뮬레이터

👉 시뮬레이터에서는 카메라, 마이크, 전화, 센서를 사용할 수 X
👉 Apple의 푸시 알림 받기와 보내기 기능을 지원하지 X
👉 Mac과 iPhone의 성능 차이로 CPU, memory에서 차이가 O
👉 앱 백그라운드 전환, 터치, 다크모드 등 기본적인 기능은 시뮬레이터에서도 가능

App Bundle

👉 실행 가능한 코드와 리소스를 한 공간에 묶는 디렉터리 모음
👉 애플리케이션을 실행시키기 위한 모든 것들이 저장되어 있음
👉 실행 파일, 앱 아이콘, Info.plist, 리소스 등이 포함되어 있음

테마 설정(일반/다크모드)

👉 Color Asset에 Any, Dark, Light을 모두 설정하면 모드에 맞게 설정한 색이 화면에 출력됨
👉 window의 backgroundColor를 systemBackground로 설정하여 기기 테마의 설정을 따르도록 구현 가능

*****

iOS Computer Science of iOS