[iOS] Static/Dynamic Library

Library

 

Xcode Target의 일부로 빌드되지 않은 코드 및 데이터 조각을 정의한 것.

라이브러리는 다른 프로젝트에서 재사용 할 수 있는 코드 및 리소스 모음을 나타낸다. 여기에는 특정 기능을 제공하거나 일반적인 프로그램이 문제를 해결하는 미리 작성된 함수, 클래스 및 기타 구성 요소가 포함되어있다.

 

단순히 코드 및 데이터 조각을 정의했고 이걸 내 앱 코드에 가져다 쓰고싶다.

 

라이브러리와 앱의 소스코드 파일을 병합(merge)하는 프로세스를 Link라고 한다.

 

라이브러리는 앱에 Link되는 방식에 따라 두 가지로 나뉘게 된다.

 

• Static Library - ".a" 접미사를 가진다
• Dynamic Library - "dylib" 접미사를 가진다

 

Static Library

Static Library는 빨간색 네모의 Static Libraries에 위치하게된다.

 

Static Library를 가져다 쓰려면 라이브러리와 앱의 소스코드 파일을 병합(Merge)하는 Link작업이 필요하다.

이 때 Static linker를 사용해  앱의 Source files와 Static Libraries를 merge하게된다.

 

Linker는 input으로 object파일, Libraries(.dylib, .tbd, .a)파일을 받게된다. 

이 파일들을 받아서 단일 파일로 결합해주는 역할을 한다.

 

보통 link과정은 컴파일 마지막에 일어나기 때문에

 

linker는 excutable file을 생성한다고 보면 된다.

 

앱의 소스코드는 excutable file 내부에 복사되게된다.

그리고 static libraries코드 역시 excutable file에 복사된다.

 

static library가 excutable file의 일부가 되기 때문에 앱이 실행되면 앱 소스코드 + static library코드를 포함하는 것들이 앱의 주소공간에 로드된다.

 

다시 종합해보자면 

1. 앱에 static library를 추가한다.

2. 컴파일 타임에 Static linker가 library코드 + 앱코드를 merge하고

3. 단일 excutable file을 만든다.

4. 앱이 실행되면 library코드 + 앱코드가 앱 주소공간에 로드된다.

 

여기서 추측해볼 수 있는것

1. 많은 static library를 앱에 link하면 큰 executable file이 생성된다.

excutable file 내부에 static library코드가 복사되기 떄문이다.

 

2. 큰 executable file은 느린 시작시간(launch time) + 큰 메모리공간을 가져간다.

 

3. static library가 업데이트되면 클라이언트 앱은 개발자가 업데이트된 library와 다시 link하지 않는 이상 업데이트된 기능을 사용할 수 없다.

 

Static Library의 종합적인 문제점

static library가 많아질수록 큰 excutable file이 만들어지고, 새 버전이 나오면 또 다시 컴파일해서 Link해줘야한다.

 

여기서 나온 개념이 Dynamic Library이다.

 

Dynamic Library

Dynamic Library역시 library이고 library는 Xcode target의 일부가 아닌 코드 및 데이터 조각을 정의하는 파일이다.

 

Dynamic Library역시 Link프로세스를 거쳐야 한다.

 

하지만 결과물이 Static Library와 조금 다르다.

linker에 의해 만들어진 executable file에 library코드가 모두 포함됐던 static과 달리,

Dynamic library에 대한 참조만 executable file에 포함된다.

 

참조만 포함된다는 말이 어려워서 알아보니 executable file에 dynamic library에서 제공하는 함수, 변수, 리소스 등 찾고 사용하는 방법에 대한 정보는 포함되어 있지만 실제 구현 코드는 포함되어있지 않음을 의미한다고 한다.

 

 

executable file과 Link됐지만 복사가 안됐다는 점이 가장 중요하다.

 

즉 exectable file의 크기가 Static에 비해 작다.

 

이로써 library코드가 executable file에 포함이 되어 executable file이 비대해진다는 점은 해결됐다.

 

근데 Library코드를 써야하는데 참조만 가지고 어떻게 사용하는가?

 

Dynamic library는 앱이 실행될 때 앱 주소 공간에 로드된다.

 

1. 앱을 실행함

2. 앱 코드 + Dynamic library에 대한 참조가 앱 주소공간에 로드된다.

3. 참조를 이용해 Dynamic library를 로드한다.

 

그렇다면 "3. 참조를 이용해 Dynamic library를 로드한다" 에서 사용하는 Dynamic Library가 많다면 Library를 가져오는데 시간이 많이 걸릴것이라는 생각을 해볼 수 있다.

 

Static Library의 특징으로는

큰 excutable file은 느린 시작시간 + 큰 메모리공간을 가져간다.

 

그에 비해 Dynamic library의 특징으로는

static에 비해서 작은 executable file이 만들어 지지만 dynamic library를 로드하는 시간이 있고 그만큼 launch time이 오래 걸리게 된다.

 

 

또한 Static library는 Static Library가 업데이트되면 클리아이언트 앱은 개발자가 업데이트된 library와 다시 Link하지 않는 이상 업데이트된 기능을 사용할 수 없다. 

였는데, Dynamic Library는 그렇지 않기 때문에 다시 컴파일하지 않고도 업데이트된 기능을 사용할 수 있게 된다.

 

모든 iOS, macOS 시스템 라이브러리는 Dynamic이다.

 

+ 추가적으로 Dynamic Library에대한 이해가 부족하다고 생각돼서 알아본 내용입니다.

 

Dynamic Library의 executable 파일에는 Dynamic library에 정의된 기능 및 리소스에 대한 place holder역할을 하는 symbol, identifier가 포함되어있다.이런 것들은 라이브러리에서 필요한 구성요소의 이름과 위치를 지정한다. 런타임에 운영체제의 linker는 이런 참조를 이용하여 Dynamic Library에서 해당 file을 찾아 메모리에 load하게 된다.

 

참조만을 포함하므로 executable file은 전체 라이브러리 코드를 포함하지 않기 때문에 Static 링크에 비해 크기가 더 작게 유지된다. 이를 통해 시스템 리소스를 보다 효율적으로 사용할 수 있고 여러 실행파일이 동일한 Dynamic Library를 공유할 수 있는 모듈식 개발, 배포가 용이해진다.