ART

안드로이드에서 사용되던 기존의 달빅VM의 한계점을 해결하기 위해서 구글에서 새로 개발한 런타임(실행환경).

안드로이드 런타임(Android RunTime)을 줄여서 ART라고도 부른다.

2016년 하반기에 출시된 안드로이드 누가부터, ART라고 해서 무조건 AOT인 것은 아니므로 구분하여 서술할 것.

킷캣 버전에서 처음으로 선보였다.[1]
안드로이드 5.0 롤리팝(Lolipop)부터는 달빅VM을 완전히 폐지하고 ART를 새로운 런타임으로 완전히 대체했다. 또한 위에 설명했듯이 ART가 라이브러리인 점때문에 x86, mips 아키텍처 및 64비트를 공식적으로 지원하게 되었다.[2]

일반적인 컴파일 언어는 CPU의 아키텍쳐와 플랫폼의 환경에 맞추어 기계어로 컴파일된다. 간단히 말하자면, 사람이 작성한 프로그램을 CPU가 알아들을 수 있는 언어로 바로 번역하여 저장하는 것이다. 이 CPU간의 서로 다른 "언어"가 "아키텍쳐"에 해당한다고 보면 된다. 그러나, 자바의 경우는 기본적으로 한 가지 CPU의 아키텍쳐나 환경에 맞추는 것이 아닌 바이트코드라는 것으로 컴파일 되며, 이를 실행하기 위해서는 자바 가상 머신이 필요하다. 이렇게 하는 이유는 자바는 바이트코드 하나만으로 여러 가지 아키텍쳐나 플랫폼에서 작동할 수 있도록 하는 것이 목표이기 때문이다. 아키텍쳐와 플랫폼에 맞는 가상머신만 있다면 하나의 실행 파일만 가지고도 각종 장치에서 쓸 수 있는 것이다. 플랫폼이 안 맞아서 작동시키지 못하는 예시가 안드로이드 ↔ iOS 혹은 윈도우↔맥↔리눅스 간의 호환이 안 되는 경우이고, 아키텍쳐가 안 맞아서 작동시키지 못하는 예시가 윈도우 8 ↔윈도우 8 RT 간의 호환이 안되는 경우이다.

안드로이드도 Java 언어를 사용하기 때문에 VM이 필수적이다. 이에 자바 가상머신(JVM)을 사용할 수 있지만, JVM은 라이선스 문제[3]가 있어서 구글에서는 Dalvik VM을 따로 개발해서 안드로이드에 넣었다.

JIT(Just-In-Time) 컴파일러 이전에는, 앱이 구동되는 와중에 실시간으로 자바 바이트코드를 CPU에 맞게 변환하였다. 그러나 JIT 컴파일러가 들어가고부터는 앱 최초 실행시에 자바 코드가 일정 부분 캐싱되어, 차후 실행시에는 캐시에 저장된 코드를 불러오는 식으로 작업하게 된다.

이러한 JIT 컴파일러가 추가되면서 성능은 향상되었다. 그런데 여기서 문제가 생겼다. JIT 컴파일러가 돌아가는데 실행시마다 하드웨어 전체적으로 상당한 부하가 생겨 배터리 시간이 안습이 돼버리는 불상사가 터진 것. 화면 전환이 많을수록[5] 배터리는 더욱 더 안습이 되어버렸다. 게다가 달빅은 실행 직전에 실행 부분 전체를 RAM에다가 올려놔야 하기 때문에 각 앱이 다른 OS보다 램을 더 많이 사용하는 탓에 램고자라고도 알려져 있다. 이 때문에 안드로이드는 한 때 iOS와 많이 비교되면서 가루가 되도록 까이게 되는 원인이 되어버렸다. 또한, 안드로이드에 프로세서 킬러를 함부로 쓰면 안 된다는 말도 여기에서 나온 것.

이런 문제를 해결하기 위해서 구글에서 새로 개발해낸 것이 ART로, AOT 컴파일러를 기반으로 제작되었다.

