Android移动架构理解

1.MVC

• Model：用于封装与业务逻辑相关的数据，并提供数据的处理方法。
• View：用来渲染UI页面。
• Controller：Model层和View层的连接器，处理相关的业务逻辑。

其大致流程为：

        1）在View层接受用户请求，触发到Controller层

         2）Controller层操作Model进行获取数据

         3）数据获取成功后，Model通知View数据变化

         4）View层更新UI，展示新数据

       在Android中Activity和Fragment其实同时承担了View和Controller的职责（甚至model层做的东西也在activity和fragment里），当业务逻辑复杂时，代码就会变得臃肿，难以维护，各层次模块也就不清晰等。

2.MVP

• Model：负责检索、存储、操作数据，包括来自网络、数据库、磁盘文件和SP文件里的数据。
• View：负责与用户交互、UI渲染，对于Activity、Fragment、Xml、Adapter、自定义View等。
• Presenter：它也是左右Model和View的纽带，从Model层获取数据，然后调用View的接口把数据显示到View上。
• Contract：Google推荐加入契约类来统一管理View和Presenter的接口，使得某一模块接口能更加直观的显示，有利于后期维护。

其大致流程为：

        1）View接受用户的交互请求，并转交给Presenter

        2）Presenter操作Model进行数据更新

        3）数据更新后，Model通知Presenter数据发生变化

        4）Presenter通过接口回调更新View数据

       其跟MVC的主要区别是，MVC模式下，Model获取数据后是直接通知View更新，而MVP模式则是将更新结果通知Presenter，有Presenter通过接口回调的形式将新数据更新到View。由于P层和V层的交互通过接口实现，所以V层可能有很多个接口，如果后期需要改动，P层和Activity（V层）都要改，比较麻烦；P层承担了主要的业务处理，一旦逻辑越来越复杂，也会导致P层臃肿，且View定义的接口方法也会越来越多。

3.MVVM

     其仍然是一个三层架构，分别是Model、View、ViewModel，在使用过程当中，通常还会利用双向绑定技术，使得Model变化时，ViewModel会自动更新，而ViewModel变化时，View也会自动变化。

     MVVM在实际使用中，确实能够使得Model和View解耦，但如果需要实现MVVM中的双向绑定的话，那么通常需要引入更多复杂的框架来实现；并且数据绑定使得bug很难被调试，界面异常了，可能是View代码的问题，也可能是Model层的问题。数据绑定使得一个位置的bug被快速传递到别的位置，定位出问题的地方变得不那么容易了；对于过大的项目，数据绑定需要花费更多的内存。

• View：View中使用DataBinding的Command来绑定事件和响应事件，触发网络请求。
• ViewModel：进行分析处理，调用Model的方法去请求数据。
• Model将收到的请求等信息封装，调用网络请求，请求到的数据再返回到Model层中。
• ViewModel在回调中收到返回的实体类对象。
• 因为xml与实体类对象实现了双向绑定，实体类更新，使得UI更新。

4.MVP+组件化

      在开发模式下，每一个module都可以做一个单独的apk打包运行，发布模式的时候将各个module合并。

• app壳：负责管理各个业务组件，打包apk，没有具体的业务功能。
• 业务组件：某一个独立业务作为一个单独的moudle，独立开发。
• 功能组件：封装一些依赖库，比如网络库、日志、常用控件等。
• Main组件：属于业务组件，指定App启动页面、主页面。

 总结：

       整体来看，MVVM比MVC/MVP精简了很多，在MVVM中，View不知道Model的存在，ViewModel和Model也觉察不到View，这种低耦合模式使得开发工程更容易，提高应该的可重用性。好的框架思想一定是“调用更加方便、更加安全、代码间的耦合度更低”。