하이 D:)veloper

최근 스레드를 통해 정말 많은 자극을 받고 있는 딜라이트룸 iOS 개발자 리디님. 다양한 개발 스토리를 들으면서 나도 나중에 내실 있는 나만의 앱을 만들고 싶다는 꿈이 점점 커지고 있다. 이 글에서는 리디님이 연사로서 SwiftRise 컨퍼런스에서도 소개해주셨고 내 프로젝트에도 적용해 볼 만한 것이어서 공부해 보면서 구현했던 부분을 공유해보려 한다. 사실 컨퍼런스에서는 도입한 도구나 구체적 구현 방법을 자세히 설명해 주셨다기보다 왜 이런 자동화 시스템을 구축했었어야 했는지에 대해 사고의 변화와 점진적인 디벨롭 과정에 대해 충분히 납득할 수 있게 설명해 주셔서 더 기억에 남았던 듯싶다! 결과적으로 우리는 iOS 개발자이기 이전에 product developer이기에 이런 자동화 도구나 AI를 잘 활용해서 ..

메모리 캐싱에 대한 내용을 작성하고 거의 반년만에 쓰는 이미지 캐싱에 대한 내용입니다.. :) 틀린 내용이 있을 수도 있으니 언제든 피드백 주세요! [Swift] iOS의 메모리 캐시 NSCache | NSMutableDictionary객체와의 차이점, NSCopying, 깊은복사/얕은복사 캐싱에 대한 내용을 늦게 다시 쓰는 만큼 디스크 캐싱 & Etag기반으로 서버와 리소스 동기화 체크 & instruments로 로딩 속도 분석에 내용까지 함께 작성해보려 한다. 이번을 계기로 OSLog의 os_signpost를 사용해서 instruments를 통해 성능을 테스트해 보았고 실제 이미지 로드 속도가 얼마나 나아질 수 있는지에 대한 실질적인 지표를 보아서 의미 있었다.그리고 앞으로는 이렇게 정량적 지표를 근..

> 뷰의 성능 개선 시리즈[SwiftUI] 뷰의 성능 개선(1) - Dependency 관리[SwiftUI] 뷰의 성능 개선(2) - 뷰의 slow update 개선[SwiftUI] 뷰의 성능 개선(3) -Identifier의 중요성  이번 글은 뷰 성능 개선 (1), (3) 보다는 간단한 글이 될 것 같다. 근데 실제 프로젝트에 대한 성능을 개선할 때 고려해야 할 점을 언급한 부분이 있어서 작성해 본다.   첫 번째 성능 개선 글에서는 dependency와 뷰의 업데이트 "횟수"에 초점을 맞췄다면, 이 글에서는 뷰가 업데이트 될 때 사용되는 비용을 줄여 "속도"를 개선하는 것에 초점이 있다.  📍 반응성 저하(reduced responsiveness)뷰가 느리게 업데이트 되는 것이 어떤 문제가 있길래..

> 뷰의 성능 개선 시리즈[SwiftUI] 뷰의 성능 개선(1) - Dependency 관리[SwiftUI] 뷰의 성능 개선(2) - 뷰의 slow update 개선[SwiftUI] 뷰의 성능 개선(3) -Identifier의 중요성   함께 공부하는 분께 SwiftUI를 선호하는지 UIKit를 선호하는지 여쭤본 적이 있다. 그분의 대답은 “SwiftUI보다 UIKit를 더 선호한다. SwiftUI는 데이터에 따라 뷰가 재 렌더링 되는 것을 관리하기 까다로운 것 같다” 이었다. 나는 어떨까 생각해 보니 성능적인 것보다는 뷰를 만들기 직관적이고 쉽다는 측면으로 SwiftUI를 선호했던 것 같다. 그래서 최근에 SwiftUI 뷰에 대한 최적화 방법은 무엇이 있을까 여러 방면으로 공부해 보고 테스트해 보았다...

왜 SwiftUI에서는 some View를 사용해서 뷰를 그려요? some 키워드가 Opaque Type에서 사용되고 Opaque Type에 대한 개념도 어느 정도 알고 있지만, 어느 날 문득 왜 SwiftUI에서는 any View도 아니고 some View로 뷰에 대한 타입을 리턴 받아 사용하는 걸까 궁금했다.    이렇게 some 키워드로 나타내는 타입을 Opaque Type이라고 하는데, 불명확 타입이라고도 불리며, 역제네릭 타입으로도 불린다. 왜 불명확 혹은 역제네릭 타입으로 불리는지 Opaque Type에 대해 살펴보고, 왜 SwiftUI에서 뷰를 그릴 때는 some View 처럼 Opaque Type을 사용하는지에 대해서도 알아보자!    📍Generic 왜 Opaque Type 알아본다고 ..

