Static Framework & Dynamic Framework (feat. Library)
안녕하세요. 그린입니다🟢
이번 포스팅에서는 Framework에 대해서 static과 dynamic으로 나눠 학습해보겠습니다💁🏻
우선 Framework에 대해 짚어보고 갈께요.
Framework?
프레임워크라 함은 frame + work의 합성어입니다.
즉 직역해보자면 "일하는 틀"이라고 볼 수 있어요.
당연히 이렇게만 설명하면 이게뭐야.. 하겠죠?
다시 말해보면 프레임워크라는건 주어진 요소 그리고 규칙으로 원하는걸 구현하는 틀이라고 생각하면 됩니다.
조금 더 프로그래밍적 관점에서 바라볼께요.
Xcode로 개발하다보면 한 프로젝트 타겟에 많은것들 넣기보다 따로 프레임워크나 라이브러리로 빼서 모듈화를 진행합니다.
즉 여기서 모듈화로 별도로 빼서 가져와 사용한다는것은 이 별도 뺀 모듈의 규칙에 따라 프로그램을 만드는걸 뜻합니다.
정의하자면 어떤걸 만드는데 있어 가이드북인 셈입니다.
이걸 우리는 프레임워크라 부릅니다.
그럼 여기서 나온 왜 모듈화를 해야할까요?
모듈화를 할 수록 빌드 속도는 개선됩니다.
또한 모듈 단위로 테스트를 할 수 있음으로 단위 테스트에도 적합합니다.
Framework vs Library의 개념
위에서 말한 프레임워크와 비슷한 개념으로 라이브러리를 말했습니다.
그럼 둘의 차이는 도대체 뭘까요?
개념적으로 보면 우선 프레임워크는 위에서 말한것처럼 프로그램을 만드는데 주어지는 가이드북인셈입니다.
즉 그 가이드에서 정의된 규칙을 따라야하죠.
또한 여러 요소들도 제공해줍니다.
예를들어 에셋, nib 파일 등등을 제공해주고 이를 사용합니다.
그리고 이 요소들과 위의 가이드 규칙을 꼭 지켜서 만들어야합니다.
반면 라이브러리는 도구 모음이라 보면 됩니다.
위와 다르게 우리가 프로그램을 만드는데 쓰면 좋을것들, 편한것들을 가져와 사용하는 도구 같은겁니다.
프로그램 제작에 있어 나의 일을 조금 더 쉽게 해주는것이라고 볼 수 있습니다.
그럼 예시로 들어볼께요.
자동차를 만들어야 한다고 칩니다.
그때 우리는 자동차를 만드는 프레임워크를 따릅니다.
바퀴와 핸들, 모터가 들어가고 이는 차를 구성하는데 프레임워크에서 제공되는 요소이며 따라야할 가이드입니다.
이를 따라서는 꼭 만들어야 자동차가되죠.
그런데 프레임워크가 없이 만든다면 어려울것이고 매번 같은 자동차를 만드는걸 보장할 수 없습니다.
그리고 라이브러리는 여기서 용접도구, 컴프레스 같은 기계입니다.
당연히 손으로도 만들 수 있겠지만 더 빠르고 편안하게 만들 수 있도록 도와주는 기계일뿐입니다.
이렇게 예시를 드니 이해가 좀 더 쉽네요🙌
Framework vs Library의 공통점과 차이점
그럼 위에서 연결되어 공통점과 차이점을 알아보죠!
공통점은 둘다 프로그램을 만드는데 도움을 준다는것입니다.
가이드북이나 도구나 모두 우리가 프로그램을 만드는데 있어 더욱 편리하고 빠르게 만들 수 있도록 제공해주죠.
그렇다면 차이점은 따라야하는지에 대한 필수제약입니다.
프레임워크를 쓴다면 꼭 그 가이드를 따라야하며 라이브러리를 쓸때는 원할때 원하는 도구를 쓰면 되죠.
즉 프레임워크는 꼭 써야되고 지켜야할 규칙이 있어 따르는 대신 자유롭지 못하고 라이브러리는 자유롭죠.
이 차이가 있습니다.
Framework vs Library의 구성 차이
그렇다면 이 두가지를 구성하는것에서는 어떤 차이가 있을까요?
우선 프레임워크는 계층이 있는 디렉토리입니다.
동시에 shared resource, 공유자원 (dynamic library를 포함한 nib, image assets)를 가집니다.
다시 원점으로와 둘의 구성 차이는 번들 즉 에셋의 유무입니다.
에셋이라함은 위에 말한 우리가 흔히 알고 있는 그 에셋(이미지 등 각종 파일이 들어가는)로 볼 수 있습니다.
결국 이렇게 정리해볼 수 있습니다.
Framework = Library + Asset(Bundle)
Static Framework?
그러면 이제 Framework에서 static과 dynamic이 뭔지 살펴보죠.
우선 Static Framework가 뭔지 살펴보겠습니다.
다이나믹 프레임워크와 다르게 정적으로 연결되어 있습니다.
즉 빌드 시 링킹이 되어 있습니다.
Static Linker를 통해 힙 메모리 영역에 들어갑니다.
즉 복사가 이뤄지기에 해당 프레임워크를 여러 타겟에서 사용하면 빌드 시 중복 에러가 발생합니다.
Static Framework가 많을 수록 빌드 시간은 높아지고 런타임 시 해야될 수행 시간은 적어집니다.
쉽게 말하자면 초기에 모든걸 다 고정으로 두고 가는겁니다.
SDK의 형태를 가진다면 이 설정으로 하는것이 좋습니다.
Dynamic Framework?
엑코에서 기본으로 프레임워크 생성하면 다이나믹으로 설정됩니다.
쉽게 말해 동적으로 연결되있는겁니다.
즉 앱을 런타임하고 사용 시 Dynamic하게 링크해줍니다.
application executable file(실행파일) 안에 들어가게 되죠.
앱이 런타임 시에 불러오고 다이나믹이 필요한 모듈들을 링커 즉 이어줍니다.
즉 Dynamic Linking이 되죠.
정리하면 빌드 시간을 줄이고 앱 내에서 런타임 시 해당 프레임워크가 사용되는 부분에서 연결하여 사용하게 됩니다.
빌드 시간은 낮아지고 실행 시간은 높아집니다.
전체적인 에셋 등의 소스를 가진다면 이 설정을 하는것이 좋습니다.
Mach-O Type?
위에서 말한 Static과 Dynamic의 차이를 변경하고 싶다면 Mach-O Type(마하 오 타입 뭐 이렇게 읽던데.. 왜 마하인지..)를 변경하면됩니다.
아래와 같이 해당 프레임워크 타겟 빌드 설정에서 변경할 수 있습니다.
Embed vs Do Not Embed?
마지막으로 임베드와 두낫임베드에 대해 알아보겠습니다.
그전에 다들 타겟에서 필요한 프레임워크를 만들고 추가할때 General 탭에서 이러한걸 본적이 있을겁니다.
자 많이 보셨죠?
여기서 임베드와 두낫임베드를 보는겁니다.
우선 임베드는 이 프레임워크를 앱에 넣어라는 뜻입니다.
반면 두낫임베디는 앱에 이 프레임워크를 넣지말라는 뜻이구요.
패키지가 프레임워크로 불리는 폴더를 포함하는지의 여부입니다.
위에서 말한 다이나믹한것은 런타임에 의존되는데 만약 두낫임베드로 하게되면 런타임에서
이 프레임워크가 필요할때 호출해도 없으니 에러가 납니다.
반면 Static한것은 이미 빌드 시 넣어줬기에 두낫임베드를해야합니다.
다시 임베드하는것은 중복입니다.
프레임워크를 두낫임베드하면 ipa에 포함하지 않습니다.
아래 참고 레퍼런스에서 이런 좋은 비교표가 있습니다.
권장되는것은 Dynamic Library는 Embed, Static Library는 Do Not Embed입니다.
예외되는 상황이라면 만약 Static Library가 미디어 번들에 접근한다면 런타임 전에 이미 이를 가져야하니 Embed해야합니다.
마무리
이렇게 오늘은 조금 딥한 개념에 대해 다뤄봤습니다.
정말 코딩하는것보다 이런 세세한 세팅과 개념을 알아가는것이 매우 어렵군요🤔
그래도 쭉 개발자로 산다면 언젠가 마주쳐야할 부분이기에 이참에 완벽하진 않지만 개념은 잡고 가게되었습니다.
아..! 왜 이걸 학습하게되었냐면 AppStore에 테스트플라이트로 빌드를 올릴때 중복 Embed에러가 발생해서 이를 알아보다
여기까지 왔네요🥲
다음번에도 이런 비슷한걸 가져오겠습니다🙌
[참고자료]
https://holyswift.app/frameworks-embed-or-not-embed-thats-the-question