<###
odex 파일에 관한 일반적인 설명 ###>
기본적으로 안드로이드는 자바 기반의
가상머신을 프로그램 실행의 기본으로 삼습니다. 이녀석이 바로 Dalvik이라는 넘입니다.
dex파일이란 녀석은 달빅머신에 의해 사용되는
Dalvik-cache 를 포함하고 있는데요. 이는 apk파일 안에 들어있습니다.
odex파일은 dex파일을 기기 특성에 맞게
최적화하여수정하여 apk의 안에 넣지 않고 apk와 나란히 저장되는 녀석이고, 기본 시스템 어플리케이션들은 모두 apk+odex 형식으로
저장되어 있습니다.
하나의 odex 파일이 생성될 때 BOOTCLASSPATH라는 파일을
불러오고 여기서 이 odex는 해당 BOOTCLASSPATH 파일들에 의존성을 가지게 됩니다. 그러므로
이 odex가 유효하게 사용되기 위해서는 의존성을 가지는 정확한 BOOTCLASSPATH 파일들이 함께 하여야만 하는
것이지요. Dalvik은 각각의 odex 파일이 의존하고 있는 녀석들의 checksum을 저장하고 있다가 해당 odex
파일이 사용될 때 BOOTCLASSPATH와의 checksum이 매치가 되는지 단단히 확인을 합니다.
BOOTCLASSPATH는
메인 어플/jar가 로드될 때 추가적으로 클래스를 불러올 수 있는 jar와 어플들의 리스트입니다.
보통의 안드로이드 시스템에는 5개의 기본
BOOTCLASSPATH가 있습니다.
기본
BOOTCLASSPATH라 함은, 모든 어플들이 이 5개를 기본적으로 참조한다는 말이겠죠?
그러나 몇몇 어플들은 이 기본 jar들 외에
다른 녀석에게 의존성을 가지기도 합니다.
예를 들어보면, 구글 지도를 사용하는 어플리케이션은 위의 기본 5개외에
com.google.android.maps.jar 라는 파일에 의존성을 가지고 있으므로 이를 반드시 BOOTCLASSPATH에 추가해 주어야
한다는 것입니다.
이런 odex의 의존성은 여러 가지 불편한 점이 있습니다.
1) 예를 들어 갤럭시S의
apk+odex를 갤럭시K에 가져와서 실행할 수 없습니다. (익히 알고 계시죠?)
-->> 이 것이 가능하려면
갤럭시K가 갤럭시S와 똑같은 프레임워크 파일들을 사용해야 합니다.
2) BOOTCLASSPATH중 하나에 수정을 가하게 되면 이
녀석에 의존하고 있는 모든 odex 파일들이 사용 불가가 됩니다.
<### Deodex란? ###>
Deodex를 한다는 것은
이렇게 밖으로 나와있는 odex파일들을 apk파일 안으로 되돌려 넣는다는 것을 말합니다. 이를 적용하게 되면 기본적으로 odex파일을 걱정할
필요 없이 쉽게 파일들을 바꿀 수 있습니다. 하지만 이 행위의 주된 목적은 services.jar파일을 deodex함으로써 모든 텍스트의
색깔같은 테마를 변경하는 것이 가능하게 하는 것입니다. 많은 테마변경을 하고자
한다면 롬은 반드시 deodex가 되어야 합니다. 예를 들자면 커스텀 lockscreen 같은 것들은 보통 deodex된 롬을 필요로 합니다.
deodex를 하지 않고서도 몇 가지 테마 수정을 할 수는 있지만, deodex를 하게 됨으로써 더욱 더 많은 변경을 할 수
있습니다.
deodex는 단지 위의 조각들을 원래 어플의 안으로 되돌려 넣는 행위입니다. 이로 인한 장점은
어플들이 효과적으로 수정될 수 있는 점과, 개발자들로 하여금 나눠져 있는 코드의 odex부분때문에 곯머리 썩지 않아도 된다는
것입니다.
결론은 deodex는 odex를 dex로
재컴파일한 다음에 apk 안에 다시 쑤셔 넣는 것을 말합니다.
<### Zipalign이란? ###>
Zipalign을 하게 됨으로써 안드로이드는 어플리케이션과 조금 더 효율적으로 상호작용을 할
수 있게 됩니다. 따라서 이로 인해 전체적인 시스템과 어플리케이션의 실행을 빠르게 할 수 있습니다. 구글에서는 Zipalign을 강하게
권유하는군요. 그래서 했습니다. -_-)
안드로이드에선, 각각의 어플에 적재된 데이터 파일들이 다중 프로세스에 의해 이용됩니다. 홈
어플리케이션은 다른 어플의 이름과 아이콘에 관한 자원을 읽어들이고, 시스템 서버는 다양한 이유때문에 어플의 자원을 읽습니다. 그리고 명백하게,
어플 자기 자신도 자원들을 읽습니다.
안드로이드의 이 자원관리 코드는 4바이트 경계들로 메모리-맵핑
(Wh.....What?..-0-)되었을 때 효율적으로 이용될 수 있습니다. 하지만 이 자원들이 4바이트 정렬이 되지 않는다면, 즉
zipalign이 되지 않는다면, 이를 명확하게 읽기 위한 과정이 필요하므로 약간의 느려짐과 추가적인 메모리 소비를
보입니다.
따라서 우리는 zipalign 툴을 이용해 어플리케이션 자원들을 4바이트로 정렬하는 것입니다.
odex 파일에 관한 일반적인 설명 ###>
기본적으로 안드로이드는 자바 기반의
가상머신을 프로그램 실행의 기본으로 삼습니다. 이녀석이 바로 Dalvik이라는 넘입니다.
dex파일이란 녀석은 달빅머신에 의해 사용되는
Dalvik-cache 를 포함하고 있는데요. 이는 apk파일 안에 들어있습니다.
odex파일은 dex파일을 기기 특성에 맞게
최적화하여수정하여 apk의 안에 넣지 않고 apk와 나란히 저장되는 녀석이고, 기본 시스템 어플리케이션들은 모두 apk+odex 형식으로
저장되어 있습니다.
하나의 odex 파일이 생성될 때 BOOTCLASSPATH라는 파일을
불러오고 여기서 이 odex는 해당 BOOTCLASSPATH 파일들에 의존성을 가지게 됩니다. 그러므로
이 odex가 유효하게 사용되기 위해서는 의존성을 가지는 정확한 BOOTCLASSPATH 파일들이 함께 하여야만 하는
것이지요. Dalvik은 각각의 odex 파일이 의존하고 있는 녀석들의 checksum을 저장하고 있다가 해당 odex
파일이 사용될 때 BOOTCLASSPATH와의 checksum이 매치가 되는지 단단히 확인을 합니다.
BOOTCLASSPATH는
메인 어플/jar가 로드될 때 추가적으로 클래스를 불러올 수 있는 jar와 어플들의 리스트입니다.
보통의 안드로이드 시스템에는 5개의 기본
BOOTCLASSPATH가 있습니다.
기본
BOOTCLASSPATH라 함은, 모든 어플들이 이 5개를 기본적으로 참조한다는 말이겠죠?
그러나 몇몇 어플들은 이 기본 jar들 외에
다른 녀석에게 의존성을 가지기도 합니다.
예를 들어보면, 구글 지도를 사용하는 어플리케이션은 위의 기본 5개외에
com.google.android.maps.jar 라는 파일에 의존성을 가지고 있으므로 이를 반드시 BOOTCLASSPATH에 추가해 주어야
한다는 것입니다.
이런 odex의 의존성은 여러 가지 불편한 점이 있습니다.
1) 예를 들어 갤럭시S의
apk+odex를 갤럭시K에 가져와서 실행할 수 없습니다. (익히 알고 계시죠?)
-->> 이 것이 가능하려면
갤럭시K가 갤럭시S와 똑같은 프레임워크 파일들을 사용해야 합니다.
2) BOOTCLASSPATH중 하나에 수정을 가하게 되면 이
녀석에 의존하고 있는 모든 odex 파일들이 사용 불가가 됩니다.
<### Deodex란? ###>
Deodex를 한다는 것은
이렇게 밖으로 나와있는 odex파일들을 apk파일 안으로 되돌려 넣는다는 것을 말합니다. 이를 적용하게 되면 기본적으로 odex파일을 걱정할
필요 없이 쉽게 파일들을 바꿀 수 있습니다. 하지만 이 행위의 주된 목적은 services.jar파일을 deodex함으로써 모든 텍스트의
색깔같은 테마를 변경하는 것이 가능하게 하는 것입니다. 많은 테마변경을 하고자
한다면 롬은 반드시 deodex가 되어야 합니다. 예를 들자면 커스텀 lockscreen 같은 것들은 보통 deodex된 롬을 필요로 합니다.
deodex를 하지 않고서도 몇 가지 테마 수정을 할 수는 있지만, deodex를 하게 됨으로써 더욱 더 많은 변경을 할 수
있습니다.
deodex는 단지 위의 조각들을 원래 어플의 안으로 되돌려 넣는 행위입니다. 이로 인한 장점은
어플들이 효과적으로 수정될 수 있는 점과, 개발자들로 하여금 나눠져 있는 코드의 odex부분때문에 곯머리 썩지 않아도 된다는
것입니다.
결론은 deodex는 odex를 dex로
재컴파일한 다음에 apk 안에 다시 쑤셔 넣는 것을 말합니다.
<### Zipalign이란? ###>
Zipalign을 하게 됨으로써 안드로이드는 어플리케이션과 조금 더 효율적으로 상호작용을 할
수 있게 됩니다. 따라서 이로 인해 전체적인 시스템과 어플리케이션의 실행을 빠르게 할 수 있습니다. 구글에서는 Zipalign을 강하게
권유하는군요. 그래서 했습니다. -_-)
안드로이드에선, 각각의 어플에 적재된 데이터 파일들이 다중 프로세스에 의해 이용됩니다. 홈
어플리케이션은 다른 어플의 이름과 아이콘에 관한 자원을 읽어들이고, 시스템 서버는 다양한 이유때문에 어플의 자원을 읽습니다. 그리고 명백하게,
어플 자기 자신도 자원들을 읽습니다.
안드로이드의 이 자원관리 코드는 4바이트 경계들로 메모리-맵핑
(Wh.....What?..-0-)되었을 때 효율적으로 이용될 수 있습니다. 하지만 이 자원들이 4바이트 정렬이 되지 않는다면, 즉
zipalign이 되지 않는다면, 이를 명확하게 읽기 위한 과정이 필요하므로 약간의 느려짐과 추가적인 메모리 소비를
보입니다.
따라서 우리는 zipalign 툴을 이용해 어플리케이션 자원들을 4바이트로 정렬하는 것입니다.
감사합니다!!