저는 최근 안드로이드 런타임을 연구 중입니다. 특히 dex2oat 도구에 중점을 둡니다. 그러나 dex2oat는 격리되어 있지 않지만 Android의 부트 이미지, android-root, 명령어 세트, 런타임 arg 등과 함께 작동합니다.Android 컴파일러, 아키텍처 및 런타임, 어떻게 함께 작동합니까?
누구나 무엇을 사용하고 무엇을 사용하는지 설명 할 수 있습니까? 그리고 그들의 내부 연결?
좋아요. dex2oat은 새로운 Android 런타임 (ART)의 일부로 제공됩니다. 아이디어는 Android의 바이트 코드 인터프리터 (및 JIT 컴파일러)를 사전 컴파일러로 대체하고 컴파일 된 앱을로드하고 실행할 수있는 새로운 런타임을 제공하는 것입니다.
dex2oat 유틸리티 dex2oat
안드로이드가 현재 실행하는 각 프로세서 플랫폼에 대한 컴파일 옵션, 여러 컴파일러 및 코드 생성 백엔드를 많이 제공하는 전체 컴파일 제품군입니다. 따라서 누군가가 dex2oat을 참조하면 Android AOT 컴파일러 (suite)를 의미합니다. 그것의 입력 형식은 dex 바이트 코드이며 ELF 공유 객체 인 oat 파일을 출력합니다. 해석 (또는 JIT 컴파일)과 달리 AOT 컴파일의 장점은 응용 프로그램에 앞서 복잡한 최적화가 적용될 때 실행 시간을 늦추지 않는다는 것입니다. 또한 디바이스 컴파일러에 대해 이야기 할 때, 앱은 여전히 덱스 바이트 코드로 출하 될 수 있지만 구체적인 아키텍처를 위해 디바이스에서 컴파일됩니다. 내 지식으로는 ARM, MIPS 및 x86 용 백엔드가 현재 32 비트 및 64 비트 각각 있습니다.
부팅 이미지
사전 ART는, 안드로이드는 각 응용 프로그램 프로세스 및 프리로드 포크 및 최적화 목적을 위해 몇 가지 클래스를 사전 초기화하는 수정란을 사용했다. ART에서는 각 앱 프로세스에 미리로드해야하는 jar 라이브러리 세트가 한 번 컴파일 이미지로 컴파일됩니다. boot.oat와 boot.art의 두 파일로 구성됩니다. Boot.oat에는 컴파일 된 코드가 들어 있으며 boot.art에는 사전 초기화 된 힙이 들어 있습니다. 두 코드 모두 dex2oat으로 생성됩니다. 이 부팅 이미지는 각 앱의 프로세스에 최적화로로드됩니다. 애플 리케이션은 지금 귀리 파일을 컴파일으로
런타임 환경는
, ART로드하고 실행할 수있는 새로운 런타임을 제공합니다. 따라서 아이디어는 ELF 공유 객체를 사전 초기화 된 app 프로세스로로드하고 응용 프로그램을 실행하는 것입니다. 코드가 이미 컴파일되었으므로 런타임에 해석 할 필요가 없습니다. 일부 예외는 낮은 영구 저장 장치 (귀리 파일이 많음)에서 실행되는 시스템, 디버깅 된 응용 프로그램 등입니다.이 경우 ART는 해석으로 되돌아 갈 수 있습니다. 그러나 일반적으로 AOT 컴파일은 새로운 기본값입니다.