MVVMArchitecture，一款可配置的 MVVM 框架

简介

作了几年开发后，在 Android 领域我一直指望找到一种较为合理且易用的开发模式，从 MVC 到 MVP，再到如今的 MVVM，配合 Jetpack 套件，以及 Kotlin 和协程，还有 Rx 系列，我认为 Android 的开发范式已经成熟了，再经过 AS 和 Gradle 提供的动态引入代码的功能，彻底能够封装一套开发框架，并尽量提供定制化，基于基本的开发范式，经过配置文件来决定框架的内容。

在开始以前，先来看一张 Google 推荐的架构图：

这是一张 MVVM 架构的示意图，分为 View、ViewModel、Model，三个层次，层与层之间有明确的调用界限，应该尽量的避免跨层调用，可是代码的灵活性是很高的，你很难彻底避免团队成员开发不符合框架标准的代码，一旦有成员对框架的理解不够全面，那么他很可能在交付时间的压力下，选择他熟悉的实现方式来开发。

举一个例子就是：你指望他使用 Glide 来加载图片，但是由于他以前一直用 Fresco，搞很差你稍不留神他就给你来个意外，自行引入了 Fresco，但其实学习 Glide 成本是很低的，尤为是在通过封装的状况下。可是人就是这样，老是倾向于本身熟悉的。

因此在团队中，应该对成员进行必定的培训，以及督促成员自行学习和领悟框架中的知识，并积极发现和上报问题，持续改进框架，而不是一言不合的就想重构推倒整个架构，不得不说“重构”也是新人常常提的问题，并非说必定不能说重构，但说实在不少时候都是由于他对框架不理解，就抨击框架，想法设法想改为本身熟悉的，这个时候团队领导就得正确引导了。

综上所述，维护一套框架的成本是蛮大的，须要造成相应的文档，讲解视频，并组织培训等，但好处也是显而易见的，统一的思想和框架标准，让每个成员都成为了备胎，只要有须要，均可以快速上手，专一于业务逻辑，提升成员的可替代性，不会由于一人的离职而形成他负责的业务无人可接的状况。

好了，下面咱们看看如何来建立这样的一个基本框架。

指望达到的目标

咱们先来定目标，理清楚咱们对于框架的指望。通过梳理，我认为框架要达到的目标以下：

1. 基础的框架范式

采用 MVVM 模式。框架会对基本的功能进行封装，使得层与层之间的调用变得容易，减小样板代码，易于上手，对于必不可少的样板代码，能够经过 AS 的 File Templates 和 Live Templates 来快速生成，或者写个 AS 插件就更好了。

2. 统一的第三方库

对于库的使用尽量进行封装，避免引入功能重复的库。尽可能使用官方的。

3. 尽可能可定制化，减小包大小

对于某些小型的项目，或者项目中不想要的第三方库，能够经过配置文件去除指定的库，减小包的大小。甚至对于部分功能，也要作到可定制化，尽可能避免没必要要的实例建立。

4. 统一的框架维护，更新便捷。

利用 git 的 submodule 功能，引入框架的源码，不采用远程仓库的方式，由于远程仓库每次更新都要更新版本，太麻烦了，不灵活。 若是你的代码是要交付出去的，好比外包，那么最终能够清除掉框架的 .git 目录，同时对框架进行清理后再交付，以避免交付了客户不想要的代码，同时也对框架作一个保留。 团队成员齐心合力对框架的各项功能进行持续的优化，对于框架的更新和代码合并，需进行评审。

View 视图层，简称 V 层

在 Android 中，属于 View 层的有 Activity/Fragment，还有对应的 xml 文件。

关于布局的建议，优先采用 ConstraintLayout，可是若是很明显是线性布局的，采用 LinearLayout，简单列表采用 ListView，简单网格采用 GridView，复杂的用 RecyclerView。

下拉刷新上拉加载优先用 scwang90/SmartRefreshLayout，若是只有下拉刷新，采用 SwipeRefreshLayout。

视图层会封装 BaseActivity/BaseFragment，持有 ViewModel 和 ViewDataBinding 的实例，这样用户的操做能够流向 VM 层。

