提示！應用程序的安裝有兩種情況，第一：首次啟動系統時安裝。第二：系統啟動完畢后安裝。

本篇博文基于第一種安裝場景。在系統首次啟動的場景中，系統會對/system/app、/system/priv-app、/data/app文件夾下的全部APK進行dex字節碼到本地機器碼的翻譯，相同也會對/system/framework文件夾下的APK或者JAR文件，以及這些APK所引用的外部JAR。進行dex字節碼到本地機器碼的翻譯。這樣能夠保證除了應用之外。系統中使用Java來開發的系統服務，也會統一地從dex字節碼翻譯成本地機器碼。具體內容請移步老羅的博客Android ART執行時無縫替換Dalvik虛擬機的過程分析。

一、JVM、DVM、ART虛擬機了解

• JVM虛擬機執行的是java字節碼：

java->java bytecode（class）->java bytecode（jar） 注！

java虛擬機基于棧，基于棧的機器必須使用指令來加載和操作棧上的數據，所需指令相對來說比較多。

• Dalvik虛擬機解釋運行的dex字節碼：

java->java bytecode（class）->dalvik bytecode（dex） 注：相對JVM，Dalvik基于寄存器，且經過優化并同意有限的內存中同一時候執行多個虛擬機實例。每一個Dalvik應用作為一個獨立的Linxu進程執行。假設一個應用中有非常多類，編譯后會對應生成非常多class文件。class文件之間也會有不少冗余信息，dex格式文件把全部classs文件內容整合到一個文件。這樣能夠降低總體文件占用，IO操作，同一時候也提高了類的查找速度。

此外。dex格式文件添加了新的操作碼支持，文件結構也相對簡潔，使用等長的指令來提高解析速度。

并且dex文件會盡量擴大僅僅讀結構的大小，來提高進程間數據共享的速度。

• ART虛擬機運行的本地機器碼：

java->java bytecode（class）->dalvik bytecode（dex）->optimized android runtime machine code（oat） 注：ART所使用的AOT（Ahead-Of-Time）編譯。在應用首次安裝時，字節碼預編譯成機器碼存儲在本地，也就是說在程序執行前編譯。而Dalvik是典型的JIT（Just_In_Time），此模式下，應用每次執行的時候，字節碼都須要即時編譯器轉換為機器碼再執行，也就是在程序執行時編譯。因此在App執行時。ART模式相對于Dalvik省去了解釋字節碼的過程，占用內存也對應降低，進而提高App的執行效率。
二、Odex 從上面一節中我們知道，在編譯打包APK時，Java類會被編譯成一個或者多個字節碼文件（.class），通過dx工具CLASS文件轉換成一個DEX（Dalvik Executable）文件。 通常情況下，我們看到的Android應用程序實際上是一個以.apk為后綴名的壓縮文件。我們能夠通過壓縮工具對apk進行解壓，解壓出來的內容中有一個名為classes.dex的文件。

那么我們首次開機的時候系統須要將其從apk中解壓出來保存在data/app文件夾中。

假設當前執行在Dalvik虛擬機下，Dalvik會對classes.dex進行一次“翻譯”?！胺g”的過程也就是守護進程installd的函數dexopt來對dex字節碼進行優化，實際上也就是由dex文件生成odex文件。終于odex文件被保存在手機的VM緩存文件夾data/dalvik-cache下（注意。這里所生成的odex文件依然是以dex為后綴名，格式如：system@priv-app@Settings@Settings.apk@classes.dex）。 假設當前執行于Art模式下， ? ?Art相同會在首次進入系統的時候調用/system/bin/dexopt工具來將dex字節碼翻譯成本地機器碼，保存在data/dalvik-cache下。 那么這里須要注意的是，不管是對dex字節碼進行優化，還是將dex字節碼翻譯成本地機器碼，終于得到的結果都是保存在同樣名稱的一個odex文件中面的，可是前者相應的是一個dey文件（表示這是一個優化過的dex），后者相應的是一個oat文件（實際上是一個自己定義的elf文件，里面包括的都是本地機器指令）。

簡單來說不管是Art模式。還是DVM，優化的結果都是一個odex文件，僅僅是這兩種odex文件有著本質的差別（一個是dey字節碼，一個是oat機器碼）。之所以這么設計。主要通過這樣的方式，原來不論什么通過絕對路徑引用了該odex文件的代碼就都不須要改動了。能夠理解為這是art與dalvik兼容的結果。

因為在系統首次啟動時會相應用進行安裝。那么在預置APK比較多的情況下。將會大大添加系統首次啟動的時間。從前面的描寫敘述可知，既然不管是DVM還是ART，對DEX的優化結果都是保存在一個同樣名稱的odex文件，那么假設我們把這兩個過程在ROM編譯的時候預處理提取Odex文件將會大大優化系統首次啟動的時間。
三、預編譯提取Odex 在BoardConfig.mk中定義：WITH_DEXPREOPT := true。打開這個宏之后，不管是有源代碼還是無源代碼的預置apk預編譯時都會提取odex文件。

只是這里須要注意的是打開WITH_DEXPREOPT 宏之后，預編譯時提取Odex會添加一定的空間。預置太多apk。會導致system.img 過大。而編譯只是。遇到這樣的情況能夠通過刪除apk中的dex文件、調大system.img的限制大小，或在預編譯時跳過一些apk的odex提取。 比如跳過helloworld應用提取的方法例如以下： 在文件夾\build\core\dex_preopt_odex_install.mk中加入紅色標記的代碼： ifeq ($(LOCAL_MODULE),helloworld) LOCAL_DEX_PREOPT:= endif build_odex:= installed_odex:= .... helloworld可替換為須要跳過提取odex的apk的LOCAL_MODULE名字，如Settings等。
《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Android首次启动时间长优化之预编译提取Odex的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。