Android-Architecture是Google给出的MVP架构及其变种示例。各个分支代表了不同的架构。
todo-mvp：原生态的MVP，其实就是说明了一下，在使用Fragment时MVP和Android组件是怎么对应的。
Model：纯Bean，既是View Model，又是Biz Model。Model不负责存取和转换逻辑View：对应着Fragment和Android View，主要负责事件到PResenter函数的对应、原子化的显示功能。前者是Presenter接口的调用，后者是View为Presenter暴露的接口Presenter：独立的类，主要提供简单的事件处理功能。这种方式，声明了View和Presenter的interface，通过这个隔离了实现。还有个比较好的方法来组织多层次的数据存储，使用同一个interface声明同一个TasksDataSource接口，不同的数据源各自实现内部逻辑。最后，Cache和调度由一个TasksRepository负责。Cache逻辑太简单，又有太多的各种更新逻辑，放到最高层，可以简化接口。todo-mvp-clean：clean-architecture的例子，基于MVP而来。clean本来就是要隔离系统的变化，所以对应关系更加脱离了Android系统
Entity（不变式）：对应了Model和接口，包括了Bean和MVP中的interface声明、DataSource声明UseCase（功能）：对应了Presenter中独立存在的功能，可以看做使用Command模式抽象了一下Presenter的功能Interface Adapters（粘合）：对应了Presenter的总体逻辑。相较于MVP中的Presenter，功能更加单一，没有了具体的业务逻辑Frameworks&Drivers（外围）：View和Storage都可以算在这里面，跟runtime相关理解层面可以按上面总结，代码层面最大的变化其实就是Presenter又分了一层todo-mvp-rxjava：只是学习一下rx在生产环境长什么样。
不得不说，lamda表达式用到各种listener上很舒爽不得不说，Java8实在是应该赶紧用上rx看得到的好处，就是把每一步遍历（flatMap）、合并（toList）、finally（doOnTerminate）等行为省略，改用对应的rx函数来做。如果熟悉，会非常易读、易维护CompositeSubscription用来统一管理一个类中的所有订阅自己的想法：
抽象来说，一个App大概可以分为几个层面，依次向上依赖： BizModel：业务模型，最核心的数据模型，大概相当于数据库的表。提供一个BeanModelStore：数据存取，核心数据存取逻辑，提供DAOBizLogic：业务逻辑，将一段业务封装成一个小服务，供外部使用ViewLogic：显示逻辑，将用户操作与业务逻辑粘合起来，提供ViewModel和View事件处理能力ViewModel：显示模型，仅为显示提供完整的内容，View层仅使用和修改该ModelView：显示内容，真正的处理显示和用户事件各个MVC框架变种都是用不同的方式合并上述几个层面，或者是做各层面间交互的解耦附依据该想法的简单demo
新闻热点
疑难解答
