android网络框架作用,是时候开始重构Android Http网络层框架了(一个现代化的Http网络框架源码分析)...

男娘i 2022-10-18 00:49 77阅读 0赞

横观历史

![b2e8e5d40510][]

image.png

一点感概

记得当年刚入行Android，让我记忆犹新的框架android-async-http，当时用的不亦乐乎，随着时间的变迁，官方的新宠Volley诞生，不久的不久官方宣布自己放弃，坑爹，Android 4.4后，HttpURLConnection底层实现改为OkHttp，随即OkHttp是各个大牛封装的根基，Retrofit最为知名，可以说几乎没有人没用过，后来不知道谁刮起了RxJava大风，变成了Retrofit+RxJava+OkHttp，到目前为止我都很反感RxJava，框架固然很好，但我们不合适，不爱就是不爱，没必要牵强。自从有了Coroutines协程，算是找到了最优解，为什么这么说呢？我们先来分析下这几种实现方式

基于Apache的HttpClient库构建的Android异步网络框架，大致用法如下：

private AsyncHttpClient asyncHttpClient = new AsyncHttpClient() \{

@Override

protected AsyncHttpRequest newAsyncHttpRequest(DefaultHttpClient client, HttpContext httpContext, HttpUriRequest uriRequest, String contentType, ResponseHandlerInterface responseHandler, Context context) \{

AsyncHttpRequest httpRequest = getHttpRequest(client, httpContext, uriRequest, contentType, responseHandler, context);

return httpRequest == null

? super.newAsyncHttpRequest(client, httpContext, uriRequest, contentType, responseHandler, context)

: httpRequest;

\};

@Override

public RequestHandle executeSample(AsyncHttpClient client, String URL, Header\[\] headers, HttpEntity entity, ResponseHandlerInterface responseHandler) \{

return client.get(this, URL, headers, null, responseHandler);

@Override

public String getDefaultURL() \{

return "https://httpbin.org/get";

@Override

public ResponseHandlerInterface getResponseHandler() \{

return new AsyncHttpResponseHandler() \{

@Override

public void onStart() \{

clearOutputs();

@Override

public void onSuccess(int statusCode, Header\[\] headers, byte\[\] response) \{

debugHeaders(LOG\_TAG, headers);

debugStatusCode(LOG\_TAG, statusCode);

debugResponse(LOG\_TAG, new String(response));

@Override

public void onFailure(int statusCode, Header\[\] headers, byte\[\] errorResponse, Throwable e) \{

debugHeaders(LOG\_TAG, headers);

debugStatusCode(LOG\_TAG, statusCode);

debugThrowable(LOG\_TAG, e);

if (errorResponse != null) \{

debugResponse(LOG\_TAG, new String(errorResponse));

@Override

public void onRetry(int retryNo) \{

Toast.makeText(GetSample.this,

String.format(Locale.US, "Request is retried, retry no. %d", retryNo),

Toast.LENGTH\_SHORT)

.show();

\};

我们暂且不提现在官方现在已经不用HttpClient，框架本身有很多可以借鉴的优秀设计，放在当初可谓是功能丰富，非常稳定，且bug极少。我少啰嗦几句，直接看下一个实现，最终我们再宏观的看看，到底网络框架的前世今生是什么走向。

VolleyPlus库对Volley进行的项目改进以及完整的图像缓存，涉及使用RequestQueue，RequestTickle和Request

RequestQueue mRequestQueue = Volley.newRequestQueue(getApplicationContext());

StringRequest stringRequest = new StringRequest(Request.Method.GET, url, new Response.Listener() \{

@Override

public void onResponse(String response) \{

....

\}, new Response.ErrorListener() \{

@Override

public void onErrorResponse(VolleyError error) \{

....

\});

mRequestQueue.add(stringRequest);

比起AsyncHttpClient，加入了请求队列(AsyncHttpClient也有线程池)，线程调度，缓存DiskLruCache，支持的缓存类型：

网络缓存

资源缓存

文件缓存

视频缓存

内容URI缓存

等等吧，也是给我们网络层提供了不少的遍历，接下来看看Retrofit+RxJava

Retrofit+RxJava

public interface ApiService \{

@GET("demo")

Observable getDemo(@Query("start") int start, @Query("count") int count);

// 使用例子

apiService.getDemo(0, 10)

.subscribeOn(Schedulers.io())

.observeOn(AndroidSchedulers.mainThread())

.subscribe(new Observer() \{

@Override

public void onSubscribe(Disposable d) \{

Log.d(TAG, "onSubscribe: ");

@Override

public void onNext(Demo demo) \{

Log.d(TAG, "onNext: " + demo.getTitle());

List list = demo.getSubjects();

for (Subjects sub : list) \{

Log.d(TAG, "onNext: " + sub.getId() + "," + sub.getYear() + "," + sub.getTitle());

@Override

public void onError(Throwable e) \{

Log.e(TAG, "onError: " + e.getMessage());

@Override

public void onComplete() \{

Log.d(TAG, "onComplete: Over!");

\});

这种似乎是很多很多App目前的使用方式，毋庸置疑，它解决了开发中网络层的很多问题，那为什么它会这么火呢？它背后的本质是什么？我这里啰嗦几句哈，大家应该都听说过后端的开发框架Spring，说到Spring，你肯定会想到它设计的两个核心概念，IOC控制反转，AOP面向切面编程，Retrofit本质上用IOC控制反转，你只需要定义接口，对象由框架本身负责管理，接口有个特点就是不变，利用IOC使得你不得不定义接口，这样间接提高代码的稳定性，是不是很佩服大佬的思想，在这感谢这些大佬们的努力，让我们慢慢养成一个好的编程习惯，当然我们也更应该关注他们设计的思想，这样我们在自己做框架的时候，是不是可以借鉴(copy)一下呢。好了，今天的主角上场了，来看下最新的实现

Net(okhttp+coroutines+lifecycle)

Get

scopeNetLife \{

// 该请求是错误的路径会在控制台打印出错误信息

Get("error").await()

Post

scopeDialog \{

tv\_fragment.text = Post("dialog") \{

param("u\_name", "drake")

param("pwd", "123456")

\}.await()

这么简单的实现蕴含了什么？

生命周期监控

加载中显示框

自动序列化

异常处理

协程同步

非线程阻塞

优势很明显，代码的确很简洁，让他们阅读代码不吃力，功能更完善，无需切换线程，消除类似Rxjava的observeOn，subscribe匿名内部类的模板代码，让人更加注重业务逻辑的编写。想必这就是我认为的最优解的一些理由吧。你肯定也会说Rxjava也有这些功能(如：lifecycle)，是的，你想怎么用是你的权利，我不能左右。我只想说

，你饿了吗？哈哈

![b2e8e5d40510][]

50555D97-51B2-4722-B334-55B80055E84D-6692-000003D06E6D4B5B.jpg

小结

经过几个版本的代码对比，你是不是已经察觉到，网络的前世今生，让我们一起总结下进化的特点

简单化

生命感知力

更轻量级的调度

自我管理

高内聚(隐藏实现细节)

高可定制

这就是我们网络框架的今生，你不重构一下吗？亲。

老师说经常教我们知其然知其所以然，那么我就带你走进Net框架实现的底层，让我们看看作者都做了些什么的封装。

源码分析

首先来看下项目的目录结构

![b2e8e5d40510][]

image.png

项目主要分为两个Lib

Kalle的源码我们后期再分析，虽然已经一年零两个月未维护了，但毕竟大佬做的，有很多可以学习的地方，这期我们针对强哥的框架Net做深入的分析，由于本人最近两年一直在做Rom相关，对Jetpack相关的使用也不是特别的熟悉，有什么不对的还请各位手下留情，强哥说他还对Kalle的源码做了变更，所以才拿到项目里维护，后期还会升级一下okhttp的版本，因为YanZhenjie没有升级最新的okhttp，当然这不是我们的重点，下面我们来开始分析源码

再来看下强哥总结的框架特性

协程

并发网络请求

串行网络请求

切换线程

DSL编程

方便的缓存处理

自动错误信息吐司

自动异常捕获

自动日志打印异常

自动JSON解析

自动处理下拉刷新和上拉加载

自动处理分页加载

自动缺省页

自动处理生命周期

自动处理加载对话框

协程作用域支持错误和结束回调

支持先强制读取缓存后网络请求二次刷新

附带超强轮循器

最近强哥还加了个优先队列，同时发起10个请求，优先取第一个回来的结果，而且代码极其简洁好用。

Net源码目录

![b2e8e5d40510][]

image.png

22个文件，不多不少，刚刚好，整体看目录，根本不用深入看代码，我们就能清晰的知道这是干什么的，这就是一种好的目录结构，值得学习

connect 真实的链接对象

convert 序列化

error 异常定义

scope 作用域

tag 日志tag

time 时间相关(结合它的特性，轮训应该在这里有相关实现)

utils 工具类

Net.kt 网络请求的核心实现

NetConfig.kt 全局配置文件

类图

一张清晰可见的类图，是分析一个源码有利的手段，随我将其源码类图搞个明白，请看下图

![b2e8e5d40510][]

Net类图.jpg

通过类图，我们可以清晰看到，该框架源码的类结构，我大致分以下模块，好统一分析

kalle扩展支持部分：ConnectFactory、Converter、NetException

作用域部分：CoroutineScope结合Android Lifecycle的扩展，以及Sate、Page、Dialog对NetCoroutineScope的实现

动态扩展部分，这是框架的核心：Net，组合协程、Kalle实现新的网络框架

配置、工具部分：NetConfig、Utils(省略未画)、Interval

接下来，详细看下各个模块的实现

kalle扩展支持部分

ConnectFactory只有一个功能：就是创建一个Connection对象，参数是Request。这里为什么这样做呢？其实是为了能兼容不同的URLConnection，强哥使用的okhttp，自然使用HttpClient

![b2e8e5d40510][]

image.png

Converter就是大家熟悉的Response处理，这里有个巧妙的设计，将接口返回的数据，通过传入的code作为key，默认是code，取到业务定义的code码，与传入的success参数对比，如果一样就是成功，然后parsebody，如果返回其他，则抛出失败的结果。

![b2e8e5d40510][]

image.png

NetException 异常对于一个框架来说几乎不可避免，自定义的异常信息，有利于问题的归类和追踪。上图中就是作者自定义的RequestParamsException请求参数异常、ServerResponseException服务器异常，这个代码就不用看了，大家肯定是明白了，下面来看作用域部分

作用域部分

作用域都继承自CoroutineScope，CoroutineScope持有CoroutineContext上下文，其实不难理解，就像Android的Context，分别有Applicaition Context和Activity Context，其实就是标示出不同的生命周期，那么顺着这个理解就好说了，作者抽象AndroidScope，其实就是为了监听Lifecycle的生命周期，然后在默认的ON\_DESTROY函数回调中cancel掉协程，如下图代码所示

![b2e8e5d40510][]

image.png

![b2e8e5d40510][]

image.png

看到了吧，继承CoroutineScope需要实现CoroutineContext对吧，那这里的context是啥呢？

![b2e8e5d40510][]

image.png

协程上下文包含当前协程scope的信息，如CoroutineDispatcher，CoroutineExceptionHandler，Job，其实这三个都是继承实现CoroutineContext.Element，而这个+号不是我们以为的加号，点击后看到如下源码，这里巧妙的运用操作符重载，不理解概念可以点击该链接：https://www.kotlincn.net/docs/reference/operator-overloading.html 学习。

![b2e8e5d40510][]

image.png

我们先不研究这样做的用意哈，这里你要知道的是，该协程上下文承载了三个对象

Dispatchers.Main 主线程

exceptionHandler 异常捕获

SupervisorJob 需要执行的协程

SupervisorJob 它类似于常规的 Job，唯一的不同是：SupervisorJob 的取消只会向下传播。看下官方的例子

import kotlinx.coroutines.\*

fun main() = runBlocking \{

val supervisor = SupervisorJob()

with(CoroutineScope(coroutineContext + supervisor)) \{

// 启动第一个子作业——这个示例将会忽略它的异常(不要在实践中这么做！)

val firstChild = launch(CoroutineExceptionHandler \{ \_, \_ -> \}) \{

println("The first child is failing")

throw AssertionError("The first child is cancelled")

// 启动第二个子作业

val secondChild = launch \{

firstChild.join()

// 取消了第一个子作业且没有传播给第二个子作业

println("The first child is cancelled: $\{firstChild.isCancelled\}, but the second one is still active")

try \{

delay(Long.MAX\_VALUE)

\} finally \{

// 但是取消了监督的传播

println("The second child is cancelled because the supervisor was cancelled")

// 等待直到第一个子作业失败且执行完成

firstChild.join()

println("Cancelling the supervisor")

supervisor.cancel()

secondChild.join()

这段代码的输出如下：

The first child is failing

The first child is cancelled: true, but the second one is still active

Cancelling the supervisor

The second child is cancelled because

其实我没怎么理解向下传播，哪位大佬能解释解释，我们接着往下分析。

![b2e8e5d40510][]

image.png

作者抽象这些高级函数，用于实现dsl的效果如：

![b2e8e5d40510][]

image.png

![b2e8e5d40510][]

image.png

catch用于捕获协程异常信息处理，finally是在invokeOnCompletion里触发，invokeOnCompletion在协程进入完成状态时触发，包括异常和正常完成。

![b2e8e5d40510][]

image.png

好滴，AndroidScope大致就分析完了，我们来简单总结一下

AndroidScope 在lifecycle ON\_DESTROY时 自动cancel

可以监听异常catch，可以实现finally

主线程执行，作用域内可以刷新UI，不用切换线程

就这些，再来看下NetCoroutineScope，它是网络框架的扩展重心，NetCoroutineScope同样的具有自动取消的逻辑，如：

![b2e8e5d40510][]

image.png

看下面的变量，我们其实能知道，NetCoroutineScope主要是扩展了网络的缓存策略，需不需要缓存，是否缓存成功等等，还有个animate，这里看作者注释，是控制是否在缓存成功后依然显示加载动画

![b2e8e5d40510][]

image.png

然后覆盖launch函数，将逻辑插入到里面，其实这里违背了里氏替换原则，子类尽量不要重写父类的方法，继承包含这样一层含义：父类中凡是已经实现好的方法(相对于抽象方法而言)，实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。

![b2e8e5d40510][]

image.png

然后就是cache配置的实现

![b2e8e5d40510][]

image.png

用例：

用起来简单的一批

![b2e8e5d40510][]

image.png

接下来就是StateCoroutineScope、PageCoroutineScope、DialogCoroutineScope，这三个我就不一一解读了，同样的套路，对实际业务中的高发场景做的高度抽象。如：StateCoroutineScope是对StateLayout的扩展处理，在StateLayout onViewDetachedFromWindow时 自动cancel()掉协程，等等吧。

Net的核心部分，动态扩展

不啰嗦，直接看代码哦

![b2e8e5d40510][]

image.png

扩展CoroutineScope，添加get函数

执行完后对uid做cancel或者remove处理，释放缓存

结合NetConfig的host+path，形成完整的请求路径

SimpleUrlRequest创建新的请求

async(Dispatchers.IO) 子线程的网络请求

![b2e8e5d40510][]

image.png

Post同理，其实差别就在请求参数，其他Head、Options 就不用分析喽