前言

最近有关Android架构的讨论越来越火热,很多Android开发者也开始关注,但却对架构相关的基础知识不甚清晰。本文从最初的原生模式开始,从需求和原理角度,解读Android架构的演变过程。

一、MV*架构的鼻祖——MVC

Android原生的开发模式是基于MVC的架构。最初的MVC架构是由挪威计算机科学家Trygve Reenskaug于1978年提出的,当时他工作于著名的Xerox PARC研究中心 Smalltalk团队中。MVC最初被实现为Smalltalk-80类库的一部分,用于桌面GUI的建立。

android应用 发展现状 android的发展历程和系统架构_android应用 发展现状

MVC架构

一般认为在Android中的MVC分层:

  • View:XML布局文件。
  • Model:数据管理模块(数据的获取、存储、数据状态变化)。
  • Controller:对应于Activity和Fragment,处理业务逻辑和UI。

Andy Rubin在最初发明Android时,是按照MVC的结构的思想来设计的。但是,随着Android版本的演进,界面的动态化特性变得越来越重要,这时候XML布局文件作为View层的功能就太弱了。于是很大一部分界面相关的操作被转移到了Activity和Fragment中,这就使得Activity和Fragment兼具了Controller和View的职责。在这样的场景下看来Android已经有些违背MVC架构的初衷,逐渐变成了一种MV架构。

android应用 发展现状 android的发展历程和系统架构_Android_02

混乱的MV架构

在这样的架构中,Activity中的代码急剧膨胀,逻辑代码与界面处理混杂在一起,变得难以阅读和维护。在这样的背景下,MVP架构应运而生。

二、真正的界面逻辑分离——MVP

在Android中,MVP架构的核心思想即是把与界面无关的业务逻辑代码从Activity类中抽离出来,放到Presenter类中。并通过接口来实现通信。

android应用 发展现状 android的发展历程和系统架构_MVC_03

MVP架构

Android中MVP的分层:

  • View: 对应于Activity和XML,负责View的绘制以及与用户的交互。
  • Model: 依然是实体模型。
  • Presenter: 负责完成View与Model间的交互和业务逻辑。

下面是一个简单的MVP架构的Demo:

View:

public interface ILoginView {
    void loginSuccess();
    void clearUserName();
    void clearPassword();
}
public class LoginActivity extends Activity implements ILoginView,View.OnClickListener {

    private ILoginPresenter loginPresenter;

    private EditText etUserName;
    private EditText etPassword;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_login);
        initView();
        loginPresenter = new LoginPresenterImpl(this);
    }

    private void initView(){
        findViewById(R.id.btn_login).setOnClickListener(this);
        findViewById(R.id.btn_clear).setOnClickListener(this);
        etUserName = (EditText) findViewById(R.id.et_userName);
        etPassword =  (EditText) findViewById(R.id.et_password);
    }


    @Override
    public void onClick(View view) {
        switch (view.getId()) {
            case R.id.btn_login:
                loginPresenter.Login(etUserName.getText().toString(), etPassword.getText().toString());
                break;
            case R.id.btn_clear:
                loginPresenter.clear();
                break;
        }
    }

    @Override
    public void loginSuccess() {
        Toast.makeText(this, "Login Success", Toast.LENGTH_SHORT).show();
    }

    @Override
    public void clearUserName() {
        etUserName.setText("");
    }

    @Override
    public void clearPassword() {
        etPassword.setText("");
    }
}

Presenter:

public interface ILoginPresenter {
    void Login(String userName, String password);
    void clear();
}
public class LoginPresenterImpl implements ILoginPresenter{

    private ILoginView view;
    private ILoginModel model;

    public LoginPresenterImpl(ILoginView view){
        this.view = view;
        this.model = LoginModelImpl.getInstance();
    }

    @Override
    public void Login(String userName, String password){
        Map<String, Object> params = new HashMap<>(2);
        if(userName != null & !"".equals(userName)) {
            params.put("userName", userName);
        }
        if(password != null && !"".equals(password)){
            params.put("password", password);
        }
        model.loginRequest(params, new CommonCallback<LoginRetMsg>() {
            @Override
            public void onError(Throwable e) {
                Toast.makeText(MVPApplication.getContext(), "Login failed", Toast.LENGTH_SHORT).show();
            }

            @Override
            public void onSuccess(LoginRetMsg data) {
                view.loginSuccess();
            }
        });
    }

    @Override
    public void clear() {
        view.clearUserName();
        view.clearPassword();
    }
}

Model:

public interface ILoginModel {
    void loginRequest(Map<String, Object> params, CommonCallback callback);
}
public class LoginModelImpl implements ILoginModel {

    private static LoginModelImpl instance;

    private LoginModelImpl(){
    }

