code cat

출처: Android Open Source code, dalvik/doc/dexopt.hml

Dalvik Optimization and Verification

Dalvik Optimization and Verification with dexopt

• class 데이터(특히 bytecode), 는 시스템 메모리 사용을 최소화하기 위해 프로세스간 공유함
• app을 띄울때 응답성을 높이기 위해 overhead를 줄임
• class 데이터를 각 개개별의 파일에 저장할 경우 낭비가 심하여, 이를 방지함
• class 데이터 파싱을 하면 class 로딩 시에 많은 overhead가 발생하므로, C 타입의 data value로 처리하는게 유리함
• Bytecode verification은 필요하나 느리므로, app의 실행외에 verify 하는 방향으로 추진
• Bytecode 최적화는 속도와 배터리 수명을 위해 매우 중요함
• 보안을 위해 프로세스는 공유 코드를 못 고침

결론적으로 다음과 같은 결과물이 필요하다.

• multiple class들은 하나의 "DEX" file로 통합됨
• DEX 파일은 read-only로 맵핑되며 프로세스간에 공유됨
• Byte ordering 과 word alignment는 local system에 맞게 변경가능함
• Bytecode verification은 필요하나 "pre-verify"를 함
• bytecode를 rewrite해야 하는 최적화는 반드시 선행되어야 함

VM Operation

어플리케이션 코드는 어플이름.jar 혹은 어플이름.apk 로 시스템이 전달되는데, 이는 단지 어플이름.zip 에 meta-data를 첨가한 것이다.  Dalvik DEX data 파일은 항상 clases.dex라고 표기된다.

bytecode는 zip 형태로 데이터가 압축되어 있고, 파일의 시작이 word-aligned가 아닐 수 있으므로, 메모리 맵핑되거나 zip 파일로부터 곧바로 실행이 불가능하다.  그러므로 classes.dex를 압축해제 하고 필요한 다른 액션(예를 들어 realignment, optimization, verification등)을 취해줘야 한다.  그럼 누가 이런 결과물을 만들어내고 저장해야 하는가??

Preparation

"preapred" DEX file을 생성하는데는 적어도 3가지의 방법이 있다.

1. VM 이 'Just-In-Time'(보통 JIT)을 통해 dalvik-cache 디렉터리에 결과물을 저장. desktop이나 engineering-only 디바이스에 적합하다.(dalvik-cache의 퍼미션 문제로 양산품에는 적용불가함)
2. dalvik-cache에 쓸 권한을 가진 시스템 인스톨러가 어플리케이션이 처음 추가되었을 때 한다. 
3. classes.dex를 제외한 관련 jar나 apk파일들을 이용해  빌드시스템이 선행적으로 진행한다. optimized DEX 파일은 오리지널 zip 아카이브 옆에 놓이며, 시스템 이미지의 일부분이 된다.