1. Dynamic Framework와 Static Framework의 차이
두 개의 차이는 "컴파일된 코드를 참조하는 방식"에 있습니다. Dynamic framework는 라이브러리에 대한 참조만 포함하고, Static Framework는 라이브러리 코드가 모두 포함되어 있습니다.
Dynamic Framework
장점:
- Framework 내에 이미지나 뷰같은 리소스 파일 혹은 Bundle을 Embeded 할 수 있음
- 링크를 참조하기에 Static Framework에 비해 메모리가 자유로움.
- 빌드 속도가 단축
단점:
- 디버그시 필요한 dSYM 파일을 프레임워크 개발자가 제공해야함
- Static Framework에 비해 런타임상 속도가 느림
Static Framework
장점:
- 앱 실행파일에 직접 링크되어 있어 런타임상 속도가 빠름
- 참조가 아닌 코드가 복사되기에 안정적
단점:
- 메모리를 Dynamic Framework에 비해 더 차지
1-1. 해당 프로젝트에서 Dynamic Framework를 활용해서 개발한 이유
요약: static framework는 컴파일 타임에 라이브러리의 코드가 실행 파일에 포함되는 방식으로 동작하는데, Static Framework를 여러 모듈에서 사용하면, 각 모듈이 static framework를 컴파일하는 과정에서 같은 이름의 함수나 변수를 사용하는 경우, 이름 충돌이 생길 수 있다. 결과적으로 이름 충돌을 피하기 위해서 각 모듈에서 사용되는 함수나 변수의 이름을 고유하게 만들거나, Static Framework 말고 Dynamic Framework를 사용하면 되는 일이다. 그러나 첫번째 방법은 현실적으로 어렵기 때문에 Dynamic framework를 사용하는 것이다.
긴 설명: static framework는 앱을 빌드하면 static linker(라이브러리와 앱의 소스코드 파일을 병합(merge)하는 것을 link라 한다.)를 통해 static library 코드가 앱 바이너리 합쳐져 내로 들어가 Heap 메모리에 저장된다. 이 말은 라이브러리의 코드 자체가 복사되어서 들어간다는 뜻이고, static framework를 여러 framework에서 사용할 경우 코드 중복이 생기게 된다.
dynamic framework는 컴파일된 코드가 앱의 바이너리에 포함되지 않는다. Static linker를 통해 합쳐지는 코드는 dynamic framework의 reference이다. 따라서, link는 됐지만, 라이브러리의 코드 자체는 복사가 되지 않는다. 결과적으로, dynamic framework는 동시에 여러 모듈에서 사용해도, 동일한 코드 사본을 공유하고 사용한다.
‘mangled name’은 함수나 변수의 이름을 컴파일 타임에 고유한 식별자로 변환하는 것을 말한다. 이를 통해 같은 이름의 함수나 변수가 서로 충돌하지 않도록 보장하고, 함수 오버로딩 같은 기능을 지원한다.
‘demangle’은 mangle된 이름을 읽기 쉬운 형태로 변환하는 과정을 의미한다. swift에서 함수나 변수 이름은 컴파일러에 의해 mangle 되어 저장되는데, 이러한 mangled 이름은 일반적으로 사람이 읽기 어렵기 때문에 디버깅에 문제가 될 수 있다. 따라서, ‘demangle’은 mangeld 한 이름을 원래의 의미있는 이름으로 복원하는 것을 말한다.
이것이 static framework에서 문제가 되는 이유는 static framework는 컴파일 타임에 라이브러리의 코드가 실행 파일에 포함되는 방식으로 동작하는데, 이때 여러 모듈에서 같은 라이브러리를 사용는 경우에는 라이브러리 코드가 중복해서 포함될 수 있다. 따라서, static framework을 여러 모듈에서 사용하면, 각 모듈이 static framework을 컴파일하는 과정에서 같은 이름의 함수나 변수를 사용하는 경우, 이름 충돌이 발생할 수 있다. 결과적으로 “failed to demangle superclass of ‘…’ from mangled name ‘…’”란 에러를 를 뱉게 된다. 해당 에러는 특정 모듈들이 사용한 서드파티의 클래스, 함수, 변수의 mangled된 이름이 모듈마다 다르게 해석되기 때문에 발생할 수 있는 것.
결과적으로, 여러 모듈에서 static framework을 사용하는 경우, 이름 충돌을 피하기 위해 각 모듈에서 사용되는 함수나 변수의 이름을 고유하게 만들거나, static framework을 사용하지 않고 dynamic framework을 사용하는 것이 좋다. 하지만 각 모듈에서 사용되는 서드 파티의 함수나 변수의 이름을 고유하게 만드는 것은 현실적으로 어렵기 때문에 dynamic framework로 서드 파티를 관리하는 것이 속편하다. 구구절절 말했지만 결론은 dynamic framework은 코드 사본을 만들지 않고 모든 모듈이 동일한 코드 사본을 공유하고 사용하기 때문에, 충돌이 발생하지 않는다.
2. 모듈화를 했을 때 빌드 시간 단축이 발생하는 이유
모듈화로 나누어져 있으면 변경된 모듈(프레임워크)에 대해서만 빌드가 진행되기 때문에, 빌드 속도가 증가하는 효과를 가져올 수 있다.
2-1. 한 두개의 프레임워크가 아닌 프로젝트 내 모든 프레임워크가 변경되었을 때 모듈화를 한 프로젝트와 모듈화를 하지 않은 프로젝트의 빌드 속도 차이
개인적인 생각으로는 비슷하거나 오히려 모듈화된 프로젝트가 조금 더 빌드시간이 오래 걸릴 수도 있을 거 같다고 예상된다.
iOS에서 빌드 속도에 영향을 줄 수 있는 요소에는 3가지가 있다.
- 코드에 의한 영향
- 빌드 환경에 의한 영향
- 빌드 자동화에 의한 영향
진행한 프로젝트에서 모듈화 전과 후를 비교해봤을 때 달라진 부분이 있다면 1번 요소라고 생각한다.
코드에 의한 영향은 다음과 같다.
- 프로퍼티 선언시 var보다는 let을 사용
- 타입을 명시: 타입 추론 안하도록
- 타이트한 접근제어자
- 상속이나 오버라이딩이 필요없는 클래스나 프로퍼티에 final 사용
- Method Inlining final이나 private으로 선언된 메소드나 프로퍼티는, 컴파일 시간에 static하게 처리되기에, 런타임에 주소 탐색 시간을 절약하여 성능에 큰 도움을 준다.
- 가능한 참조타입보다 값 타입을 사용
- 비트 연산자. 오버플로 연산자를 사용하면 오버플로 체크 시간을 아낄 수 있다.
이 중 나머지 코드는 대부분 비슷하지만 3번 타이트한 접근제어자 부분에 있어서 모듈화로 인해 불가피하게 public으로 선언된 접근 제어자들이 존재한다. 그렇기 때문에 만약 모든 모듈이 변경된다면 하나의 모듈과 똑같이 모든 모듈에 대해 빌드가 발생할 것이고, 모듈화에서는 public으로 선언된 부분이 존재하기 때문에 빌드 시간이 더 걸릴 수도 있지 않을까라고 생각한다.
3. App은 Data프레임워크를 의존하고, Data프레임워크는 Domain프레임워크을 의존하고 있는 상태이다. 그런데 App은 Domain 프레임워크에도 의존하고 있다. App이 Data 프레임워크를 활용해 Domain 프레임워크에 접근할 수도 있을텐데, 그렇지 않고 직접적으로 App이 Domain을 의존하도록 설계한 이유
개인적인 생각으로는 App이 Domain을 직접 의존하던 하지 않던 결국은 Presentation, Domain, Data 프레임워크에 의존하고 있음. 따라서 app이 domain을 직접 의존하던 하지 않던 결합도가 낮아지는 일은 발생하지 않을 것이라 판단. 그렇다면 사용성 측면에서 살펴봤을 때 App에서 의존성 주입시 직접 의존하는 것이 사용성이 더 좋기 때문에 해당 방법으로 설계.
4. 현업에서 모듈 사용방법
현재 진행한 모듈화는 계층별로 모듈화를 진행했다. 아직 계층별로 모듈화까지만 진행했기 때문에 장점이 나타나지 않았다고 생각한다. 만약 세부적으로 더 모듈화를 진행했다면, 특정 역할(network, Custom UI)을 수행하는 모듈들이 존재했을 것이다.
가장 작은 단위의 모듈은 앞서 말한 Custom UI, Network를 수행하는 모듈정도가 있다. 그리고 가장 작은 모듈들을 활용해 특정 도메인 서비스를 관리하는 프로젝트 단위의 모듈들이 이를 활용할 것이다. 그리고 이러한 각 서비스를 호출하고 연결하는 모듈이 존재하고, 이를 app에서 실행하면 되는 구조일 것으로 예상한다.
'회고' 카테고리의 다른 글
[회고] 8개월차 iOS 개발자 2023년 회고 (6) | 2023.12.25 |
---|---|
[회고] - 신입 iOS 개발자 4개월차 회고 (2) | 2023.08.13 |
[회고] 신입 iOS 개발자 1개월간 회고 (0) | 2023.05.17 |
iOS 신입 개발자 이력서 및 면접 준비 회고 (13) | 2023.04.11 |
[SwiftUI] - 쉽고(택배 조회 서비스) 회고 (4) | 2023.02.24 |