35 | 用Kotlin写一个GitHub Trending App

你好，我是朱涛。

这节课，我们一起来用Kotlin和Jetpack写一个简单的Android应用。为了便于理解，这个应用的功能会尽量简单，即使你对Android不是特别熟悉，跟着课程的引导，你也能轻松完成。

准备工作

在之前的课程中，我们的实战项目都是基于JVM的，并没有涉及过Android相关的配置。因此，如果你的电脑没有Android开发的环境的话，那么可能需要做一些额外的配置。当然，在你已有Java环境的前提下，想要配置Android开发环境并不麻烦，你可以去搜索一些相关的Android开发环境配置的教程。

那么，要进行Android开发，我们可以使用IntelliJ，也可以使用Android Studio，后者针对Android开发做了很多定制化，也是免费的，这里我也建议你去下载Android Studio。

当配置好所有的环境以后，我们就可以像创建Kotlin工程一样，来创建一个新的Android工程了。

然后，当你创建好工程以后，就可以尝试运行代码了，这时候你大概率会看到一个Hello World的初始界面。

接下来，我们就正式进入开发吧。

MVVM架构

Android应用的架构，在过去的这些年里一直都在变化。最开始的Android其实没有什么明确的架构，大家习惯于把所有代码都往Activity里放，直到后来才开始有了MVC、MVP以及MVVM。

那么，站在现在这个时间节点上，当前Android中比较主流、比较受Google推崇的，是MVVM架构。这节课，我们就以 MVVM架构为基础，并且也尝试结合Clean架构来进行一些实践。

关于MVVM架构，它其实就是代表了Model — View — ViewModel，如果将其对应到Android当中来的话，它们之间大概会是这样的关系：

MVVM其实是一种广泛存在的架构模式，在Android当中也有类似的实现。ViewModel会连接View和Model，View和Model之间是隔离开的。而View和ViewModel之间，也往往会存在数据绑定，这里的数据绑定可以是一个组件（如Android的DataBinding），也可以是由代码来完成绑定。

而相比MVVM架构，Clean架构则是一种更加抽象的思维模式了。它将整个架构大致分为三层，由外到内分别是：表现层、领域层、数据层。它们之间的依赖关系也是由外到内的。

不过 Clean架构只是一种思想，当我们尝试在Android中落地应用的时候，其实并不一定会完全按照这里的架构图来设计，目前比较常见的架构是下面这样的：

可以看到，上面这个架构，融入了MVVM与Clean两个架构的特点，让我们从下往上看：

实体层，这里其实就是我们平时定义的一些Bean的实体类，用Kotlin的数据类即可。
数据层，这里一般会有两个概念，分别是DataSource与Repository，前者代表数据源，后者代表数据仓库。数据源一般会区分本地数据源和远程数据源，而数据仓库则会统筹它们两者。
领域层，这里一般会是一些相对具体一些的业务逻辑。
表现层，这里则是接近UI展示的上层逻辑了。

好，架构分析完了，接下来我们看看代码该怎么写，我们还是按照架构的分层，从下往上来实现。

实体层

首先，我们要定义一个密封类，来统一不同情况下的数据形式。

sealed class ResultX<out R: Any> {
    
        data class Success<out T: Any>(val data: T) : ResultX<T>()
        data class Error(val exception: Exception) : ResultX<Nothing>()
        object Loading : ResultX<Nothing>()
    
        override fun toString(): String {
            return when (this) {
                is Success<*> -> "Success[data=$data]"
                is Error -> "Error[exception=$exception]"
                Loading -> "Loading"
            }
        }
    }

这里，我们利用密封类和泛型，将数据的成功、失败、加载中都统一了起来。类似这样的做法，我们在课程的第2讲里也已经提到过了。

然后，由于我们是要实现一个GitHub Trending的应用，所以这里我们只需要找一个开源的API，通过分析它的JSON结构，然后定义出具体的Data Class就行了。这一步，我们其实在第12讲当中就已经完成了。

data class RepoList(
        var count: Int?,
        var items: List<Repo>?,
        var msg: String?
    )
    
    data class Repo(
        var added_stars: String?,
        var avatars: List<String>?,
        var desc: String?,
        var forks: String?,
        var lang: String?,
        var repo: String?,
        var repo_link: String?,
        var stars: String?
    )

