转载 原文地址:http://blog.csdn.net/fangrenlai1990/article/details/7584581
感谢作者方家仁兄
Android项目中如何正确的引入第三方jar包(工程)
最近在学习一个Android技术点时,需要在工程项目中引入第三方jar包,遇到的问题是在编译的时候能通过,但是在实际运行的时候会出错。后来经过调研发现,原来是在引入第三方jar包的时候出错了,现在总结已经成功的两种方式。
一 使用Build Path中的Order and Export选项卡
1.将实例Android项目(project源码)import到Eclipse中,这时由于第三方jar包路径和原作者的存放路径不一致,项目会提示红叉叉,不能进行编译;
2.下载第三包jar包3rd.jar保存到本地,然后通过Build Path→Configure Build Path→Libraries→Add external JARS,将3rd.jar添加到项目的Build Path中去,这时该Android项目上的红叉叉就会消失,项目能通过编译;
```
```点击“OK”
3.接着,我们到模拟器上Run下这个项目,模拟器启动是在是太慢了,这个时候,我们可以喝点水,上个厕所,站起来走走。程序员,要对自己的身体好一点。我这次就不去厕所了,写这篇文章呢。模拟器还崩溃了一次,悲剧,只得again......
结果:
到logcat中查错呗:
4.重新配置Build Path:
继续Build Path→Configure Build Path→Order and Export,将里面的3rd.jar勾选,点击OK
再run一次:
还是报错?!虾米情况!!!
别急Project→clean一下当前项目,再run一次就得到正确结果了。
Success!
思考:如果第三方jar包只有一个这样做还好说,如果在项目中引入的jar包很多,这是可参考第二种方法。
二 创建自己的 Source Folder
1.Build Path→New Source Folder→给第三方jar的文件夹起个名字,例如3rd.jar→将所有的第三方jar包全部复制黏贴到这个包下面:
2.复制黏贴所有第三方jar包:
3.这个时候,仅仅是将这个新建的Folder添加到Build Path中去,复制过来的3rd.jar还是没有添加进去的,这时,选中3rd jar文件下面的所有第三方jar包,右键→Add to Build Path:
```我们看看这里发生了什么变化:
为了区别之前的,我在这里clean一下。
结果:成功,success!
==================================================================================================================
总结:
其实这个问题的核心是:有没有将第三方jar包添加至新apk文件的Build Path中去。
什么是Build Path?其实在这里(Android Project最后构建成apk文件)顾名思义,就是最后apk文件构建的资源在该项目中存放的路径。结合这里的实际情况,在正确的Order and Export选项卡里面,默认勾选了3个路径:src、gen和我们自定义的3rd jar,这就表示,我们的3rd jar包将会直接构成最后的apk文件(部分还是全部?)。
我们结合Order and Export选项卡的注释来看下:构建class文件路径的顺序和导出条目,导出的条目对依赖的项目有效。
我们电脑上的Eclipse IDE开发环境是配置了本地的JDK环境的(环境变量classpath),我们将已经为Eclipse配置好的JDK环境当做第一方,我们为第二方,那么3rd.jar就是第三方了。(不知道正确与否,我是这么理解的)
在Eclipse上开发当前项目的时候,我们默认依赖的是本地JDK环境里面的工程(这里的工程就是一个个的jar文件),如果要引入第三方(工程)jar的话,必须要添加额外的jar文件(工程文件),保证能通过编译,也就是当前项目没有红叉叉,允许你去run。
当当前项目构建好(Build)apk文件(project)后,我们用模拟器去运行。请注意这时候环境开始发生了微妙的变化,现在当前的运行环境是Android SDK的dalvikvm(而不是为Eclipse配置的本机JRE环境,那是一般的Java项目的运行环境,我们现在是Android Project)。对于dalvikvm来说,apk是它的一个project;同理,在Eclipse开发过程中,当前项目明显是它的一个project(Android Project),额外引用的3rd.jar包也是它的一个project。在项目的开发阶段,我们自己的当前项目依赖了3rd.jar,在项目构建成apk文件(project)的时候,如果我们不将3rd.jar这个工程设为Exported(让依赖当前Android Project的apk project也能依赖3rd.jar)。在apk文件运行时,当apk运行到需要依赖3rd.jar流程的时候,dalvikvm环境无法访问3rd.jar project中的class文件,自然就会报错。
依赖关系分析:
在实际运行的时候:apk project依赖我们开发的Android Project,而Android Project又依赖3rd.jar project,相当于apk project间接依赖3rd.jar project,这种间接关系应该是不能自动传递的,需要进行手动设置,也就是在构建apk project的时候,把3rd.jar project设为Exported,让它可以被apk project间接依赖,当然apk project是直接依赖Android Project的。
第二种方法完全就是将3rd.jar project和Android project一起构建(打包)成apk project,然后部署(安装)在dalvikvm中运行,其实也是相当于在dalvikvm运行环境中直接添加了一个3rd.jar。
通过文件的大小分析,我们发现第一种export的方式比第二种直接构建的方式构建成的正常apk文件要小一些。具体是:第一种方法正常情况下apk文件大小306KB;第二种方法下正常情况下apk文件大小334KB。apk异常情况时大小是295KB。3rd.jar的大小是33.7KB。我也不知道具体原因,猜测是进行了“结合编译”,也就是将Android Project和3rd.jar project在编译的时候结合起来,比如去掉相同的地方,从而构建成apk project;或者是“有效编译”,也即是只将3rd.jar中有效有用的部分整合到Android Project中去,然后构建成apk project。本人也只是菜鸟一只,只能这样猜想一下,凭目前的知识水平,还不知道到底是怎么回事,也不知道如何去验证,如有高手能赐教一二的话,不胜感激。当然由于本人的水平有限,本文中的语言和词汇肯定有表述不当的地方,大家自己辨别了,这只是我的个人理解。建议大家无论什么时候都不要尽心他人言,官方的文档才是你最坚实后盾。
我们假如官方文档是100分,完美的;我们的原作者是一个技术大牛,能学到95分;然后在他的书或者文章中,由于翻译写作表述等因素限制,可能能将80分的内容表述清楚;然后我们读者在阅读学习的时候,由于个人的理解能力和方式差别,能得到60分就很不错了。在这个过程中,如果仅仅只是只是数量上的减少还可以接受,但是知识都是一环扣一环的,前面的理解不到位或者错误将会一直误导后面的学习和理解。所以我还是建议大家尽量去看相对权威、准确、规范的官方文档,别人的二手甚至N手资料只能当一个引导作用,切不可全信。