java - 通过服务选择的插件架构

Question

我正在寻找一种方法来实现基于插件的 Android 应用程序并找到了 this great article ，描述了一种基于服务的插件方法。

我尝试这种基于服务的插件架构的目标是:

1. 避免将附加模块(“插件”)静态链接到核心应用。
2. 避免分发核心应用或库的源代码。
3. 可选择通过 Proguard 传递核心应用程序/库，保护关键部分。

基于服务的方法很好地满足了目标 #1，但是当谈到目标 #2 和 #3 时，我发现自己陷入了无限循环(即“追尾”):

文章中实现的基于服务的插件演示效果很好，因为...它只返回内置类型(参见IBinaryOp.aidl)。

但在我的真实世界应用程序中，我需要返回我自己的类，其中一些类很复杂并且包含“商业 secret ”。

这是一种先有鸡还是先有蛋的情况，无论我做什么，我都必须公开我的一些核心类吗？

或者这个问题可以解决吗？

我正在考虑解决这个问题的方法之一(真的是解决方法吗？)是为我的类使用接口(interface)-to-be-returned-via-the-service 等:

1. 插件(由其他人编写)仍然需要了解我的命名空间，因此在构建时 需要我的图书馆项目的 JAR，但它无法访问实现源代码。
2. 我可以将当​​前的单体库项目分成 2 个 JAR:一个仅包含接口(interface)，另一个甚至不作为 JAR 发布，而是作为我的应用程序 APK 的一部分发布。

我的思考方向是否正确？还是您发现了一些误解？

是否有更好的方法来解决这个问题？

是否有已经成功应对这一挑战(即上述所有 3 个目标)并可用作引用或教程的演示项目？

Answer 1

Are there better ways to approach this problem?

您必须以源代码形式发送 AIDL。 是一个接口(interface)。您不必再单独拥有另一接口(interface)层。 AIDL 中引用的 Java 类的实现可以在 JAR 中。

话虽如此，由于版本管理的原因，野马无法让我做你正在做的事情。

除非您计划用枪指着您的第三方，否则您不能强制他们升级您的 JAR 版本。因此，您要么:

• 永远不能改变那些类，或者

• 必须非常小心管理版本控制，例如每个版本都有单独的 IPC 端点，以便您的核心代码可以处理任意版本的第三方代码和任意版本的 JAR

Are there demo projects out there that have already addressed this challenge (i.e. all 3 goals outlined above) successfully and can be used as a reference or tutorial?

您的目标可以通过任何 Android 的 IPC 机制来实现:

• 按照您的建议使用自定义类绑定(bind)服务
• 仅使用常用类的绑定(bind)服务，例如 String 和 List 以及 Bundle
• 带有服务的命令模式(即，通过startService() 发送命令)
• 广播 Intent
• ContentProvider
• Activity

困难的症结在于这个假设:

I need to return my own classes

我会完全改变这个观点，即:您应该为实际的 IPC 坚持使用标准的 Android 类，您和第三方代码都可以识别并能够使用这些类。

这仍然有您需要执行的版本管理，但它归结为更传统的“清理您的输入”逻辑，就像您对任何 Web 服务或其他公开的 API 所做的那样。如果您想在源代码或 JAR 中发布一些“帮助程序”代码，以便更轻松地使用您的 API，那很好，因为您不再依赖于 JAR 中这些类的特定版本。

就“演示项目”而言，这完全取决于您尝试创建的 API 类型。