對Too many classes in –main-dex-list,main dex capacity exceded提供簡單幾種方案吨拍。
問題：
這里寫圖片描述
這個(gè)問題出現(xiàn)在使用分包庫后褪猛，main-dex里面的方法數(shù)超出。
gradle plugin版本：2.+
gralde 版本：2.10+
簡單提供一些解決方案：
1羹饰、使用Android官方提供方案伊滋，見Configure Apps with Over 64K Methods，里面這樣說的队秩，
Avoiding the 64K Limit
Before configuring your app to enable use of 64K or more method references, you should take steps to reduce the total number of references called by your app code, including methods defined by your app code or included libraries. The following strategies can help you avoid hitting the dex reference limit:
Review your app’s direct and transitive dependencies - Ensure any large library dependency you include in your app is used in a manner that outweighs the amount of code being added to the application. A common anti-pattern is to include a very large library because a few utility methods were useful. Reducing your app code dependencies can often help you avoid the dex reference limit.
Remove unused code with ProGuard - Configure the ProGuard settings for your app to run ProGuard and ensure you have shrinking enabled for release builds. Enabling shrinking ensures you are not shipping unused code with your APKs.
Using these techniques can help you avoid the build configuration changes required to enable more method references in your app. These steps can also decrease the size of your APKs, which is particularly important for markets where bandwidth costs are high.
還說了要配合使用Android官方提供的分包庫笑旺。當(dāng)然這個(gè)方案是可以解決目前我們提出的這個(gè)問題的。但是如果是在開發(fā)環(huán)境中去使用proguard的話馍资，請問還讓苦逼的程序員怎么調(diào)試燥撞？心塞啊。迷帜。。
所以我們強(qiáng)大的酷狗的同學(xué)們提出的解決方案色洞，作為內(nèi)部技術(shù)戏锹，目前好像還沒有開源出來，這樣就不貼出來了火诸。但是酷狗同學(xué)提出的方法問題是可以解決锦针，但是解決前要經(jīng)歷一次陣痛，我在嘗試幾次后置蜀，果斷放棄奈搜。其中的陣痛比用Proguard方案要痛苦多了。
于是后來我找到了一個(gè)簡單有效的方案盯荤，目前暫時(shí)解決了問題馋吗。在工程目錄下的build.gradle中修改：
dependencies {
classpath 'com.android.tools.build:gradle:2.2.0+'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
好了，現(xiàn)在讓我們安靜的做一個(gè)程序員吧秋秤。：）宏粤。。灼卢。绍哎。
