通过服务替代方案的插件架构

Question

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

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

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

基于服务的方法很好地达到了目标＃1，但是当涉及目标＃2和＃3时，我发现自己陷入了无限循环（即“追逐我的尾巴”）：

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

但是在我的现实世界的应用程序中，我需要返回自己的类，其中一些是复杂的，包含“商业机密”。

这是一只鸡和鸡吗？鸡蛋的情况，无论我做什么，我都会不得不揭露我的一些核心课程？

或者这个问题是否可以解决？

我正在考虑解决这个问题的方法之一（解决方法真的吗？）是使用接口来通过服务返回我的类，所以：

1. 插件（由其他人编写）仍然需要知道我的命名空间，因此需要我的库项目的JAR 构建时间，但它不会有任何访问实现源代码的权限。
2. 我可以将我当前的单片库项目分成2个JAR：一个只包含接口，另一个甚至不作为JAR发布，而是我的应用程序APK的一部分。

我在思考正确的方向吗？或者您是否发现了一些误解？

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

是否已经成功解决了这一挑战（即上述所有3个目标）的演示项目，可以作为参考或教程使用？

Answer 1

  

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

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

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

除非你打算用枪支持你的第三方，否则你不能强迫他们升级他们的JAR版本。因此，您要么：

• 永远不能更改这些类，或

• 必须非常小心地管理版本控制，例如每个版本具有单独的IPC端点，以便您的核心代码可以使用任意版本的JAR处理任意版本的第三方代码< / p>

  

是否已经成功解决了这一挑战（即上述所有3个目标）的演示项目，可以作为参考或教程使用？

任何Android的IPC机制都可以实现您的目标：

• 使用自定义类绑定服务，正如您提议的那样
• 仅使用库存类绑定服务，例如String和List以及Bundle
• 带服务的命令模式（即通过startService()发送命令）
• 广播Intents
• ContentProviders
• 活动

你的困难的关键在于这个假设：

  

我需要返回自己的课程

我会彻底改变：你应该坚持使用实际IPC的标准Android类，你和第三方代码都能识别并能够使用它们。

这仍然需要您进行版本管理，但这取决于更常规的“清理您的输入”逻辑，就像使用任何Web服务或其他公开的API一样。如果你想在源代码或JAR中发布一些“帮助”代码，以便更容易地使用API​​，这很酷，因为你不再依赖于JAR中这些类的特定版本。

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