quotation
Dalvik과 ART의 차이
quotation
Android Reverse Engineering
quotation
Angular의 컴파일 (JIT vs AOT)
quotation
달빅과 ART, JIT 컴파일러와 AOT컴파일러
quotation
안드로이드 롤리팝 개발 따라잡기
quotation
안드로이드 런타임
quotation
안드로이드 런타임 - Dalvik & ART


  • Dalvik은 JIT "Just In Time" 방식으로 코드를 사용할 때 컴파일하는 반면에
  • ART는 AOT "Ahead Of Time" 방식으로 코드를 컴파일 해놓고 사용하는 방식
  • So. 실행 시 컴파일 해서 사용하는 Dalvik은 실행 시간 및 성능에서 단점을 갖고
  • 반면에 ART는 실행 시간과 성능에서 장점을 가짐.
  • 반대로 설치 시간에서는 ART가 단점을 가진다고 볼 수 있음


  • Dalvik과 ART 둘 다 원래 상태는 dex 
  • 설치 가능한 파일엔 항상 dex file을 가지고 있음 
  • odex file은 de-odexed 해야 함 (inlined code 최적화 해제)
  • oat file은 odex/dex file을 포함하고 있음.
  • dex 파일을 oat 밖으로 꺼낼 수 있음


JIT 컴파일이란?

JIT(Just In Time)은 실제 앱이 브라우저에서 실행되는 순간 코드에 대해 컴파일을 진행한다.

  1. 사용자가 브라우저에 접속하면 (컴파일러를 포함한) 소스코드를 로드하고
  2. 로드된 소스코드는 실제 실행되기 직전에 컴파일을 진행
  3. 실행 직전에 컴파일을 하기 때문에 에러를 미리 발견하지 못함 (=사용중 에러 발생하여 앱 사용 불가능한 상황이 나타남)
소스코드에 컴파일러가 포함되어 있기 때문에 용량이 더 크고, 소스코드가 실행되기 전에 컴파일을 진행하기 때문에 사용자가 기다려야 하는 시간이 있음


AOT 컴파일이란?

AOT(Ahead Of Time)은 앱이 실행되기 전에 (정확히는 배포되기 전에) 미리 '브라우저에서 바로 실행 가능하도록' 컴파일을 한다.

  1. 사용자가 브라우저에 접속하면 (컴파일러를 제외한) 소스코드를 로드하고
  2. 로드된 소스코드는 추가 컴파일 작업 없이 바로 실행 가능

이미 컴파일된 상태이기 때문에, 소스코드에 컴파일러가 포함되지 않는다. 따라서 소스코드의 용량이 대폭 줄어들고, 뿐만 아니라 사용자가 기다려야 하는 시간이 거의 없다고 볼 수 있다.


그럼 AOT가 무조건 좋은건가?

AOT 컴파일러도 단점은 있다. 앱 설치하면 공간을 1.5배에서 2배 가량 더 많이 차지하고 설치 속도가 Dalvik 보다 더 느리다는 것. 이는 처음 설치할 때 필요한 컴파일 작업을 다 해놓기 때문에 생기는 근본적인 한계. 


또한 킷캣까지 대부분 앱은 런타임을 모두 Dalvik 에 초점을 잡아 개발했기 때문에 Dalvik 에서 잘 돌아가던 앱들이 ART 환경에서 안돌아가는 호환성 문제가 발생함.


킷캣-롤리팝 초기(5.0) 기준으로 ART는 아직 적용 초기 단계인지라 사용자도 구글도 밝혀내지 못한 잠재적인 문제들이 산재해 있을 가능성이 있음


프로필 가이드 방식의 JIT/AOT 컴파일

※ 구글 I/O 2016의 발표에 따른 추가사항

안드로이드 N에서는 ART에 JIT 컴파일러도 추가 됨

Android N에서 코드 프로파일링을 포함한 JIT(Just In Time) 컴파일러를 ART에 추가했으며, 실행 시에 Android 앱의 성능이 계속해서 향상됨


JIT 컴파일러는 ART의 현재 AOT(Ahead Of Time) 컴파일러를 보완하고 런타임 성능을 개선하며, 저장 공간을 절약하고 앱 업데이트 및 시스템 업데이트 속도를 빠르게 해줌

프로필 가이드 방식의 컴파일을 통해 ART는 실제 사용량과 기기의 조건에 따라 각 앱의 AOT/JIT 컴파일을 관리할 수 있음. 예를 들어, ART는 최적의 성능을 위해 각 앱의 핫 메서드에 대한 프로필을 유지관리하고 이들 메서드를 프리컴파일하고 캐싱할 수 있음. 이 경우 앱의 다른 부분들은 실제로 사용될 때까지 컴파일하지 않고 남겨둠


프로필 가이드 방식의 컴파일은 앱의 주요 부분들에서 성능을 개선할 뿐만 아니라 관련 바이너리를 비롯한 앱 전체의 RAM 공간을 줄이는데 도움이 됨. 이 기능은 저용량 메모리 기기에 특히 중요함.


런타임 엔진 ART

초기 안드로이드에 탑재된 가상 머신 달빅(Dalvik)은 모바일 환경을 고려해 적은 메모리, 최적화된 리소스 관리, 최소화 오버헤드 등이 목표였다. 자주 수행되는 구간(트레이스, trace)을 기계어 코드로 바꾸는 JIT(Just-in-time) 컴파일러는 안드로이드 프로요(2.2) 버전에서야 도입됐다. 달빅의 기본 전략은 달빅 바이트코드(Dalvik bytecode)로 된 코드를 한 줄씩 해석하고 반복 수행되는 구간을 기계어 코드로 변환해 효율을 높이는 것이었다. 


트레이스라 불리는 특정 구간을 번역하는 작업은 메소드 단위로 기계어로 변환하는 것보다 시간이 짧게 소요됐다. 또 변환된 기계어 코드의 용량이 작아 메모리가 적고 CPU 파워가 낮은 상황에 적합했다. 그러나 경량 가상 머신에서 시작한 달빅은 고성능과 고기능에서 구조적 한계를 드러냈다.


구글은 안드로이드 킷캣부터 ART(Android Runtime)를 준비했고 롤리팝부터는 강제 사항이 됐다. 

ART는 AOT(ahead-of-time) 방식의 런타임 환경이다. ART의 내장된 dex2oat 유틸리티는 달빅에서 쓰이던 달빅 바이트 코드와 리소스 파일이 통합된 .dex 파일을 리눅스에서 널리 쓰이는 실행파일 형태 ELF(Executable and Linkable Format)로 변환한다. dex2oat는 앱의 초기 수행 시 호출되며 ART의 AOT는 앱의 최초 수행 과정에 dex2oat 유틸리티를 이용, 실행 파일을 얻어내는 기술인 셈이다. 


이로 인해 롤리팝은 수행 성능, 가비지 컬렉션(GC : Garbage collection)의 성능, 프로파일링, 디버깅 등에서 이점을 얻었다.

Dalvik과 ART의 차이

- Dalvik 은 DEX 파일에서 최적화된 Odex를 얻고 ART는 실행파일 ELF를 얻는다.