在 V 层发起异步，可以使用 lifecycleScope 或 lifecycle.coroutineScope 协程，让异步跟随生命周期，在生命周期结束时取消协程。

ViewModel 业务逻辑层，简称 VM 层

在 Android 中，VM 层是由继承自 ViewModel 或 AndroidViewModel 的类组成，VM 层持有 Repository 仓库实例，能够向仓库请求数据，那么如何把数据流向 V 层呢？首先要明确的一个点就是：VM 层绝对不能持有 V 层的实例，这个是相当重要的，不然会形成内存泄露。那么不持有 V 层实例如何把数据流过去呢？

答案是经过 LiveData 或 DataBinding 将数据流回 V 层。只有这两种作法。

另外，经过 Lifecycles，VM 能够 感知 V 层的生命周期，VM 层的生命周期和 V 层保持一致，这也是能够封装的点。但只有 V 彻底销毁时，onCleared 方法才会回调。

在 VM 层发起异步或调用 Repository 数据，使用 viewModelScope 生命周期感知型协程替代 Rx，在界面销毁时可自动取消协程，性能也好。 或者使用 liveData 协程，这样在 liveData 被激活时自动执行协程，若是未执行完成就被取消，那么下次激活时还会自动执行。

VM 和 V 层的交互，很大程度上能够经过 DataBinding 来实现，DataBinding 是 Google 推出的数据绑定库，应该尽可能使用。固然，不用的话，也能够在 V 层写相关的代码，可是 DataBinding 能够最大程度的减小样板代码，默认框架应该要求使用 DataBinding。

VM 层和 V 层能够封装一些经常使用的功能，好比加载中对话框，启动和结束界面等，同时应该考虑到有些界面不须要这些功能，所以也应该提供取消这些功能的接口，以避免形成没必要要的实例建立。

Model 数据层，简称 M 层

主要用 Repository 仓库来表示，Retrofit2 用于请求网络，Gson 用于解析 JSON，Room 用于存储本地数据。

访问网络、数据库、文件等，都可以使用协程来实现异步。

一般来讲，Repository 会持有多个数据实例，好比网络数据实例和本地数据实例，可是对外暴露的接口，提供的数据来源对于使用者是无感知的，即 VM 或 V 层是不用关心数据的来源，统一由 M 层来控制。

在 Google 的架构指南中，推荐使用 Room 做为单一的数据源，即便用者获取数据所有经过 Room，而利用 Room 的特性，M 层操做 Room 将会自动响应给使用者最新的变化。

这种作法好很差，一般还得结合需求，在请求网络数据前，为了防止出现白屏，常常会先使用本地数据，等到网络数据请求成功了再刷新。

Jetpack 必须有的库

基础

• AndroidX
• AppCompat
• MultiDex
• Fragment

架构

• DataBinding
• Lifecycles
• LiveData
• ViewModel

Jetpack 可选的库

• Benchmark

• Security

• Navigation

• Room

• Paging

• WorkManager

• CameraX

• DownloadManager

• Notifications

• Permissions

• Preference

• Animation

• Palette

其余必须的库

• ConstraintLayout
• Kotlin
• Kotlin-ktx

其余可选的库

• RecyclerView
• material
• swiperefreshlayout
• viewPager2
• retrofit二、retrofit2RxJava2
• glide
• gson、gsonConverter
• rxAndroid二、rxJava二、rxKotlin
• debugDB
• leakCanary2
• bindingAdapter
• livePermissions
• 各类 ktx

各类可选的支持库

• GridLayout
• CardView
• ...

总结

综上所述，我在 Github 中开源了 MVVMArchitecture 框架，部分灵感是来自 MVVMHabit 和 MVVMLin。

MVVMArchitecture 主代码使用的是 Kotlin 编写，部分工具类代码使用的 Java，对于框架的内容，大幅度增长了定制化功能，尽可能作到全局可配置和单独可配置，详见 Github 的 Wiki，后续会进行持续的优化和改进，欢迎 fork、star、issue。