Android开发架构

如果开发过程中大家各自为战，没有统一规范，久而久之，项目代码会变得混乱且后续难以维护。当使用统一的架构模式后，有很多的好处，如：

• 统一开发规范，使得代码整洁、规范，后续易于维护及扩展
• 提高开发效率(尤其在团队人员较多时)
• 模块单一职责，使得模块专注自己内部(面向对象)，模块间解耦

总之，开发架构是前人总结出来的一套行之有效的开发模式，目的是达到高内聚，低耦合的效果，使得项目代码更健壮、易维护。

Android中常见的架构模式有MVC（Model-View-Controller）、MVP（Model-View-Presenter）、MVVM（Model-View-ViewModel），一起来看下各自的特点:

MVC

MVC（Model-View-Controller）是比较早期的架构模式，模式整体也比较简单。

MVC模式将程序分成了三个部分：

• Model模型层：业务相关的数据(如网络请求数据、本地数据库数据等)及其对数据的处理
• View视图层：页面视图(通过XML布局编写视图层)，负责接收用户输入、发起数据请求及展示结果页面
• Controller控制器层：M与V之间的桥梁，负责业务逻辑

MVC特点：

• 简单易用：上图表述了数据整个流程：View接收用户操作，通过Controller去处理业务逻辑，并通过Model去获取/更新数据，然后Model层又将最新的数据传回View层进行页面展示。
• 架构简单的另一面往往是对应的副作用：由于XML布局能力弱，我们的View层的很多操作都是写在Activity/Fragment中，同时，Controller、Model层的代码也大都写在Activity/Fragment中，这就会导致一个问题，当业务逻辑比较复杂时，Activity/Fragment中的代码量会很大，其违背了类单一职责，不利于后续扩展及维护。尤其是后期你刚接手的项目，一个Activity/Fragment类中的代码动辄上千行代码，那感觉着实酸爽：当然，如果业务很简单，使用MVC模式还是一种不错的选择。

MVP

MVP（Model-View-Presenter），架构图如下：

MVP各模块职责如下：

• Model模型：业务相关的数据(如网络请求数据、本地数据库数据等)及其对数据的处理
• View视图：页面视图(Activity/Fragment)，负责接收用户输入、发起数据请求及展示结果页面
• Presenter：M与V之间的桥梁，负责业务逻辑

MVP特点： View层接收用户操作，并通过持有的Presenter去处理业务逻辑，请求数据；接着Presenter层通过Model去获取数据，然后Model又将最新的数据传回Presenter层，Presenter层又持有View层的引用，进而将数据传给View层进行展示。

MVP相比MVC的几处变化：

• View层与Model层不再交互，而是通过Presenter去进行联系
• 本质上MVP是面向接口编程，Model/View/Presenter每层的职责分工明确，当业务复杂时，整个流程逻辑也是很清晰的

当然，MVP也不是十全十美的，MVP本身也存在以下问题：

• View层会抽象成IView接口，并在IView中声明一些列View相关的方法；同样的，Presenter会被抽象成IPresenter接口及其一些列方法，每当实现一个功能时，都需要编写多个接口及其对应的方法，实现起来相对比较繁琐，而且每次有改动时，对应的接口方法也基本都会再去改动。
• View层与Presenter层相互持有，当View层关闭时，由于Presenter层不是生命周期感知的，可能会导致内存泄漏甚至是崩溃。

ps：如果你的项目中使用了RxJava，可以使用 AutoDispose 自动解绑。

MVVM

MVVM（Model-View-ViewModel），架构图如下：

MVVM各职责如下：

• Model模型：业务相关的数据(如网络请求数据、本地数据库数据等)及其对数据的处理
• View视图：页面视图(Activity/Fragment)，负责接收用户输入、发起数据请求及展示结果页面
• ViewModel：M与V之间的桥梁，负责业务逻辑

MVVM特点：

• View层接收用户操作，并通过持有的ViewModel去处理业务逻辑，请求数据；
• ViewModel层通过Model去获取数据，然后Model又将最新的数据传回ViewModel层，到这里，ViewModel与Presenter所做的事基本是一样的。但是ViewModel不会也不能持有View层的引用，而是View层会通过观察者模式监听ViewModel层的数据变化，当有新数据时，View层能自动收到新数据并刷新界面。

UI驱动 vs 数据驱动

MVP中，Presenter中需要持有View层的引用，当数据变化时，需要主动调用View层对应的方法将数据传过去并进行UI刷新，这种可以认为是UI驱动；而MVVM中，ViewModel并不会持有View层的引用，View层会监听数据变化，当ViewModel中有数据更新时，View层能直接拿到新数据并完成UI更新，这种可以认为是数据驱动，显然，MVVM相比于MVP来说更加解耦。

