iOS

이미지 렌더링 최적화 — Downsampling앞서 살펴본 것처럼 iOS에서 이미지는 다음 과정을 거쳐 화면에 표시됩니다.Image Load↓UIImage 생성↓UIImageView에 설정↓Layer Tree Commit↓Display Preparation (Decode)↓GPU Texture Upload↓Core Animation Compositing↓Framebuffer↓Display이 과정에서 가장 비용이 큰 단계는 Decode 단계입니다.압축된 JPEG / PNG 이미지는 이 단계에서 RGBA Bitmap으로 변환됩니다. 예를 들어 다음과 같은 이미지가 있다고 가정해보겠습니다.파일 크기 : 590KB해상도 : 2048 × 1536 디코딩이 발생하면 메모리 사용량은 다음과 같습니다.2048 × 15..

Load → Decode → Render590KB의 이미지가 있고, 2048 * 1536의 해상도를 가진다고 가정Load이미지를 메모리에 로드590KB 파일을 메모리로 불러옴Decode로딩한 이미지 파일을 GPU가 렌더링 할 수 있는 포맷으로 변환이 과정에서 대략 10MB 크기의 데이터가 됨이미지는 바이너리 데이터이기 때문에 인코딩 된 상태였기 때문에, 디코딩 단계가 필요Render디코딩 된 이미지를 화면에 렌더링 하는 단계 iOS 이미지 렌더링 과정iOS에서 네트워크 이미지를 화면에 표시할 때, 단순히 imageView.image = image 한 줄로 끝나는 것처럼 보이지만 실제로는 내부적으로 여러 단계의 렌더링 파이프라인이 실행됩니다.핵심 흐름은 다음과 같습니다.Image Load↓UIImage ..

iOS에서의 기본 개념: Point vs Pixel개념설명PointiOS 레이아웃 단위 (AutoLayout, UIView frame)Pixel실제 디스플레이 픽셀iOS는 레이아웃을 Point 기준으로 설계하지만, 실제 화면은 Pixel 단위로 그려집니다. 이때 등장하는 것이 Scale Factor입니다. Retina Display의 Scale Factor디바이스ScaleNon-Retina1xRetina2xSuper Retina3x 예를 들어UIImageView.frame = 100 x 100 pt실제 렌더링 픽셀은 다음과 같습니다.Scale실제 픽셀1x100 × 100 px2x200 × 200 px3x300 × 300 px즉보이는 크기 = 100pt실제 렌더링 이미지 = 200px 또는 300px UI..

이전에 FlexLayout과 PinLayout에 대해 간단히 정리해보았었는데, 이번 글에서는 '왜 더 빠른지'에 대해 초점을 맞춰 글을 작성해보고자 합니다.성능의 핵심인 레이아웃 엔진의 수학적 차이와 그 대안인 FlexLayout, PinLayout에 대해 깊게 파헤쳐 보겠습니다. 1. Auto Layout의 심장: Cassowary 알고리즘의 한계Apple이 채택한 Auto Layout은 Cassowary(카소와리)라는 선형 방정식(Linear Equation)를 기반으로 합니다. | 수학적 메커니즘: "방정식을 푸는 수학자" Auto Layout에 제약을 추가하는 것은 시스템에 다음과 같은 연립 부등식을 던져주는 것과 같습니다. ViewA.leading = ViewB.trailing + 10 View..

Demystify SwiftUI - Dependency종속성(Dependency)은 SwiftUI가 언제, 그리고 왜 UI를 업데이트해야 하는지 이해하는 방식입니다. 이는 앱의 성능과 정확성에 직결됩니다.종속성이란 뷰의 입력값(input)으로, 종속성이 변경되면 뷰는 새로운 body를 생성합니다. 여기서 입력값은 @State, @Binding, 프로퍼티 등이 있고, 이 값들이 변경되면 뷰는 다시 그려집니다.body는 뷰의 계층 구조를 만드는 곳이고, 이 뷰의 게층 구조를 더 깊이 보면, 액션(action)이 있는 버튼이 있습니다. 액션은 뷰의 종속성에 변경을 일으킵니다. SwiftUI의 뷰 계층은 단순한 트리 구조가 아니라 ‘그래프’ 구조입니다. 왜냐하면 여러 뷰가 하나의 동일한 데이터 소스에 의존할 수..

Demystify SwiftUI - LifetimeLifetime(수명)은 SwiftUI가 뷰와 데이터의 존재에 대해 추적하는 방법으로, 뷰의 identity(정체성)가 유지되는 기간을 의미입니다. 하지만 여기서의 뷰의 수명은 struct의 자체의 수명이 아닙니다. View value와 Identity의 차이영상에서는 고양이에 비유하여 View의 Value와 Identity에 대해 설명합니다.뷰의 값 (Value) - "고양이의 순간적인 사진"body 프로퍼티가 실행될 때마다 생성되는 struct 인스턴스입니다.이것은 "졸고 있는 테세우스", "놀고 있는 테세우스"처럼 순간을 포착한 사진과 같습니다.SwiftUI는 이 '사진'을 이전 '사진'과 비교하여 변경 사항이 있는지 확인한 다음, 바로 버립니다. ..

Source of TruthUIKit과 SwiftUI의 차이점 중 가장 중요한 부분 중 하나는 SoT(Source of Truth)라고 생각합니다. UIKit에서는 데이터와 UI의 상태를 개발자가 직접 일치시켜줘야 했습니다. 하지만 이 과정에서 실수가 발생하면 데이터와 UI가 서로 다른 상태를 가지는 불일치 문제가 생기고, 이는 예측하기 어려운 버그의 원인이 되었습니다.하지만 SwiftUI에선 SoT라는 개념을 통해 이러한 문제를 해결하였습니다. SoT는 데이터의 일관성과 정확성을 유지하는 중요한 개념으로, 데이터는 오직 한 곳에서만 관리되고, 모든 UI는 해당 데이터를 바라보며 자신(뷰)을 그립니다. 즉, 데이터가 변경되면 UI는 자동으로 변경되기 때문에, 데이터 불일치 문제가 차단되고, 코드 구조가 ..

MVVM의 한계점RxSwift + MVVM을 기반으로 프로젝트를 진행하면서 MVVM의 비즈니스 로직을 더욱 분리하는 방법에 대해 고민하게 되었습니다. 그 중 뷰를 생성하고 이동하는 flow logic과 business logic이 모두 ViewModel에 정의되어 있었는데, 이러한 부분은 단일 책임 원칙을 위배한다고 생각하였고, 이를 분리하는 Coordinator 패턴에 대해 학습하게 되었습니다.