本文已授权 微信公众号 玉刚说 （@任玉刚）独家发布。
本文中我将尝试分享我个人 搭建个人MVVM项目 的过程中的一些心得和踩坑经历，以及在这过程中目前对 编程本质 的一些个人理解和感悟，特此分享以期讨论及学习进步。
缘由
最近在尝试搭建自己理解的 MVVM模式 的应用程序，在这近一个月中，我思考了很多，也参考了若干Github上MVVM项目源码，并从中获益匪浅。
我根据所得搭建了一个MVVM开发模式的Github客户端，并托管在了自己的github上：
MVVM-Rhine: MVVM+Jetpack的Github客户端
创建这个项目的原因是我想有一个自己写的 Github客户端 方便我查看，目前我基本实现了自己的目标，App整体的效果是这样的：
在开发过程中，我根据自己对于编程的理解，在技术选型中，加了一些自己喜欢的库，写了一些自己比较满意的风格的代码，特此和大家一起分享我的所得，谬误之处，欢迎拍砖。
1.我为什么选择Kotlin?
回顾近半年来，我博客中的编程语言使用的清一色是 Kotlin，这样做的最初目的是督促自己学习Kotlin。
我曾在 某篇文章 中这样声明我用Kotlin的原因：
不仅如此，Kotlin语言国外已经有相当的热度了，只是目前相比Java，国内还没有完全推广起来而已。
此外，Kotlin的一些特性能够让我们实现Java实现不了的东西（不是空安全，无需findViewById这些基本的语法糖），对于某些设计点，Kotlin是Java无法替代的，这点我会在后文中提到。
2.MVVM的本质：异步观察者模式
很多朋友对RxJava的理解是 链式调用、线程切换 等等，对我来说，在RxJava的逐渐使用过程中，我对它的理解慢慢趋于 异步 一词——RxJava 强迫开发者从思想上将异步代码和同步代码归于一统，对于任何业务功能，都可以抽象为一个可观察的对象。
MVVM的本质亦是如此，DataBinding 帮我们为 数据驱动视图 提供了可实现的方案，因此它成为了大多数MVVM项目中的核心库。
MVVM观察者模式的本质也意味着，即使没有DataBinding，我们通过RxJava或者其他方式也能够实现 MVVM，只不过DataBinding更方便搭建MVVM而已。
这里不拿MVC、MVP和MVVM进行比较，因为不同的架构思想，都有不同的优劣势，我非常沉迷于RxJava和其优秀的思想，我认为它的思想相当一部分和MVVM不谋而合，因此我更倾向使用MVVM，配合以RxJava，能够让代码更加赏心悦目。
3.Android Jetpack: Architecture Components
Android Jetpack（下称Jetpack） 是Google今年IO大会上正式推出官方的新一代 组件、工具和架构指导 ，旨在加快开发者的 Android 应用开发速度:
这是一套非常迷人的架构组件，Google今年还同步（其实晚了2个月）开源了一个Jetpack的示例项目 Sunflower。
这个示例项目有着丰富的学习价值，也很方便开发者迅速上手并熟悉Jetpack的组件——当然，只是上手当然满足不了我的需求，我想通过自己参与一个项目的实践来深入了解并感受这些组件，于是 我在这个项目中使用了这些组件：
我简单通过个人感受分别阐述一下这些组件真正融入MVVM项目中的感受：
3.1 DataBinding
MVVM的 核心组件，通过良好的设计，我的项目中避免了95%以上的 冗余代码—— 它的作用简单直接，就是 数据驱动视图，我再也不需要去通过控件设置UI，相反，所有UI的变动都交给了 被观察的成员属性 去驱动。
View的点击事件：
<ImageView
android:id="@+id/btnEdit"
android:layout_width="40dp"
android:layout_height="40dp"
android:src="@drawable/ic_edit_pencil"
app:bind_onClick="@{ () -> delegate.edit() }" />
ImageView的url加载：
<ImageView
android:id="@+id/ivAvatar"
android:layout_width="80dp"
android:layout_height="80dp"
app:bind_imageUrl_circle="@{ delegate.viewModel.user.avatarUrl }" />
TextView的设置值：
<TextView
android:id="@+id/tvNickname"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@{ delegate.viewModel.user.name }" />
有同学觉得这太简单，那我们换一些有说服力的。
你还在 Activity 代码配置 RecyclerView？直接xml里一次性配置RecyclerView，包括 滑动动画，下拉刷新，点击按钮列表滑动到顶部：
<android.support.v4.widget.SwipeRefreshLayout
android:layout_width="match_parent"
android:layout_height="match_parent"
app:onRefreshListener="@{ () -> delegate.viewModel.queryUserRepos() }" // 刷新监听
app:refreshing="@{ safeUnbox(delegate.viewModel.loading) }"> // 刷新状态
<android.support.v7.widget.RecyclerView
android:id="@+id/recyclerView"
app:bind_adapter="@{ delegate.viewModel.adapter }" // 绑定Adapter
app:bind_scrollStateChanges="@{ delegate.fabViewModel.stateChangesConsumer }"
app:bind_scrollStateChanges_debounce="@{ 500 }"
app:layoutManager="android.support.v7.widget.LinearLayoutManager"
tools:listitem="@layout/item_repos_repo" />
</android.support.v4.widget.SwipeRefreshLayout>
<android.support.design.widget.FloatingActionButton
android:id="@+id/fabTop"
android:src="@drawable/ic_keyboard_arrow_up_white_24dp"
app:bind_onClick="@{ () -> recyclerView.scrollToPosition(0) }" // 点击事件，列表直接回到顶部
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent" />
还在配置 ViewPager+Fragment+BottomNavigationView的切换效果，包括ViewPager滑动切换监听，自动配置Adapter，BottomNavigation的点击监听, 我们都在Xml声明好，交给DataBinding就行了：
<android.support.v4.view.ViewPager
android:id="@+id/viewPager"
app:onViewPagerPageChanged="@{ (index) -> delegate.onPageSelectChanged(index) }"
app:viewPagerAdapter="@{ delegate.viewPagerAdapter }"
app:viewPagerDefaultItem="@{ 0 }"
app:viewPagerPageLimit="@{ 2 }" />
<android.support.design.widget.BottomNavigationView
android:id="@+id/navigation"
app:bind_onNavigationBottomSelectedChanged="@{ (menuItem) -> delegate.onBottomNavigationSelectChanged(menuItem) }"
app:itemBackground="@color/colorPrimary"
app:itemIconTint="@drawable/selector_main_bottom_nav_button"
app:itemTextColor="@drawable/selector_main_bottom_nav_button"
app:menu="@menu/menu_main_bottom_nav" />
篇幅所限，省略了一些常见的属性，上述的所有源码，你都可以在我的项目中找到。
我的意思不是想说 DataBinding 多么强大（它确实可以实现足够多的功能），对我而言，它最强大的好处是—— 节省了足够多UI控件的设置代码，让我能够 抽出更多时间去写纯粹业务逻辑的代码。
有朋友觉得DataBinding最大的问题就是不好Debug，我的解决方案是统一 状态管理，这个后文再提。
3.2 Lifecycle
Lifecycle 让我能够更专注于 业务逻辑 而非 生命周期，我认为这是不可代替的，如果你熟悉 Lifecycle,你可以看我的这篇文章：
Android官方架构组件Lifecycle:生命周期组件详解&原理分析
Lifecycle能够让我想要的组件也拥有 生命周期（实际上是对生命周期容器的观察），比如，我不再需要让Activity或者Fragment在onCreated()中去请求网络，取而代之的是：
class LoginViewModel(private val repo: LoginDataSourceRepository) : BaseViewModel() {
override fun onCreate(lifecycleOwner: LifecycleOwner) {
super.onCreate(lifecycleOwner)
// 自动登录
autoLogin.toFlowable()
.filter { it }
.doOnNext { login() }
.bindLifecycle(this)
.subscribe()
}
}
上文的示例代码展示了，Login界面的自动登录逻辑（当然也可以是网络请求展示数据的逻辑），ViewModel检测到了Activity的生命周期并自动调用了
onCreate()函数——我并没有通过Activity去调用它。
3.3 ViewModel
ViewModel能够检测到持有者的 生命周期，并避免了 横竖屏切换时额外的代码的配置，它的内部是通过一个不可见的 Fragment 对数据进行持有，并在真正该销毁数据的时候去销毁它们。
同时，它是MVVM中的 核心组件，我在项目的规范定义中，layout中所有的属性配置都应该依赖于ViewModel中的MutableLiveData属性:
class LoginViewModel(
private val repo: LoginDataSourceRepository
) : BaseViewModel() {
val username: MutableLiveData<String> = MutableLiveData() // 用户名输入框
val password: MutableLiveData<String> = MutableLiveData() // 密码输入框
val loading: MutableLiveData<Boolean> = MutableLiveData() // ProgressBar
val error: MutableLiveData<Option<Throwable>> = MutableLiveData() // Errors
val userInfo: MutableLiveData<LoginUser> = MutableLiveData() // 用户信息
private val autoLogin: MutableLiveData<Boolean> = MutableLiveData() // 是否自动登录
// ......
}
3.4 LiveData
参照 RxJava 丰富的生态圈, LiveData 看起来似乎实在鸡肋，但是DataBinding在最近的版本中提供了对 LiveData 的支持，考虑再三，我采用了 LiveData，正如上文示例代码，配合以 ViewModel, UI完整的驱动系统被搭建起来。
LiveData并非一无是处，它确实值得我作为依赖添加进自己的项目中，原因有二：
- 原生支持 DataBinding 和 Room
实际上 Paging 也是支持的，但是我没有用到Paging。
- 安全的数据更新
RxJava在子线程进行UI的更新依赖于 observerOn(AndroidSchedudler.mainThread())，但是LiveData不需要，你只需要通过 postValue()，就能安全的进行数据更新，就像这样:
val loading: MutableLiveData<Boolean> = MutableLiveData()
this.loading.postValue(value) // 数据的设置会在主线程上
但是我仍然需要面临一个问题，就是LiveData的生态圈实在没办法和 RxJava 相关的库对比，想要通过LiveData的操作符进行业务处理实在不靠谱，因此我选择将LiveData的observe()变成RxJava的Flowable：
private val autoLogin: MutableLiveData<Boolean> = MutableLiveData()
autoLogin.toFlowable() // 变成了一个Flowable
.filter { it }
.doOnNext { login() }
.bindLifecycle(this)
.subscribe()
得益于 kotlin 强大的 扩展函数，两者之间的融合如 丝滑般的流畅：
fun <T> LiveData<T>.toFlowable(): Flowable<T> = Flowable.create({ emitter ->
val observer = Observer<T> { data ->
data?.let { emitter.onNext(it) }
}
observeForever(observer)
emitter.setCancellable {
object : MainThreadDisposable() {
override fun onDispose() = removeObserver(observer)
}
}
}, BackpressureStrategy.LATEST)
现在，我们一边享受着 LiveData 安全的数据更新和DataBinding的原生支持，一边享受 RxJava 无以伦比 强大的操作符和函数式编程思想，这简直让我如沐春风。
3.5 Room
ORM数据库，市面上太多了不解释，我选择使用它的原因有二：
- 1.Google爸爸官方出品，无脑用
- 2.原生支持
RxJava和LiveData, 无脑用
真香。
3.6 Navigation
Google官方 单Activity多Fragment 的架构组件，如果你不是很熟悉，可以参考这篇文章：
Android官方架构组件Navigation：大巧不工的Fragment管理框架
很感谢文章吹来之后，很多同学对文章的肯定，我也相信很多同学已经熟悉甚至尝试上手了这个库，我这次尝试在项目中使用它，原因是，我想试试 它是不是真的像我文章吹的那么好用。
经实战，初步结果是：
可以用，但没必要。
在大多数情况下，Navigation都显得非常稳健，但是 框架是死的，但是需求是千变万化的，我总是不可避免去面对一些问题：
1.官方提供了
Navigation对Toolbar和BottomNavigationView的原生支持，但是令我哭笑不得的是，Navigation内部对Fragment的切换采用的是replace(),这意味着，每次点击底部导航控件，我都会销毁当前的Fragment，并且实例化一个新的Fragment。2.很多APP采用了Home界面，双击返回才会退出Application的需求，正常我们可以重写Activity的
onBackPress()方法，而使用了Navigation，我们不得不把导航的返回行为委托给了Navigation：
class MainActivity : BaseActivity<ActivityMainBinding>() {
override val layoutId = R.layout.activity_main
override fun onSupportNavigateUp(): Boolean =
findNavController(R.id.navHostFragment).navigateUp()
// ...
}
当然，这些问题都是有解决方案的，以BottomNavigationView每次切换都会销毁当前Fragment并实例化新的Fragment为例，我的建议是：
对根布局的View使用
Navigation，界面内部的布局采用常规实现方式（比如ViewPager+Fragment）。
比如我在MainActivity中声明NavHostFragment:
<android.support.constraint.ConstraintLayout
android:id="@+id/container"
android:layout_width="match_parent"
android:layout_height="match_parent">
<fragment
android:id="@+id/navHostFragment"
android:name="androidx.navigation.fragment.NavHostFragment"
android:layout_width="0dp"
android:layout_height="0dp"
app:defaultNavHost="true"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintTop_toTopOf="parent"
app:navGraph="@navigation/navigation_main" />
</android.support.constraint.ConstraintLayout>
我的BottomNavigationView导航界面,则是一个MainFragment：
<android.support.constraint.ConstraintLayout
android:id="@+id/container"
android:layout_width="match_parent"
android:layout_height="match_parent">
<android.support.v4.view.ViewPager
android:id="@+id/viewPager"
android:layout_width="0dp"
android:layout_height="0dp"" />
<android.support.design.widget.BottomNavigationView
android:id="@+id/navigation"
android:layout_width="0dp"
android:layout_height="wrap_content"
app:menu="@menu/menu_main_bottom_nav" />
</android.support.constraint.ConstraintLayout>
我保证 只有根布局的页面通过Navigation进行导航，至于Navigation对BottomNavigationView的原生支持，我选择无视......
总而言之，对于是否使用Navigation，我的建议是持保守态度，因为这个东西和其它三方库不同，Navigation的配置是 项目级 的。
4. 天马行空：RxJava
关于项目中RxJava相关库的配置，我选择了这些：
我是RxJava的重度依赖使用者，它让我沉迷于 业务逻辑的抽象，尝试将所有代码归 异步 于一统，因此我依赖了这些库。
5. 依赖注入：Kodein
编程的乐趣在于 探索，对于Android开发者来说，Dagger2 可能会是更多开发者的首选，但对于一个 探索性质更多 的项目来说，Dagger2 并不是最优选，最终我选择了Kodein：
Kodein官网：Painless Kotlin Dependency Injection
如果您完整的阅读了 《Kotlin 实战》这本书，你能在书末的附录中找到选择它的原因：
常见的Java依赖注入框架，比如 Spring/Guide/Dagger，都能很好地和Kotlin一起工作，如果你对原生的Kotin方案感兴趣，试试 Kodein, 它 提供了一套漂亮的DSL来配置依赖，而且它的实现也非常高效。
总结一下我个人的感受：
- 更Kotlin，整个框架都由Kotlin实现
- 实现方式依赖于 Kotlin 的 属性委托
- 很简洁，相比复杂的Dagger，上手更简单
- 超级漂亮的DSL && 说出去更唬人......
以 Http网络请求 相关为例，来看看依赖注入的代码：
很漂亮，对吧？
当然，对于依赖注入库，Dagger2是一个不会错的选择，但是如果仅仅只是个人项目，或者您已经厌倦了Dagger的配置，Kodein是一个不错的建议。
如果你对 Kodein 感兴趣，可以参考这篇文章，参考本文的项目代码，相信很快就能上手：
告别Dagger2，Android的Kotlin项目中使用Kodein进行依赖注入
6.函数式支持库：Arrow
对于Kotlin的各种优点，函数是第一等公民 是一个无法忽视的闪光点，它与其他简单的语法糖不同，它能够让你的代码更加优雅。
Arrow是提供了一些简单函数式编程的特性，利用Arrow提供的各种各样的函子，你的代码可以更加简洁并且优雅。
比如，配合RxJava，你可以实现这样的代码以避免各种分支的处理，比如随时都有可能的if..else()，并将这些额外的操作放在最终的操作符中（Terminal Operator）去处理：
interface ILoginLocalDataSource : ILocalDataSource {
fun fetchPrefsUser(): Flowable<Either<Errors, LoginEntity>>
}
class LoginLocalDataSource(
private val database: UserDatabase,
private val prefs: PrefsHelper
) : ILoginLocalDataSource {
override fun fetchPrefsUser(): Flowable<Either<Errors, LoginEntity>> =
Flowable.just(prefs)
.map {
when (it.username.isNotEmpty() && it.password.isNotEmpty()) {
true -> Either.right(LoginEntity(1, it.username, it.password))
false -> Either.left(Errors.EmptyResultsError)
}
}
}
现在我们将特殊的分支（数据错误）也同样像正常的流程一样交给了 Either<Errors, LoginEntity>统一返回,只有我们在真正需要使用它们时，它们才会被解析：
fun login() {
when (username.value.isNullOrEmpty() || password.value.isNullOrEmpty()) {
true -> applyState(isLoading = false, error = Errors.EmptyInputError.some())
false -> repo
.login(username.value!!, password.value!!) // 返回的是 Flowable<Either<Errors, LoginUser>>
.compose(globalHandleError())
.map { either -> // 用到的时候再处理它
either.fold({
SimpleViewState.error<LoginUser>(it)
}, {
SimpleViewState.result(it)
})
}
.startWith(SimpleViewState.loading())
.startWith(SimpleViewState.idle())
.onErrorReturn { it -> SimpleViewState.error(it) }
.bindLifecycle(this)
.subscribe { state ->
// ...
}
}
}
在函数式编程的领域，我只是一个满怀敬意且不断学习探索的新人，但是它的好处在于，即使没有完全理解 函数式编程 的思想，我也可以通过运用一些简单的函子写出更加Functional的代码。
7. 其他库
除上述库之外，我还引用了目前比较优秀的三方库：
基于OkHttp的 网络请求库Retrofit，不赘述。
Glide 和 Timber，已经被大众所熟知的 图片加载库 和 小巧精致的 日志打印库，不赘述。
DslAdapter 是低调的Yumenokanata开发的RecyclerViewAdapter，API的DSL设计加上对 DataBinding 的支持，我认为我还远远没达到写这个库的水平，因此在阅读完源码之后，我选择使用它。
8. 面向工具编程：模版插件
无论是MVP还是MVVM，对于一种开发模式而言，代码规范是很重要的，这意味着界面的实现总是需要用 同一种开发模式 进行规范化。
以MVP为例，标准的MVP，实现一个Activity的容器页面，我们需要定义Contract和其对应的View，Presenter,Model层的接口及其实现类，这就引发了另外一个问题，类似这种死板的开发模式的流程是否太繁琐（即简单的界面是否就没写这么多接口类的必要）？
我不这样认为，模版代码意味着开发的规范，这在团队开发中尤其重要，这样能够保证项目品质的稳定性和一致性，并且便于扩展，对于繁琐的生成重复性模版代码的情况，我认为MVP的代表性框架 MVPArms做出了非常值得学习的方案，即配置模版插件。
因此我也花了一点时间配置了一套属于自己MVVM开发模式的模版插件,对于每个界面的初始化，可以很方便一键生成：
就这样几步，Activity/Fragment，ViewModel,ViewDelegate以及依赖注入的KodeinModule类，都通过模版插件自动生成，我只需要关注UI的绘制和业务逻辑的编写即可。
无论是哪种开发模式，我认为模版插件都是一个能大大提高开发效率的工具，而且它的学习成本并不高，以我个人经验，即使没有相关经验，也只需要3～4小时，就能开发出一套属于自己的模版插件。
9.没有使用的一些尝试
9.1 组件化/模块化开发
从我个人经验来看，对于简单的项目并不需要进行复杂的模块化配置，因为开发者和维护者也只有我一个人。
9.2 Paging和WorkManager
这两个也是 Android Jetpack 的架构组件，但我并没有使用它们。
Paging是一个优秀的库，我曾举出它的优点（参考我的这篇文章），但是正如有朋友提到的，它的缺点很明显，那就是Paging本身是对RecyclerView.Adapter的继承，这意味着使用了Paging，就必须抛弃其他的Adapter库，或者自己造轮子，最终我选择了搁置。
WorkManager的原因就很简单了，项目中的功能暂时用不到它....
9.3 事件总线
说到事件总线，国内比较容易被提及的有 EventBus和RxBus，此外之前还看到某位大佬曾经分享过 LiveDataBus，印象很深刻，但是文章找不到了。
没有采用事件总线的原因是，我已经有RxJava了。
有同学说既然你有RxJava,为什么不使用RxBus呢，因为对于依赖来说并没有额外的负担？
对此我推荐这篇文章放弃RxBus，拥抱RxJava:为什么避免使用EventBus/RxBus。
引用文章中作者@W_BinaryTree对Jake Wharton对RxBus的评价翻译：
W_BinaryTree的相关文章写的都很有深度，我读完很受启发，冒昧推荐一下这位作者。
我认为RxJava本身就是对发布-订阅者模式最优秀的体现，我尽量保证我的工程中处处都由RxJava去串联就够了。
于我个人而言，我完全赞同没有引入RxJava的项目中使用EventBus,但是我确实不推荐RxBus，因为这意味着业务模块之间层级设计得不清晰，才会导致全部交由RxJava中全局的Subject的订阅情况的产生。
9.4 协程
协程的整体替换也在我下一步的学习计划中。
这需要一段时间的发展，因为我认为目前协程还没有发展足够的生态环境——我更期待更多类似 retrofit2-kotlin-coroutines-adapter这样优秀的拓展库，能够让我下决定把所有RxJava的代码给替换掉。
目前项目中，Room，网络请求以及Databinding依赖的LiveData，都是通过RxJava进行编织串在一起的，这些代码糅合很深，因此Kotlin1.3发布后（协程从实验性的功能正式Release），我只先尝试性的使用了类似 Result 这样的API在异常处理上代替Arrow的Either, 而协程则处于观察状态。
此外，我还没有开始深入学习协程，从新手角度来看，可能还需要一段时间学习深入并理解它，因此我期待更多关于协程的分析和相关分享的文章。
10.关于状态管理
状态的管理一直是争论不休的话题，甚至基于状态管理还引申了 MVI (Model-View-Intent)的开发模式,关于MVI中文相关的博客我推荐这篇文章：
从状态管理(State Manage)到MVI（Model-View-Intent）
这是一篇分析非常透彻的文章，阅读之如饮甘怡，其中最重要的优势便是对状态额统一管理，读后收获甚丰，并做出了一些实验性的尝试，篇幅所限，不再赘述，详情请参考 项目中ViewModel 的源码。
11.感受
MVVM模式和设计理念相关博客已经烂大街了，而且我也不认为我能够讲的比别人更透彻。
我写本文的原因是分享自己对于编程本质的理解，于我对编程的认知，探索过程中所带来的乐趣和成就感才是最重要的，追究本质可能是探索和创造。
我不喜欢拘泥于固定的开发模式，日复一日的重复操作让我想起了工厂的流水线，编程不同，每个人的代码风格的迥异背后代表着思想的碰撞，这是很多工作不能给予我的。
回顾本文，我希望本文的每一小节都能给您带来有益的东西，它可能是一种积极状态的传递，也可能某小节涉及的知识点让您感兴趣，或是其他——项目本身意义和这种收获 相比反而不大，因为每个人的思想不同，对于MVVM的理解也不同。
因此，我不敢妄言这个项目代表了MVVM的规范，但至少目前我对它的设计很满意（对您来说可能嘈点满满），它代表了我是这一阶段持续学习的结果，，很期待不久之后的我能够用怀疑的眼光去看待这个项目，那将意味着下一阶段的进步。
项目地址：https://github.com/qingmei2/MVVM-Rhine
--------------------------广告分割线------------------------------
系列文章
争取打造 Android Jetpack 讲解的最好的博客系列：
Android Jetpack 实战篇：
关于我
Hello，我是却把清梅嗅，如果您觉得文章对您有价值，欢迎 ❤️，也欢迎关注我的个人博客或者Github。
如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章——万一哪天我进步了呢？