앞에서 살펴본 바와 같이, JIT 컴파일러는 프로그램 최초 실행시마다 코드를 변환한다. 반면, AOT 컴파일러는 프로그램 최초 실행시가 아닌, 그 이전에(주로 설치시에) 한번에 전체를 변환해 두고 저장한 뒤, 프로그램 실행시 마다 변환된 코드를 읽어들이게 된다.

비행 매뉴얼을 가지고 비유를 해 보자면, 기존의 컴파일 언어는 각국의 언어로 처음부터 인쇄되어 나오는 매뉴얼이라고 볼 수 있다. 자바 언어의 경우, 애초부터 배우기 쉬운 언어로 의도되어 만들어진 에스페란토어, 혹은 현실적으로는 세계 공용어 역할을 하는 영어 정도의 위치를 갖는다고 할 수 있겠다.

JIT 이전에는 외국어 매뉴얼을 비행하는 도중에 계속 해석해 가면서 읽고 비행을 했다고 한다면, JIT는 비행 이전에 아 이번에 비행할 때에는 이런이런 부분을 쓰겠구나 하고 적당히 해석하면서 메모한 뒤 비행을 하는 것이고, AOT는 비행 메뉴얼을 받아오는 시점에서 완전히 번역해 놓고 번역본을 원본 매뉴얼과 함께 구비한 뒤에 번역본을 계속 읽으면서 비행하는 식이다. JIT는 책상 위가 항상 어지러울 것이고, AOT는 선반 위의 공간이 부족해지는 사태가 발생할 것이다.

번외로, 안드로이드의 성능 향상을 위한 다른 기법으로는 NDK가 있다. 이는 이 비행기는 특정 언어를 쓰는 파일럿이 조종할 것이라고 상정하고 제조사부터가 해당 언어로 작성된 매뉴얼을 제공하는 것. 번역의 과정을 추가로 거칠 필요가 없고, 해당 언어의 특성을 제대로 활용할 수 있어 성능이나 효율상으로는 꽤 매력적인 옵션이다. 그러나 안드로이드는 ARM에서만 돌아가는 것이 아니다. 이미 중국제 태블릿 컴퓨터의 상당수는 AMD64계열 CPU를 쓰고 있는데, 그런 환경에선 NDK가 안 돌아갈 가능성이 높다. 그래서 불편하지만 이런 구조를 채택하고 있는 것. 제대로 활용한다면 어느 정도 성능 향상을 기대할 수 있지만, 일반적으로는 안드로이드의 철학에 배치되는 이야기이기도 하고, 초기 안드로이드에 비하면 가상 머신의 최적화도, 하드웨어의 성능도 여유가 꽤 생겼기 때문에 잘 권장되지 않는다.

직독직해할 정도로 그 언어를 배운다는 것은, 안드로이드로 한정했을 때 굳이 얘기하자면 JIT 이전의 방식이 그나마 유사하다. 성능을 최대한 쥐어짜내도 모자랄 판에 굳이 번역의 짐을 더할 필요는 없는 것. 파일럿의 국적이 다 다르고 언어를 배운다 하더라도 모국어만큼 빠르게 이해하기는 어렵기 때문에 각 언어별 매뉴얼을 만들어 줘야 하는 것과 같은 이치다.

안드로이드의 범주를 벗어난다면, 유사한 예시로는 자바 프로세서, 조금 더 일반적인 사례로는 CPU의 하위 호환성, 혹은 호환 모드를 들 수 있다. 전자의 경우는 별로 성공하지 못했고, 후자의 경우는 흔히 사용되기는 하지만 이름에서도 보듯 버전업과 같은 특수한 상황에서나 가능하며 이와 같은 용도로의 활용은 기대하기 어렵다.

