androiddx

㈠ 求解：在Android中無法使用混淆後的第三方包問題

本應該暴露出來的參數或者類名被你混淆了，或者你把原來的變數類型改變了 造成變數類型不匹配

㈡ Android手機的apk文件中的class.dex文件是什麼是做什麼用的呢

簡單說就是優化後的android版.exe。每個apk安裝包里都有。相對於PC上的java虛擬機能運行.class；android上的Davlik虛擬機能運行.dex。

作用

讓dalvik能夠運行。

dex好處

可以直接用DexClassLoader類載入，動態載入。於是只要在dex上加殼，在程序運行時脫殼，就可以規避靜態反編譯的風險。

(2)androiddx擴展閱讀

使用dex文件的原因

在Android系統中，一個App的所有代碼都在一個Dex文件裡面。Dex是一個類似Jar的包，存儲了很多Java編譯位元組碼的歸檔文件。

因為Android系統使用Dalvik虛擬機，所以需要把使用Java Compiler編譯之後的class文件轉換成Dalvik能夠執行的class文件。

㈢ android開發有沒有可以通過代碼將.class文件轉化成.dex文件的jar包

adt裡面有dx.jar，可以將class轉換成dex.

㈣ 安卓系統觸摸屏參數問題：P dX dY Xv Yv Prs Size

prs代表壓力值，越小越好！變成紅色表示數值已穩定或最大

㈤ android dex何時載入

