Dalvik Optimization and Verification중에서 (dexopt)

출처 : http://anzero.blog.me/89651858

안드로이드 소스를 빌드해서 생성하면 dalvik문서가 생성되는데,

Android site에서는 공개되지 않은 것 같다.

dalvik vm 목적, 구현 mechanism, prepared dex등으로 구성되는데,

관심사순으로 재구성하여 발췌하였다.

There are at least three different ways to create a "prepared" DEX file, sometimes known as "ODEX" (for Optimized DEX):

1. The VM does it "just in time". The output goes into a special dalvik-cache directory. This works on the desktop andengineering-only device builds where the permissions on the dalvik-cache directory are not restricted. On production devices, this is not allowed.
2. The system installer does it when an application is first added. It has the privileges required to write to dalvik-cache.
3. The build system does it ahead of time. The relevant jar / apk files are present, but the classes.dex is stripped out. The optimized DEX is stored next to the original zip archive, not in dalvik-cache, and is part of the system image.

The dalvik-cache directory is more accurately $ANDROID_DATA/data/dalvik-cache. The files inside it have names derived from the full path of the source DEX

The goals led us to make some fundamental decisions:

• Multiple classes are aggregated into a single "DEX" file.
• DEX files are mapped read-only and shared between processes.
• Byte ordering and word alignment are adjusted to suit the local system.
• Bytecode verification is mandatory for all classes, but we want to "pre-verify" whatever we can.
• Optimizations that require rewriting bytecode must be doneahead of time.

They also run Linux, which provides virtual memory, processes andthreads, and UID-based security mechanisms.

The features and limitations caused us to focus on certain goals:

• Class data, notably bytecode, must be shared between multiple processes to minimize total system memory usage.
• The overhead in launching a new app must be minimized to keep the device responsive.
• Storing class data in individual files results in a lot of redundancy, especially with respect to strings. To conserve disk space we need to factor this out.
• Parsing class data fields adds unnecessary overhead during class loading. Accessing data values (e.g. integers and strings) directly as C types is better.
• Bytecode verification is necessary, but slow, so we want to verify as much as possible outside app execution.
• Bytecode optimization (quickened instructions, method pruning) is important for speed and battery life.
• For security reasons, processes may not edit shared code.

  [출처] Dalvik Optimization and Verification중에서 (dexopt)|작성자 포크맨