자바의 철학은 하드웨어 아키텍처에 영향을 받지 않는다는 것이다. ARM 프로세서에서 동작하는 네이티브 앱은 당연히 x86 프로세서 환경에서 동작하지 않아 코드를 재구축하는 과정이 필요하지만[6], 자바 앱이라면 이야기가 다르다. 앱과 하드웨어 사이에 중간 코드 및 가상 머신(VM)[7]이 끼어들기 때문에 하드웨어 플랫폼과 무관하게 구동이 가능하다.[8] 구글이 안드로이드를 만들 때 주목한 것이 이 부분이었다. 지금이야 ARM이 시장을 장악하기는 했지만 그 이전에는 MIPS도 어느 정도 시장 지분이 있는 상황이었고 예나 지금이나 데스크탑에 쓰이는 x86(AMD64) 시장은 변함없이 강력하므로 잘만 하면 데스크탑 시장까지도 노릴 수 있는 것이다. 지금도 (비록 구글이 직접 나서서 하고 있는 것은 아니지만) Android-x86 프로젝트가 어느정도 활성화되어 있는 것에서 그 가능성을 엿볼 수 있다. 이런 이유로 자바를 선택한 뒤에, 어떻게 하면 그 구조를 조금이라도 효율적으로 써먹을 수 있을까 고심해 온 결과물이 JIT 컴파일이고 또 AOT 컴파일인 것이다.

다른 큰 이유는 일단 자바가 배우기 쉽고, 생산성이 높으며, 이미 자바 개발자가 차고 넘치는 데다가, 사용처도 굉장히 넓기 때문이라는 것도 있다. 상대적으로 후발주자였던 안드로이드가 앱 생태를 쉽게 구축할 수단으로써 자바를 선택했다는 것.

구글은 안드로이드 인수 당시 대화면 풀 터치 스마트폰이 이렇게 빨리 일반화 될 것이라는 것을 예측하지 못했고 그 화면 위에서 멀티미디어 콘텐츠가 그 정도로 빠른 속도로 보급될 것이라는 것도 예측하지 못했다. 애플이 iPhone을 처음 내놨을 때에 여기에 필적할 제품이 준비되어 있는 경쟁사는 단 한곳도 없었다. 심지어 애플조차 ARM 프로세서가 모바일 시장을 독점 구도로 평정해버릴 거라는 예상은 하지 못했다. iPhone보다 먼저 기획되기 시작한 아이패드에 쓰일 프로세서를 위해 최초에 접촉한 곳은 ARM 프로세서 개발사들이 아니라 x86을 만드는 인텔이었기 때문이다. 단지 구글은 경쟁이 가능할 법한 제품을 가지고 있는 듯한 홍보를 성공적으로 수행했고 어찌되었든 애플을 제외한 모든 시장 경쟁자들 중 가장 빠른 시간 내에 소비자들이 최소한의 납득을 할 수 있는 제품을 내놓을 수 있었다. 그러니까 폭발하듯 팽창하며 급변하는 스마트폰 시장 초기에 오로지 생존을 위해 멀티미디어용으로 디자인 되지 않은 OS를 마개조하며 임기응변으로 쌓아 올려나간 결과물이 지금의 안드로이드인 것이다. 반면 마이크로소프트는 삼성 옴니아와 같은 제품을 만들 수 있는, 비록 엄청난 혹평에 직면하더라도 당장 제품을 만들어낼 수는 있었던 윈도우 모바일이 있었음에도 불구하고 iOS에 필적하는 수준의 윈도우 폰 OS가 1년 후에 발매될 것이며 현재 판매 중인 기기는 이를 위한 어떤 지원도 받을 수 없다는 이해 못할 통보와 함께 긴 시간을 침묵해버렸다. 그리고 당시의 1년이면 강산이 두 번은 바뀌고도 남았을 정도로 격변이 계속되던 때였다. 거기다 마이크로소프트는 예고했던 시점에 제품을 내놓지도 못했고 내놓은 OS는 상대적으로 빠르고 안정적이기만 했을 뿐 기본적인 기능이 여러가지로 나사가 빠져있는 상태였다. 즉 마이크로소프트는 자멸한 것이나 마찬가지인 셈이다. 구글은 오로지 생존을 위해 기능 개발에만 매달려야 했던 긴 기간이 끝나고 애플을 제외한 경쟁자가 모두 사라져버린 시점이 되어서야 이러한 성능 개선 작업에 착수할 수 있었다.