不过，在之前的课程当中，我提到过以这种方式定义的数据类，其实还存在2个问题。

问题1：不符合“不变性思维”，成员属性全部都是var定义的。
问题2：不符合“空安全思维”，所有的类型都是可为空的。

那么针对这两个问题，我们像下面这样做，其实很容易就能搞定：

data class RepoList(
        val count: Int = 0,
        val items: List<Repo> = listOf(),
        val msg: String = "数据为空"
    )
    
    data class Repo(
        val added_stars: String = "",
        val avatars: List<String> = listOf(),
        val desc: String = "",
        val forks: String = "",
        val lang: String = "",
        val repo: String = "",
        val repo_link: String = "",
        val stars: String = ""
    )

在这段代码中，我们是把var都替换成了val，把所有的可空类型都改成了不可空类型，同时也为属性都提供了默认值。

当然，仅仅只是改变底层的实体类的定义还远远不够，具体遇到的问题，我们会在后面分析。下面我们接着来看数据层。

数据层

在数据层当中，最关键的就是RepoDataSource和Repository。那么首先，我们就要定义它们对应的接口。你可以参考这里的实现：

interface RepoDataSource {
        suspend fun getRepos(): ResultX<RepoList>
    }
    
    interface IRepository {
        suspend fun getRepoList(): ResultX<RepoList>
    }

接下来，就是它们对应的实现类了，我们先来看看数据源怎么处理。

由于我们需要请求网络，所以这里我们自然就会想到OkHttp和Retrofit了。虽然我们也可以使用自己写的KtHttp，但它毕竟只是用于学习和研究目的而编写的，并不适合真的拿来用。

object RetrofitClient {
    
        private const val TAG = "OkHttp"
        private const val BASE_URL = "https://baseUrl.com/"
        private const val TIME_OUT = 10
    
        val moshi: Moshi by lazy {
            Moshi.Builder()
                .add(KotlinJsonAdapterFactory())
                .build()
        }
    
        val service by lazy { getService(RepoService::class.java, BASE_URL) }
    
        private val client: OkHttpClient by lazy {
            val builder = OkHttpClient.Builder()
            builder.connectTimeout(TIME_OUT.toLong(), TimeUnit.SECONDS)
            builder.build()
        }
    
        private fun <S> getService(
            serviceClass: Class<S>,
            baseUrl: String,
            client: OkHttpClient = this.client
        ): S {
            return Retrofit.Builder()
                .client(client)
                .addConverterFactory(MoshiConverterFactory.create(moshi))
                .baseUrl(baseUrl)
                .build().create(serviceClass)
        }
    }
    
    interface RepoService {
        @GET("repo")
        suspend fun repos(@Query("lang") lang: String = "Kotlin", @Query("since") since: String = "weekly"): RepoList
    }

其实，当我们自己手写了KtHttp的源码以后，Retrofit用起来就会非常顺手。这里我们是定义了一个单例RetrofitClient用来请求API，还有RepoService来代表具体的请求参数规则。

那么有了Retrofit以后，我们要处理数据源也就很容易了。

object RemoteRepoDataSource : RepoDataSource {
        const val TAG = "RemoteRepoDataSource"
        override suspend fun getRepos(): ResultX<RepoList> =
            withContext(Dispatchers.IO) {
                try {
                    Success(RetrofitClient.service.repos())
                } catch (e: Exception) {
                    Log.e(TAG, e.message, e)
                    Error(e)
                }
            }
    }

在这里，我们定义了一个RemoteRepoDataSource，它实现了RepoDataSource这个数据源的接口。而它具体的实现方法，是使用withContext{} 将API请求分发到了IO线程池，然后根据实际的运行结果，将数据封装成对应的ResultX的子类型。

接着就是数据仓库了，它一般是用于统筹缓存数据、远程数据的，这里为了不引入过多的复杂度，我们简单来实现：

class MainRepository(
        private val dataSource: RepoDataSource = RemoteRepoDataSource,
        private val localDataSource: RepoDataSource? = null
    ) : IRepository {
        override suspend fun getRepoList(): ResultX<RepoList> {
            // 暂不处理缓存逻辑
            return dataSource.getRepos()
        }
    }

