안드로이드는 초반 몇년간 혼란스러운 시기를 보냈다고 할 수 있습니다. 이 운영 체제가 전례 없는 속도로 성장함에 따라 개발의 속도도 빨라졌죠. 앞을 알 수 없는 미래는 이미 존재하는 하드웨어와 아키텍쳐, 현존하는 개발 툴에 안주하게 하며, 긴박한 마감시일에 코드를 짜내도록 만들었습니다. 이제 안드로이드는 성장했고, 안드로이드 팀도 오래되지 않은 몇몇 요소에 상당한 관심을 가지기 시작했습니다. 안드로이드 퍼즐에 가장 오래된 조각 중 하나는 달빅 런타임, 대부분의 앱을 실행하는데 중요한 소프트웨어 입니다. 이게 바로 구글의 개발자들이 지난 2년간 'ART' 개발에 몰두한 이유입니다. 'ART'는 달빅의 대체 방안으로 더 빠르고 효율적인 동작, 배터리 수명 향상, 그리고 더욱 더 유연한 경험을 보장합니다.

'ART'란 무엇인가?

안드로이드 런타임의 약자인, 'ART'는 달빅과 근본적으로 앱을 실행하는 방식이 다릅니다. 현재 런타임은 오리지날 애플리케이션 코드의 일반적인 버전인, 바이트코드를 해석하기 위해 Just-In-Time (JIT) 컴파일러에 의존하고 있습니다. 말하자면, 앱들은 개발자들에 의해서 부분적으로만 컴파일되고, 그 다음 완성된 코드는 앱이 실행되는 동안 유저의 디바이스에 있는 해석기를 통과해야 합니다. 이 과정은 엄청난 낭비를 가져오고 효율적인 방법은 아닙니다만, 앱이 다양한 하드웨어와 아키텍쳐에서 작동하기 쉽게 해줍니다. 'ART'는 이 과정을 앱이 처음 설치될 때 바이트코드를 기계 언어에 포함시켜, 진정한 네이티브 앱으로 작동하게 변경하도록 만들어졌습니다. 이러한 과정은 Ahead-Of-Time (AOT) 컴파일이라고 불립니다. 새로운 가상 머신이나 해석 코드를 작동시킬 필요를 제거함으로써, 켜지는 시간은 상당히 줄어들 수 있으며 실행 중인 동작을 더욱 빠르게도 또한 만들 수 있습니다.

현재, 구글을 'ART'를 개발자들과 하드웨어 파트너들이 시험해 볼 수 있도록 실험적인 프리뷰로 다루고 있습니다. 구글의 'ART' 소개 페이지에는 기본 런타임을 변경하는 것이 앱을 손상시킬 수 있다거나 시스템을 불안정하게 할 수도 있다는 것을 명확하게 경고하고 있습니다. 'ART'는 본격적으로 사용하기에는 아직 완전히 준비되지 않았을 수도 있습니다, 하지만 안드로이드 팀은 이걸 언젠가 세상에 내놓을 것이라 생각하고 있음이 분명합니다. 'ART'를 시험해보는데 관심이 있다면, 설정 -> 개발자 옵션 -> 런타임 선택 으로 가십시오. 'ART'를 활성화하는 것은 libdvm.so에서 libart.so로 바꾸기 위한 재시작이 요구됩니다, 그러므로 설치된 앱들이 새로운 런타임에 적용되기까지는 대략 10분 정도가 소요됩니다. 경고: 파라노이드 안드로이드 (또는 다른 AOSP) 빌드에서는 지금 실행시키지 마십시오. 현재 gapps 패키지와 호환되지 않아 충돌, 인터페이스를 사용 불가능하게 만듭니다.

얼마나 더 나은건가?

현재로선, 'ART'가 킷캣에서 새로이 등장하였으므로, 효율성에 이득이 있는지는 알기 어렵습니다, 그렇기 때문에 널리 최적화 되었을 때 어떤 모습이 될지는 알 수 없습니다. 그렇긴 해도, 추정치와 몇몇 벤치마크는 새로운 런타임이 이미 대부분의 애플리케이션에서의 실행 기간을 반으로 줄여준다는 것을 보이고 있습니다. 이는 오랜 시간 작동한다거나, 프로세서의 성능에 의존하는 작업이 더 빠르게 끝낼 수 있다는 것을 의미합니다. 일반적인 애플리케이션은 또한 부드러운 애니메이션 효과와 즉각적인 터치 반응/다른 센서 데이터 속도로 이득을 볼 수 있을 것입니다. 더욱이, 이제 보편적인 디바이스가 쿼드-코어 (또는 그 이상) 프로세서를 탑재하고 있기 때문에, 적은 코어를 사용하는 상황이 많아지고, ARM big.LITTLE 아키텍쳐의 A7 코어의 활용도가 높아질 수도 있습니다. 'ART'가 배터리 수명과 퍼포먼스를 얼마나 향상시키는가는 사용 환경과 하드웨어에 따라 달라질 수 있으나, 상당한 향상을 얻을 수 있을 것입니다.

타협해야할 점들은?

AOP 컴파일을 사용하는 것에는 여러 단점이 존재합니다, 하지만 장점에 비한다면 무시해도 좋은 수준입니다. 시작하기에 앞서, 완전히 컴파일된 머신 코드는 보통 바이트코드가 사용하는 것보다 더 많은 저장 공간을 소비합니다. 바이트코드내 각각의 심볼이 머신 코드의 여러 명령을 대체하기 때문이죠. 당연히, 사이즈의 증가는 보통 10%-20% 정도 밖에 커지지 않기 때문에 특별히 중요한 것은 아닙니다. 그러나 APK 파일의 크기는 상당히 커지기 쉽기 때문에 APK를 놓고 본다면 크게 느껴질 수도 있습니다. 예를 들어, 새로운 동영상 편집 기능이 들어간 최신 구글+ APK 파일의 크기는 28.3 MB 이지만, 코드가 차지하는 용량은 6.9 MB 밖에 되지 않습니다. 또 다른 눈에 띄는 단점은 앱을 설치하는데 걸리는 시간이 길다는 것입니다 - AOT 컴파일의 부작용입니다. 얼마나 길어질까요? 글쎄요, 앱에 따라 달라집니다; 간단한 유틸리티는 거의 차이를 느낄 수 없지만, 페이스북과 구글+와 같이 더욱 복잡한 앱은 설치하는데 시간이 오래걸릴 것입니다. 앱이 적게 설치되어 있다면 별로 신경쓰지 않아도 되지만, 'ART'로 변경할 때 100개가 넘는 앱을 컨버팅하는 것은 엄청난 인내심을 요구할 것입니다. JIT 컴파일러보다 잠재력이 많기 때문에 완전히 나쁜 것만은 아닙니다. 이러한 희생의 대가가 보다 유연한 경험과 배터리 수명의 향상을 가져다 준다면 완전히 기쁠 것입니다.