Android Architechture Overview

做了Android也有了这么久了，从一开始的一锅粥（没有架构）代码，到慢慢的开始MVC架构模式（其实根本不是），又到然后的MVP/MVP-X架构模式，最后的MVVM架构模式，以及现在Android官方推荐的JetPack架构组件。

酸甜苦辣咸，这些架构模式虐我千百遍、我待他们…

痛定思痛，决定应该要有所沉淀，明白透彻其中奥妙，以后不管是造火箭还是拧螺丝，都能受益无穷。

架构的目的

通过设计，使得具有一定复杂度的程序模块化。
并且模块内部高度聚合，模块之间低度耦合，以提高开发效率，易于测试、易于维护。

演进过程

在Android中，一个App好与否，View层的响应时间是一个重要指标，作为App的开发者，我们对其有第一手责任，而优秀的程序设计可以帮助我们做一个好爹。

• Android中的MVC架构模式

  在Adnroid最早期的时候，大家写的代码都类似这样的：

    class LoginActivity extends Activity｛
    	...
    	
    	@Override
    	public void onClick(View view) {
    		String name = etName.getText().toString();
    		String pwd = etPwd.getText().toString();
    		login(name, pwd);	
    	}
  
    	public void login(String name, String pwd) {
    		boolean valid = ...校验密码规则等;
    		if(valid) ...showTips(...) return;
  
    		loginModel.login(name, pwd, loginCallback);
    	}
    ｝
  

  上面的代码中，Activity承担了Controller的角色，完成了XML（View）与Model之间的协调、隔离，而 [登录] 这个功能被封装到LoginModel中完成，避免了直接交互，具有一定的低耦合特性。

  所以Android中MVC架构模式是这样子的：

  XML（View）<——> Activity(Controller) <——> BusinessClass (Model)

  回顾一下，MVC中Activity负责协调View和Model之间的交互，最终Model返回数据/状态给Activity解析，解析完成之后，协调View进行展示/跳转等。

  扩展一下，比如说，业务越来越复杂，Model返回的数据/状态越来越多，Activity需要做的事情就越来越多，代码逻辑越来越多（头皮发麻，要是没有注释呢），要知道，Activity除了需要维护View和Model之间的关系，还有复杂生命周期等需要维护，所以Android中的MVC架构模式的缺点就显而易见了，即：

  随着业务越来越复杂，Activity作为Controller层，越来越臃肿，其需要承担View和Model的部分角色，这就使得Model和Activity不知不觉中扭打在一起，导致其不是纯粹的Controller。

  所以，严格划分来说，Android中的MVC是这样子的：

  View <——> Activity(30%View、30%Controller、40%UnKnow) <——> Model

• Android中的MVP架构模式

  由于在Android中MCV架构表现不够好（其实不是⊙﹏⊙‖∣），Activity往往越来越肿，所以就出现了MVP架构模式。

  因为Activity越来越肿，担负的职责越来越多，所以需要对Activity进行责任分离，MVP就是这样一种思想，即：

  Activity只需要维护好自己（譬如生命周期）以及对View的交互。

  所以，多出来的一部分，交由新的模块Presenter来负责，即：

  Presenter 负责View于Model之间的协调，以及Model返回的数据/状态的维护

  那么MVP模式是这样的：

  Activity（99%View） <——> Presenter <——> Model

  一般情况下Android中的用户行为都是从View发出的，每开发一项功能，都需要重新编译运行，而编译运行往往比较耗时，这是Android开发的一个痛点，为了解决这个痛点，在MVP模式中还额外增加了一个程序设计： ViewInerface。

  ViewInterface，作为面向View的接口，可以模拟发起View的用户行为，益于提升开发效率，方便开发、单元测试。

  即：

  Activity(99%View) <——> ViewInterface <——> Presenter <===> ModelInterface <——> Model

  注： 其实View不只是有Activity一种，还有可能是Fragment、Adapter等和UI相关的东西，上面只是为了提升阅读流畅性，做了简写。

  最后，细数一下MVP的一些优点：

  • Activity的代码不肿
  • Model影响View非常低，低耦合性体现更强
  • 面向View和Model的接口程序设计，更能方便开发、测试、维护

  不得不提的是：

  虽然MVP这种程序设计一定程度上优化了代码结构，提升了我们对View层的掌控，但是在复杂度慢慢提升的情况下，不管是Presenter还是Model，其复杂度也会越来越强，这个是MVP也无法有效解决的，所以还需要对Presenter、Model在其内部分层设计，细分业务、提炼工具代码等等。

• Android中的MVVM架构模式

  The view model of MVVM is a value converter, meaning the view model is responsible for exposing (converting) the data objects from the model in such a way that objects are easily managed and presented.
  MVVM 的ViewModel是一个值转换器，也就是说ViewModel负责从Model中公开（转换）数据对象，以便轻松管理和呈现数据对象。

  上面一段描述引用于维基百科对于MVVM的一段描述。

  记得MVP中对View的状态和数据的维护被分离出来，交由Presenter来负责，而Presenter持有View的引用，当数据和状态发生改变时随即对View发出行为变更（调用ViewInterface）。

  上面描述的这样一个过程，往往会需要编写许多的重复代码（或者称为模版代码），使得开发者不得不分出一些精力来维护这部分工作，这无疑是比较枯燥的，我们更希望更专注于用户体验需求编程，而不是这类偏向于业务逻辑的编程。

  所以，我们需要能帮我们自动处理数据/状态与View之间通信的东西，让View随着数据/状态的改变做出一个Update的操作，这就是视图模型ViewModel（View’s Model）。

  View model
  The view model is an abstraction of the view exposing public properties and commands. MVVM has a binder, which automates communication between the view and its bound properties in the view model. The view model has been described as a state of the data in the model.

  ViewModel是View的公共属性和命令的抽象，其通过Binder技术自动化View及其绑定属性之间的通信，这使得ViewModel被描述为Model中数据的状态。

  MVVM看起来是这样的：
  

参考：

• 维基百科MVVM
• Android设计架构-周鸿博
• 应用架构指南 | Android Developers