Android Clear架构最强官方指南Kotlin版

虎哥LoveOpenSource 发表于 10月以前 | 总阅读数：2950 次

Android Clear架构最强官方指南Kotlin版

在这篇文章中，我将介绍关于Android应用程序架构的一些内容。尽管自从早期更稳健的Android架构方法在移动开发中变得流行以来已经说了很多话，但改进和演进的空间总是存在的。

基于上述文章中的清晰架构示例，代码库中有明显的演进，特别是在当今应用程序在业务层面至关重要的情况下，更加需要扩展、模块化和组织围绕移动开发的团队（主要是由于其复杂性）。

因此，我们的目标是提出一种优雅的解决方案，以便在以下方面使我们的工作更加轻松：

解决问题。
可扩展性。
模块化。
可测试性。
独立于框架、UI和数据库。

这是一个架构图，如果您在Android应用程序中使用了Clear架构，它应该看起来很熟悉。

我们的场景

一个简单的电影Android应用程序。采用Kotlin编写，我们希望利用现代语言的特性，如不可变性、简洁性、函数式编程等。

以下是App项目的截图：

我们有3个主要的用例：

获取电影列表。
显示特定点击电影的详细信息。
播放电影。

通用架构

总体架构是基于基本的三层架构。好处在于，它非常容易理解，许多人都熟悉它。因此，我们将分解我们的解决方案以遵守依赖关系规则，其中依赖关系沿着一个方向流动：请参阅下面的圆形Clear架构图。

领域层(Domain Layer)：功能用例

用例是我们应用程序中要做的意图，换句话说，是我们的主要参与者之一。它的主要责任是协调我们的领域逻辑以及与UI和数据层的连接。

通过使用Kotlin的强大功能和将函数作为一等公民对待的方式（即将在稍后提到的内容），在我们的框架中有一个UseCase抽象，它充当我们应用程序中所有用例的契约。

abstract class UseCase<out Type, in Params> where Type : Any {

    abstract suspend fun run(params: Params): Either<Failure, Type>

    fun execute(onResult: (Either<Failure, Type>) -> Unit, params: Params) {
        val job = async(CommonPool) { run(params) }
        launch(UI) { onResult.invoke(job.await()) }
    }
}

这里发生了什么？

我们有一个抽象类，它接受两个泛型参数：

<out Type>：执行用例后的返回类型。
<in Params>：一个参数类，在我们需要用例的额外数据时，将在run()函数内使用。

execute()函数是魔法发生的地方：

• 我们传递了一个onResult 函数作为参数，该函数接受Either<Failure, Type>类型的参数，并返回Unit（在错误处理部分，我将扩展对Either<L, R>的解释，请耐心等待）。好处是，UseCase的调用者通过传递这个不可变函数（onResult），实际上确定了所需的行为，从而避免了任何内部暴露或副作用（这是函数式编程的好处之一，稍后会有更多）。
• 同样，通过使用Kotlin协程，我们在不同的线程中调用传递的onResult函数，因此从这一点开始，我们可以以同步的方式编写代码。结果将发布在Android主UI线程上。

当扩展UseCase<out Type, in Params>抽象时，我们必须覆盖abstract suspend fun run(params: Params)函数。例如，这就是我们的GetMovies用例的样子：

class GetMovies 
@Inject constructor(private val moviesRepository: MoviesRepository) : 
    UseCase<List<Movie>, None>() {

    override suspend fun run(params: None) = moviesRepository.movies()
}

在这个例子中，我们将电影的获取委托给一个Repository。

UI层(UI Layer)：从MVP到MVVM

Model-View-ViewModel（MVVM）模式在用户界面和领域逻辑之间提供了清晰的责任分离。

它有3个主要组件：模型（model）、视图（view）和视图模型（view model）。它们之间存在关系，尽管每个组件都有不同且独立的角色：

在最高级别上，视图“知道”视图模型，而视图模型“知道”模型，但模型不知道视图模型，视图模型也不知道视图。视图模型将视图与模型类隔离开来，并允许模型独立于视图进行演进。

