Android ART(Android Runtime)에 대해서 알아보자 1편

당시 구글에서 안드로이드에 JVM이 아닌 DVM이 선택된 이유중 라이센스 문제 외에도 몇가지 이유가 있었다.

메모리 관리: DVM은 JVM과는 다른 메모리 관리 방식을 사용한다. JVM은 스택 기반 메모리 할당을 사용하고, DVM은 레지스터 기반 메모리 할당을 사용하여 안드로이드 기기의 한정된 리소스를 효율적으로 활용할 수 있기 때문에 모바일 환경에서 제일 중요했던 배터리 절약이 가능했다.
최적화: 안드로이드는 대부분의 기기에서 사용되는 모바일 플랫폼이기 때문에, 성능과 배터리 수명을 최적화하는 것이 중요했으며, 당시 DVM은 이러한 요구사항에 맞게 최적화 되어있었다.
DEX 바이트코드: DVM은 안드로이드 앱을 위해 바이트 코드로 변환 하는 과정을 거치는 DEX 파일 형식을 사용한다. 이는 앱의 용량을 더 작은 크기로 압축이 가능하다.
범용성: 당시 안드로이드 기기들은 다양항 아키텍처와 하드웨어를 사용했으며, DVM은 크로스 플랫폼 호환성을 지원하여 다양한 기기에서 실행되도록 할 수 있었다.

[인사이드 안드로이드 OS 159p 中]

모바일 디바이스에서 가장 중요한 리소스는 배터리다. 전력 소비를 줄이는 것이 Dalvik의 궁극적 목표였다.

레지스터 기반의 가상 아키텍처는 가상머신이 실행되는 타깃 하드웨어의 아키텍처와 훨씬 더 잘 매치되기 때문에 레지스터 기반 VM을 대상으로 하는 컴파일러는 타깃 하드웨어를 위해 미리 최적화를 할 수 있도록 컴파일러가 산출하는 실행 파일을 더 잘 준비할 수 있다.

이런 이유로 고성능 JVM에서는 필수인, 전력을 많이 소비하는 JIT 최적화가 DVM에서는 덜 중요했으며, 초기 안드로이드 버전에서 DVM은 JIT 최적화가 아예 없었다.

[결론]

달빅은 저사양 기기에서 눈꼽만큼의 성능까지 사용하기 위해 스택 기반이 아닌 레지스터 기반으로 설계했다고함.

ART는 안드로이드 4.4(KitKat)에서 실험적인 런타임 환경으로 처음 도입되었으며, Android 5.0(Lollipop)에서는 Dalvik에서 ART로 완전히 대체되었다.

ART 시스템은 DVM이 사용했던 DEX 바이트 코드를 그대로 사용하며, DVM에서 실행됐던 대부분의 프로그램은 ART 환경에서도 코드 수정 없이 실행 가능하다.

DVM의 JIT 최적화의 단점은 런타임 시점에서 컴파일되어 리소스를 많이 차지하기 때문에 배터리 소모가 심각 했었나보다. (잼민이 시절 베가레이서2를 첫 스마트폰으로 사용했었는데 배터리 수명이 미친듯이 짧았던게 기억난다.)

이러한 이유로 구글은 DVM의 JIT 전략과 차별화를 위해 새로운 AOT(Ahead-Of-Time)라는 용어를 만들어 냈다.

DEX 중간 언어로 컴파일된 앱을 디바이스에 설치된 특정 시점에 dex2oat라는 툴을 사용해서 네이티브 코드로 변환함을 의미한다. 이 전략은 중간 언어(Java/Kotlin)의 핵심 목표인 이식성을 보장한다.

ART는 AOT(ahead-of-time) 컴파일을 사용하며 Android 7.0(Nougat)부터는 AOT, JIT(just-in-time) 컴파일, 프로필 기반 컴파일을 조합하여 사용한다.

이러한 모든 컴파일 모드의 조합은 구성가능 하며 공식 문서에서 확인 할 수 있다.

Android 7.0부터는 JIT + AOT 방식을 조합하여 사용하며, 처음 설치할 때 JIT 방식으로 빠르게 설치한 후 자주 사용되는 앱은 기기 미사용 상태나 충전 중일 때 컴파일 데몬이 실행되어 조금씩 컴파일 하여 AOT 방식으로 바꾸도록 한다.

두 방식에 대해서 간단히 말하면 다음과 같다.

JIT

AOT