Retrofit2.0+RxJava网络请求异常统一处理

Posted 2023-05-01

参考技术A

本文内容是基于RxJava 2.0及Retrofit 2.1分析的。参考了 Rxjava +Retrofit 你需要掌握的几个技巧，Retrofit缓存，统一对有无网络处理, 异常处理，返回结果问题
下面列出具体添加的依赖。

以下这些错误，都是在网络请求中经常见的。我们可以通过Toast弹出消息通知用户具体的异常以及加载对应的UI界面。除此之外，通过具体的异常信息，方便我们及时的排查项目中的BUG。

那么问题就来了，我们如何判断异常的类型？

这就要从服务器返回的数据格式说起了。

我们一般请求的返回都是像下面这样

服务器端返回数据约定俗称就是大概以上的格式。可能具体的code码表示的含义不一样，这个可以与服务器端人员交流，灵活变化。
关于Retrofit的基本配置就不再讲述了，这里具体讲解如何对服务器返回数据封装以及使用RxJava对错误信息处理。

封装返回数据
对于上述的服务器返回数据我们要对code做出一些判断，code不为200（假设200表示请求网络成功）就抛出异常。所以我们新建一个BaseResponse类，对应上面的数据结构。

这算是所有实体的一个基类，data可以为任何数据类型。

然后要对返回结果进行预处理，新建一个ExceptionHandle。预处理无非就是当根据返回数据BaseResponse的isOk()方法判断为是否为true，若为true则正常处理，否则抛出异常让ExceptionHandle进一步处理，判断异常为何种异常。我们先跳过前面的逻辑，先了解如何判断是何种异常？

判断异常类型

详细可看源码，下面会贴出地址。
通过ExceptionHandle.handleException(Throwable e) 即可返回一个异常，并携带具体异常类型信息。

现在我们已经知道了如何判断是否产生以上以及如何判断异常类型。接下来需要解决地就是如何把异常传递给Observer的onError(Throwable e)去处理异常。

在进行异常传递的过程中，第一步我们先要判断服务器返回的数据是否是异常，如果不是异常则返回data数据，如果是异常则抛出异常。这个时候就包含了一个数据转换的过程即把BaseResponse对象转换成data类型的对象，所以需要map()操作符。

其中HandleFuc实现了 Function<BaseResponse<T>, T> 接口

如果不出现异常则不会走第二步。如果出现异常，则需要进行第二步，即对异常进行判断，然后将ExceptionHandle.handleException(Throwable e) 返回的异常传入onError()中处理。

重点来了：当产生异常时，应该终止对onNext()方法的调用并调用onError()方法。如果不继续处理，仅通过以上步骤，虽然会调用onError()方法，但是没有对异常进行判断，并且没有取消onNext()方法。那么有没有一个好的方法，可以即取消onNext()方法，又能在其中实现异常判断的执行，并且会调用onError()方法？

如此强大的RxJava自然有这样的方法了， onErrorResumeNext() 就能实现这个要求。对于 onErrorResumeNext() ，可以简单理解为：当发生错误的时候，由另外一个Observable来代替当前的Observable并继续发射数据。

onErrorResumeNext() 中传入的参数可以是一个Function接口。这样，我们可以在Function中生成一个Observable，该Observable执行异常判断的逻辑，并调用onError()方法。
具体实现如下：

至此，我们便实现了异常判断与传递的逻辑。这样我们就可以在onError()方法中提取具体的异常状态信息，进行相应的处理。

大概流程是：map()进行数据类型转换，并检测异常。如果正常，返回data类型的数据。如果不正常，onErrorResumeNext()判断异常类型并传递异常

上述情况关闭了网络。当发起网络请求，没有网络则抛出异常，然后检测出具体异常，Toast提示异常类型，用户便知道是什么地方出错了。

demo参考地址： https://github.com/maiduoduo/RetrofitRxJavaException

基于Retrofit+RxJava的Android分层网络请求框架

目前已经有不少Android客户端在使用Retrofit+RxJava实现网络请求了，相比于xUtils，Volley等网络访问框架，其具有网络访问效率高（基于OkHttp）、内存占用少、代码量小以及数据传输安全性高等特点。

Retrofit源码更是经典的设计模式教程，笔者已在之前的文章中分享过自己的一些体会，有兴趣的话可点击以下链接了解：《Retrofit源码设计模式解析（上）》、《Retrofit源码设计模式解析（下）》

