我正在开发一个应用程序，该应用程序使用流行的 HoloEverywhere 库来使用 ActionBarCompat 并在 3.0 之前的设备中获得 Holo 视觉样式。它运行良好。
现在我需要在我的应用程序中集成第三方库项目，但我面临着一个大问题。该库使用 v7 AppCompat 库在其 Activity 中使用 ActionBarCompat，这导致我的应用程序出现大量错误。
HoloEverywhere 包含一个自定义的 ActionBarCompat(afaik 他们采用了 Google 的 ActionBarCompat 并进行了修改)，这与我要集成的第三方库中使用的 ActionBarCompat 有冲突。我在重新声明的样式(因为在 v7 AppCompat 和 HoloEverywhere 中声明了相同的样式)、重新声明的类(与以前相同的情况)方面遇到了问题，而且我无法提出任何解决方案。
有什么想法或者我应该放弃吗？
最佳答案
选项 1:
您可以尝试将 HoloEverywhere 使用的 AppCompat 替换为其他第三方库中使用的 AppCompat。
大致包含:
1) 获取两个库和修改后的 appCompat 的源代码，将其全部拉入 eclipse。
2) 在 eclipse 中将修改后的应用程序兼容性 Jar 交换到其他第三方构建路径并修改依赖项等...对于他们正在使用的那个，摆脱正常的应用程序兼容性。
3) 解决可能发生的所有冲突。
问题:
1) 你不知道他们在 AppCompat 的底层可能做了什么奇怪的事情。他们修改后的 AppCompat 可能完全依赖于您不知道的其他东西。
2) 解决所有错误的时间可能会非常糟糕。
3) 这可能需要很长时间才能完成，而且可能不值得付出努力。
4) 您需要熟悉依赖管理。
选项 2:
使用 maven 或其他一些允许您排除库部分的外部构建管理器构建您的项目。我知道过去我不得不从库中排除部分依赖树，这些库依赖于层次结构深处的不同版本，你可能(这是一个很大的可能)能够使用这种机制来解决这个问题。
这是完全可行的，但可能是一个皮塔饼，具体取决于谁在何时何地做了什么以及......等等。
另一种选择是决定哪个图书馆更重要。真的需要 Holo Everywhere 吗？或者您可以使用一些替代 UI 来满足该用户群吗？这个其他第三方图书馆真的是必要的吗？你能用其他方法解决这个问题吗？
最后 - 虽然这不是一件可怕的事情，而且我也不会说您永远不要这样做，但如果您使用经过修改的 AppCompat，您可能会再次遇到这个问题或任何其他 fork 库。
关于android - ActionBarCompat 的 Library 项目和 HoloEverywhere 的 app，它们可以共存吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/21009152/