项目使用的架构（MVP，Flux，EventBus，Observer）

一
想来做项目也有好久，一般都是看别人发表文章，自己每日看看就罢了。

二
因为项目关系，自己接触到了很多东西，是自己一开始不懂的，比方说：Http网络请求，抓包（wireShark，fiddler，tcpdump），自定义文件格式，输入输出流，音频编解码，自定义Mediaplayer（使用AudioTrack），JNI
三：因为和考拉合作的关系，所以这里记录一下，整个整体框架，这也是我们开始重构，我着重的地方(项目：电台之家)
1)EventBus
虽然说大名鼎鼎，但是一直没有在项目中使用过，正如butterknife也是知其名，连正式项目中我都没有使用过，这正式我的不足之处，今天看了几篇微信的公众号的文章，有说：要一字不差的阅读，有说：要trying，而我缺乏在实践上和教导上。说是：懂了并教会别人才是真正的懂。
EventBus。使用反射调用的一种机制
EnventBus.getDefault().register(this);//将当前类放进观察队列中
EnventBus.getDefault().post(Action);//在相应发送位置处，发送相应的事件，其中Action为任意的类
注册金EnventBus中的类，需要实现方法：onEventXXX(Action) //使用反射来调用相应参数为Action的方法，开头以onEvent。EventBus需要使用注解的方式来指定接收事件的线程，优先级，等
其中XXX表明运行的所在线程：如onEventMainThread
EventBus.getDefault().unRegister(this);//从观察队列中删除。

部分源码看后给我的感受是：最大限度的利用了缓存机制：

//每当释放掉资源的时候，将对象重置并保存
private List<SubscriberMethod> getMethodsAndRelease(FindState findState) {
        List<SubscriberMethod> subscriberMethods = new ArrayList<>(findState.subscriberMethods);
        findState.recycle();
        synchronized (FIND_STATE_POOL) {
            for (int i = 0; i < POOL_SIZE; i++) {
                if (FIND_STATE_POOL[i] == null) {
                    FIND_STATE_POOL[i] = findState;
                    break;
                }
            }
        }
        return subscriberMethods;
    }
//每次从池中获取，如果没有则新建
private FindState prepareFindState() {
        synchronized (FIND_STATE_POOL) {
            for (int i = 0; i < POOL_SIZE; i++) {
                FindState state = FIND_STATE_POOL[i];
                if (state != null) {
                    FIND_STATE_POOL[i] = null;
                    return state;
                }
            }
        }
        return new FindState();
    }

同时保存了从Action的名称找类对象

private final Map<Class<?>, CopyOnWriteArrayList<Subscription>> subscriptionsByEventType;//通过Action找观察对象，之后反射调用
private final Map<Object, List<Class<?>>> typesBySubscriber;//通过观察对象找所有的Action

四：
这里和观察者比较一下：
因为我在没有看到这个之前默认使用的是观察者模式
只需要在观察对象里面继承接口Observer实现update方法，之后按照命令字的形式进行分发
有人说：EventBus比Observer在于切换线程，有人说EventBus方便管理，可以使用
五：Flux
因为工作中的另一个项目，不是由我负责的“车载微信”使用了这个架构，并分享了，看了之后觉得可以在以后的项目中使用。

---

View： 视图层
Action（动作）：视图层发出的消息（比如mouseClick）
Dispatcher（派发器）：用来接收Actions、执行回调函数
Store（数据层）：用来存放应用的状态，一旦发生变动，就提醒Views要更新页面

---

下面以我认识的项目举例：
视图View只负责界面相关：即所有的逻辑操作全部放在Action中，比方说：网络请求，查询数据库等。
Action具体实现怎样请求网络的数据：比方说：基类实现最基本的网络请求接口，则之后的替换非常容易，如：将OKHttp替换成Volley，
一是解耦：二是清晰
Dispatcher用于分发：比方说：这里可以进行一层过滤，过滤一层有用的数据：
Store用于实际业务操作：比方说：保存导数据库，比方说弹出提示，最后通知给View，用于界面更新。

我之前的写法是：
每一个Activity对应一个Engine，而Activity持有Engine的引用，在点击的所有情况都转移到Engine中实现，实现完毕再通过发事件给View进行更新界面。个人认为Flux就是讲Engine具体细化，进行解耦。

当然可以对Action进行封装：比方说：将View进入Action的入口，进行解耦。

六：
MVP（MVVP）
接口定义操作的方法
Activity持有engine的引用，engine通过Activity的引用直接对接口定义的方法进行操作。

这是我所学到到的，有待完善。