[Android] 컴파일 과정 (Dalvik vs ART)

안드로이드 컴파일 방식은 크게 2가지로 나뉘는데, 그 2가지는 초창기에 사용한 Dalvik 컴파일 방식과 이후에 도입된 ART 컴파일 방식이다. 이번 포스팅에서는 컴파일 방식이 안드로이드 버전에 따라 어떻게 변화해 왔는지 알아보면서 컴파일 방식의 차이점도 함께 정리해보려고 한다.

 

---

 

안드로이드 개발 언어가 운영체제에 독립적인 Java로 채택이 되면서 JVM이 필요했다.

하지만 라이센스 문제와 메모리 효율성 등의 문제로 안드로이드는 Dalvik VM(=DVM)을 사용하게 된다.

 

라이센스 문제

• Java ME를 사용하기 위해서 Sun 회사에게 라이센스 비용을 지불해야하는 문제가 발생했다.

  (DVM에서 컴파일 과정 중 .class를 .dex로 변환하는 dx 툴은 Java SE를 사용했기 때문에 Java 언어 사용은 문제되지 않았다.)

메모리 효율성

• JVM은 스택 기반 모델로 많은 메모리를 요구하지만 DVM은 레지스터 기반 모델로 적은 메모리에 최적화 되어 있다. (JVM에 비해 명령이 단순하고 처리 속도가 빠르기 때문)

• 여러 개 VM 인스턴스를 실행할 수 있고, 프로세스 독립성, 메모리 관리 & 스레딩을 지원한다.

• 참고로, 스택 기반 모델과 레지스터 기반 모델의 차이는 [안드로이드] JVM의 스택 기반 모델과 DVM의 레지스터 기반 모델 차이점에서 확인할 수 있다.

 

 

 

 

Dalvik VM과 Java VM의 컴파일 과정 비교

• DVM과 JVM은 모두 JIT(=Just In Time) 컴파일러를 사용해 기계어로 번역한다.

• JVM에서는 .jar 파일을 기계어로 번역할 수 있기 때문에 .class 파일을 .jar 파일로 번역하는 작업이 필요한 것 처럼

  DVM에서는 .dex 파일을 기계어로 번역할 수 있기 때문에 .class 파일을 .dex 파일로 번역하는 작업이 필요하다.

  (.class 파일을 .dex 파일로 번역하는 작업은 Android SDK에 포함되어 있는 dx 툴을 이용한다.)

 

 

 

 

 

Dalvik VM의 컴파일 방식

위에서 말했듯이 Dalvik VM의 컴파일 방식은 JIT(=Just In Time) 방식이다. 

• 이 방식은 앱 구동 중에 실시간으로 컴파일(기계어 번역)을 하기 때문에 설치 시 속도가 빠르지만 실행 시에 느리다는 단점이 있었다. 또한 번역한 정보를 메모리에 올려서 메모리 부하가 컸다.

• 그러다가 안드로이드 2.2 (Froyo) 버전 이후 Trace JIT 방식을 사용한다.

 

Trace JIT 방식은 프로그램 실행 시 자주 사용 되는 부분의 바이트 코드를 기계어로 미리 해석하는 것이다. 그리고 번역 결과를 traslation cache에 저장하고, 실행 중에 translation cache를 확인해서 번역본이 존재하면 가져다 사용하고 없으면 바로 번역 후 translation cache에 저장하면서 컴파일을 한다. 이렇게 translation cache를 활용하면서 실행 성능을 어느정도 향상시킬 수 있었다.

 

 

 

 

 

ART(=Android Runtime)의 컴파일 방식

ART는 기계어로 해석된 앱을 실행시키기 위해 런타임 시 사용되는 라이브러리로, Android Kitkat 버전에서 처음 등장하여 Android 5.0 Lollipop 버전 이후 무조건 ART를 적용하였다. Dalvik VM의 JIT 컴파일 방식의 단점을 보완하기 위해 만들어졌다.

 

ART는 컴파일 시 AOT(=Ahead Of Time) 방식을 사용한다. 

• 설치 시에 컴파일을 하기 때문에 설치 속도가 느리지만 실행 속도가 빠르고 실행 도중에 컴파일 하지 않아 CPU 사용이 줄어 배터리 수명이 향상되었다.

• 번역 정보를 파일에 저장하기 때문에 설치 용량이 많이 필요해진다.

• 설치 시점에 기계어 번역을 완료하기 때문에 인터프리터 방식을 사용하는 Dalvik VM이 필요 없어졌다.

 

+ 컴파일러와 인터프리터 차이

Compiler: 런타임 전에 컴파일 수행

    - 빠른 실행 속도, 플랫폼 종속적, 디스크 공간 활용

      ex) C, C++, C#, Java, …

 

Interpreter: 런타임 시 컴파일 수행

    - 비교적 실행속도 느림, 코드 변경 즉시 실행 가능

      ex) javascript, python, html, SQL, …

 

 

 

아래 그림은 ART가 동작하는 방식을 도식화 한 것이다. 설치 시 AOT 컴파일러가 실행되고 ART 라이브러리를 이용해 기계어 코드로 번역 한다.

 

 

 

 

 

DVM vs ART - dex 파일의 기계어 코드로의 변경 과정

DVM과 ART는 모두 설치 후 .dex 파일을 기계어 코드로 번역한다. 이 과정에서 어떤 차이가 있는지 그림으로 알아보자.

 

 

Dalvik 방식에서는 .dex 파일을 dexopt 툴을 이용해 .odex 파일로 변형한 뒤 DVM에서 JIT 컴파일러로 .odex 파일을 기계어로 번역한다.

ART 방식에서는 .dex 파일을 dex2oat 툴을 이용해 .dex -> .odex -> .oat 파일로 변형한 뒤 OAT 컴파일러로 .oat 파일을 기계어로 번역한다.

 

• .odex 파일은 optimized dex 파일의 약자로 특정 기기에 최적화된 코드로 다른 기기에서 사용할 수 없는 특징을 가진다.

• .oat 파일은 .dex 파일 + .odex 파일 + elf 파일(실행 파일) 형식의 기계어를 포함하고 있기 때문에 용량이 크다.

 

 

 

 

ART = JIT + AOT

Android Nugat 버전 이후에는 ART에 AOT와 더불어 JIT 컴파일러까지 탑재했다. 

설치 시에는 JIT 방식으로 설치 용량을 줄이고 설치 속도를 높였고, 차후에 상황에 따라 각 방식을 유연하게 적용하면서 AOT의 단점을 해결했다.

 

 

 

 

정리

마지막으로 DVM과 ART를 비교하는 표를 통해 각 특징을 정리해 보자.

	컴파일러	실행	GC 알고리즘	설치속도	실행속도	배터리	디스크
Dalvik	JIT	dex, odex	CMS	빠름	느림	많이 소모	적게 필요
ART	AOT	oat (art)	Customized CMS	느림	빠름	적게 소모	많이 필요

ART에서 사용하는 GC 알고리즘인 Customized CMS 방식은 Dalvik에서 사용하는 CMS 알고리즘에 비해 2배 이상의 성능을 낸다고 한다.

ART의 GC인 Customized CMS에 대한 내용은 [안드로이드] Dalvik과 ART의 GC 비교 글에 정리해 두었다.

 

 

 

 

 

 

 

 

[참고한 사이트]

• 안드로이드 Dalvik & ART (1/2)
• 안드로이드 Dalvik & ART (2/2)