Android项目中如何正确的引入第三方jar包(工程)

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手资料只能当一个引导作用，切不可全信。