Android架构师丨小熊 

一、前言

本文不讨论协程、Retrofit、MVVM的原理以及基本使用，需要的可以在其他博主那儿找到很好的文章。

本文没有选择DataBinding的双向绑定方式，因为个人觉得DataBinding污染了xml,并且在定位错误问题上比较麻烦。

也没有采用Flux、Redux、ReKotlin这样的框架，因为目前还不太熟。

可以把本文看作是一篇实现过程纪要，欢迎交流分享，提出建议。

二、过程与思考

基本依赖

生命周期组件相关

implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0-beta01'

implementation "androidx.lifecycle:lifecycle-viewmodel-ktx:2.2.0-beta01"

协程

implementation "org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.0"

网络

implementation 'com.squareup.retrofit2:retrofit:2.6.0'

implementation 'com.squareup.retrofit2:converter-gson:2.6.0'

implementation 'com.squareup.okhttp3:logging-interceptor:3.11.0'

备注:Retrofit 在2.6以后对协程有了更友好的实现方式，所以在版本选择上是有要求的。

动手之前

因为接入协程的缘故，像以前以回调onResponse，onFailure的回调方式是不太符合协程设计的。Kotlin协程对于Retrofit的onFailure处理是直接以Trowable进行抛出的，所以在一开始就要构建好对执行Retrofit的挂机代码块的try..catch设计。

基本的网络访问封装

基本操作还是要有的

定义基本的Api返回类

定义一个Api以便于测试

封装BaseViewModel

网络请求必须在子线程中进行，这是Android开发常理,使用协程进行网络请求在代码上可以让异步代码看起来是同步执行，这很大得提高了代码得可读性，不过理解挂起的确需要时间。BaseViewModel中最终得事情就是要搭建关于协程对于Retrofit网络请求代码块得try..catch。

重要得try..catch

将捕获到得异常进行下放保证执行过程中得情况都是可控得。

main线程

IO线程

不要忘记onCleared

错误处理

错误处理分为1.请求异常(及trycatch中的异常),2.服务器返回的响应体中定义的异常,这些异常只要是带有网络访问性质的APP上都是常见的，所以对NetWork的异常处理我定义了一个NetWorkError.kt文件，里面的函数为顶级函数，这样方便在项目的其他位置直接访问而不需要通过类名或者实例化操作就可以访问。

try catch异常处理

像一般触发的链接超时、解析异常都可以做出处理，如果不try catch，那么APP有可能会崩溃，或者长时间没有任何回执，体验很差。

服务器定义的响应异常

一般服务器对于请求都存在响应码，客户端根据响应码去做响应的处理，不同的错误码会有不同的日志回馈或者提示，但这都是建立在请求成功上的。这里一般无非为成功和失败。

Http请求响应封装

错误枚举

错误处理

对HttpResponse进行处理

这里是直接对HttpRespoonse进行处理，还需要对当前的响应内容有一个转换

转换服务器响应

暂时定义为一个扩展函数,方便结合this使用。基本封装完成以后，开始搞一个测试类来进行测试。

测试

client

model

viewModel

最后在LoginAct对loginState实现监听

三、总结

这是目前自己能够想到的一些方式，个人觉得Kotlin的确带来很大的改观，特别是在可读性和维护性上。虽然在架构和整体设计这件事情上，本来就没有标准的方式，这些问题都是相对的。

对于DataBinding的双向绑定方式期待后期Google能有更好的实现方案，或者也可以考虑单向数据流的实现框架。

今年年初我花一个月的时间收录整理了一套知识体系，如果有想法深入的系统化的去学习的，可以私信我【安卓】，我会把我收录整理的资料都送给大家，帮助大家更快的进阶。

重要的事说三遍，转发+转发+转发，让更多需要的朋友们都可以看到并且领到！