1 問題
在Android系統中，一個App的所有代碼都在一個Dex文件裡面。Dex是一個類似Jar的存
儲了多有Java編譯位元組碼的歸檔文件。因為Android系統使用Dalvik虛擬機，所以需要把
使用Java Compiler編譯之後的class文件轉換成Dalvik能夠執行的class文件。這里需要強
調的是，Dex和Jar一樣是一個歸檔文件，裡面仍然是Java代碼對應的位元組碼文件。
當Android系統啟動一個應用的時候，有一步是對Dex進行優化，這個過程有一個專門的
工具來處理，叫DexOpt。DexOpt的執行過程是在第一次載入Dex文件的時候執行的。這
個過程會生成一個ODEX文件，即Optimised Dex。執行ODex的效率會比直接執行Dex文
件的效率要高很多。但是在早期的Android系統中，DexOpt有一個問題，也就是這篇文
章想要說明並解決的問題。DexOpt會把每一個類的方法id檢索起來，存在一個鏈表結構
裡面。但是這個鏈表的長度是用一個short類型來保存的，導致了方法id的數目不能夠超過
65536個。當一個項目足夠大的時候，顯然這個方法數的上限是不夠的。盡管在新版本的
Android系統中，DexOpt修復了這個問題，但是我們仍然需要對老系統做兼容。
2 思路
一種有效的解決思路是把Dex文件分割成多個較小的Dex。這就如同很多項目會把自己分
割成多個Jar文件一樣，不同的功能在不同的Jar文件裡面，通過一些配置和額外的操作，
可以讓虛擬機有選擇性的載入Jar文件。但是在Android系統中，一個應用是只允許有一
個Dex文件的。也就是說在編譯期的時候，所有的Jar文件最終會被合並成一個Dex文件。
我們沒有辦法在Apk文件裡面打包兩個Dex，讓DexOpt分別對兩個Dex文件做處理，而
Android系統也不會同時為一個Apk載入兩個Dex。
1
2.1 動態載入
如果我們把Dex分成多個文件，然後在程序運行的時候，再把多的那幾個動態的載入進來
是否可行呢？也就是說我們能否在運行時階段把代碼加入虛擬機中。對於虛擬機來說，其
實所有的代碼都是在運行時被載入進來的。而不同於C語言還存在著靜態鏈接。虛擬機在
所有Java代碼執行之前被啟動，然後開始把位元組碼載入到環境中執行，我們可以理解成所
有的代碼都是動態載入到虛擬機里的。
而說到載入，不得不說的是ClassLoader。它的工作就是載入.class文件。在Android的
Dalvik環境中，對應的是DexClassLoader，它們的功能是完全一樣的。ClassLoader的
一大特點就是它是一個樹狀結構。每個ClassLoader都有一個父親ClassLoader。也就是
說，ClassLoader不是把所有的Class放到一個巨大的數組或別的什麼數據結構中來處理。
ClassLoader在載入一個Jar中的類的時候，需要制定另一個ClassLoader作為父親節點，
當我們需要通過ClassLoader得到一個類類型的時候，ClassLoader會把請求優先交給父
親ClassLoader來處理，而父親ClassLoader又會交給它的父親，一直到根ClassLoader。
如果根ClassLoader有這個類，而返回這個類的類類型，否則把這個請求交給這個請求的
來源子ClassLoader。這是一種向上傳遞，向下分發的機制。這種情況下，對於調用著來
說，子ClassLoader永遠都是包含最多Class的ClassLoader。有一點我們需要注意，父親
ClassLoader只會向請求來源分發自己的處理結果。所以如果來源是自己，那麼如果沒有
請求類它就會返回空，而不是遍歷所有子ClassLoader去請求是否有被請求的類。
在Android系統中，對於一個應用來說，其實有兩個ClassLoader，一個是SystemClassLoader，這個ClassLoader裡面除了Java標準的類庫之外，還有一個android.jar，所有
Android Framework層的類都在這里。而另外一個重要的ClassLoader就是基於Android
Context的ClassLoader。所有屬於當前應用的類都是用這個ClassLoader來載入的，我們
可以在Android源碼中看到，所有的Activity，Service，View都是使用這個ClassLoader
來反射並創建的。我們暫時把它叫做ContextClassLoader。
3 載入外部Dex
3.1 構建一個Dex文件
這一步並不復雜，首先我們把所需要的.class文件或者是Jar文件和一些源碼一起編譯生
成一個Jar文件。然後使用Android SDK提供的dx工具把Jar文件轉成Dex文件。我們可以
提前對它進行ODex操作，讓它在被DexClassLoader載入的時候，跳過DexOpt的部分工
作，從而加快載入的過程。
2
3.2 DexClassLoader
現在的工作就是在運行時載入這個Dex文件了。我們可以在Application啟動的onCreate
方法裡面載入Dex，但是如果你的Dex太大，那麼它會讓你的App啟動變慢。我們也可以
使用線程去載入，但我們必須保證載入完成之後再進行某個外部類的請求。當然也可以真
正等到需要某個外部類的時候再進行Dex載入。這根本上取決於Dex文件本身的大小，太
大了可以預載入，而比較小可以等到實際需要的時候再載入。我們暫且把這個載入了外部
Dex的ClassLoader成為ExternalClassLoader
上面我們提到了樹形結構和系統中的多個ClassLoader，當我們載入外部Dex的時候，我
們是否需要指定一個父ClassLoader呢？我們當然需要一個父ClassLoader，否則我們ExternalClassLoader連一些基本的Java類都沒有，它根本不可能成功的載入一個Dex。進一
步的，我們要選擇哪一個ClassLoader來作為我們的父親呢？是SystemClassLoader還是
ExternalClassLoader？這是根據情況來定的，如果外部的Dex文件里沒有任何和Android
相關的代碼，那麼SystemClassLoader是我們的首選，否則我們就應該用ContextClassLoader。如果是後者的情況，我們的樹可以被看成一個鏈表。
3.3 外部的View, Acitivity等
我們知道，我們編寫的四大組建都不是由我們自己來創建的，是由系統來給我們構造並
管理其生命周期的。那麼這個過程是什麼樣的呢？拿Activity來舉例，我們需要通過調用
當前Activity/Context的startActivity，傳入一個Intent來調用啟動一個新的Activity。系
統有一個ActivityManager來處理這里的邏輯。這里的邏輯相當的復雜，但簡單來說，
ActivityManager會收到並處理這個Intent，從而決定是是啟動一個新的，還是把舊的放
到前台。它會先查找這個Activity在哪個應用裡面，這是通過掃描每個應用的AndroidManifest來確定。這些信息是在PackageManager裡面被檢索的。總之如果這個Activity
不再任何的manifest裡面，它就不可能被啟動。所以僅有一個Activity類是不夠的，我們
需要在manifest裡面聲明它。
上面是Activity的情況，Service之類的也是同理。那麼View怎麼辦？盡管我們可以直接創
建View，但是大部分的View都不是我們創建的，而是通過XML布局文件Inflate出來的。
也就是說，我們在XML定義了一些外部Dex裡面的View，那麼顯然這個XML是不能被成
功的Inflate的。因為除非系統會使用我們的ExternalClassLoader，否則它肯定是找不到
我們的類的：ContextClassLoader裡面並沒有外部Dex中的類。
也就是說問題的根本在於，對於那些Android系統為我們創建的對象，它是不能包含在外
部Dex裡面的。而Android系統中大部分的組建類的生命周期都交給了系統來管理。我們
3
不可能自己來創建這些類對象。那麼另一種思路：我們是不是可以通過使用我們的ExternalClassLoader來代替ContextClassLoader呢？盡管系統的ContextClassLoader是私有
的，但是我們可以通過反射強制的把它替換成我們的ExternalClassLoader。而對於那些
外部的組建（Activity等），盡管我們沒有它們的類，但是並不影響我們在AndroidManifest裡面聲明這個Activity。因為Android系統只是把它作為一個檢索，並不會真正檢查它
裡面的組建是不是真的在虛擬機環境中已經被載入了，只有真正使用Intent啟動某個組建
的時候才會去檢查。而只要我們保證這個時候我們已經載入了外部的ClassLoader，那麼
這個組建就可以被正常的啟動。
還有一點，除了我們要為外部可能有的組建在AndroidManifest裡面做聲明一外，那些外
部組建可能用到的許可權我們也需要一一聲明，例如如果外部Activity使用了相機功能，那
么如果我們的Manifest裡面沒有聲明使用相機功能的許可權的話，即便這個Activity能成功
為載入出來，仍然是不能使用的。
4 核心代碼段
載入外部Dex
mClassLoader = new DexClassLoader ( f . getAbsolutePath ( ) ,
mContext . getCacheDir ( ) . getAbsolutePath ( ) ,
null , mContext . getClassLoader ( ) ) ;
讓系統使用ExternalClassLoader
t r y {
F ie ld mMainThread = ge t F ie ld ( A c t i v i t y . class , 」mMainThread」) ;
Object mainThread = mMainThread . get ( a c t i v i t y ) ;
Class t hreadClass = mainThread . get Class ( ) ;
F ie ld mPackages = ge t F ie ld ( threadClass , 」mPackages」) ;
WeakReference<?> r e f ;
Map< St ring , ?> map =(Map< St ring , ? >) mPackages . get (mainThread ) ;
r e f = (WeakReference<? >) map . get (mContext . getPackageName ( ) ) ;
Object apk = r e f . get ( ) ;
Class apkClass = apk . get Class ( ) ;
F ie ld mClassLoader = ge t F ie ld ( apkClass , 」mClassLoader」) ;
mClassLoader . set (apk , classLoader ) ;
} catch ( I llegalArgument Except ion e) {
i f (DEBUG) {
e . print St ackTrace ( ) ;
}
} catch ( I llega lAc c essEx c ept ion e) {
i f (DEBUG) {
4
e . print St ackTrace ( ) ;
}
}
5

