Android 在内部与外部导入库的好处答案

【问题标题】：Benefits in Android to importing a library internally vs externallyAndroid 在内部与外部导入库的好处
【发布时间】：2012-05-07 07:03:45
【问题描述】：

在 ADT 17 之后，非 Android 库需要包含在项目的“libs”文件夹中或通过构建路径中的“Order and Export”选项卡导出。外部导入库有什么区别（如果有）：

以及内部：

以将库包含在“Android 依赖项”组中的方式导入库是否有优势？

【问题讨论】：

好问题我也想知道？为此 +1。

标签： java android eclipse adt

【解决方案1】：

如何将外部 jar 依赖项添加到 Android 项目的构建路径（内部或外部）对实际构建过程没有影响（更具体地说是在 compile 和 dex 步骤），它所做的只是告诉构建过程在哪里寻找用于编译和 dex 步骤所需的 jar。

Java Build Path - Libraries 窗口中显示的Android Dependencies 元素只是 ADT 插件用于管理/分组 jar 依赖项的另一个抽象层。您的外部 jar 文件（在您的情况下为 android-support-v4.jar）出现在该窗口中（在 Android Dependencies 内部或外部）的位置没有区别。

从r17开始，依赖管理有了很大的改进，推荐使用libs/目录存储所有jar依赖（参考你内部的方式），这被认为是一种自动化的方式（现在ADT插件变得更智能了），见Revisions for ADT 17.0.0:

新的构建功能

添加了自动设置 JAR 依赖项的功能。 /libs 文件夹中的任何 .jar 文件都将添加到构建配置中（类似于 Ant 构建系统的工作方式）。此外，库项目所需的 .jar 文件也会自动添加到依赖于这些库项目的项目中。（更多信息）

但是，如果您愿意，您仍然可以使用旧方法（请参阅外部方法），这被认为是手动方法（因为 ADT 插件以前很愚蠢），请参阅Recent Changes‎ for r17 Release：

重要提示：如果您仍然手动引用 jar 库而不是将它们放在 libs/ 下，请注意以下几点：

如果项目是库项目，这些 jar 库将不会自动对应用程序项目可见。你真的应该把这些移到 libs/

如果项目是应用程序，这可以工作，但您必须确保将 jar 文件标记为已导出。

以将库包含在“Android 依赖项”组中的方式导入库是否有优势？

从依赖管理的角度来看，自动化与手动相比，在计算机科学领域，自动化总是被认为比手动更无错误。

【讨论】：

如果我“手动”导入库，是否仍会从 ADT 获得重复检查？
基本上是的，请查看this link 的最后一节，了解 SDK 究竟是如何解决重复依赖的。

【解决方案2】：

第一个，显示停止，“我不敢相信他们没有测试这个”，将外部 jar 放在 libs 目录中的缺点是您无法为它们设置 javadocs 位置，如选项所示作为“无（不可修改）”。

因此我仍然在构建属性中使用导出选项

【讨论】：

根据问题跟踪器上的this response，团队似乎在发布之前就知道源附件问题。让我们希望它尽快修复:)

【解决方案3】：

它与Android的库依赖管理有关。详情见http://tools.android.com/recent/dealingwithdependenciesinandroidprojects

【讨论】：

那么只导出外部库有缺点吗？否则 ADT 不会检测到重复项吗？我问是因为我对我的所有库都使用了一个 repo，并且我想避免每次我想在我的一个项目中使用库时都创建一个副本。

【解决方案4】：

来自Eclipse FAQ

内部资源驻留在工作台中的某个项目中，因此由工作台管理；与其他资源一样，这些资源可以由工作台进行版本管理。外部资源不是工作台的一部分，只能通过引用来使用。例如，JRE 通常是外部的并且非常大，无需将其与 VCM 系统关联。

因此，很简单，如果您希望能够将 JAR 作为项目的一部分进行管理，将其公开给 SCM 等，那么将其视为内部资源，否则将其视为外部资源。最终生成的APK不会有任何区别，它只是一个eclipse的东西。

如果您想避免每次使用库时都创建副本，请将其视为外部资源。但是，我可以建议你看看maven 和android maven plugin，maven 有一点学习曲线（特别是如果你习惯于“制作”或“蚂蚁”风格的构建脚本），但它非常值得努力。

【讨论】：