sfi*_*nja 3 java android dependency-injection inversion-of-control android-service
我正在寻找一种实现基于插件的 Android 应用程序的方法，并发现了这篇很棒的文章，描述了基于服务的插件方法。
我尝试这种基于服务的插件架构的目标是：
基于服务的方法很好地满足了目标 #1，但是当涉及目标 #2 和 #3 时，我发现自己陷入了无限循环（即“追我的尾巴”）：
本文中实现的基于服务的插件演示效果很好，因为...它只返回内置类型（请参阅 参考资料IBinaryOp.aidl）。
但在我的实际应用程序中，我需要返回我自己的类，其中一些很复杂并且包含“商业秘密”。
这是一种先有鸡还是先有蛋的情况吗？无论我做什么，我总是必须暴露一些核心类？
或者这个问题可以解决吗？
我考虑解决这个问题的方法之一（真的是解决方法吗？）是使用我的类通过服务返回的接口，因此：
我的思考方向正确吗？或者你发现一些误解吗？
有更好的方法来解决这个问题吗？
是否有演示项目已经成功解决了这一挑战（即上述所有 3 个目标）并可以用作参考或教程？
有更好的方法来解决这个问题吗？
您必须以源代码形式发送 AIDL。那是一个接口。您不必再单独拥有另一层接口。AIDL 中引用的 Java 类的实现可以在 JAR 中。
话虽如此，由于版本管理的原因，野马无法让我做你正在做的事情。
除非您打算用枪指着第三方，否则您不能强迫他们升级您的 JAR 版本。因此，您可以：
永远不能改变这些类，或者
必须非常仔细地管理版本控制，例如每个版本都有单独的 IPC 端点，以便您的核心代码可以使用任意版本的 JAR 处理任意版本的第三方代码
是否有演示项目已经成功解决了这一挑战（即上述所有 3 个目标）并可以用作参考或教程？
您的目标可以通过任何 Android 的 IPC 机制来实现：
StringandList和BundlestartService()）IntentsContentProviders你的困难的症结在于这个假设：
我需要归还我自己的课程
我会完全翻转过来：您应该坚持使用实际 IPC 的标准 Android 类，您和第三方代码都可以识别并能够使用这些类。
这仍然需要您进行版本管理，但它取决于更传统的“清理您的输入”逻辑，就像您对任何 Web 服务或其他公开的 API 所做的那样。如果您想在源代码或 JAR 中发布一些“帮助程序”代码，以便更轻松地使用您的 API，那很酷，因为您不再依赖于 JAR 中这些类的特定版本。
就“演示项目”而言，这完全取决于您尝试创建哪种类型的 API。