我目前正在使用Android＆amp;iOS平台。
对于Android，我们在Gradle文件中列出了依赖项，并使用Maven提供SDK（因此我们的依赖项在.pom文件中列出）。
对于iOS，我们使用Cocoapods来处理依赖。
问题是：*我们的SDK在版本x中使用依赖关系*我们的客户之一可能使用相同的依赖性，但在版本y中*另一个客户端也可能使用z
中的完全相同的依赖关系因此，这可能导致我们的SDK可能会在我们的一个客户端破坏（如果不是两者），因为我们确保它与依赖关系X一起使用，而不是Y和Z。
。目前，旧版代码只是导入引起此问题并为其命名的库的源代码，以便它模拟我们不使用同一库。
，但我认为这不是一个可靠的解决方案：我们没有最新的修复程序，更新是痛苦的，客户有两次图书馆而不是一个。
所以，目前，我正在尝试考虑一个潜在的好解决方案，但找不到我在Google上想要的东西（也许我没有使用正确的关键字：/）。
我正在考虑的是为每种依赖关系提供一系列版本的支持。有点像"如果此方法在这里，请执行它，否则，请使用以前版本的该方法"（例如iOS上的选择器响应）。然后，客户端应能够在受支持范围内的条件下使用任何版本的依赖项。
但是，我不知道这是正确的方法吗？还有其他解决方案吗？
谢谢：）
对于Android，有两种可能的解决方案，一个基于构建的解决方案，一个结构：
：1.-如果使用Maven构建库，则可以使用"提供"范围迫使您的库从运行它的容器中获取依赖项。这样，依赖性可以由摄入库的应用程序提供。请注意，如果依赖关系大不相同，这将无济于事。
2.救援！您可以将项目细分为主库和插件库。主库将向用户显示每个类方法，这将是他们将从应用程序中调用的方法。在主库中，所有类将以间接形式导入每个外部SDK或依赖关系，通用包装器可以是抽象类或接口，并以这种方式使用它们。例如，也许您正在提供增强的Facebook登录UI。然后，您不会将Facebook SDK直接引用到您的视图中，而是引用Facebook Logininterface并调用它。然后，您将拥有一个辅助项目FacebookLogin41，您将使用Facebook SDK 4.1和第二个FacebookLogin418实现FacebookLoginInterface，您可以使用Facebook SDK 4.1.8实现相同的接口。然后，实现某种提供逻辑的类型，例如依赖注入框架（Roboguice提供商是一个很好的例子），Maven依赖范围（例如提供）等，以使库库实例成为FacebookLoginInterface。最后，客户端仅导入主要库和辅助项目所需的并使用主库。