LG G2 4.4.2 업데이트 및 ART

2014. 2. 10. 12:05News

LG G2의 통신3사 업데이트가 있었습니다. 용량은 265.55MB로 대규모업데이트였습니다.

업데이트후 변경점을 살펴보면, 안드로이드 킷캣 4.4에서 4.4.2로 OS로 업그레이드되었습니다.

인터넷 웹브라우저 버전 업 및 개발자 ART모드가 생겼습니다.


키캣 업데이트는 삼성보다 LG가 빠릅니다.

먼저, 업데이트를 실시 했었고 (물론 문제는 많았지만.....), 이번에 삼성이 겔럭시 S4 LTE-A 4.4.2 업데이트를 진행하자,

LGE는 ART 기능을 추가한 OS Update를 진행했습니다.


넥서스를 개발하면서 접한 경험이 큰 힘으로 작용한건 아닌가 싶습니다.



     






그럼 ART라는건 뭘까요??


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 (Android RunTime)

ART는 Android RunTime의 줄임말입니다. ART는 VM이 아닙니다. Native로 번역된 안드로이드 앱을 동작시키기 위한 Runtime Library입니다. 넥서스5에서 런타임을 ART로 설정해 놓으면, 앱이 설치 될 때 앱에 들어 있는 중간 언어를 모두 번역을 해 놓습니다. JIT 컴파일러가 필요 없는 것은 물론이고 Dalvik VM도 필요가 없습니다. 당연히 앞에 열거한 문제점들은 모두 사라지고, Native 언어와 동급의 속도를 얻을 수 있습니다. 같은 기기 성능 대비 iOS(아이폰, 아이패드)와 비슷한 성능을 낼 수 있다고 보시면 됩니다.

 

ART도 단점은 있습니다. 앱을 설치하면 공간을 조금 더 차지하고, 설치 속도가 조금 더 느리다는 단점이 있습니다. 그리고, 아직 완성된 것이 아니기 때문에 문제도 많습니다. 그래서 구글에서도 아직은 개발자 옵션에서만 선택할 수 있도록 제약을 두고 있습니다.



요 글은 http://avenuel.tistory.com/2102의 내용입니다.



그리고 아래의 내용은  http://bbs2.ruliweb.daum.net/gaia/do/ruliweb/default/mobile/55/read?bbsId=G003&itemId=9&articleId=1238547의 내용입니다.

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 컴파일러보다 잠재력이 많기 때문에 완전히 나쁜 것만은 아닙니다. 이러한 희생의 대가가 보다 유연한 경험과 배터리 수명의 향상을 가져다 준다면 완전히 기쁠 것입니다.