我目前正在使用适用于Android和Android的SDK。 iOS平台。
对于Android，我们在Gradle文件中列出依赖项，并使用Maven提供SDK（因此我们的依赖项列在.pom文件中）。
对于iOS，我们使用cocoapods来处理dependendies。
问题如下： *我们的SDK在版本X中使用依赖项 *我们的一个客户端可能使用相同的依赖项，但在版本Y中 *另一个客户端也可能在版本Z中使用完全相同的依赖
因此，这导致我们的SDK可能在我们的一个客户端（如果不是两个）上被破坏，因为我们确保它适用于依赖关系X，但不是Y和Z.
目前，遗留代码只是导入了导致此问题的库的源代码并对其进行了命名，因此它模拟了我们不使用相同的库。
但在我看来，这不是一个适当的解决方案：我们没有最新的修复，更新很痛苦，客户端有两倍的库而不是一个。
所以，现在，我试图考虑一个潜在的好解决方案，但无法在Google上找到我想要的东西（也许我没有使用正确的关键字：/）。
我在想的是为每个依赖项提供一系列版本的支持。有点像＆＃34;如果这个方法在这里，执行它，否则，使用先前版本的方法＆＃34; （就像iOS上的选择器响应）。然后，客户端应该能够在受支持的范围内使用任何版本的依赖项。
但是，我不知道这是不是正确的方法？ 还有其他解决方案吗？
谢谢：）
答案 0 :(得分：2)
对于android，有两种可能的解决方案，一种是基于构建工具的解决方案，另一种是架构解决方案：
1.-如果您使用maven构建库，则可以使用＆＃34;提供的＆＃34;范围强制您的库从运行它的容器中获取依赖项。这样，依赖项可以由使用您的库的应用程序提供。请注意，如果依赖项存在很大差异，这对您没有帮助。
2.-抽象救援！您可以将项目细分为主库和插件库。主库将向每个类的用户显示一个方法，这将是他们将从他们的应用程序调用的方法。在主库中，所有类都将以间接形式导入每个外部SDK或依赖项，这是一个通用包装器，可以是抽象类或接口，并以这种方式使用它们。例如，您可能正在提供增强的Facebook登录UI。然后，您将引用facebookLoginInterface并调用它，而不是直接将facebook SDK引用到您的View中。然后，你将有一个辅助项目，facebookLogin41，你将使用facebook sdk 4.1实现facebookLoginInterface，第二个是facebookLogin418，你可以使用facebook sdk 4.1.8实现相同的界面。然后，实现某种提供逻辑，如依赖注入框架（Roboguice提供程序是一个非常好的示例），maven依赖范围（例如提供）等，以使库实例成为facebookLoginInterface。最后，客户端只需导入所需的主库和辅助项目，并使用主库。