AOT 컴파일러가 적용된다면 당연히 압도적인 속도 개선을 기대할 수 있으며, 새로운 플랫폼으로써의 안정성만 보장된다면 앱이 동작하는 안드로이드 플랫폼 자체가 발적화 소리를 들을 일은 사실상 없게 될 것이다.물론 앱 개발자가 허접이면 얄짤없지만 그건 어느 플랫폼이나 마찬가지고.

안드로이드 4.4 킷캣이 실행 중인 안드로이드 기기에서 런타임을 ART로 설정해 놓으면, 앱이 설치 될 때 앱에 들어 있는 중간 언어를 모조리 번역을 미리 해 놓는다.[9] 그 덕분에 기존의 Java 기반 앱 플랫폼으로써의 문제점들은 모두 사라지고, 네이티브 언어와 동급의 성능을 체감할 수 있게 되었다.

AOT 컴파일러도 단점은 있다. 앱을 설치하면 공간을 1.5배에서 2배 가량을 더 많이 차지하고, 설치 속도가 달빅VM보다 더 느리다는 것. 이는 JIT 없는 초창기 달빅 머신은 모든 명령어[10]를 실행 시마다 한줄한줄 인터프리트하고, JIT는 필요한 부분에 한해 실행 시마다 인터프리트하는 반면에 ART의 AOT 컴파일러는 처음 인스톨할 때 필요한 컴파일 작업을 다 해놓기 때문에 생기는 근본적인 한계[11]이다. 또한 킷캣까지의 앱은 런타임을 모두 달빅에 초점을 잡아 개발했기 때문에 ART 환경에서는 안 돌아가는(즉 호환성 문제가 있는) 앱들도 존재한다. 그리고, 킷캣~롤리팝 초기(5.0) 기준으로 ART는 아직 적용 초기 단계인지라 사용자도 구글도 밝혀내지 못한 잠재적인 문제들이 산재해 있을 가능성이 있다.[12] 다만 2017년 시점은 이미 5.1.1을 넘어 마시멜로와 누가, 오레오, 파이를 향해 가고 있는 만큼 이러한 미검증의 문제는 초기에 비해 적어졌다고 할 수 있다.

안드로이드 7.0 누가에서는 최초 설치시에는 JIT를 사용하여 설치 속도를 높이고, 차후 기기를 사용하지 않을 때나 충전 중일 경우 컴파일을 조금씩 하여, 자주 사용되는 앱을 AOT 방식으로 전환하는 것으로 바뀌었다. 즉, 양 방식의 장점을 합치고 단점을 극복하려 시도한 것이며 실제로 애플리케이션의 설치 속도가 기존 AOT 방식에 비해 매우 빨라졌다. 단, 용량 문제는 여전하다.

그런데 용량문제야 말로 진짜 하드웨어 빨로 커버가 가능한 부분이라 크게 문제가 되지는 않는 듯 하다. 요샌 64GB 내장메모리가 기본사양 취급 받으니(...)

게다가 원래부터 같은 어플이라면 IOS 어플리케이션이 달빅 런타임 시절의 안드로이드 어플리케이션보다 용량이 크기도 했고. 과거의 안드로이드 어플보다야 용량이 커지긴 했지만, ios랑 비교하면 그게 그거다.

또한, 어플리케이션 자체 용량은 달빅 런타임 시절이 ART 런타임보다 적긴 했지만, 이건 어플리케이션 자체 용량이고, 쓰면 쓸수록 쌓이는 Dalvik-Cache와 Cache 용량을 감안하면 결국 도찐개찐이 된다. 왜냐하면 JIT이 코드를 캐싱할 때 일단은 메모리에다 올려 쓰지만 그 중 일부는 저장공간에도 캐싱하기 때문. 이 때문에 일반 Cache는 설정에서 사용자가 삭제할 수 있지만, Dalvik-Cache는 루팅하지 않는 이상 손댈 수도 없는 부분이다.

