android 学习 -- 插件形开发，动态部署，消息模型

     我们做android开发的人都知道，android apk升级是比较麻烦，以前我们都是整包升级的，每次更新都要重新输出apk，而且apk也不小，基本都是3M，如果下载更新的时候特别浪费流量，还有另外一个问题：android 碎片化比较严重，各个平台都不一样经常做适 配，同时一个apk也不可以所有都做，有时候免不了要接入第三方的东西，一般都三方的界面都会有jar文件和资源文件，当然还有一些android本身要求的文件，所以如果把东西都添加到项目中就是实在是太混乱了。

    因此，我想到我们能不能像浏览器开发，采用插件的形式，各个团队分别开发不同的插件，发布的时候统一集成，然后在客户端动态部署，动态加载所需的插件，而且升级的时候也采用插件的形式避免整个apk进行升级。这就好我们盖房子和堆积木一样，当我们把房子的主体框架搭好了，就可以随便装修了，也就说可以随便加载安装插件。

    这当然是一个完美的想法，不过要实现这样的东西，必须要有很多方面需要考虑的：

  1. 必须对android 本身的机制有很深的了解，比较进程的启动，view加载，activity加载有一定的了解，

  2. 必须对类的加载，以及反射有一定的学习，因为你要加载插件的jar

  3.对资源加载必须要会，而且整个框架中资源怎么规划也是一个很重要的部分，因为如果资源加载慢的话会严重影响体验 ，我们也可以借鉴android 的方式直接加载资源 包。

  4.插件或者模块之间怎么进行通信，因为插件和要模块之间有可能是都在一个进程里面，也有可能在不同的进程，如果是同进程我们可以用handler来满足基本要求，不过为了以后开发我建议还是自己开发一套消息通讯机制。如果是不同进程我们要实现binder 通信。

  5.插件的安全和完整性检测和校验，插件在运行之前必须进行上面的检测。以确保插件能正常运行。

  6.插件的升级问题，插件是自升级，还是统一交给框架来进行升级。

上面只是我们能想到的，可能还有很多方面没有想到。我们还是来学习关于消息通讯这一部分的设计：

    插件之间的集成和通信是非常关健，这里可以关系到整个apk 动态部署和运行。插件之间通信无非就是数据的处理，说到底就是对消息的处理，与对象不一样，消息本身 就是一种数据结构，我们也可以传输对象，所以对象也是一种特殊的消息。一般包含消息的生产方和消费方。以及双方对数据的识别。这些数据有可能会在不同的插件之间传输。

  常用的消息模式 ：

  消息通道就是用来传输消息，把消息从发送方传输到接收方，Channel除了具有传输的作用还有另外 的一个重要的作用，解除发送方和接收方之间的耦合,双方只要能够识别消息的协议或者消息的通信的格式，同时这样的设计我可以支持多方发送和多方接收.

不过如果是在多方接收的时候，我们一般加入另外一个元素Router （路由）来根据规则进行转发：

    消息Channel一般都是以队列的形式存在，这是一种先进先出的数据结构，无疑是最为适合的。

支持多个消费者的两种模型：拉模型和推模型，拉模型由消息的消费者发起，主动权把握在消费都手中，它会根据自己的情况对生产者发起调用。同时生产都的状态发生 变更时，通知消费者它的状态发生改变，一般通过回调的形式，可以在回调的参数里获取更多细节消息。拉模型还有一个比较明显的特征：需要别起一个进程来定期对channel进行检测，一旦有消息传递过来就会把消息传递给真正的消费者。

  推模型的主动权一般掌握在生产者手中，消费者被动地等待生产者发出消息，这就要求生产者必现掌握消费者相关信息，其实和观察都模式很相似。

 

  对于从Channel的消息接收者我们也可以有多种者形式，第一：点对对进行传输，消息只会传输给特定的消费者。

   第二：广播的形式，消息会发送给所有消费者，但要不要处理由消费都本身决定。

                                                                                           第三：串行的传输，消息会按一定的次序传给消费者，由上一个消费都决定要不要向下传递。