但在具体业务场景下，比如涉及到多种网络请求（GET/PUT/POST/DELETE等），多种请求方式（异步/同步）时，按照Retrofit官方文档实现网络请求仍然会显得比较繁琐，本文主要介绍笔者基于Retrofit+RxJava封装的Android分层网络请求框架，适用于下图所示的业务场景：Android移动端通过移动网关调用接口平台发布的业务服务。

上述业务架构可能是目前移动应用中使用的比较广的，其具有以下优点：

• 由于移动网关系统和统一服务发布平台的存在，移动端不需要直接调用业务系统的服务，避免了移动端同时对接多个业务系统，降低移动端系统的复杂性；
• 移动网关会对移动端的请求进行鉴权，屏蔽外部恶意访问，有效提高内部业务系统的安全性；
• 统一服务发布平台集成所有的业务接口，对外提供格式统一的接口服务，这对于内部系统的可维护性和可扩展性是至关重要的。
• 业务系统只需要按照格式将其服务在接口平台上发布即可，无需关心具体的调用者。

因此，本文分享的分层网络请求框架的前提是：Android移动端直接对接移动网关。主要有以下内容：

1. 网关请求封装。移动网关的请求格式（参数、字段、通信方式等）应该是固定的，并且对业务是透明的，不触碰具体业务数据。负责直接对接客户端的请求，包括请求的鉴权，客户端与后台的数据格式的转换等。
2. 基础业务请求。基础业务请求涉及到正式/测试环境的切换，网关返回业务数据的统一解析，以及添加业务相关的网关默认字段等；
3. 业务Module统一网络请求管理。业务Module负责统一管理一个业务模块中所有的网络请求，接收鉴别请求对应的字段，包含服务名、服务分组名、请求方法以及请求参数等；
4. Model层网络请求。Model层的网络请求是按服务划分的，一个应用Module通常会对应多个服务，并且接收Activity的参数，组装请求bean；
5. Activity层的网络访问。Activity直接调用Model层的方法，传入界面相关的参数，回调响应结果。
6. 文件上下传及其它网络访问。通过Retrofit+RxJava还可以实现文件上下传以及软件更新等其它网络访问，本文也会一并简要介绍。

一、网关请求封装

通过Retrofit注解定义移动网关接口，比如请求方式，参数格式，字段等。以POST请求为例，参数格式为表单数据，字段包含服务名、服务分组名、方法名、参数、请求头Map以及其他参数等。

@FormUrlEncoded
@POST("./")
Observable<WGResponseBean> postRequest (
        @FieldMap("param") String param,
        @HeaderMap Map<String, String> headMap);

Retrofit的FieldMap不支持字段值为null，如参数中有null值，需要使用Field。

如上所述，@POST表示该请求是一个POST方法，常用的POST提交数据的方式有：

• application/x-www-form-urlencoded
• multipart/form-data
• application/json
• text/xml

application/x-www-form-urlencoded对应表单数据，在Retrofit中，通过@FormUrlEncoded标注的参数将以表单形式进行提交。multipart/form-data一般用于文件上传的时候，这个在后面会提到。application/json通过JSON方式与服务端进行数据交换，text/xml使用XML数据格式。

定义了网关请求之后，需要创建对应的Service，而Service的使用方式并不确定，这里通过一个抽象类对其进行封装。

public abstract class WgReqService<T> {

    // 网关网络请求
    protected WGApi wgApi;

    // 省略代码
    public WgReqService(String baseUrl) {
        wgApi = new NetWork.Builder(baseUrl).build().getApi(WGApi.class);
    }

    public abstract T wgReq(WGRequestBean wgRequest, Map<String, String> headMap);
}

以同步/异步网络请求为例，分别继承自WgReqService，实现对应的wgReq方法即可。

public class WgReqAsync<T> extends WgReqService<Observable<T>> {

    // 省略代码 
    @Override
    public Observable<T> wgReq(WGRequestBean wgRequest, Map<String, String> headMap) {
        // 省略代码
    }
}

public class WgReqSync extends WgReqService<WGResponseBean> {
    // 省略代码
    @Override
    public WGResponseBean wgReq(WGRequestBean wgRequest, Map<String, String> headMap) {
        // 省略代码
    }
}