ART 적용 이전에도 코드 보안이나 성능 보장이 매우 중요한 앱 개발은 NDK를 이용한 C/C++ 프로그래밍을 통해 이루어져 왔다. 상용 앱 내부에는 앱에 따라서 어느 정도 네이티브 코드가 포함되어 있기도 하다는 것. 최적화가 될 만큼 되어 있는 이러한 앱들에 대해서는 유의미한 성능 개선이 이루어지지 못할 가능성 역시 존재한다.

초기에 배터리 실사용 시간이 ART가 달빅보다 불리하다는 오해가 있었다. 이런 오해를 받게 된 원인은 ART가 처음 도입 된 킷캣이나 롤리팝에서 ART를 사용할 때의 배터리 타임이 짧았기 때문으로 보인다. 그러나 이것은 달빅이 좀 더 긴 역사를 가져서 더 안정화가 되었기 때문일 뿐이지 ART의 구조 자체에 근본적인 원인이 있는 것이 아니다. 실제로 롤리팝에 비해 마시멜로우에서 배터리 수명이 크게 향상되었다. [13]

ART 또한 달빅과 같은 가상머신의 일종이다. 기존 안드로이드는 DEX 파일을 Dalvik 가상머신 위에 올려두고 필요에 따라 실시간으로 컴파일하는 방식이었다. ART를 사용하는 경우는 DEX 파일을 미리 컴파일하여 OAT 파일에 저장해두고 실행 돌리는 것으로 변했을 뿐이다. 기존의 DEX 파일을 dex2oat 라는 변환기를 이용해서 생성하고 실행한다.

OAT 파일은 DEX를 컴파일한 native machine code를 담고 있으며, 가상머신을 거치지 않고 바로 실행된다. 하지만 ART를 사용한다고 해도 Dalvik에서 실행하는 것과 논리적으로 동일한 결과물을 제공해야 하기 때문에, OAT에 저장된 native machine code에는 가상머신의 상태를 흉내내기 위한 부가적인 코드들이 잔뜩 들어가게 된다. (디버깅을 위해 필요하다. 물론 JIT compiler가 뱉어낸 machine code도 비슷하게 생겨먹었다) 다시 말해서 ART를 사용하는 경우 앱이 가상머신 위에서 작동하지는 않지만 가상머신으로부터 완전히 자유롭지도 않다.

Xposed는 상당한 기간동안 ART를 지원하지 않아 ART 상태에서 설치를 시도할 경우 강제로 달빅으로 전환해버렸다. 킷캣 때의 CyanogenMod에서는 ART를 선택해도 ART로 바뀌지 않고 달빅으로 계속 유지되는 오류가 있었다. 이러한 현상은 런타임을 달빅으로 설정한 상태에서 Xposed 프레임워크를 설치해 놓고, 그 다음 런타임을 다시 ART로 전환할 때나, 2013년 11월부터 2014년 1월 사이에 나온 커스텀롬(CM11 나이틀리 포함)이나 개발자가 자체적으로 ART를 제거한(!) 커스텀롬을 사용할 경우에 발생했다.[14]

그리고 안드로이드 롤리팝 런칭 이후에도 Xposed 개발팀은 감감무소식이어서 사용자들의 애를 태웠으나, 몇 개월 지난 뒤 ART 및 안드로이드 5.0 롤리팝을 위한 Xposed를 공개했다. 그 뒤 어떤 유저가 비공식으로 포팅한 안드로이드 5.1용 Xposed가 공개되었고, 이윽고 8월 31일 공식적으로 안드로이드 5.1을 지원하게 되었다.[15] 시간이 흘러 안드로이드 6.0 마쉬멜로우도 어렵잖게 지원하기 시작했다.

7.0 누가에서는 ART가 AOT와 JIT를 함께 탑재하고 '적절히' 사용하게 함에 따라 개발자를 엿먹이는 바람에, 2017년 5월 기준 아직 지원하지 않는다.

정리하면 현재 안드로이드 5.0 ~ 6.0 에서는 Xposed 프레임워크 및 Xposed 모듈이 거의 완전하게 돌아간다고 보면 되겠다.

2017년 10월 8일 자로 안드로이드 7.0 & 7.1 누가에서도 Xposed 프레임워크를 사용할 수 있게 되었다.링크