Android项目现在越来越流行的观察者模式来进行代码的解耦，更加优雅的撸码。比如现在比较火的RxJava，EventBus等等，都是基于观察这模式的。我今天分享的也是我上一个项目中，使用观察者模式对代码进行解耦。

项目中遇到的问题：单个类的代码复杂多很高，甚者超过几千行的类逐步增多。电商类App，UI占据了很多的成分。UI变化时，牵一发动全身。特别是一个人写的东西，不感觉让别人去顶替修改，人员离职后交接成本很大。
后来终于到了我无法忍受的时候，于是就大胆的进行了重构。
重构目标：将复杂的类进行拆分(去除各种复杂的回调代码)，降低耦合度，增加阅读性和维护性。并且有利于进行patch打补丁包。
下面大概说一下当时的思路
解决方案：

  1. 使用观察这模式，将类与类直接的关系进行尽可能的解耦，增加阅读性。
    引入EventBus等第三方库，进行解耦操作；自己实现一套自己的观察者模式事件库。
  2. 按照依赖注入的方式，避免一些重复的代码。
    使用第三方依赖注入库。ButterKnift,。。。。
    EventBus引入之后，效果不是很明显。
    原因：1. EventBus不支持注解形式的观察方法(不知到目前支不支持)，而是支持已方法名的形势进行方法匹配。这就导致了很多事件，在一个类中需要在同一个方法中处理，看起来不太舒服。
  3. EventBus功能是很强大，但是代码量比较大，维护比较费劲。由于原来使用Picasso和那个Glide的事遇到一些问题，例如使用Picasso在vivo等某些国产机器上下载图片非常慢，还经常闪退，而阅读其源码话费了很大功夫，特别是Glide库，特别大。可悲的是我们没能查出来是什么原因导致的这个问题。从那以后基本是就是能自己很快完成的就是参考别人的自己写，这样方便以后维护。

    实现自己的观察者模式的事件机制

    首先做的事情：起一个比较霸气的命名？啥也不说了，想不起来。最后直接就叫M。
    实现原：观察者模式，与EventBus基本相同。不同：结合注解，支持通过注解的方式调用方法。

    使用方式

M的原理

  1. 自定义合适的注解，作用在方法级别的
    type是指的对改时间的一个描述

  2. 添加观察者

    • 过滤出当前含有自定义注解的方法
    • 将观察者(MReciever对象，以及处理方法)按照事件类型来进行存储

  1. 发送消息，接受到数据之后，通知给观察者


通过handler统一处理发送

观察者接受指定类型的事件和数据

整个过程仅仅只是用了五个类，就将原来耦合到一起的很复杂的代码进行了降低耦合，更加方便了代码的维护和阅读。

这样重构带来的优点：1.减小的代码的耦合度，方便维护和多人开发；2.有利于我们打patch包，就是当我们线上发现某些比较严重的bug，我们只需要对特定的接受方法进行处理，这打patch的工作量会大大减小，如果类与类之间耦合度很高，patch就需要改动很多地方，不利于热修复补丁。

简单的依赖注入

MInject 就是一个View的注入工具。实现原来基本跟butterknift相同，就是通过注解的方式对View进行注入。使用方式也跟butterKnift基本一样。
唯一的区别：支持点击事件设置点击抖动事件，有点类似于RxAndroid中的某些View框架，可以方便的设置点击抖动时间。


实现原理：对View.OnClickListener接口的一个动态代理

杂项：aar上传jcenter，远程仓库统一管理

gradle中新建了一些Task，依赖jcenter提供的插件就可以非常轻松的实现。MInject这个我就放到了jcenter上。通过gradle调用很方便。

1
compile 'com.glanwang.minject:MInject_core:1.0.0'

http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0623/3097.html

http://www.cnblogs.com/qianxudetianxia/p/4322331.html