1. 查询状态主要是什么作用，查询是否存在该插件吗？
2. 插件间需要通信的地方需要归纳一下，对于公共数据的操作可以放到lib.*模块，往外导API

举个例子，main模块页面有个message模块的入口图标，现在需要在这个入口处显示一下未读消息的badge，这个时候，比较理想的操作就是main模块向message模块发一个query. 如果把message模块的数据拿到lib中去，感觉是不妥的。

我有一个提议，在bundle.json中增加一个配置选项，专门用来处理调用。

然后定义一个公共接口

参数和返回值都是标准的json。 通过这种注册、查找的方式调用。

另外一种方式就是用事件来驱动，各插件或插件中的组件（包括UI如fragment，业务组件等）只关注自己敢兴趣的事件，与其他组件不之间交互。即：
1.定义好所有的事件对象，app.* 引入这些事件的依赖（用于在编译时）
2.事件的产生者和消费者只通过一个中介交换，例如事件总线

@peacepassion 设计上可以，不过就是怕实用性不高，bundle.json在宿主，也不够灵活。

你提到的这个可以借助v4包的LocalBroadcastManager来实现。message模块在拉取数据时，发送本地广播携带badge信息。main模块监听之实现刷新。

借助其他第三方的库也应该可以，基于消息或事件的可以达到解耦的目的。

@galenlin

1. 通过eventbus这种库来实现的话，局限性比较高，只能被动监听，无法主动调用；
2. bundle.json就是small的manifest，目前的uri, rules都是注册在那里的，如果不够灵活的话，可以考虑把bundle.json给分拆到各个bundle自己写。

对业务的主动调用需要增加业务逻辑层，例如

//主动调用具体的业务逻辑
OrderManager m=OrderManager.getInstance().tryGetOrderList();//向服务器发送请求，结果通过事件触发

//UI 层接受事件
@Subscribe(threadMode = ThreadMode.MAIN)
    public void onEvent(OrderListEvent event){
        if(event.ok()){
            adapter.setData(event.getData());
        }else{
            //show error
       }
    }

Manager们作为逻辑处理层，无需关心UI，不需要在small中进行注册，small也不需要关心业务是怎么处理的

@peacepassion @tcking 我的想法是Small框架本身也可以组件化的。在设计上我需要保证Small足够精巧，解决最核心的问题。然后其它的特性通过扩展库来做，甚至渐渐的形成一个组件仓库。如果这步能实现，相信Small能做更多事。

eventbus这个框架在small中可以跨lib使用吗？

我认为需要有一个消息总线的组件，独立各插件；

------------------------message bus------------------------------
| --------------------|---------------- |--------------- |------------------|
插件1-----------插件2--------- 插件3-------- 插件4-----------插件5

假设：插件1要跳转到插件3，同时，需要把一些参数传过去，
那么在开发过程中，插件1与插件3开发团队应该是沟通过的，
插件1往消息总线里扔数据，插件3从消息总线里取数据

@peacepassion @tcking 用ContentProvider解决“插件间通讯”，感觉可行！ContentProvider本身为了解决APP间数据共享，我们把不同插件，当做不同APP。

@kkmike999 提供一个思路 用LocalBroadcast来解决通信问题 ContentProvider这个用于对外提供比较合适一些 如果是应用内的数据 有时候会有敏感信息问题 至于上面提到的eventbus 由于交换数据的class导致会在各个不同插件之间有代码的依赖 应该也是不合适的