在我们的示例中，MVVM的实现是通过使用架构组件完成的，它的主要优势是在屏幕旋转时处理配置更改，这对于Android开发人员来说是一个常见的头痛问题（我想你明白我在说什么）。

免责声明：这并不意味着我们不再需要关心生命周期，但处理起来要容易得多。

关于前面示例中的MVP（Model View Presenter）的一点注释：我发现很难避免由于活动和片段被重新创建而导致的内存泄漏，所以我使用了一个简单的解决方案：保留片段（retain fragments）。

然而，我无论如何都会遇到这种情况。这就是为什么我决定去尝试MVVM的原因。

让我们看看MVVM与之前示例相比有何变化以及它是如何工作的：

片段充当视图，在这里发生与屏幕上数据显示相关的所有逻辑。
片段也知道视图模型，它们实际上是订阅视图模型的。
视图模型包含LiveData对象和对UseCases的引用。
UseCases更新LiveData，LiveData对这些更改做出反应并通知视图模型。
视图模型与订阅的片段进行通信，以更新UI。

为了看到所有这些部分如何协同工作，让我们看一些代码。包含LiveData并通过调用UseCase.execute()函数进行更新的ViewModel：

class MoviesViewModel
@Inject constructor(private val getMovies: GetMovies) : BaseViewModel() {

    var movies: MutableLiveData<List<MovieView>> = MutableLiveData()

    fun loadMovies() = 
        getMovies.execute({ it.either(::handleFailure, ::handleMovieList) }, None())

    private fun handleMovieList(movies: List<Movie>) {
        this.movies.value = movies.map { MovieView(it.id, it.poster) }
    }
}

片段在onCreate()中订阅上述的ViewModel。

我使用了一些扩展函数的技巧来减少一些冗长和样板代码。

class MoviesFragment : BaseFragment() {

    @Inject lateinit var navigator: Navigator
    @Inject lateinit var moviesAdapter: MoviesAdapter

    private lateinit var moviesViewModel: MoviesViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        appComponent.inject(this)

        //subscribtion to LiveData in MoviesViewModel
        moviesViewModel = viewModel(viewModelFactory) {
            observe(movies, ::renderMoviesList)
            failure(failure, ::handleFailure)
        }
    }
    ...
}

数据层(Data Layer)：拯救的存储库模式

与之前的示例相比，这里有什么新东西吗？因为我在使用存储库模式时取得了非常好的结果。

需要记住的是：在其核心，存储库模式是一个简单的接口。它存在于我们的领域和数据之间的一层，这样我们的逻辑就不需要关注不同数据源的实现：网络、数据库或内存。

在下面的代码块中，我们可以看到我们的MoviesRepository契约：

interface MoviesRepository {
    fun movies(): Either<Failure, List<Movie>>
    fun movieDetails(movieId: Int): Either<Failure, MovieDetails>
}

在我们的示例中，我们通常将Repository作为UseCase实现的协作者进行注入。

功能性错误处理

整体上，错误/异常处理应该在设计层面而不是实现层面上加以处理，而在我看来，作为开发者我们所犯的最大错误之一就是这个（吸取了教训）。这就是为什么有一个专门的框架来处理这个目的非常重要。

传统的错误处理会发生什么？

观察异常（try/catch块）并基于此做出改变控制流的决策是一种不好的实践：它会导致不可预测性，影响我们的弹性，并且调试变得困难，尤其是在并发环境中。再加上回到C风格的错误处理，使用需要按约定检查的错误代码可能会成为一个噩梦。

说到这里，我们已经看到我们在UseCase抽象中使用Either<L, R>作为返回类型：

abstract suspend fun run(params: Params): Either<Failure, Type>

因此，让我介绍一下Either

Either<L, R>被称为不相交函数，这意味着这个结构被设计为只容纳Left<T>或Right<T>值，而不是两者兼有。它是一种函数式编程的单子类型，尚未存在于Kotlin标准库中。

这里有一个简单的实现，非常符合我的需求，并且易于理解和使用：

