在前面几节课当中，我们一起学习了 Kotlin 的委托、泛型、注解、反射这几个高级特性。那么今天这节课，我们将会运用这些特性，来写一个 Kotlin 版本的 HTTP 网络请求框架 。由于它是纯 Kotlin 开发的，我们就把它叫做是 KtHttp 吧。
事实上，在 Java 和 Kotlin 领域，有许多出色的网络请求框架，比如 OkHttp 、Retrofit 、Fuel 。而我们今天要实现的 KtHttp，它的灵感来自于 Retrofit。之所以选择 Retrofit 作为借鉴的对象，是因为它的底层使用了大量的泛型、注解和反射的技术。如果你能跟着我一起用泛型、注解、反射来实现一个简单的网络请求框架，相信你对这几个知识点的认识也会更加透彻。
在这节课当中，我会带你从 0 开始实现这个网络请求框架。和往常一样，为了方便你理解，我们的代码会分为两个版本：
1.0 版本，我们会用 Java 思维，以最简单直白的方式来实现 KtHttp 的基础功能——同步式的 GET 网络请求；
2.0 版本，我们会用函数式思维来重构代码。
另外，在正式开始学习之前，我也建议你去 clone 我 GitHub 上面的 KtHttp 工程：https://github.com/chaxiu/KtHttp.git，然后用 IntelliJ 打开，并切换到 start 分支跟着课程一步步敲代码。
1.0：Java 思维 在正式开始之前，我们还是先来看看程序的运行效果：
在上面的动图中，我们通过 KtHttp 请求了一个服务器的 API，然后在控制台输出了结果。这其实是我们在开发工作当中十分常见的需求。通过这个 KtHttp，我们就可以在程序当中访问任何服务器的 API，比如GitHub 的 API 。
那么，为了描述服务器返回的内容，我们定义了两个数据类：
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? )
除了数据类以外，我们还要定义一个用于网络请求的接口：
interface ApiService { @GET("/repo" ) fun repos ( @Field("lang" ) lang: String , @Field("since" ) since: String ) }
在这个接口当中，有两个注解，我们一个个分析：
GET 注解 ，代表了这个网络请求应该是 GET 请求，这是HTTP请求的一种方式。GET 注解当中的“/repo”，代表了 API 的 path，它是和 baseURL 拼接的；Field 注解 ，代表了 GET 请求的参数。Field 注解当中的值也会和 URL 拼接在一起。
也许你会好奇，GET、Field 这两个注解是从哪里来的呢？ 这其实也是需要我们自己定义的。根据上节课学过的内容，我们很容易就能写出下面的代码：
@Target(AnnotationTarget.FUNCTION) @Retention(AnnotationRetention.RUNTIME) annotation class GET (val value: String)@Target(AnnotationTarget.VALUE_PARAMETER) @Retention(AnnotationRetention.RUNTIME) annotation class Field (val value: String)
从这段代码里我们可以看出，GET 注解只能用于修饰函数，Field 注解只能用于修饰参数。另外，这两个注解的 Retention 都是 AnnotationRetention.RUNTIME，这意味着这两个注解都是运行时可访问的。而这，也正好是我们后面要使用的反射的前提。
最后，我们再来看看 KtHttp 是如何使用的：
fun main () val api: ApiService = KtHttpV1.create(ApiService::class .java) val data : RepoList = api.repos(lang = "Kotlin" , since = "weekly" ) println(data ) }
上面的代码有两个注释，我们分别来看。
注释①：我们调用 KtHttpV1.create() 方法，传入了 ApiService::class.java，参数的类型是Class，返回值类型是 ApiService。这就相当于创建了 ApiService 这个接口的实现类的对象。
注释②：我们调用 api.repos() 这个方法，传入了 Kotlin、weekly 这两个参数，代表我们想查询最近一周最热门的 Kotlin 开源项目。
看到这里，你也许会好奇，KtHttpV1.create() 是如何创建 ApiService 的实例的呢？要知道 ApiService 可是一个接口，我们要创建它的对象，必须要先定义一个类实现它的接口方法，然后再用这个类来创建对象才行。
不过在这里，我们不会使用这种传统的方式，而是会用动态代理，也就是 JDK 的Proxy 。Proxy 的底层，其实也用到了反射。
不过，由于这个案例涉及到的知识点都很抽象，在正式开始编写逻辑代码之前，我们先来看看下面这个动图，对整体的程序有一个粗略的认识。
现在，相信你大概就知道这个程序是如何实现的了。下面，我再带你来看看具体的代码是怎么写的。
这里我要先说明一点，为了不偏离这次实战课的主题，我们不会去深究 Proxy 的底层原理。在这里，你只需要知道，我们通过 Proxy，就可以动态地创建 ApiService 接口的实例化对象 。具体的做法如下：
fun <T> create (service: Class <T >) return Proxy.newProxyInstance( service.classLoader, arrayOf<Class<*>>(service), object : InvocationHandler{ override fun invoke (proxy: Any ?, method: Method ?, args: Array <out Any >?) } } ) as T }
在上面的代码当中，我们在 create() 方法当中，直接返回了 Proxy.newProxyInstance() 这个方法的返回值，最后再将其转换成了 T 类型。
那么，newProxyInstance() 这个方法又是如何定义的呢？
public static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces, InvocationHandler h){ ... } public interface InvocationHandler { public Object invoke(Object proxy, Method method, Object[] args) throws Throwable; }
从上面的代码当中，我们可以看到，最后一个参数，InvocationHandler 其实是符合 SAM 转换要求的，所以我们的 create() 方法可以进一步简化成这样：
fun <T> create (service: Class <T >) return Proxy.newProxyInstance( service.classLoader, arrayOf<Class<*>>(service) ) { proxy, method, args -> } as T }
那么到这里，我们程序的基本框架也就搭建好了。
细心的你一定发现了，我们程序的主要逻辑还没实现 ，所以接下来，我们就一起看看上面那个“待完成”的 InvocationHandler，这个 Lambda 表达式应该怎么写。这个换句话说，也就是 Proxy.newProxyInstance()，会帮我们创建 ApiService 的实例对象，而 ApiService 当中的接口方法的具体逻辑，我们需要在 Lambda 表达式当中实现。
好了，让我们回过头来看看 ApiService 当中的代码细节：
interface ApiService { @GET("/repo" ) fun repos ( @Field("lang" ) lang: String , @Field("since" ) since: String ) }
从代码注释中可以看出来，其实我们真正需要实现的逻辑，就是想办法把注解当中的值 /repo、lang、since 取出来，然后拼接到 URL 当中去。那么，我们如何才能得到注解当中的值呢？
答案自然就是我们在上节课学过的：反射 。
object KtHttpV1 { private var okHttpClient: OkHttpClient = OkHttpClient() private var gson: Gson = Gson() var baseUrl = "https://baseurl.com" fun <T> create (service: Class <T >) return Proxy.newProxyInstance( service.classLoader, arrayOf<Class<*>>(service) ) { proxy, method, args -> val annotations = method.annotations for (annotation in annotations) { if (annotation is GET) { val url = baseUrl + annotation .value return @newProxyInstance invoke(url, method, args!!) } } return @newProxyInstance null } as T } private fun invoke (url: String , method: Method , args: Array <Any >) } }
在上面的代码中，一共有 6 个注释，我们一个个看。
注释①：method 的类型是反射后的 Method，在我们这个例子当中，它最终会代表被调用的方法，也就是 ApiService 接口里面的 repos() 这个方法。
注释②：args 的类型是对象的数组，在我们的例子当中，它最终会代表方法的参数的值，也就是“api.repos(“Kotlin”, “weekly”)”当中的”Kotlin”和”weekly”。
注释③：method.annotations，代表了我们会取出 repos() 这个方法上面的所有注解，由于 repos() 这个方法上面可能会有多个注解，因此它是数组类型。
注释④：我们使用 for 循环，遍历所有的注解，找到 GET 注解。
注释⑤：我们找到 GET 注解以后，要取出 @GET(“/repo”) 当中的”/repo”，也就是“annotation.value”。这时候我们只需要用它与 baseURL 进行拼接，就可以得到完整的 URL；
注释⑥：return@newProxyInstance，用的是 Lambda 表达式当中的返回语法，在得到完整的 URL 以后，我们将剩下的逻辑都交给了 invoke() 这个方法。
接下来，我们再来看看 invoke() 当中的“待完成代码”应该怎么写。
private fun invoke (url: String , method: Method , args: Array <Any >) }
在上面的代码中，我们的 invoke() 方法一共分成了四个步骤，其中的③、④两个步骤其实很容易实现：
private fun invoke (url: String , method: Method , args: Array <Any >) val request = Request.Builder() .url(url) .build() val response = okHttpClient.newCall(request).execute() val body = response.body val json = body?.string() val result = gson.fromJson<Any?>(json, genericReturnType) return result }
继续看，经过我们的分解，现在的问题变成了下面这样：
注释①，利用反射，解析出“api.repos(“Kotlin”, “weekly”)”这个方法当中的”Kotlin”和”weekly”，将其与 URL 进行拼接得到：url + ?lang=Kotlin&since=weekly
注释②，利用反射，解析出 repos() 的返回值类型，用于 JSON 解析。
我们来看看最终的代码：
private fun invoke (path: String , method: Method , args: Array <Any >) if (method.parameterAnnotations.size != args.size) return null var url = path val parameterAnnotations = method.parameterAnnotations for (i in parameterAnnotations.indices) { for (parameterAnnotation in parameterAnnotations[i]) { if (parameterAnnotation is Field) { val key = parameterAnnotation.value val value = args[i].toString() if (!url.contains("?" )) { url += "?$key =$value " } else { url += "&$key =$value " } } } } val request = Request.Builder() .url(url) .build() val response = okHttpClient.newCall(request).execute() val genericReturnType = method.genericReturnType val body = response.body val json = body?.string() val result = gson.fromJson<Any?>(json, genericReturnType) return result }
上面的代码一共涉及五个注释，它们都是跟注解与反射这两个知识点相关的。
注释①，method.parameterAnnotations，它的作用是取出方法参数当中的所有注解，在我们这个案例当中，repos() 这个方法当中涉及到两个注解，它们分别是@Field(“lang”)、@Field(“since”)。
注释②，由于方法当中可能存在其他注解，因此要筛选出我们想要的 Field 注解。
注释③，这里是取出注解当中的值“lang”，以及参数当中对应的值“Kotlin”进行拼接，URL 第一次拼接参数的时候，要用“?”分隔。
注释④，这里是取出注解当中的值“since”，以及参数当中对应的值“weekly”进行拼接，后面的参数拼接格式，是用“&”分隔。
注释⑤，method.genericReturnType 取出 repos() 的返回值类型，也就是 RepoList，最终，我们用它来解析 JSON。
说实话，动态代理的这种模式，由于它大量应用了反射，加之我们的代码当中还牵涉到了泛型和注解，导致这个案例的代码不是那么容易理解。不过，我们其实可以利用调试 的手段，去查看代码当中每一步执行的结果，这样就能对注解、反射、动态代理有一个更具体的认识。
前面带你看过的这个动图，其实就是在向你展示代码在调试过程中的关键节点，我们可以再来回顾一下整个代码的执行流程：
相信现在，你已经能够体会我们使用 动态代理 + 注解 + 反射 实现这个网络请求框架的原因了。通过这样的方式，我们就不必在代码当中去实现每一个接口，而是只要是符合这样的代码模式，任意的接口和方法，我们都可以直接传进去。在这个例子当中，我们用的是 ApiService 这个接口，如果下次我们定义了另一个接口，比如说：
interface GitHubService { @GET("/search" ) fun search ( @Field("id" ) id: String ) }
这时候，我们的 KtHttp 根本不需要做任何的改动，直接这样调用即可：
fun main () KtHttpV1.baseUrl = "https://api.github.com" val api: GitHubService = KtHttpV1.create(GitHubService::class .java) val data : User = api.search(id = "JetBrains" ) }
可以发现，使用动态代理实现网络请求的优势，它的灵活性 是非常好的。只要我们定义的 Service 接口拥有对应的注解 GET、Field，我们就可以通过注解与反射，将这些信息拼凑在一起。下面这个动图就展示了它们整体的流程：
实际上，我们的 KtHttp，就是将 URL 的信息存储在了注解当中（比如 lang 和 since），而实际的参数值，是在函数调用的时候传进来的（比如 Kotlin 和 weekly）。我们通过泛型、注解、反射的结合，将这些信息集到一起，完成整个 URL 的拼接，最后才通过 OkHttp 完成的网络请求、Gson 完成的解析。
好，到这里，我们 1.0 版本的开发就算是完成了。这里的单元测试代码很容易写，我就不贴出来了，单元测试是个好习惯 ，我们不能忘。
接下来，我们正式进入 2.0 版本的开发。
2.0：函数式思维 其实，如果你理解了 1.0 版本的代码，2.0 版本的程序也就不难实现了。因为这个程序的主要功能都已经完成了，现在要做的只是：换一种思路重构代码 。
我们先来看看 KtHttpV1 这个单例的成员变量：
object KtHttpV1 { private var okHttpClient: OkHttpClient = OkHttpClient() private var gson: Gson = Gson() fun <T> create (service: Class <T >) fun invoke (url: String , method: Method , args: Array <Any >) }
okHttpClient、gson 这两个成员是不支持懒加载的，因此我们首先应该让它们支持懒加载 。
object KtHttpV2 { private val okHttpClient by lazy { OkHttpClient() } private val gson by lazy { Gson() } fun <T> create (service: Class <T >) fun invoke (url: String , method: Method , args: Array <Any >) }
这里，我们直接使用了 by lazy 委托的方式，它简洁的语法可以让我们快速实现懒加载。
接下来，我们再来看看 create() 这个方法的定义：
fun <T> create (service: Class <T >) return Proxy.newProxyInstance( service.classLoader, arrayOf<Class<*>>(service) ) { proxy, method, args -> } }
在上面的代码中，create() 会接收一个Class类型的参数。其实，针对这样的情况，我们完全可以省略掉这个参数。具体做法，是使用我们前面学过的inline，来实现类型实化 （Reified Type）。我们常说，Java 的泛型是伪泛型，而这里我们要实现的就是真泛型。
inline fun <reified T> create () return Proxy.newProxyInstance( T::class .java.classLoader, arrayOf(T::class .java) ) { proxy, method, args -> } }
正常情况下，泛型参数类型会被擦除 ，这就是 Java 的泛型被称为“伪泛型”的原因。而通过使用 inline 和 reified 这两个关键字，我们就能实现类型实化，也就是“真泛型”，进一步，我们就可以在代码注释①、②的地方，使用“T::class.java”来得到 Class 对象。
下面，我们来看看 KtHttp 的主要逻辑该如何重构。
为了方便理解，我们会使用 Kotlin 标准库当中已有的高阶函数，尽量不去涉及函数式编程里的高级概念。在这里我强烈建议你打开 IDE 一边敲代码一边阅读 ，这样一来，当你遇到不熟悉的标准函数时，就可以随时去看它的实现源码了。相信在学习过第 7 讲的高阶函数以后，这些库函数都不会难倒你。
首先，我们来看看 create() 里面“待重构”的代码该如何写。在这个方法当中，我们需要读取 method 当中的 GET 注解，解析出它的值，然后与 baseURL 拼接。这里我们完全可以借助 Kotlin 的标准库函数 来实现：
inline fun <reified T> create () return Proxy.newProxyInstance( T::class .java.classLoader, arrayOf(T::class .java) ) { proxy, method, args -> return @newProxyInstance method.annotations .filterIsInstance<GET>() .takeIf { it.size == 1 } ?.let { invoke("$baseUrl ${it[0 ].value} " , method, args) } } as T }
这段代码的可读性很好，我们可以像读英语文本一样来阅读：
首先，我们通过 method.annotations，来获取 method 的所有注解；
接着，我们用filterIsInstance()，来筛选出我们想要找的 GET 注解。这里的 filterIsInstance 其实是 filter 的升级版，也就是过滤的意思；
之后，我们判断 GET 注解的数量，它的数量必须是 1，其他的都不行，这里的 takeIf 其实相当于我们的 if；
最后，我们通过拼接出 URL，然后将程序执行流程交给 invoke() 方法。这里的”?.let{}”相当于判空。
好了，create() 方法的重构已经完成，接下来我们来看看 invoke() 方法该如何重构。
fun invoke (url: String , method: Method , args: Array <Any >) method.parameterAnnotations .takeIf { method.parameterAnnotations.size == args.size } ?.mapIndexed { index, it -> Pair(it, args[index]) } ?.fold(url, ::parseUrl) ?.let { Request.Builder().url(it).build() } ?.let { okHttpClient.newCall(it).execute().body?.string() } ?.let { gson.fromJson(it, method.genericReturnType) }
这段代码读起来也不难，我们一行一行来分析。
第一步，我们通过 method.parameterAnnotations，获取方法当中所有的参数注解，在这里也就是@Field(“lang”)、@Field(“since”)。
第二步，我们通过 takeIf 来判断，参数注解数组的数量与参数的数量相等，也就是说@Field(“lang”)、@Field(“since”)的数量是 2，那么[“Kotlin”, “weekly”]的 size 也应该是 2，它必须是一一对应的关系。
第三步，我们将@Field(“lang”)与”Kotlin”进行配对，将@Field(“since”)与”weekly”进行配对。这里的 mapIndexed，其实就是 map 的升级版，它本质还是一种映射的语法，“注解数组类型”映射成了“Pair 数组”，只是多了一个 index 而已。
第四步，我们使用 fold 与 parseUrl() 这个方法，拼接出完整的 URL，也就是：https://baseurl.com/repo?lang=Kotlin&since=weekly。 这里我们使用了函数引用的语法“::parseUrl”。而 fold 这个操作符，其实就是高阶函数版的 for 循环。
第五步，我们构建出 OkHttp 的 Request 对象，并且将 URL 传入了进去，准备做网络请求。
第六步，我们通过 okHttpClient 发起了网络请求，并且拿到了 String 类型的 JSON 数据。最后，我们通过 Gson 解析出 JSON 的内容，并且返回 RepoList 对象。
到目前为止，我们的 invoke() 方法的主要流程就分析完了，接下来我们再来看看用于实现 URL 拼接的 parseUrl() 是如何实现的。
private fun parseUrl (acc: String , pair: Pair <Array <Annotation >, Any>) pair.first.filterIsInstance<Field>() .first() .let { field -> if (acc.contains("?" )) { "$acc &${field.value} =${pair.second} " } else { "$acc ?${field.value} =${pair.second} " } }
可以看到，这里我们只是把从前的 for 循环代码，换成了 Kotlin 的集合操作符 而已。大致流程如下：
首先，我们从注解的数组里筛选出 Field 类型的注解；
接着，通过 first() 取出第一个 Field 注解，这里它也应该是唯一的；
最后，我们判断当前的 acc 是否已经拼接过参数，如果没有拼接过，就用“?”分隔，如果已经拼接过参数，我们就用“&”分隔。
至此，我们 2.0 版本的代码就完成了，完整的代码如下：
object KtHttpV2 { private val okHttpClient by lazy { OkHttpClient() } private val gson by lazy { Gson() } var baseUrl = "https://baseurl.com" inline fun <reified T> create () return Proxy.newProxyInstance( T::class .java.classLoader, arrayOf(T::class .java) ) { proxy, method, args -> return @newProxyInstance method.annotations .filterIsInstance<GET>() .takeIf { it.size == 1 } ?.let { invoke("$baseUrl ${it[0 ].value} " , method, args) } } as T } fun invoke (url: String , method: Method , args: Array <Any >) method.parameterAnnotations .takeIf { method.parameterAnnotations.size == args.size } ?.mapIndexed { index, it -> Pair(it, args[index]) } ?.fold(url, ::parseUrl) ?.let { Request.Builder().url(it).build() } ?.let { okHttpClient.newCall(it).execute().body?.string() } ?.let { gson.fromJson(it, method.genericReturnType) } private fun parseUrl (acc: String , pair: Pair <Array <Annotation >, Any>) pair.first.filterIsInstance<Field>() .first() .let { field -> if (acc.contains("?" )) { "$acc &${field.value} =${pair.second} " } else { "$acc ?${field.value} =${pair.second} " } } }
对应的，我们可以再看看 1.0 版本的完整代码：
object KtHttpV1 { private var okHttpClient: OkHttpClient = OkHttpClient() private var gson: Gson = Gson() var baseUrl = "https://baseurl.com" fun <T> create (service: Class <T >) return Proxy.newProxyInstance( service.classLoader, arrayOf<Class<*>>(service) ) { proxy, method, args -> val annotations = method.annotations for (annotation in annotations) { if (annotation is GET) { val url = baseUrl + annotation .value return @newProxyInstance invoke(url, method, args!!) } } return @newProxyInstance null } as T } private fun invoke (path: String , method: Method , args: Array <Any >) if (method.parameterAnnotations.size != args.size) return null var url = path val parameterAnnotations = method.parameterAnnotations for (i in parameterAnnotations.indices) { for (parameterAnnotation in parameterAnnotations[i]) { if (parameterAnnotation is Field) { val key = parameterAnnotation.value val value = args[i].toString() if (!url.contains("?" )) { url += "?$key =$value " } else { url += "&$key =$value " } } } } val request = Request.Builder() .url(url) .build() val response = okHttpClient.newCall(request).execute() val genericReturnType = method.genericReturnType val body = response.body val json = body?.string() val result = gson.fromJson<Any?>(json, genericReturnType) return result } }
可见，1.0 版本、2.0 版本，它们之间可以说是天壤之别。
小结 好了，这节实战就到这里。接下来我们来简单总结一下：
在 1.0 版本的代码中，我们灵活利用了动态代理、泛型、注解、反射 这几个技术，实现了 KtHttp 的基础功能。
动态代理 ，由于它的底层原理比较复杂，课程当中我是通过 ApiImpl 这个类，来模拟了它动态生成的 Proxy 类。用这种直观的方式来帮助你理解它存在的意义。
泛型方面，我们将其用在了动态代理的 create() 方法上，后面我们还使用了“类型实化”的技术，也就是 inline + reified 关键字。
注解方面 ，我们首先自定义了两个注解，分别是 GET、Field。其中，@GET 用于标记接口的方法，它的值是 URL 的 path；@Field 用于标记参数，它的值是参数的 key。
反射方面 ，这个技术点，几乎是贯穿于整个代码实现流程的。我们通过反射的自省能力，去分析 repos() 方法，从 GET 注解当中取出了“/repo”这个 path，从注解 Field 当中取出了 lang、since，还取出了 repos() 方法的返回值 RepoList，用于 JSON 数据的解析。
在 2.0 版本的代码中，我们几乎删除了之前所有的代码，以函数式的思维 重写了 KtHttp 的内部逻辑。在这个版本当中，我们大量地使用了 Kotlin 标准库里的高阶函数，进一步提升了代码的可读性。
在前面的加餐课程当中，我们也讨论过 Kotlin 的编程范式问题。命令式还是函数式，这完全取决于我们开发者自身 。
相比起前面实战课中的单词频率统计程序，这一次我们的函数式范式的代码，实现起来就没有那么得流畅了。原因其实也很简单，Kotlin 提供了强大的集合操作符，这就让 Kotlin 十分擅长“集合操作”的场景，因此词频统计程序，我们不到 10 行代码就解决了。而对于注解、反射相关的场景，函数式的编程范式就没那么擅长了。
在这节课里，我之所以费尽心思地用函数式风格，重构出 KtHttp 2.0 版本，主要还是想让你看到函数式编程在它不那么擅长的领域表现会如何。毕竟，我们在工作中什么问题都可能会遇到。