㈥ android dx.bat怎麼用

Android無法使用.BAT 批處理文件。

㈦ android和java的區別

android Java虛擬機和sun java虛擬機的主要區別體現在因為手機內存和硬體的限制，不可能直接將sun java虛擬機的機制搬過去，對於一些位元組、內存管理方面需要重新設計，一下是主要區別：
1、Dalvik 和標准 Java 虛擬機(JVM)
Dalvik 基於寄存器，而 JVM 基於棧。基於寄存器的虛擬機對於更大的程序來說，在它們編譯的時候，花費的時間更短。 JVM位元組碼中，局部變數會被放入局部變數表中，繼而被壓入堆棧供操作碼進行運算，當然JVM也可以只使用堆棧而不顯式地將局部變數存入變數表中。Dalvik位元組碼中，局部變數會被賦給65536個可用的寄存器中的任何一個，Dalvik指令直接操作這些寄存器，而不是訪問堆棧中的元素。
2、Dalvik 和 Java 位元組碼的區別
VM位元組碼由.class文件組成，每個文件一個class。JVM在運行的時候為每一個類裝載位元組碼。相反的，Dalvik程序只包含一個.dex文件，這個文件包含了程序中所有的類。Java編譯器創建了JVM位元組碼之後，Dalvik的dx編譯器刪除.class文件，重新把它們編譯成Dalvik位元組碼，然後把它們寫進一個.dex文件中。這個過程包括翻譯、重構、解釋程序的基本元素（常量池、類定義、數據段）。常量池描述了所有的常量，包括引用、方法名、數值常量等。類定義包括了訪問標志、類名等基本信息。數據段中包含各種被VM執行的函數代碼以及類和函數的相關信息（例如DVM所需要的寄存器數量、局部變數表、操作數堆棧大小），還有實例變數。
3、Dalvik 和 Java 運行環境的區別
Dalvik 經過優化，允許在有限的內存中同時運行多個虛擬機的實例，並且每一個Dalvik 應用作為一個獨立的Linux 進程執行。獨立的進程可以防止在虛擬機崩潰的時候所有程序都被關閉。
Dalvik虛擬機在android2.2之後使用JIT （Just-In-Time）技術，與傳統JVM的JIT並不完全相同，
Dalvik虛擬機有自己的 bytecode，並非使用 Java bytecode。

