Eclipse / ADT 在 Android 库项目方面有多智能？
因此，我的一些项目中有一些 "Utility" 样式类。我很好奇是否可以将它们移动到包含全部或大部分非应用程序特定粘合代码（主要是包装器和接口）的 Android 库项目。
所以，我的问题是该库中我不需要的文件会怎样。我知道 Android 库项目基本上只是将其代码复制到另一个项目中，所以如果我说在我的“通用”库中使用 25% 的代码，我的应用程序实际上是否包含全部 100% 的字节码，或者是否正确剥离只剩下我需要的东西。
过去我在 Proguard 中未使用的类上遇到了一些问题，所以我现在对 ADT 只能是一朝被咬，两次害羞......
So, I've got a handful of "Utility" style classes in some of my projects. I'm curious if I can move them to an Android Library Project that contains all or most of my non-app specific glue code (wrappers and interfaces, mostly).
So, my question is what happens to the files I don't need in that library. I know Android Library Projects basically just copy their code into the other project, so if I say use 25% of the code in my "general purpose" library, will my app actually contain the bytecode for all 100%, or does it properly strip it down to only the stuff I need.
I had some issues with unused classes in Proguard in the past, so I'm just once-bitten, twice shy with the ADT now...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不幸的是，当库变得更大时，你的所有项目都会增长 - 即使该库的大部分内容都没有被使用。我自己通过创建应用程序 A 和库 L 进行了测试。如果 L 是 A 中使用的库，则如果我添加更多类，classes.dex 文件（因此 A.apk 文件）也会增长 - 即使它们不是用过的。
总结一下：现在，我会为某些较小且可能被许多项目使用的东西创建一个基本库，并为每个将更大且仅由某些项目使用的新组件创建一个新库。新库的一个很好的候选者是一个在资源中定义了多个图像的新 UI 组件。例如，基础库的一个很好的候选者是常用的方法和文件缓存之类的东西。 Dalvik 的编译代码被严重压缩，您可以此处查看。 （整个演示实际上看起来很有趣:-)
编辑：如果 ProGuard 被激活，它还会为您删除未使用的代码。默认的 proguard.cfg 就足够了。它不会在（默认）调试构建时运行，而是在编译最终的 .apk 时运行。所以这实际上是可能的！
Unfortunately, all your projects will grow when the library is getting bigger - even if most contents of that library are not used. I tested it myself by creating an app A and a library L. If L is a library used in A, the classes.dex file (and therefore the A.apk file) is growing if I add more classes - even if they are not used.
To sum up: Right now I would create a basic library for certain things that are small and that may be used by many projects, and create a new library for every new component that is going to be larger and only is used by some projects. A good candidate for a new library would be a new UI component with multiple images defined in the resources. A good candidate for the base library are commonly-used methods and things like file caches, for example. Compiled code is compressed quite heavily for Dalvik, which you can see here. (The whole presentation is actually fun to watch :-)
Edit: If ProGuard is activated, it will also remove unused code for you. The default proguard.cfg is sufficient. It will not run on the (default) debug built, but when the final .apk is compiled. So it actually is possible!
我已经成功地使用了 3 级深度的 Android 库项目，尽管这有点痛苦。主要用例是当您想要在几个项目之间共享一组资源和类时。由于我使用版本控制系统，我宁愿不使用符号链接。
I have used 3 level deep Android library projects successfully though it is kind of a pain. The primary use-case is when there are a set of resources and classes that you want to share across a few projects. Since I use a version control system, I would rather not use symlinks.
请注意，Android 库项目在处理资源时也会受到很大影响。 ADT 将为每个库重建一次 R.java，并且每个 R.java 将包含所有库中所有资源 id 的副本。这里的核心问题是，整个项目的资源是作为一个整体重新生成的，并且无法像普通“库”所期望的那样为依赖项“构建 jar”。我们尝试与 OpenFeint 集成，但在处理库和依赖项方面遇到了各种麻烦。我认为我们最终只是将所有 OpenFeint 源文件和资源文件合并到我们自己的项目中，并放弃了“Library”项目，因为它几乎没有提供任何价值。
Android 库项目是一种在项目之间共享代码的笨拙方式，并且有许多缺点。我发现用库项目完成的所有事情也可以用符号链接来完成（符号链接源到两个项目）。我还没有找到一个用例，其中 Android 库项目提供了一些不容易用其他不那么脆弱的方法复制的东西。
Note that Android Library projects also suffer greatly when dealing with resources. ADT will rebuild R.java once for each library, and each R.java will contain a copy of all resource ids from all libraries. The core problem here is that resources are regenerated for the entire project as a whole, and there is no way to "build a jar" for a dependency as would be expected with normal "libraries". We tried integrating with OpenFeint, and had all kinds of hell dealing with libraries and dependencies. I think we ended up just merging all the OpenFeint source and resource files into our own project and ditching the "Library" project as it was offering little value.
Android Library projects are a clunky way of sharing code between projects and have a number of drawbacks. I've found that everything accomplished with a Library project can also be accomplished with symlinks (symlink source into two projects). I've yet to find a usecase where an Android Library project offered something that wasn't easy to replicate with other, less fragile means.