MVVM的具体实现

上面介绍了MVC/MVP/MVVM的各自特点，其中MVC/MVP的具体使用方式，本文不再展开实现，接下来主要聊一下MVVM的使用及封装，MVVM也是官方推荐的架构模式。

Jetpack MVVM

Jetpack是官方推出的一系列组件库，使用组件库开发有很多好处，如：

• 遵循最佳做法：采用最新的设计方法构建，具有向后兼容性，可以减少崩溃和内存泄漏
• 消除样板代码：开发者可以更好地专注业务逻辑
• 减少不一致：可以在各种Android版本中运行，兼容性更好。

为了实现上面的MVVM架构模式，Jetpack提供了多个组件来实现，具体来说有Lifecycle、LiveData、ViewModel(这里的ViewModel是MVVM中ViewModel层的具体实现)，其中Lifecycle负责生命周期相关；LiveData赋予类可观察，同时还是生命周期感知的(内部使用了Lifecycle)；ViewModel旨在以注重生命周期的方式存储和管理界面相关的数据，针对这几个库的详细介绍及使用方式就不再展开了。

通过这几个库，就可以实现MVVM了，官方也发布了MVVM的架构图：

其中Activity/Fragment为View层，ViewModel+LiveData为ViewModel层，为了统一管理网络数据及本地数据数据，又引入了Repository中间管理层，本质上是为了更好地管理数据，为了简单把他们统称为Model层吧。

使用举例

• View层代码：

//MvvmExampleActivity.kt
class MvvmExampleActivity : BaseActivity() {

    private val mTvContent: TextView by id(R.id.tv_content)
    private val mBtnQuest: Button by id(R.id.btn_request)
    private val mToolBar: Toolbar by id(R.id.toolbar)

    override fun getLayoutId(): Int {
        return R.layout.activity_wan_android
    }

    override fun initViews() {
        initToolBar(mToolBar, "Jetpack MVVM", true)
    }

    override fun init() {
        //获取ViewModel实例，注意这里不能直接new，因为ViewModel的生命周期比Activity长
        mViewModel = ViewModelProvider(this).get(WanViewModel::class.java)

        mBtnQuest.setOnClickListener {
            //请求数据
            mViewModel.getWanInfo()
        }

        //ViewModel中的LiveData注册观察者并监听数据变化
        mViewModel.mWanLiveData.observe(this) { list ->
            val builder = StringBuilder()
            for (index in list.indices) {
                //每条数据进行折行显示
                if (index != list.size - 1) {
                    builder.append(list[index])
                    builder.append("\n\n")
                } else {
                    builder.append(list[index])
                }
            }
            mTvContent.text = builder.toString()
        }
    }
}

• ViewModel层代码：

//WanViewModel.kt
class WanViewModel : ViewModel() {
    //LiveData
    val mWanLiveData = MutableLiveData<List<WanModel>>()
    //loading
    val loadingLiveData = SingleLiveData<Boolean>()
    //异常
    val errorLiveData = SingleLiveData<String>()

    //Repository中间层 管理所有数据来源 包括本地的及网络的
    private val mWanRepo = WanRepository()

    fun getWanInfo(wanId: String = "") {
        //展示Loading
        loadingLiveData.postValue(true)
        viewModelScope.launch(Dispatchers.IO) {
            try {
                val result = mWanRepo.requestWanData(wanId)
                when (result.state) {
                    State.Success -> mWanLiveData.postValue(result.data)
                    State.Error -> errorLiveData.postValue(result.msg)
                }
            } catch (e: Exception) {
                error(e.message ?: "")
            } finally {
                loadingLiveData.postValue(false)
            }
        }
    }
}

• Repository层(Model层)代码：

class WanRepository {

    //请求网络数据
    suspend fun requestWanData(drinkId: String): BaseData<List<WanModel>> {
        val service = RetrofitUtil.getService(DrinkService::class.java)

        val baseData = service.getBanner()
        if (baseData.code == 0) {
            //正确
            baseData.state = State.Success
        } else {
            //错误
            baseData.state = State.Error
        }
        return baseData
    }
}

这里只通过Retrofit请求了网络数据 玩Android 开放API，如果需要添加本地数据，只需要在方法里添加本地数据处理即可，即 Repository是数据的管理中间层，对数据进行统一管理，ViewModel层中不需要关心数据的来源，大家各司其职即可，符合单一职责，代码可读性更好，同时也更加解耦。在View层点击按钮请求数据，执行结果如下：

以上就完成了一次网络请求，相比于MVP，MVVM既不用声明多个接口及方法，同时ViewModel也不会像Presenter那样去持有View层的引用，而是生命周期感知的，MVVM方式更加解耦。

