Android常见的异常之ClassNotFoundException--Didn't find class
两个可以完美运行的程序合在一起就会报以下的错误,彷徨了好久,终于迎来答案:
报的异常(还有很多相似的异常,这里只截取了一部分)是:
解决方案:
还是先解决打包问题,回头再研究那些高深的动态化加载技术。偷懒一下咯考虑到投入产出比,决定使用Google官方的multiDex解决。(Google的补丁方案啊,不会再有坑了吧?后面才发现还是太天真) 该方案有两步:
1.修改gradle脚本来产生多dex。
2.修改manifest 使用MulitDexApplication。
步骤1.在gradle脚本里写上:
android { compileSdkVersion 21 buildToolsVersion "21.1.0" defaultConfig { ... minSdkVersion 14 targetSdkVersion 21 ... // Enabling multidex support. multiDexEnabled true } ...}dependencies {compile 'com.android.support:multidex:1.0.0'}
步骤2. manifest声明修改
<?xml version="1.0" encoding="utf-8"?>...
如果有自己的Application,继承MulitDexApplication。如果当前代码已经继承自其它Application没办法修改那也行,就重写 Application的attachBaseContext()这个方法。
@Overrideprotected void attachBaseContext(Context base) { super.attachBaseContext(base); MultiDex.install(this); }
run一下,可以了!但是dex过程好像变慢了。。。
文档还写明了multiDex support lib 的局限。瞄一下是什么:
1.在应用安装到手机上的时候dex文件的安装是复杂的(complex)有可能会因为第二个dex文件太大导致ANR。请用proguard优化你的代码。呵呵
2.使用了mulitDex的App有可能在4.0(api level 14)以前的机器上无法启动,因为Dalvik linearAlloc bug(Issue 22586) 。请多多测试自祈多福。用proguard优化你的代码将减少该bug几率。呵呵
3.使用了mulitDex的App在runtime期间有可能因为Dalvik linearAlloc limit (Issue 78035) Crash。该内存分配限制在 4.0版本被增大,但是5.0以下的机器上的Apps依然会存在这个限制。
4.主dex被dalvik虚拟机执行时候,哪些类必须在主dex文件里面这个问题比较复杂。build tools 可以搞定这个问题。但是如果你代码存在反射和native的调用也不保证100%正确。呵呵
感觉这就是个坑啊。补丁方案又引入一些问题。但是插件化方案要求对现有代码有比较大的改动,代价太大,而且动态化加载框架意味着维护成本更高,会有更多潜在bug。所以先测试,遇到有问题的版本再解决。
这种顽固没有头绪的bug是不好找,必须我们亲自遇见才能更好的解决它,希望能帮助和我有相同问题的同志。
详细可以访问:http://www.open-open.com/lib/view/open1452264136714.html
更多相关文章
- Android切近实战(四)
- 使用Android(安卓)Studio发布私有库到仓库中心
- 修改Android中Spinner的显示及下拉样式的四种方法
- Android开发过程遇到的安装好的APP打开程序崩溃,或者安装后应用列
- 自动化代码检查优化Lint
- 第三部分:Android(安卓)应用程序接口指南---第二节:UI---第二章 输
- Android直播实现(一)Android端推流、播放
- Android之代码写布局
- Android中导入工程出现Project has no default.properties file!