你可以看到，它其实就是数据源的一层封装而已。

好，至此，我们的数据层就已经完成了。

领域层

所谓领域层，其实就像是业务逻辑的一个小单元，这里的小单元，我们可以将其称为UseCase。

class GetRepoListUseCase(private val repository: IRepository = MainRepository()) {
        suspend operator fun invoke(): ResultX<RepoList> {
            return repository.getRepoList()
        }
    }

在当前的案例中，我们只有一个业务场景，也就是获取GitHub仓库的列表，所以这个UseCase的逻辑也很简单。不过你要知道，在实际的工作场景中，UseCase是可以承载复杂的业务逻辑的。

接下来，我们往上看一下表现层。

表现层

到了表现层这里，我们其实就已经非常接近UI了，具体来说，这里主要涉及到ViewModel还有Activity、Fragment。我们先来看看ViewModel。

class MainViewModel(
        val getRepoListUseCase: GetRepoListUseCase = GetRepoListUseCase()
    ) : ViewModel() {
        val repos: LiveData<RepoList>
            get() = _repos
        private val _repos = MutableLiveData<RepoList>()
    
        fun loadRepos() {
            viewModelScope.launch {
                val result = getRepoListUseCase()
                when (result) {
                    is ResultX.Success -> {
                        _repos.value = result.data
                    }
                    is ResultX.Error -> {
                        _repos.value = RepoList()
                    }
                    ResultX.Loading -> {
                        // 展示Loading
                    }
                }
            }
        }
    }

可以看到，我们在ViewModel当中定义了一组LiveData，并且针对它的读写做了限制，这一点，我们在讲不变性思维的时候提到过。

在loadRepos()这个方法中，我们用到了viewModelScope.launch {} 来启动协程。经过上节课的学习，我们知道以这种方式启动的协程是不会发生泄漏的，其中的协程任务会随着Activity的销毁而取消。

OK，最后，就是Activity当中的逻辑了。

class MainActivity : AppCompatActivity() {
        // 1
        private val viewModel: MainViewModel by viewModels()
        // 2
        private lateinit var binding: ActivityMainBinding
    
        private lateinit var adapter: RepoAdapter
        private val layoutManager = LinearLayoutManager(this, LinearLayoutManager.VERTICAL, false)
    
        override fun onCreate(savedInstanceState: Bundle?) {
            super.onCreate(savedInstanceState)
            binding = ActivityMainBinding.inflate(layoutInflater)
            setContentView(binding.root)
    
            viewModel.loadRepos()
            observeData()
        }
    
        private fun observeData() {
            // 3
            viewModel.repos.observe(this) {
                display(it)
            }
        }
    
        private fun display(repoList: RepoList) {
            adapter = RepoAdapter(repoList)
            binding.recycler.layoutManager = layoutManager
            binding.recycler.adapter = adapter
        }
    }

上面Activity的逻辑也很简单，其中有几个注释，我们一起来看看：

注释1，这里我们使用了委托的语法，将ViewModel的创建交给了"by viewModels()"。它其实是Activity的一个扩展函数，是由KTX实现的。
注释2，ActivityMainBinding，这里我们使用了Jetpack当中的ViewBinding，这样我们就不用写烦人的findViewById()了。
注释3，viewModel.repos.observe{}，这里我们完成了ViewModel当中LiveData的数据监听，当我们的网络请求有结果以后，它就会立刻被回调。

另外，以上代码中还涉及到了一些RecyclerView相关的适配器逻辑，也非常简单：

class RepoAdapter(private val repoList: RepoList): RecyclerView.Adapter<RepoHolder>() {
        override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): RepoHolder {
            return RepoHolder(LayoutInflater.from(parent.context).inflate(R.layout.item_repo, parent, false))
        }
    
        override fun onBindViewHolder(holder: RepoHolder, position: Int) {
            holder.text.text = repoList.items.getOrNull(position)?.repo
        }
    
        override fun getItemCount(): Int = repoList.count
    }
    
    class RepoHolder(itemView: View): RecyclerView.ViewHolder(itemView) {
        val text : TextView = itemView.findViewById(R.id.text)
    }

也就是，为了让RecyclerView正确展示数据，我们需要实现一些方法，以上这些都是一些模板代码。