/**
 * Represents a value of one of two possible types (a disjoint union).
 * Instances of [Either] are either an instance of [Left] or [Right].
 * FP Convention dictates that: 
 *      [Left] is used for "failure".
 *      [Right] is used for "success".
 *
 * @see Left
 * @see Right
 */
sealed class Either<out L, out R> {
    /** 
    * Represents the left side of [Either] class 
    * which by convention is a "Failure". 
    */
    data class Left<out L>(val a: L) : Either<L, Nothing>()

    /** 
    * Represents the right side of [Either] class 
    * which by convention is a "Success". 
    */
    data class Right<out R>(val b: R) : Either<Nothing, R>()

    val isRight get() = this is Right<R>

    val isLeft get() = this is Left<L>

    fun either(fnL: (L) -> Any, fnR: (R) -> Any): Any =
            when (this) {
                is Either.Left -> fnL(a)
                is Either.Right -> fnR(b)
            }

    fun <T> flatMap(fn: (R) -> Either<L, T>): Either<L, T> {...}
    fun <T> map(fn: (R) -> (T)): Either<L, T> {...}
}

让我也引用一下Daniel Westheide（Scala专家）在他的一篇精彩博客文章中的话：

Either<L, R>类型的语义中没有规定其中一个子类型分别表示错误或成功。事实上，Either是一种通用类型，用于处理结果可能为两种可能类型之一的情况。

然而，错误处理是它的一种常见用例，并且根据惯例，当以这种方式使用时，Left<T>表示错误情况，而Right<T>包含成功值。

请不要忘记阅读他的整个Scala系列文章，以拓宽你的视野（从其他语言中获取灵感总是+1）：

使用Try进行错误处理。

http://danielwestheide.com/blog/2012/12/26/the-neophytes-guide-to-scala-part-6-error-handling-with-try.html
Either类型。

http://danielwestheide.com/blog/2013/01/02/the-neophytes-guide-to-scala-part-7-the-either-type.html

那么我们的代码示例呢？

在GetMovies UseCase中，在实现层面上，我们总是返回一个Either<Failure, List<Movie>>，从数据层开始一直到我们的MoviesViewModel，它会更新either失败LiveData<Failure>（如果失败，则为Left<T>）或电影LiveData<List<MovieView>>（成功，Right<T>）：

class MoviesViewModel
@Inject constructor(private val getMovies: GetMovies) {

    var movies: MutableLiveData<List<MovieView>> = MutableLiveData()
    var failure: MutableLiveData<Failure> = MutableLiveData()

    fun loadMovies() = 
        getMovies.execute({ it.either(::handleFailure, ::handleMovieList) }, None())

    private fun handleMovieList(movies: List<Movie>) {
        this.movies.value = movies.map { MovieView(it.id, it.poster) }
    }

    private fun handleFailure(failure: Failure) {
        this.failure.value = failure
    }
}

在视图层级的MoviesFragment中，我们订阅来自视图模型的更新：

moviesViewModel = viewModel(viewModelFactory) {
    observe(movies, ::renderMoviesList)
    failure(failure, ::handleFailure)
}

这是用于处理Failure的handleFailure()函数的样子：

private fun handleFailure(failure: Failure?) {
    when (failure) {
        is NetworkConnection -> renderFailure(R.string.failure_network_connection)
        is ServerError -> renderFailure(R.string.failure_server_error)
        is ListNotAvailable -> renderFailure(R.string.failure_movies_list_unavailable)
    }
}

顺便说一下，Failure是一个密封类，它提供了全局默认的Failures：

/**
 * 用于处理错误/失败/异常的基类。
 * 每个特定功能的失败应该扩展[FeatureFailure]类。
 */
sealed class Failure {
    class NetworkConnection: Failure()
    class ServerError: Failure()

    /** * 扩展此类以获取特定功能的失败。*/
    abstract class FeatureFailure: Failure()
}

我希望现在对Either<L, R>的用法更清晰了，你理解了这种应用技术的原因和好处。