Failure[INSTALL_FAILED_DEXOPT]のソリューションについて.
ある同僚はpackage/appの下の工事を修正した後、full buildを思わないで、そこで直接mmを見つけてからAPK直接adb installを見つけて次のように報告しました.
まず問題が発生した原因を話します.
userバージョンでmmでapkをコンパイルするとoutディレクトリの下で生成されます.apkと.odexの2つのファイルは、実行速度を速めるためにdexを分割した事前最適化処理です.しかし、一般的にはmmで完全なapkをコンパイルする必要があり、adbで直接インストールすればデバッグできます.これには2つの選択肢があり、1つの選択肢は非userバージョンにカットしてコンパイルすることであり、もう1つのスキームは現在コンパイルする必要があるappディレクトリである.mkファイルには、現在のAPKに対する事前最適化処理を閉じるコードを追加すればよい.
ではなぜuserバージョンはapkを事前に最適化するのでしょうか.device.mkの中かdeviceの下か.mkファイルには次のコードがあります.
ではuserバージョンでWITH_DEXPREOPTはtrueになります.そしてWITH_DEXPREOPTがLOCAL_を決定しましたDEX_PREOPTの値.
では、問題はまた来て、何が予備最適化なのか、予備最適化の原理は何なのか、予備最適化のメリットは何なのか、これらの問題を持って見てみましょう.
まず、事前最適化とは何か.
Androidにとって、事前最適化とは、Androidがlaunchやruntimeで行う必要があることをコンパイル期間に繰り上げてAndroidの起動速度の加速とアプリの実行速度の加速を達成することです.
そしてAndroidプリチューニングの原理.
5.0までAndroidでずっと使っていたDVM仮想マシンが、5.0になってARTに変わりました.
あれ、どうして急に仮想マシンといえば、焦らないでください.まずJavaのいくつかの仮想マシンの動作メカニズムを見てみましょう.
Javaファイルから仮想マシン実行コードまで、ARTがDVMよりもOATを多くするプロセスを見ることができます.
ARTが使用するAOT(Ahead-Of-time)コンパイルは,初めてアプリケーションをインストールする際にバイトコードがマシンコードにプリコンパイルされてローカルに存在する.
DVMは典型的なJIT(Just-In-Time)であり、このモードでは、アプリケーションが実行するたびにバイトコードを即時にコンパイルしてマシンコードに変換して実行する必要がある.
これにより、ARTにとってバイトコードを解析するプロセスが省け、メモリの消費量も減少し、APPの稼働効率が向上します.
Failure [INSTALL_FAILED_DEXOPT]
まず問題が発生した原因を話します.
userバージョンでmmでapkをコンパイルするとoutディレクトリの下で生成されます.apkと.odexの2つのファイルは、実行速度を速めるためにdexを分割した事前最適化処理です.しかし、一般的にはmmで完全なapkをコンパイルする必要があり、adbで直接インストールすればデバッグできます.これには2つの選択肢があり、1つの選択肢は非userバージョンにカットしてコンパイルすることであり、もう1つのスキームは現在コンパイルする必要があるappディレクトリである.mkファイルには、現在のAPKに対する事前最適化処理を閉じるコードを追加すればよい.
LOCAL_DEX_PREOPT := false
ではなぜuserバージョンはapkを事前に最適化するのでしょうか.device.mkの中かdeviceの下か.mkファイルには次のコードがあります.
ifeq ($(TARGET_BUILD_VARIANT), user)
ifeq ($(WITH_DEXPREOPT),)
WITH_DEXPREOPT ?= true
ではuserバージョンでWITH_DEXPREOPTはtrueになります.そしてWITH_DEXPREOPTがLOCAL_を決定しましたDEX_PREOPTの値.
では、問題はまた来て、何が予備最適化なのか、予備最適化の原理は何なのか、予備最適化のメリットは何なのか、これらの問題を持って見てみましょう.
まず、事前最適化とは何か.
Androidにとって、事前最適化とは、Androidがlaunchやruntimeで行う必要があることをコンパイル期間に繰り上げてAndroidの起動速度の加速とアプリの実行速度の加速を達成することです.
そしてAndroidプリチューニングの原理.
5.0までAndroidでずっと使っていたDVM仮想マシンが、5.0になってARTに変わりました.
あれ、どうして急に仮想マシンといえば、焦らないでください.まずJavaのいくつかの仮想マシンの動作メカニズムを見てみましょう.
(1)JVM:JVM java 。Java JVM :java -> java bytecode(class) -> java bytecode(jar)。
(2)DVM:DVM dex 。Java DVM :java -> java bytecode(class) -> dalvik bytecode(dex)。
(3)ART:ART 。Java ART :java -> java bytecode(class) -> dalvik bytecode(dex) -> optimized android runtime machine code(oat)。
Javaファイルから仮想マシン実行コードまで、ARTがDVMよりもOATを多くするプロセスを見ることができます.
ARTが使用するAOT(Ahead-Of-time)コンパイルは,初めてアプリケーションをインストールする際にバイトコードがマシンコードにプリコンパイルされてローカルに存在する.
DVMは典型的なJIT(Just-In-Time)であり、このモードでは、アプリケーションが実行するたびにバイトコードを即時にコンパイルしてマシンコードに変換して実行する必要がある.
これにより、ARTにとってバイトコードを解析するプロセスが省け、メモリの消費量も減少し、APPの稼働効率が向上します.