Android Studioはandroid-support-multidexを利用して65536問題(64 k問題)を解決
64 kの各種異常
アプリケーションとライブラリの参照が一定の規模に達すると、構築エラーに遭遇し、Androidアプリケーションの構築アーキテクチャの制限に達していることがわかります.以前のバージョンの構築システムでは、このエラーが次のように報告されていました.
最新バージョンのAndroid構築システムでは、異なるエラーが表示されますが、同じ問題です.
あるいは(私が出会ったのはこのようなものです)
上のエラーは、共通の数字:65536を示しています.この数字は、参照の総数を表し、単一呼び出しのコードDalvikで実行可能(Dex)バイトコードファイルを表すことが重要です.もしあなたのAndroidアプリにこのエラーが発生したら、おめでとうございます.あなたのコードはすでに一定の量に達しています.この制限を解決し、アプリケーションの構築を継続する方法について説明します.
64 k参照制限について
Androidアプリケーション(APK)は、Dalvik実行可能ファイルの形式で実行可能なバイトコードファイル(DEX)ファイルを含み、コンパイルされたコードが含まれてアプリケーションを実行します.Dalvik実行可能仕様制限Dexファイルには、Androidフレームワークメソッド、Libraryメソッドの合計数、および独自のコードメソッドの合計数を含む65536のメソッドが含まれています.65536は64だから×1024、この制限は「64 k参照制限」と呼ばれる.この限界は、アプリケーションの構築プロセスを構成する必要があり、複数のDEXファイルを生成する必要があるため、multidex構成と呼ばれています.
原因と注意事項を分析する
解決策はAndroid 5.0以上のシステムと5.0以下のシステムに分けられます.客官たちは焦らないで、まず私が原因を分析しているのを見てください.結局、私はハハを装う必要があります.
一、Android 5.0以下のバージョン
Android 5.0(API leve 21)以前のシステムはDalvikを使用してアプリケーションコードを実行していた.デフォルトでは、Dalvikは1つのapkに1つのDexファイルしかないことを制限します.この制限を回避するために、multidex support libraryを使用することができます.これは私たちのAPKの主なDEXファイルの一部となり、私たちのAPKが他のDEXファイルとコードにアクセスすることを管理します.
注意:minSdkValersonが20以下の場合、Android 4.4(API leve 20)以下のデバイスで実行する場合は、Android Studioの即時実行を無効にする必要があります.
二、Android 5.0以降
Android 5.0(API leve 21)以上のシステムでruntimeを使用するのはARTで、アプリケーションのapkファイルから複数のDEXファイルをロードすることを原生でサポートしています.ARTはアプリケーションのインストール時にアプリケーションをプリコンパイルし、複数のclasses(..N)をスキャンする.dexファイルを1つにコンパイルする.oatのファイル.さらにAndroid 5.0 runtimeの詳細については、インスタント実行-instant-runを参照してください.
注意:Android Studioを使用してアプリケーションを自動的に構成する場合は、アプリケーションのminSdkValersionを21以上に設定する必要があります.アプリのDebugバージョンですぐにしか動作しないので、releaseバージョンの構築を構成するときにmultidexで64 kの制限を避ける必要があります.
64 k制限は極力避ける
私たちのAppが64 k以上のメソッドリファレンスを有効にするように構成する前に、アプリケーションコード内のスケジューリングの総数を減らすことができます.私たち自身のアプリケーションのメソッドとサードパーティのライブラリを含めて、次のいくつかのポリシーが役立ちます.
あなたのAPPの直接的および間接的な過度な依存関係を確認します.あるLibarayのいくつかの方法または機能を使用する場合、このライブラリは非常に大きく、この依存を減らすことは64 kの問題を回避するのに非常に効果的です.
本格的なパッケージ構築では、コード混同器ProGuard混同を使用して未使用のコードを削除します.つまり、使用していないコードを私たちのapkにパッケージしません.
上記の方法を使用すると、アプリケーションで無駄な方法を生成しすぎたり、apkのサイズを小さくしたりすることを避けることができます.これは、自分のサーバでappの更新とアップグレードを行う学生にとって非常に役立ちます.
ここでは、次の玉剛さんのプラグイン式開発フレームワークをお勧めします.https://github.com/singwhatiwanna/dynamic-load-apk、共同参加開発者:田啸、宋思宇.
64 k問題の解決
まず、メインmoduleのbuildを変更します.gradleファイル
gradleでは
ステップ2、
二つのケース
1つ目は、アプリがApplicationクラスを書き換えていない場合は、
2つ目の場合、アプリケーションクラスを書き換えた場合は、
アプリケーションの登録
Multidexライブラリの制限要因
DEXファイルをデバイスにインストールするプロセスは非常に複雑で、2番目のDEXファイルが大きすぎると、アプリケーションが応答しない可能性があります.この場合、ProGuardを使用してDEXファイルのサイズを小さくする必要があります.
Dalvik linearAllocのBugのため、Android 4.0以前のバージョンではアプリケーションが起動できない可能性があります.アプリケーションがこれらのバージョンをサポートする場合は、テストを多く実行する必要があります.
同様にDalvik linearAllocの制限のため、大量のメモリを要求するとクラッシュする可能性があります.Dalvik linearAllocは固定サイズのバッファです.アプリケーションのインストール中にdexoptというプログラムが実行され、現在の機種で実行する準備ができます.dexoptはLinearAllocを用いてアプリケーションのメソッド情報を格納する.Android 2.2と2.3のバッファは5 MB、Android 4.xは8 MBまたは16 MBに向上した.メソッドの数が多すぎるとバッファを超えて大きくなるとdexoptがクラッシュします.
Multidexコンストラクションツールでは、最初のDEXファイルに含めるクラスを指定することはサポートされていません.そのため、元のコードからJavaコードにアクセスする必要があるクラスなどのクラスライブラリが使用できなくなる可能性があります.
Multidexを使用した構築最適化
一、したがって、アプリケーションにliraryエンジニアリングが含まれている場合、次のエラーが発生する可能性があります.
プリコンパイルを無効にする必要があります.
二、運転中に次のエラーが発生した場合:
Javaスタックのメモリサイズを大きくする必要があります.
三、Android leve 21以上のSDKバージョンでの稼働速度の向上.ART-supportedフォーマットを使用してmultidex出力を生成すると、時間を節約できます.そのため、デバッグの使用も5.0以下に互換性がある必要はありません.そのため、最低バージョンを構成するときは、次のような互換性があります.
Android plugin Gradleバージョン1.1を下回ったらどうする?
次の依存multidex-instrumentationを追加する必要があります.
Eclipse Jarパッケージのダウンロード:http://download.csdn.net/detail/yanzhenjie1003/9566518公式リファレンス:https://developer.android.com/tools/building/multidex.html
以上の内容は厳振傑のブログから転載しました.http://blog.csdn.net/yanzhenjie1003
これで終わりだと思ってるのか?
パッケージまたはコンパイル時にOOMが発生した場合は、gradle-propertiesを以下の記事を参照して変更してください.
http://blog.csdn.net/oshenli1/article/details/52622009
アプリケーションとライブラリの参照が一定の規模に達すると、構築エラーに遭遇し、Androidアプリケーションの構築アーキテクチャの制限に達していることがわかります.以前のバージョンの構築システムでは、このエラーが次のように報告されていました.
Conversion to Dalvik format failed:
Unable to execute dex: method ID not in [0, 0xffff]: 65536UNEXPECTED TOP-LEVEL EXCEPTION:
java.lang.IllegalArgumentException: method ID not in [0, 0xffff]: 65536
at com.android.dx.merge.DexMerger$6.updateIndex(DexMerger.java:501)
at com.android.dx.merge.DexMerger$IdMerger.mergeSorted(DexMerger.java:282)
at com.android.dx.merge.DexMerger.mergeMethodIds(DexMerger.java:490)
at com.android.dx.merge.DexMerger.mergeDexes(DexMerger.java:167)
at com.android.dx.merge.DexMerger.merge(DexMerger.java:188)
at com.android.dx.command.dexer.Main.mergeLibraryDexBuffers(Main.java:439)
at com.android.dx.command.dexer.Main.runMonoDex(Main.java:287)
at com.android.dx.command.dexer.Main.run(Main.java:230)
at com.android.dx.command.dexer.Main.main(Main.java:199)
at com.android.dx.command.Main.main(Main.java:103) 最新バージョンのAndroid構築システムでは、異なるエラーが表示されますが、同じ問題です.
trouble writing output:
Too many field references: 131000; max is 65536.
You may try using --multi-dex option.あるいは(私が出会ったのはこのようなものです)
Error:The number of method references in a .dex file cannot exceed 64K.上のエラーは、共通の数字:65536を示しています.この数字は、参照の総数を表し、単一呼び出しのコードDalvikで実行可能(Dex)バイトコードファイルを表すことが重要です.もしあなたのAndroidアプリにこのエラーが発生したら、おめでとうございます.あなたのコードはすでに一定の量に達しています.この制限を解決し、アプリケーションの構築を継続する方法について説明します.
64 k参照制限について
Androidアプリケーション(APK)は、Dalvik実行可能ファイルの形式で実行可能なバイトコードファイル(DEX)ファイルを含み、コンパイルされたコードが含まれてアプリケーションを実行します.Dalvik実行可能仕様制限Dexファイルには、Androidフレームワークメソッド、Libraryメソッドの合計数、および独自のコードメソッドの合計数を含む65536のメソッドが含まれています.65536は64だから×1024、この制限は「64 k参照制限」と呼ばれる.この限界は、アプリケーションの構築プロセスを構成する必要があり、複数のDEXファイルを生成する必要があるため、multidex構成と呼ばれています.
原因と注意事項を分析する
解決策はAndroid 5.0以上のシステムと5.0以下のシステムに分けられます.客官たちは焦らないで、まず私が原因を分析しているのを見てください.結局、私はハハを装う必要があります.
一、Android 5.0以下のバージョン
Android 5.0(API leve 21)以前のシステムはDalvikを使用してアプリケーションコードを実行していた.デフォルトでは、Dalvikは1つのapkに1つのDexファイルしかないことを制限します.この制限を回避するために、multidex support libraryを使用することができます.これは私たちのAPKの主なDEXファイルの一部となり、私たちのAPKが他のDEXファイルとコードにアクセスすることを管理します.
注意:minSdkValersonが20以下の場合、Android 4.4(API leve 20)以下のデバイスで実行する場合は、Android Studioの即時実行を無効にする必要があります.
二、Android 5.0以降
Android 5.0(API leve 21)以上のシステムでruntimeを使用するのはARTで、アプリケーションのapkファイルから複数のDEXファイルをロードすることを原生でサポートしています.ARTはアプリケーションのインストール時にアプリケーションをプリコンパイルし、複数のclasses(..N)をスキャンする.dexファイルを1つにコンパイルする.oatのファイル.さらにAndroid 5.0 runtimeの詳細については、インスタント実行-instant-runを参照してください.
注意:Android Studioを使用してアプリケーションを自動的に構成する場合は、アプリケーションのminSdkValersionを21以上に設定する必要があります.アプリのDebugバージョンですぐにしか動作しないので、releaseバージョンの構築を構成するときにmultidexで64 kの制限を避ける必要があります.
64 k制限は極力避ける
私たちのAppが64 k以上のメソッドリファレンスを有効にするように構成する前に、アプリケーションコード内のスケジューリングの総数を減らすことができます.私たち自身のアプリケーションのメソッドとサードパーティのライブラリを含めて、次のいくつかのポリシーが役立ちます.
あなたのAPPの直接的および間接的な過度な依存関係を確認します.あるLibarayのいくつかの方法または機能を使用する場合、このライブラリは非常に大きく、この依存を減らすことは64 kの問題を回避するのに非常に効果的です.
本格的なパッケージ構築では、コード混同器ProGuard混同を使用して未使用のコードを削除します.つまり、使用していないコードを私たちのapkにパッケージしません.
上記の方法を使用すると、アプリケーションで無駄な方法を生成しすぎたり、apkのサイズを小さくしたりすることを避けることができます.これは、自分のサーバでappの更新とアップグレードを行う学生にとって非常に役立ちます.
ここでは、次の玉剛さんのプラグイン式開発フレームワークをお勧めします.https://github.com/singwhatiwanna/dynamic-load-apk、共同参加開発者:田啸、宋思宇.
64 k問題の解決
Android SDK Build Tools 21.1以降のbuildツールでは、Android plugin gradleが使用されます.Android SDK build toolsとAndroid supportを最新バージョンに更新し、multidexでアプリケーションを構成することを確認します.私たちは2つのステップをしなければなりません.まず、メインmoduleのbuildを変更します.gradleファイル
gradleでは
multidexに依存し、multiDexEnableを有効にします.android {
compileSdkVersion 21
buildToolsVersion
defaultConfig {
...
minSdkVersion 14
targetSdkVersion 21
...
// Enabling multidex support.
multiDexEnabled true
}
...
}
dependencies {
compile 'com.android.support:multidex:1.0.1'
}ステップ2、
android.support.multidex.MultiDexApplicationクラスを継承二つのケース
1つ目は、アプリがApplicationクラスを書き換えていない場合は、
MultiDexApplicationを直接継承し、manifestにいます.xmlにアプリケーションを登録すればいいです.2つ目の場合、アプリケーションクラスを書き換えた場合は、
attachBaseContext(Context)メソッドを書き換え、MultiDex.install(this);を呼び出すとよい.protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);MultiDexApplicationのソースコードをめくったので、中はこの方法を書き直しただけです.public class MultiDexApplication extends Application {
public MultiDexApplication() {
}
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
MultiDex.install(this);
}
}アプリケーションの登録
<?xml version= encoding=?>
<manifest xmlns:android=
package=>
<application
...
android:name=" Application ">
...
</application>
</manifest>Multidexライブラリの制限要因
DEXファイルをデバイスにインストールするプロセスは非常に複雑で、2番目のDEXファイルが大きすぎると、アプリケーションが応答しない可能性があります.この場合、ProGuardを使用してDEXファイルのサイズを小さくする必要があります.
Dalvik linearAllocのBugのため、Android 4.0以前のバージョンではアプリケーションが起動できない可能性があります.アプリケーションがこれらのバージョンをサポートする場合は、テストを多く実行する必要があります.
同様にDalvik linearAllocの制限のため、大量のメモリを要求するとクラッシュする可能性があります.Dalvik linearAllocは固定サイズのバッファです.アプリケーションのインストール中にdexoptというプログラムが実行され、現在の機種で実行する準備ができます.dexoptはLinearAllocを用いてアプリケーションのメソッド情報を格納する.Android 2.2と2.3のバッファは5 MB、Android 4.xは8 MBまたは16 MBに向上した.メソッドの数が多すぎるとバッファを超えて大きくなるとdexoptがクラッシュします.
Multidexコンストラクションツールでは、最初のDEXファイルに含めるクラスを指定することはサポートされていません.そのため、元のコードからJavaコードにアクセスする必要があるクラスなどのクラスライブラリが使用できなくなる可能性があります.
Multidexを使用した構築最適化
一、したがって、アプリケーションにliraryエンジニアリングが含まれている場合、次のエラーが発生する可能性があります.
UNEXPECTED TOP-LEVEL EXCEPTION:
com.android.dex.DexException: Library dex files are not supported in multi-dex mode プリコンパイルを無効にする必要があります.
android {
...
dexOptions {
preDexLibraries = false
}
...
} 二、運転中に次のエラーが発生した場合:
UNEXPECTED TOP-LEVEL ERROR:
java.lang.OutOfMemoryError: Java heap space Javaスタックのメモリサイズを大きくする必要があります.
maxProcessCount 4 // this is the default value
javaMaxHeapSize "2g"三、Android leve 21以上のSDKバージョンでの稼働速度の向上.ART-supportedフォーマットを使用してmultidex出力を生成すると、時間を節約できます.そのため、デバッグの使用も5.0以下に互換性がある必要はありません.そのため、最低バージョンを構成するときは、次のような互換性があります.
android {
productFlavors {
// .
dev {
// Android leve 21
minSdkVersion 21
}
prod {
// .
minSdkVersion 14
}
}
...
}
dependencies {
compile 'com.android.support:multidex:1.0.1'
}Android plugin Gradleバージョン1.1を下回ったらどうする?
次の依存multidex-instrumentationを追加する必要があります.
dependencies {
androidTestCompile('com.android.support:multidex-instrumentation:1.0.1') {
exclude group: 'com.android.support', module: 'multidex'
}
}Eclipse Jarパッケージのダウンロード:http://download.csdn.net/detail/yanzhenjie1003/9566518公式リファレンス:https://developer.android.com/tools/building/multidex.html
以上の内容は厳振傑のブログから転載しました.http://blog.csdn.net/yanzhenjie1003
これで終わりだと思ってるのか?
パッケージまたはコンパイル時にOOMが発生した場合は、gradle-propertiesを以下の記事を参照して変更してください.
http://blog.csdn.net/oshenli1/article/details/52622009