some과 any를 공부하다 보니 any라는 키워드가 등장한 이유가 궁금해졌다.궁금증이 의식의 흐름처럼 생기는 편.. ㅎㅎ  any 키워드에 대해서 공부하다보니 Existential type 이라는 것까지 공부하게 되었는데 Existential type의 특성과 함께 swift 5.6에서 any 키워드가 등장한 이유에 대해서도 알게되어 흥미로워 글을 적는다. Swift를 공부하면서 Existential 이라는 단어는 Existential Container 공부할 때 밖에 못 봤는데 (프로토콜 타입의 인스턴스를 저장하는 방법에 대한 내용) 역시나 이번에도 프로토콜에 관련한 내용이었다. Existential Container 에 대한 내용이 궁금하다면 아래 블로그 글로!프로토콜 채택한 구조체 Existent..

ReactiveX를 공부하다 보면 한 번쯤은 만나게 되는 개념 Hot&Cold Observable, 문서에서도 Observable설명하는 부분에서 대문짝만하게 적어놓은 걸 보니 중요한 개념인 듯싶어서 공부해 보았다!  단순하다면 단순한 개념이지만, ReactiveX에서 등장하는 다른 개념들과 복합적으로 생각하다 보면 이게 이해가 잘 된 건가.. 싶어서 보고 또 보고 해서 이해하는데 며칠이 걸렸다면 믿으시겠습니까.. https://reactivex.io/documentation/observable.html ReactiveX - ObservableObservable In ReactiveX an observer subscribes to an Observable. Then that observer reacts ..

RxSwift는 사용하다 보면 참 편리한 아이인 것 같다. 반응형으로 사용자의 이벤트를 구독하고 방출된 이벤트를 관찰하고 있다가 처리해주다 보니 MVVM 패턴과도 찰떡인 게 사용하면서 체감된다. 하지만 우리가 이벤트를 방출할 때 사용해주는 Observable이 편리하긴 하지만 여러 곳에서 구독을 할 경우 유의해주어야 할 점이 있는데 이것에 대해 알아보자! ReactiveX를 공부할 때 반드시 알아야할 multicast, unicast 개념과도 연결되니 꼭 알고 넘어가기로!       📍 Observable Stream 우리는 이미 Observable를 여러번 구독할 수 있다는 것을 알고 있는데... 근데 이렇게 여러번 구독하게 되면 각각 구독하는 시점에 Observable stream이 새롭게 생긴다...

저번 글에서 이미지를 업로드하는 여러 가지 방법에 대해 살펴봤다면, 이번 글에서는 그 이미지들을 메모리 차원에서 캐싱해 놓고 재사용해줄 수 있는 방법에 대해 정리해보려 합니다!  그리고 사실 공부하면서 메모리 캐싱까지만 정리하고 만족하려고 했지만 ㅎㅎ  스터디 함께하시는 분이 흥미로운 키워드를 던져주셔서 다음 글에서는 디스크 캐싱까지 정리해보려 합니다. 어떤 키워드인지는 디스크 캐싱 글에서 공개!        📍 Cache캐시란?캐시..캐싱...이미지 캐싱... 많이는 들어봤는데 일단 Cache의 의미가 무엇인지부터 제대로 알아보시죠.캐시(cache)는 데이터나 값을 미리 복사해 놓는 임시 장소를 뜻한다캐시에 데이터를 미리 복사해 놓으면 계산이나 접근 시간 없이 더 빠른 속도로 데이터에 접근할 수 있기..

이미지를 로드하는 방법에는 매우 여러 가지가 있다.Asset 카탈로그에 추가해서 불러오는 경우도 있겠지만, 대게는 원격 저장소에 저장되어 있는 이미지에 대해 url을 사용하여 이미지를 로드시켜야 할 것이다.  아직 그 많은 방법들을 다 경험해보지는 못했지만, 이번 글에서는 크게 세 가지를 방법을 소개하고자한다!1) 라이브러리를 사용하는 방법(Kingfisher)2) Data(contentsOf:)를 사용하는 방법3) URLSession, Alamofire을 사용하는 방법  왜 하필 이 세 가지 방법을 소개하는가? 하면..이미지가 대량으로 뜨는 작은 프로젝트를 만들었는데 이미지를 로드하는 코드에 대해  위의 세 가지 방법으로 점진적으로 리팩토링을 하며 느낀 점이 많기 때문 ..!!! 나의 블로그 글은 지극..