    public static LoginModelImpl getInstance(){
        if(instance == null){
            synchronized (LoginModelImpl.class){
                if(instance == null){
                    instance = new LoginModelImpl();
                }
            }
        }
        return instance;
    }

    @Override
    public void loginRequest(final Map<String, Object> params, final CommonCallback callback) {
        new Thread(){
            //模拟异步操作
            @Override
            public void run() {
                Looper.prepare();
                try{
                    Thread.sleep(2000);
                }catch (InterruptedException e){
                    callback.onError(e);
                }
                if(params.size() > 1) {
                    LoginRetMsg retMsg = new LoginRetMsg();
                    retMsg.setSuccess(true);
                    callback.onSuccess(retMsg);
                }else {
                    callback.onError(new Throwable("You must input your username and password"));
                }
            }
        }.start();
    }
}

除了减少了Activity中的代码,使程序结构更加清晰之外,MVP模式还有哪些好处呢?

  • 分离了视图逻辑和业务逻辑,降低了耦合:
    很多时候,我们在不同的界面中会用到相同的功能。这个时候通常会产生的重复代码或者耦合。使用MVP模式之后,逻辑功能被抽象到Presenter中,Activity通过实现多个View接口并引用不同的Presenter就可以实现功能逻辑代码的复用。
  • Presenter被抽象成接口,可以有多种具体的实现,所以方便进行单元测试:
    在编写界面过程中,我们通常会写一些本地数据进行测试。但每次测试完成后测试代码就要删掉或者注释掉,如果后面发现有问题可能又要重写测试代码。这样反反复复浪费了很多时间。在MVP架构中,由于业务逻辑都在Presenter里,我们完全可以写一个PresenterTest的实现类继承Presenter的接口,现在只要在Activity里把Presenter的创建换成PresenterTest,就能进行单元测试了,测试完再换回来即可。万一发现还得进行测试,那就再换成PresenterTest吧。

MVP架构在Android中可能发生内存泄漏的问题,主要是因为异步任务的回调匿名内部类中持有了View引用,会导致实现传入的View类在生命周期结束时无法被回收。对于这个问题,有多种解决方案,其基本的思路都是讲Presenter的生命周期和Activity实现同步,具体的实现可以参考这篇文章

三、界面响应自动化——MVVM

MVP模式已经比传统的MVC模式要清晰不少了,然而在使用中还是会发现一些问题:

  • 生命周期的控制比较复杂。
  • 接口粒度不好控制。粒度太小,就会存在大量接口的情况,使代码太过碎版化;粒度太大,解耦效果不好。
  • 当UI输入或者数据源产生变化时,需要手动调用接口才能通信,当逻辑复杂时,会产生大量回调接口。

为了解决这些问题,Google推出了Data Binding库 和MVVM架构。

android应用 发展现状 android的发展历程和系统架构_android应用 发展现状_04

MVVM架构

在常规的开发模式中,数据变化需要更新UI的时候,需要先获取UI控件的引用,然后再更新UI。获取用户的输入和操作也需要通过UI控件的引用。在MVVM中,这些都是通过数据驱动来自动完成的,数据变化后会自动更新UI,UI的改变也能自动反馈到数据层,数据成为主导因素。在Android中,MVVM架构通常是基于观察者模式实现的。

四、横向架构——模块化与组件化

前面讲的MV*架构适用的都是按照数据——逻辑——界面的层次来部署,在整个架构体系中来看应该属于纵向架构。而一个APP在开发过程中不仅要关心数据的流向,更要关心业务的分层,亦即横向的架构。

对于一般的APP横向架构的体现一般在于分包,按照功能模块会把整个工程分为成几个目录,然后每个目录中再按MV*架构分层。

但随着整个项目的迭代,这种架构就会渐渐地暴露出很多问题。比如每个模块内的重复造轮子现象比较严重,不同业务之间的功能耦合加深。这个时候,我们就要从各个模块中提炼出其中可以共用的部分,包括底层业务和基础功能,将其封装为单一的组件,对外使用统一的接口来调用。这样便可以实现业务和功能的解耦,当功能组件内部的实现发生变化时,不会影响到业务层的代码。

对于组件化的实践,各大厂都有自己的解决方案,比较典型的如360和携程的插件化,阿里前段时间开源的容器化框架Altas,以及58的路由解决方案都是在自身业务场景下合理的选择。当一个公司的移动端的开发团队越庞大,业务分解的越明确,组件化的重要性就越高。Google官方也推出了Dragger2开源库,其中借鉴了一些AOP编程的思想,主要是通过apt在编译期注入代码,个人认为也可以以此为鉴作为实现组件化的一种途径。

后记

随着业务的发展,项目架构也必然避免不了重构,因此在设计架构时也不要想一步到位,不然很容易犯过度设计的错误。
正所谓抛开业务谈架构都是耍流氓,架构本身并无优劣之分,适合自己项目进度和业务场景的架构才是最好的架构