由于采用了RxJava，因此在异步实现中，泛型参数为Observable<T>，而同步请求时直接返回网关的出参Bean。另外，需要说明的是WgReqAsync包含域Func1<WGResponseBean, T>，Func1为RxJava支持的接口，这里表示将网关返回的业务数据进行统一解析的方法。

二、基础业务请求

通过上述的分析可知，业务请求可以有同步/异步等多种实现方式，同时涉及到正式/测试环境的切换，网关返回业务数据的统一解析，以及添加业务相关的网关默认字段等，这里以异步请求为例：

public class BaseWgRequest implements Func1<WGResponseBean, BusinessBean> {

    // 网关请求Helper类
    private WgReqAsync<BusinessBean> wgReqAsync;

    // 服务名
    protected String service;
    // 服务组名
    protected String alias;
    // 解析类
    protected Class<? extends BusinessBean> rClazz;

    // 省略代码
}

BaseWgRequest持有WgReqAsync<BusinessBean>引用，并通过其完成网关访问，service、alias等域指定相应的服务，Class<? extends BusinessBean>表示对业务返回值进行解析的类。

return JSON.parseObject(wgResponse.getData(), rClazz != null ? rClazz : BusinessBean.class);

异步请求中，通过上述域及业务相关的网关默认字段封装请求体，同时获取请求head。

// 请求
return wgReqAsync.wgReq(ParamUtil.getWGRequestBean(service, alias, method, param),
            BaseConstants.getHeaderMap());

三、业务Module

首先申明，对整个项目进行多工程划分（业务工程和库工程独立，便于库工程独立维护），同时业务工程中分为多个功能Module（便于功能模块插件化、热加载），这种方式在比较大型的项目中应用效果可能比较好，在小型项目中并不推荐。这里的业务Module是以功能模块进行划分的，对一个功能模块中的所有网络请求进行统一管理，能有效的单元测试，提高整体开发效率。

如上所述，业务Module的主要职责是接收鉴别请求对应的字段，包含服务名、服务分组名、请求方法以及请求参数等，并继承自上述 BaseWgRequest实现。

public class WelNetwork extends BaseWgRequest {}

业务Module包含了一个功能模块中的所有网络请求方法，以登录为例：

public Observable<BusinessBean> userLoginWork(SysUsersReqDto sysUsersReqDto) {
    return wgRequest(service, alias, BusinessConstants.userLoginWork, ParamUtil.getJsonParam(sysUsersReqDto));
}

这里重点说明下登录方法的入参，BaseWgRequest关注的是与网关接口相关的参数，由于业务Module继承自BaseWgRequest，这一层的方法不再关注网关相关内容，重点是业务相关的请求入参。换句话说，业务Module的入参直接对应业务接口的入参，具有访问形式的无关性。考虑清楚每一个层次的关注重点，是搭建软件架构的基础。

四、Model层网络请求

在本系统中，按照服务名对Model进行了划分，需要申明的是，由于每个公司的具体情况不一样，这种划分方式不一定适用于你的系统。不过这种分层方式仍有借鉴之处。

由于Model中方法的访问可能不止一处，因此对外（Activity）提供单实例对象。这里提供一种最简单饿汉模式的单实例：

private static LoginModel loginModel = new LoginModel();

public static LoginModel getInstance() {
    return loginModel;
}

同时，在其构造器中初始化业务Module访问类。

private LoginModel() {
        super();
        welNetwork = new WelNetwork.Builder().service(BusinessConstants.SysLogin).alias(BaseConstants.getALIAS())
                .rClazz(SysUsersResDto.class).build();
}

上面提到，业务Module关注的是业务接口的入参，那么这个入参就是有Model提供的。一个功能模块可能对应多个服务，那么这些服务需要持有业务Module的引用，并通过业务Module的方法实现自身的方法。还是以登录为例：

public Observable<BusinessBean> userLoginWork(String username, String password) {
        return welNetwork.userLoginWork(new SysUsersReqDto.Builder(username).userPwd(password)
                .devType("1").devIp(DeviceUtils.getClientIpAddress()).build());
}

Model负责连接Activity和业务Module，对上直接对接Activity，Activity关注的是用户输入的用户名和密码，并不知道业务接口需要的数据格式，而业务Module关注的是业务接口的入参格式。因此，Model层对这两种数据进行适配，常见的就是对请求bean的组装，比如上述登录方法接收用户名和密码，组装成业务Module所需的SysUsersReqDto。

五、Activity层的网络访问

