iOS

FlexLayoutFlexLayout은 UIStackView에서 발전한 레이아웃 방법으로, 사용하기 쉬우면서 성능이 우수한 라이브러리입니다.flex container라는 부모 컨테이너 안에 flex items라는 자식들을 포함시켜 item을 정렬하는 구조입니다. 특징Flexbox의 레이아웃 잡는 방식은 간단하고 빠름main axis와 cross axis를 바탕으로 정렬 방향이 정의되며, direction을 통해 정의됨Creation, modification, definition of flexbox itemsaddItem(:UIView) → FlexUIView를 subview로 추가한 뒤, flexbox를 사용 가능하게 만듦define(_ closure: (_ flex: Flex) -> Void)flexb..

PinLayout“No Auto layout constraints attached” PinLayout은 오토 레이아웃을 사용하지 않고, 뷰의 레이아웃을 수동으로 정의하는 라이브러리로, UIStackView, 오토 레이아웃보다 뷰의 렌더링 속도가 훨씬 빠른 레이아웃 방식입니다.특징문법적으로 간결함addSubview까지 진행해야 함수동으로 레이아웃 (오토 레이아웃에 의존하지 않음)그렇다고 둘을 같이 쓰면 안되는 것은 아님Full Control기기, traitCollection, animation에 따른 조건문, 반복문 추가 가능간단하고 빠르게 동작하기 위해 존재함StatelessUIView에 저장 프로퍼티를 추가하지 않고, view의 frame 프로퍼티를 계산Stateless하기 때문에 다른 프레임워크와 충..

배경NumberFormatter는 생성 비용이 크고 내부 상태를 가지기 때문에, 멀티스레드 환경에서 공유할 경우 성능 최적화와 함께 스레드 안정성도 중요한 고려사항입니다.이번 실험에서는 os_unfair_lock, Mutex(NSLock), RecursiveLock, SpinLock 등 여러 락 기법을 사용해 NumberFormatter를 공유했을 때의 실행 시간, CPU 효율, 메모리 사용량을 측정하여 가장 효율적인 방법을 분석하였습니다. 성능 측정 지표 정의Clock Time실제 경과 시간 (사용자가 체감하는 대기 시간)CPU Time모든 스레드의 CPU 연산 총합CPU 활용도CPU Time ÷ Clock Time × 100 (멀티코어 활용도 지표)Memory Peak프로그램 실행 중 가장 많이 사용..

배경이전 포스팅에서 10개 스레드로 NumberFormatter 성능을 테스트했지만, 최적의 스레드 수에 대한 의문이 남았습니다.이번에는 1개부터 8개까지 체계적으로 측정하여 진짜 최적점을 찾아보았습니다. 또한 Clock Time 뿐만 아니라 Memory Peak 등에 대해서도 고려했습니다. 테스트 환경하드웨어: MacBook Pro M1 (4P + 4E 코어)측정: XCTest measure() 100,000번 반복메트릭: Clock Time, CPU Time, Memory Peak조건: 모든 테스트에서 동일한 NumberFormatter 설정 성능 테스트 결과방식스레드Clock Time (초)CPU Time (초)CPU 효율Memory Peak (KB)성능 향상매번 생성1개4.1214.09899.4%..

Optimistic UIOptimistic UI는 사용자 경험을 개선하기 위한 중요한 프론트엔드 패턴으로, 이에 대해 학습하고자 작성하게 되었습니다.Optimistic UI는 서버 응답을 기다리지 않고 사용자의 액션이 성공할 것이라고 "낙관적으로 가정"하여 UI를 즉시 업데이트하는 방법입니다. 예를 들어 ‘좋아요’ 버튼을 클릭하면 서버 응답을 기다리지 않고 바로 하트가 채워지는 것이 있습니다. 장단점Optimistic UI를 적용한다면 즉각적인 피드백을 기반으로 사용자는 클릭과 동시에 결과를 볼 수 있게 되어 앱의 반응성이 좋다는 느낌을 줄 수 있는데, 이는 결과적으로 사용자 경험을 크게 향상시킵니다.하지만 구현을 하기 위해선 적절한 에러 처리와 상태 관리를 해야하기 때문에 구현의 복잡도는 증가합니다...

검증NumberterKit이 그럼 기존의 Race Condition 문제를 해결했는지와 실제로 성능은 어느정도 개선되었는지에 대해 분석하였습니다. 테스트 케이스를 통한 검증앞서 수동 테스트로 동작을 확인했지만,신뢰할 수 있는 결과를 보장하기 위해 XCTestCase를 통한 자동화 테스트도 함께 진행하였습니다.다음과 같이 Race Condition 재현 테스트를 테스트 케이스로 등록하여,매번 일관된 결과가 출력되는지 검증했습니다.import XCTestfinal class FormatterProviderTests: XCTestCase { func testDecimalFormatterRaceSafe() { let number = NSNumber(value: 1234.5678) ..

NumberFormatter()를 개발하던 도중, static Formatter 공유 방식이 멀티스레드 환경에서 Race Condition을 유발한다는 테스트 결과를 확인하였습니다. 이번 개선에서는 해당 테스트를 동일하게 반복 실행하여,SpinLock 동기화 적용 전후의 차이를 직접 검증하였습니다. 결과적으로, SpinLock을 적용한 이후에는 설정 충돌 없이 일관된 결과가 출력됨을 확인할 수 있었습니다. 공용 NumberForamtter() 인스턴스 접근앞선 블로그에서 작성했듯이, 다음과 같은 문제점이 발생하였습니다.public extension Decimal { func formatted(fractionDigits: Int) -> String { FormatterProvider.d..

데이터 변환의 불편함iOS 앱을 개발하다 보면 숫자를 문자열로 변환하거나, 통화 및 퍼센트로 표시하는 등의 작업을 반복적으로 하게 됩니다. 저 또한 최근에 개발한 프로젝트가 가상 화폐와 관련된 프로젝트였기 때문에 Int64, Decimal 등의 데이터 타입의 변환이 빈번하게 발생하였습니다. 보통 이런 상황에서 Extension이나 Formatter와 관련된 폴더 및 파일을 생성하고 관리합니다.하지만 이러한 처리 로직이 프로젝트마다 다르게 작성되고, formatter 설정 방식도 일관되지 않다 보니 유지보수가 어려워지는 문제를 겪게 되었습니다. 특히, 같은 Decimal 타입이라도 어떤 화면에서는 소수점 없이, 어떤 화면에서는 소수점 둘째 자리까지 표현해야 하는 상황이 빈번하게 발생하였고, 이에 따른 fo..