封装

上一节介绍了Jetpack MVVM的使用例子，可以看到有一些代码逻辑是可以抽离出来封装到公共部分的，那么本节就尝试对其做一次封装。

首先，请求数据时可能会展示Loading，请求完后可能是空数据、错误数据，对应下面的IStatusView接口声明：

interface IStatusView {
    fun showEmptyView() //空视图
    fun showErrorView(errMsg: String) //错误视图
    fun showLoadingView(isShow: Boolean) //展示Loading视图
}

因为ViewModel是在Activity中初始化的，所以可以封装成一个Base类：

abstract class BaseMvvmActivity<VM : BaseViewModel> : BaseActivity(), IStatusView {

    protected lateinit var mViewModel: VM
    protected lateinit var mView: View
    private lateinit var mLoadingDialog: LoadingDialog

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        mLoadingDialog = LoadingDialog(this, false)
        mViewModel = getViewModel()!!
        init()
        registerEvent()
    }

    /**
     * 获取ViewModel 子类可以复写，自行初始化
     */
    protected open fun getViewModel(): VM? {
        //当前对象超类的Type
        val type = javaClass.genericSuperclass
        //ParameterizedType表示参数化的类型
        if (type != null && type is ParameterizedType) {
            //返回此类型实际类型参数的Type对象数组
            val actualTypeArguments = type.actualTypeArguments
            val tClass = actualTypeArguments[0]
            return ViewModelProvider(this).get(tClass as Class<VM>)
        }
        return null
    }

    override fun showLoadingView(isShow: Boolean) {
        if (isShow) {
            mLoadingDialog.showDialog(this, false)
        } else {
            mLoadingDialog.dismissDialog()
        }
    }

    override fun showEmptyView() {
       ......
    }

    //错误视图 并且可以重试
    override fun showErrorView(errMsg: String) {
       .......
    }

    private fun registerEvent() {
       //接收错误信息
       mViewModel.errorLiveData.observe(this) { errMsg ->
           showErrorView(errMsg)
       }
       //接收Loading信息
       mViewModel.loadingLiveData.observe(this, { isShow ->
           showLoadingView(isShow)
       })
    }

    abstract fun init()
}

Base类中初始化ViewModel，还可以通过官方activity-ktx、fragment-ktx扩展库，初始化方式：val model: VM by viewModels()。

子类中继承如下：

class MvvmExampleActivity : BaseMvvmActivity<WanViewModel>() {

    private val mTvContent: TextView by id(R.id.tv_content)
    private val mBtnQuest: Button by id(R.id.btn_request)
    private val mToolBar: Toolbar by id(R.id.toolbar)

    override fun getLayoutId(): Int {
        return R.layout.activity_wan_android
    }

    override fun initViews() {
        initToolBar(mToolBar, "Jetpack MVVM", true)
    }

    override fun init() {
        mBtnQuest.setOnClickListener {
            //请求数据
            mViewModel.getWanInfo()
        }
        /**
         * 这里使用了扩展函数，等同于mViewModel.mWanLiveData.observe(this) {}
         */
        observe(mViewModel.mWanLiveData) { list ->
            val builder = StringBuilder()
            for (index in list.indices) {
                //每条数据进行折行显示
                if (index != list.size - 1) {
                    builder.append(list[index])
                    builder.append("\n\n")
                } else {
                    builder.append(list[index])
                }
            }
            mTvContent.text = builder.toString()
        }
    }
}

我们把ViewModel的初始化放到了父类里进行，代码看上去更简单了。监听数据变化mViewModel.mWanLiveData.observe(this) {} 方式改成observe(mViewModel.mWanLiveData) {}方式，少传了一个LifecycleOwner，其实这是一个扩展函数，如下：

fun <T> LifecycleOwner.observe(liveData: LiveData<T>, observer: (t: T) -> Unit) {
    liveData.observe(this, { observer(it) })
}

ps：我们初始化View控件时，如 private val mBtnQuest: Button by id(R.id.btn_request)，依然使用了扩展函数，如下：

fun <T : View> Activity.id(id: Int) = lazy {
    findViewById<T>(id)
}

不用像写java代码中那样时刻要想着判空，同时只会在使用时才会进行初始化，很实用！

说回来，接着是ViewModel层的封装，BaseViewModel.kt：

abstract class BaseViewModel : ViewModel() {
    //loading
    val loadingLiveData = SingleLiveData<Boolean>()
    //异常
    val errorLiveData = SingleLiveData<String>()