通过上述分层封装，在Activity中的网络访问就非常简单了。直接上示例代码：

LoginModel.getInstance().userLoginWork(usernameStr, passwordStr)
    .subscribe(new RxObserver<BusinessBean>(this) {
    @Override
    public void onSuccess(BusinessBean businessBean) {
          handleLoginResult(businessBean);
    }
});

需要说明的是RxObserver，RxObserver<T>继承自Subscriber<T>，Subscriber是RxJava的回调类，RxObserver包含抽象方法onSuccess，并在onNext实现中进行调用。

public abstract class RxObserver<T> extends Subscriber<T> {
    // 省略代码
    @Override
    public void onNext(T t) {
        onSuccess(t);
    }

    public abstract void onSuccess(T t);
}

从Activity的角度来讲，其负责用户交互，因此只关注用户输入和接口返回具体数据，并对数据进行处理。而至于网关的实现，业务接口的入参格式，网络请求的方式等底层实现，则对Activity完全闭合。

上述简要介绍了题目所讲到的基于Retrofit+RxJava的Android分层网络请求框架，由于涉及具体业务，只能开放部分代码样例。至于对架构的观点，可参考《什么是架构？》。

1. 根据要解决的问题，对目标系统的边界进行界定。
2. 并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。
3. 并对这些切分出来的部分，设立沟通机制。
4. 根据3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。

界定-切分-沟通-系统，是架构设计的基本步骤。

本系统界定为基于Retrofit+RxJava实现Android分层网络请求，然后将整个系统进行切分五个层次，每个层次的关注点相异，但又相互联系，这五个层次通过抽象（抽象类或接口）、继承、复合等方法进行沟通，形成一个统一系统，完成Android中的网络请求。

六、文件上下传及其它网络访问

除上述网关请求外，Android中还经常涉及文件上下传、软件更新等与网络相关的操作，这里也对其进行简要的介绍。

如上所述，文件上传需要采用multipart/form-data数据提交方式，因此在Retrofit中定义方法时，需要采用@Multipart注解。

@Multipart
@POST("./")
Observable<UploadFileResponseBean> uploadFile(@Part MultipartBody.Part file,
                                                   @PartMap Map<String, RequestBody> params,
                                                   @HeaderMap Map<String, String> headMap);

同时，其入参类型为@Part，或@PartMap。需要注意的是，传入该方法的参数为MultipartBody.Part。

// 根据文件路径生成文件
File file = new File(requestBean.getFilePath());
// 根据文件创建请求体
RequestBody requestFile = RequestBody.create(MediaType.parse("multipart/form-data"), file);
// 创建实际请求用的MultipartBody
MultipartBody.Part body = MultipartBody.Part.createFormData("file", file.getName(), requestFile);

其他封装形式与上述网关请求类似，这里不再赘述。

对于文件的下载，笔者尝试了《Retrofit 2 — How to Download Files from Server》的方法，但由于其涉及下载进度的监听以及下载完成的操作等，对后续系统的封装并不好，这里就不详细介绍了。

针对文件下载这种场景，如果自定义实现，需要处理OOM、多线程等问题。DownloadManager是Android2.3以后引入的系统自带类库，通过getSystemService(Context.DOWNLOAD_SERVICE)就能获取并使用，系统服务已经完成网络访问控制、文件读写控制、通知栏进度显示、大文件续传等一系列文件下载可能遇到的问题。因此，推荐系统自带实现，这个列出简要参考代码，详细情况请参考《DownloadManager官方文档》。

DownloadManager downloadManager = (DownloadManager) getSystemService(Context.DOWNLOAD_SERVICE);
DownloadManager.Request request = new DownloadManager.Request(Uri.parse(apkUrl));
// 设置目标文件路径
request.setDestinationInExternalPublicDir(dir, fileName);
// 仅在WIFI网络下载
request.setAllowedNetworkTypes(DownloadManager.Request.NETWORK_WIFI);
// 设置标题及描述
request.setTitle(getString(R.string.app_name));
// 发送请求
downloadManager.enqueue(request);

最后，举个GET请求的栗子，查询软件是否有更新一般会采用GET请求，比如请求参数包括系统、包名、版本号等入参的请求格式为：

@GET("./")
Observable<ApkUpdateResponseBean> apkUpdate(
        @Query("os") String os,
        @Query("packageName") String packageName,
        @Query("version") String version);

@Query表示请求字段。