還有以下幾點：
1、Dalvik主要是完成對象生命周期管理，堆棧管理，線程管理，安全和異常管理，以及垃圾回收等等重要功能。
2、Dalvik負責進程隔離和線程管理，每一個Android應用在底層都會對應一個獨立的Dalvik虛擬機實例，其代碼在虛擬機的解釋下得以執行。
3、不同於Java虛擬機運行java位元組碼，Dalvik虛擬機運行的是其專有的文件格式Dex。

不過有一點是習慣了java語言開發的程序員，在android平台上同樣可以接著使用java的全部語法，只不過新增了很多知識點。

㈧ android程序運行時提示：the file dx.jar was not loaded from the SDK folder! 但是我有dx.jar這個文件

該提示意思是：
文件dx.jar沒有從SDK文件夾載入！
是不是你的SDK沒有將路徑載入到eclipse中？

㈨ android開發環境搭建出錯dx.jar

tools中有文件名為「android」的程序， 運行它， 選擇你要下載的版本， 下載。

㈩ android系統 主要有哪幾部分

android系統分為四部分，從高到低分別是：

1、Android應用層

2、Android應用框架層

3、Android系統運行層

4、Linux內核層

Android系統構架主要應用於ARM平台，但不僅限於ARM，通過編譯控制，在X86、MAC等體系結構的機器上同樣可以運行。

(10)androiddx擴展閱讀：

Android運行庫

Android包括了一個核心庫，該核心庫提供了JAVA編程語言核心庫的大多數功能。

每一個Android都擁有一個獨立的Dalvik虛擬機實例。Dalvik被設計成一個設備可以同時高效地運行多個虛擬系統。Dalvik虛擬機執行(.dex)的Dalvik可執行文件，該格式文件針對小內存使用做了優化。

同時虛擬機是基於寄存器的，所有的類都經由JAVA編譯器編譯，然後通過SDK中的「dx」工具轉化成.dex格式由虛擬機執行。