最后，在运行代码之前，我们还需要给App增加一个网络权限。

<uses-permission android:name="android.permission.INTERNET" />

这个时候，如果你在模拟器或者真机上运行的话，就会看到类似这样的一个效果：

那么，到这里，我们的代码是不是就写完了呢？其实并没有。

空安全

因为，我们还有一个问题没有解决：**如果服务端返回的JSON字段是null的话，我们的程序仍然会出错。**具体来说，我们可以用这个单元测试来模拟。

@Test
    fun test() {
        //                  强行返回null
        //                      ↓
        val json = """{"repo": null, "repo_link": "https://github.com/JetBrains/kotlin", "desc": "The Kotlin Programming Language.", "lang": "Kotlin", "stars": "40,907", "forks": "5,067", "added_stars": "98 stars this week", "avatars": ["https://avatars.githubusercontent.com/u/292714?s=40&v=4", "https://avatars.githubusercontent.com/u/1127631?s=40&v=4", "https://avatars.githubusercontent.com/u/908958?s=40&v=4", "https://avatars.githubusercontent.com/u/3007027?s=40&v=4", "https://avatars.githubusercontent.com/u/888318?s=40&v=4"]}"""
        val repo = RetrofitClient.moshi.adapter(Repo::class.java).fromJson(json)
        println(repo?.repo)
    }
    
    /*
    报错：
    Non-null value 'repo' was null at $.repo at com.squareup.moshi.internal.Util
    */

其实，当我们利用空安全思维，将Repo中所有的成员都定义成“非空类型”以后，当API不返回某个字段的时候，程序是可以自动填充默认值的。但是，当API强行在接口当中返回null的时候，我们的程序还是会崩溃。

为了解决这个问题，我们需要为JSON解析框架Moshi，配置一个额外的规则：

object NullStringAdapter {
        @FromJson
        fun fromJson(reader: JsonReader): String {
            if (reader.peek() != JsonReader.Token.NULL) {
                return reader.nextString()
            }
            reader.nextNull<Unit>()
            return ""
        }
    
        @ToJson
        fun toJson(writer: JsonWriter, value: String?) {
            writer.value(value)
        }
    }

这个Adapter，其实就是在服务端返回null的时候，我们做一层兼容，将其替换成默认值。它的用法也很简单：

object RetrofitClient {
    
        // 省略
    
        val moshi: Moshi by lazy {
            Moshi.Builder()
                .add(NullStringAdapter) // 变化在这里
                .add(KotlinJsonAdapterFactory())
                .build()
        }
    
    }

这样，当我们把这个Adapter配置到Moshi当中以后，单元测试就可以正常通过了。

小结

好，这节课的内容到这里就差不多结束了。让我们来做一个简单的总结。

MVVM，是一种常见的架构模式，在Android当中，一般会借助ViewModel、LiveData之类的组件来实现。在实战当中，我们还可以将其跟Clean架构的思想相结合，将整体应用的架构分为四层：实体层、数据层、领域层、表现层。
实体层，在大部分架构设计当中，实体层会和数据层进行融合，不过在这节课当中，我们将其单独抽了出来，放在了整个架构的最底层，通过密封类、数据类来实现的。
数据层，这里有两个概念，分别是“数据源”和“数据仓库”。数据源一般会分为缓存数据与远程数据，数据仓库则负责统筹多种数据源。
领域层，这里会涉及到业务逻辑的最小单元，我们一般将其称为UseCase。
表现层，这里会涉及到数据与UI交互的逻辑。ViewModel当中会封装UseCase，并且持有数据和View进行交互。
最后，我们还根据实际情况，对JSON解析库Moshi，做了额外配置，让它可以对服务端返回null的时候，仍然保持兼容，不会出现空指针异常。

那么，如果你本身对Android、MVVM、Clean架构都不是很熟悉，也许在学习这节课的过程中会有点不太适应。这时候，你可以去GitHub下载本课程对应的Demo，来实际运行和调试，以加深印象，链接在这里。

思考题

这节课，我们融合MVVM和Clean完成了一种混合架构，请问这种架构有什么样的优点和缺点呢？

大师兄

35 | 用Kotlin写一个GitHub Trending App

准备工作

MVVM架构

实体层

数据层

领域层

表现层

空安全

小结

思考题