댓글 쓰기 권한이 없습니다. 로그인 하시겠습니까?
Android
2014.02.10 12:47
ART(Android RunTime)에 대해
조회 수 17865 댓글 1
클리앙 쟝그리안님 http://www.clien.net/cs2/bbs/board.php?bo_table=lecture&wr_id=200729 1. Java의 특징...
안드로이드 앱은 Java라는 언어를 써서 개발하도록 되어있습니다. 제임스 고슬링 할아버지와 그 친구들이 만든 객체지향의 완성격인 아주 훌륭한 언어지요.
고슬링 할아버지가 자바 언어를 설계하면서 가장 기본적인 목표로 삼은 것이 One Source Multi-Using 입니다. 프로그램을 한번 작성해 놓으면, 리눅스든 유닉스든 윈도우든 가지리 않고 쓸 수 있게 한다는 것입니다..
이것을 위해서 Java Virtual Machine (JVM)이란 장치를 만들어 놓습니다. Java 언어로 작성된 프로그램을 컴파일 하면 JVM이 읽을 수 있는 중간 언어로 번역되고, JVM이 각 플랫폼(리눅스, 유닉스, 윈도우 등등)이 알아 들을 수 있는 언어로 번역해서 프로그램을 실행시켜 주는 것입니다.
Java는 이런 특징을 가지고 있어서, 태생적으로 *Native 언어들에 비해 속도가 느리다는 단점이 있습니다. 그리고, Java 언어가 발전하면서 이런 단점을 만회하기 위해, JIT(Just-In-Time) 컴파일러라는 장치가 추가됩니다.
*Native 언어 : 컴파일(번역)이 완료되면 플랫폼에 맞는 언어로 번역이 되는 언어들
2. JIT Compiler
JVM은 중간 언어를 읽어 들일 때 한줄 한줄 읽어들입니다. 이것을 인터프리터라고 하는데, JIT는 인터프리터 형식으로 중간 언어를 읽지 않고, 프로그램이 실행 될 때 한꺼번에 읽어 들여서 Native 플랫폼(리눅스, 유닉스, 윈도우 등등)이 읽어 들일 수 있는 언어로 번역합니다. 한줄 한줄 읽는 것에 비해 당연히 속도가 빠르지만, Native 언어에 비해선 여전히 속도가 느립니다.
3. Dalvik VM과 JIT Compiler
안드로이드도 Java 언어를 사용하기 때문에 VM을 이용해야만 합니다. 다만 JVM은 라이선스 문제가 있어서 Dalvik VM을 사용했지요. 초창기에는 안드로이드에서 사용하는 Dalvik VM에 JIT 컴파일러가 포함되어 있지 않았습니다. 안드로이드 2.3 버전인가? 그때부터 JIT 컴파일러가 추가되었지요.
JIT 컴파일러가 추가되면서 성능은 상당히 향상되었습니다. 그런데, JIT 컴파일러가 동작하는데 상당한 부하가 발생되기 때문에 배터리 시간이 안습이 되버리는 문제가 발생합니다. 화면 전환이 많을수록 배터리는 더욱 더 안습이 되버립니다. 그리고 화면 전환시에도 속도가 느리다는 단점이 있습니다.
이런 문제를 해결하기 위해서 개발한 것이 ART입니다.
4. ART
ART는 Android RunTime의 줄임말입니다. ART는 VM이 아닙니다. Native로 번역된 안드로이드 앱을 동작시키기 위한 Runtime Library입니다. 넥서스5에서 런타임을 ART로 설정해 놓으면, 앱이 설치 될 때 앱에 들어 있는 중간 언어를 모두 번역을 해 놓습니다. JIT 컴파일러가 필요 없는 것은 물론이고 Dalvik VM도 필요가 없습니다. 당연히 앞에 열거한 문제점들은 모두 사라지고, Native 언어와 동급의 속도를 얻을 수 있습니다. 같은 기기 성능 대비 iOS(아이폰, 아이패드)와 비슷한 성능을 낼 수 있다고 보시면 됩니다.
ART도 단점은 있습니다. 앱을 설치하면 공간을 조금 더 차지하고, 설치 속도가 조금 더 느리다는 단점이 있습니다. 그리고, 아직 완성된 것이 아니기 때문에 문제도 많습니다. 그래서 구글에서도 아직은 개발자 옵션에서만 선택할 수 있도록 제약을 두고 있습니다.
P.S : 틀린 내용도 있겠지만, 너그러히 봐주시면 좋겠습니다; 아직 개발중인 런타임이기 때문에 호환성에 문제가 많습니다. 부디, ART 지원 안해준다고, 개발사에게 항의하시는 분들이 없으시기를....ㅠㅠ Dreamy의 코드 스크랩내가 모으고 내가 보는
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Designed by sketchbooks.co.kr / sketchbook5 board skin
Sketchbook5, 스케치북5
Sketchbook5, 스케치북5
Sketchbook5, 스케치북5
Sketchbook5, 스케치북5
dalinaum님 댓글
구글은 기기 독립성을 위해서 달빅을 도입해던 것이고 게임 개발을 위한 요구를 만족하기 위해 NDK를 뒤 늦게 개방하면서도 ARM 종속성을 경계하였습니다. 그래서 렌더스크립트 등의 LLVM 비트코드 등을 쓰는 대안들을 마련해보려고 했지만 대대로 실패했고요. 그래서 구글이 네이티브를 선택할 가능성은 적습니다.
짓(JIT)을 쓴다고 특별히 배터리가 그렇게 비효율적이지는 않습니다. 왜냐하면 일정 횟수가 이상 수행이 되는 부분적인 경로만 빌드를 하기 때문입니다.
달빅은 트레이스 방식의 짓(JIT) 컴파일러를 가지고 있습니다. 설명하면 길어지니 간단히 말하면 분기 하나나 for 루프 하나 등이 트레이스라고 보시면 됩니다. 개발 트레이스가 몇회 이상 반복 수행되면 (스레스홀드를 넘는다고 합니다.) 기계 언어로 컴파일하는 방식입니다. 그걸 위해 트레이스마다 카운터를 세팅하고요. 변환된 기계 코드를 저장할 트렌슬레이션 캐쉬를 가지고 있습니다. 이 컴파일 과정은 다른 스레드에서 이루어지고요.
보통 데스크탑, 서버용 기술들은 메서드 기반의 짓 컴파일러를 가지고 있는데 이건 메서드마다 카운터를 두고 있다가 횟수가 넘어가면 빌드를 하는 방식입니다.
잘 쓰이지 않는 트레이스도 언젠가 쓰일 수 있기 때문에 효율로 따지면 메서드 기반의 짓 컴파일러가 훨씬 낫습니다. 하지만 빌드 시간이 더 오래 걸려서 부하가 실제 기계어 코드를 쓰게 되는 시점이 더 뒤가 됩니다. 즉, 메서드 방식이 성능은 더 좋은데 레이턴시가 길고 트레이스 방식이 레이턴시가 짧고 성능은 덜 좋습니다.
안드로이드는 모바일이기 때문에 적당히 성능이 좋아져도 좀 더 빨리 쓸 수 있는 트레이스 방식의 짓을 쓴 것입니다.
구글은 오라클과 소송을 벌이고 있고 곧 2차 소송전이 본격적으로 벌어질겁니다. 1차 소송은 구글의 압승으로 끝났지만 구글은 여전히 질지도 모른다는 리스크를 가지고 있습니다. 그런 우려 때문에 달빅에 참여하던 다른 업체(Q모사등)이 달빅에서 손을 떼고 있고 있고요. 그래서 구글은 젤리빈 말기부터 짓을 쓰지 않는 자바 기술에 대해 열중하게 되고 그 중에 선택한 것이 AOT입니다. 구글이 만든 AOT 구현이 ART이죠.
AOT는 중간언어로 배포된 결과를 목적 디바이스에 빌드를 해서 기계어를 얻어내는 기술입니다. 안드로이드가 달빅을 위해 만든 중간언어를 목적 디바이스에서 빌드를 하는 것입니다. 이 방식의 이점은 프로그램이 수행될 때 기계 코드를 저장할 별도의 트랜슬레이션 캐쉬를 가질 필요도 없고 어떤 구간은 아직 빌드된 데이터가 없어서 기다려야 하는 레이턴시가 없으며 성능은 JIT이 완료된 코드와 동일합니다.