Android 插件框架 xCombine 开发思路简介

最近有网友留言说让介绍一下xCombine开发的大概思路，之前因为比较忙，一直没有写过介绍，现在简单介绍一下吧。

为什么要使用插件式框架，android的插件限制这么多为什么还要使用这种机制？我想大家都会有这样的疑问。
   插件式的应用可以将你的应用免费功能与收费功能分离，你可以靠免费功能吸引用户使用，当用户需要高级功能是在购买扩展功能；也可以最小化你的应用主体，去掉大部分用户不使用的累赘功能等等。
   使用xCombine可以大大简化你的插件式应用开发，它提供了很好的插件开发思路，和一些常见问题的最佳解决方案。请看下面的介绍:

xCombine 介绍：

• xCombine 是一个 android 的插件框架。

• xCombine 遵循简单易用，易扩展，约定大于配置的思想开发。

框架的约定：

• 插件分为 容器(Container) 和 模块(Module) 两类(继承自Plugin)。

• Module 的实现类必须命名为：packageName + ".CustomModule"。

• Container 随意命名，并在主界面初始化(参考tests/MainContainer)。

• Container 和 Module 必须使用相同的 android:sharedUserId。

使用方法：

• 插件之间互通可使用 插件消息 和 MOP(可以叫它面向方法约定编程)

• 使用 插件消息 时消息遵守接受者的实现约定，适用同步或非同步返回的场景。

• 使用 MOP 定义一个外部插件实现的方法时，方法名和参数类型与外部插件保持一致，返回值类有多个时变为List，适用同步返回场景。

• MOP 可用在 Module， Container 和 初始化Container的Activity 中(用法参考tests)。

• 上面的介绍在tests中有详细的示例，包含插件之间传递对象和View组件的例子。

看到这里感觉还是一头雾水，不知到接下来该怎么应用吧？下来介绍一下插件开的技巧吧：

1. 实现框架中的Container，这个Container作为你的应用主体“容器”，提供基本的UI以及主要的控制功能。

2. 实现框架中的Module，作为“容器”的附加功能，即插件。
  Module的实现类也作为“容器”或其他插件访问该插件功能的唯一入口，插件内部的所有功能都有这个类来代理访问，类似单点登陆的概念。这样可以降低插件之间相互协作的复杂性。

3. 插件之间相互协作框架中提供了两种机制，一种是发送消息，等待返回... 另一种是使用框架中提供的方法约定机制。sample源码目录下面有简单的例子，这里不在赘述。

常见问题解决：

a. “容器”与插件之间定义的业务接口发生改变，无法兼容老版本怎么办？
  不推荐大家在使用中给插件或容器自定义业务接口去调用业务功能，框架中提供的MOP（方法约定编程）是比较推荐的。因为如果定义了接口，以后发生一点小改变就必然导致插件与“容器”的不兼容，但是实现约定好的方法，就可以很轻易的克服这一问题。考虑这样一种情况，如果使用接口，接口中要新增一个功能，老的插件必定会加载错误（因为没有找到接口的实现类），但是使用MOP（方法约定编程），就可以直接提示该功能未实现可能需要新版本的插件，之前的功能不受影响。

b. 怎样启动插件中需要访问其他模块中定义的类型的Activity或Service？
  插件中的类都是被加载到“容器”中访问的，如果插件中需要启动Activity或Service，且需要访问“容器”或其他插件中的类型怎么办？ 如果直接启动插件中的Activity必定找不到类型的定义，因为这个Activity不在“容器”的进程中，所以需要“容器”提供Activity容器，插件只提供View，启动Activity容器时将插件提供的View加入即可。Service类似。“容器”一般只负责将插件展示出来，插件自身完成它的具体功能。

如果还有其他疑问或改进的建议，可以给我发邮件 wyouflf@qq.com
如果发现大家其他常见问题我会更新到这个帖子上，请持续关注。

源码及简介地址：https://github.com/wyouflf/xCombine

用户反馈：运行代码中的例子报错：java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation？
解决方法： MainContainer依赖插件库，编译进源码；但ModuleTest是运行时依赖，不编译进去，eclipse怎么设置自己百度，我用idea开发依赖设置为provided。