    /**
     * @param request 正常逻辑
     * @param error 异常处理
     * @param showLoading 请求网络时是否展示Loading
     */
    fun launchRequest(
        showLoading: Boolean = true,
        error: suspend (String) -> Unit = { errMsg ->
            //默认异常处理，子类可以进行覆写
            errorLiveData.postValue(errMsg)
        }, request: suspend () -> Unit
    ) {
        //是否展示Loading
        if (showLoading) {
            loadStart()
        }

        //使用viewModelScope.launch开启协程
        viewModelScope.launch(Dispatchers.IO) {
            try {
                request()
            } catch (e: Exception) {
                error(e.message ?: "")
            } finally {
                if (showLoading) {
                    loadFinish()
                }
            }
        }
    }

    private fun loadStart() {
        loadingLiveData.postValue(true)
    }

    private fun loadFinish() {
        loadingLiveData.postValue(false)
    }
}

扩展一下： 1、上面执行网络请求时，使用viewModelScope.launch来启动协程，引入方式：

implementation 'androidx.lifecycle:lifecycle-livedata-ktx:2.2.0'

这样就可以直接在ViewModel中启动协程并且当ViewModel生命周期结束时协程也会自动关闭，避免使用GlobalScope.launch { }或MainScope().launch { }还需自行关闭协程， 当然，如果是在Activity/Fragment、liveData中使用协程，也可以按需引入：

implementation 'androidx.lifecycle:lifecycle-runtime-ktx:2.2.0'
implementation 'androidx.lifecycle:lifecycle-livedata-ktx:2.2.0'

具体可以参见官方的 将 Kotlin 协程与生命周期感知型组件一起使用 这篇文章。

2、另外细心的读者可能观察到，上面我们的Loading、Error信息监听都是用的SingleLiveData，把这个类打代码贴一下：

/**
 * 多个观察者存在时，只有一个Observer能够收到数据更新
 * https://github.com/android/architecture-samples/blob/dev-todo-mvvm-live/todoapp/app/src/main/java/com/example/android/architecture/blueprints/todoapp/SingleLiveEvent.java
 */
class SingleLiveData<T> : MutableLiveData<T>() {
    companion object {
        private const val TAG = "SingleLiveEvent"
    }
    private val mPending = AtomicBoolean(false)

    @MainThread
    override fun observe(owner: LifecycleOwner, observer: Observer<in T>) {
        if (hasActiveObservers()) {
            Log.w(TAG, "Multiple observers registered but only one will be notified of changes.")
        }
        // Observe the internal MutableLiveData
        super.observe(owner) { t ->
            //如果expect为true，那么将值update为false，方法整体返回true，
            //即当前Observer能够收到更新，后面如果还有订阅者，不能再收到更新通知了
            if (mPending.compareAndSet(true, false)) {
                observer.onChanged(t)
            }
        }
    }

    override fun setValue(@Nullable value: T?) {
        //AtomicBoolean中设置的值设置为true
        mPending.set(true)
        super.setValue(value)
    }

    /**
     * Used for cases where T is Void, to make calls cleaner.
     */
    @MainThread
    fun call() {
        value = null
    }
}

可以看到SingleLiveData还是继承自MutableLiveData，区别是当多个观察者存在时，只有一个Observer能够收到数据更新，本质上是在observe()时通过CAS加了限制，注释已经很详细了，不再赘述。

子类中继承如下：

class WanViewModel : BaseViewModel() {
    //LiveData
    val mWanLiveData = MutableLiveData<List<WanModel>>()

    //Repository中间层 管理所有数据来源 包括本地的及网络的
    private val mWanRepo = WanRepository()

    fun getWanInfo(wanId: String = "") {
        launchRequest {
            val result = mWanRepo.requestWanData(wanId)
            when (result.state) {
                State.Success -> mWanLiveData.postValue(result.data)
                State.Error -> errorLiveData.postValue(result.msg)
            }
        }
    }
}

最后是对Model层的封装，BaseRepository.kt：

open class BaseRepository {
    suspend fun <T : Any> executeRequest(
        block: suspend () -> BaseData<T>
    ): BaseData<T> {
        val baseData = block.invoke()
        if (baseData.code == 0) {
            //正确
            baseData.state = State.Success
        } else {
            //错误
            baseData.state = State.Error
        }
        return baseData
    }
}

数据基类BaseData.kt：

class BaseData<T> {
    @SerializedName("errorCode")
    var code = -1
    @SerializedName("errorMsg")
    var msg: String? = null
    var data: T? = null
    var state: State = State.Error
}

enum class State {
    Success, Error
}

子类中继承如下：

class WanRepository : BaseRepository() {
    suspend fun requestWanData(drinkId: String): BaseData<List<WanModel>> {
        val service = RetrofitUtil.getService(DrinkService::class.java)
        return executeRequest {
            service.getBanner()
        }
    }
}