RxJava新手求助：跨Observable调用subscribe方法遇Token刷新问题

作为RxJava新手，嵌套调用subscribe确实容易踩坑——不仅代码可读性差、线程逻辑混乱，还可能引发内存泄漏。咱们换个思路，用RxJava的操作符来优雅串联Token刷新和业务请求的流程，完全避开嵌套订阅的问题。

核心逻辑梳理 #

我们需要把「Token有效性校验/刷新」和「业务请求」两个Observable按顺序组合：

1. 先判断当前Token是否过期
2. 过期则先调用刷新接口，拿到新Token后再发起业务请求
3. 未过期则直接发起业务请求

具体实现代码示例 #

第一步：封装获取有效Token的Observable #

先写一个专门处理Token逻辑的方法，返回Observable，帮你搞定Token的检查和刷新：

private Observable<String> getValidToken() {
    String currentToken = PreferencesUtils.getAccessTokenKey();
    // 替换成你实际判断Token是否过期的逻辑
    boolean isTokenExpired = checkTokenExpired(currentToken);

    if (!isTokenExpired) {
        // Token有效，直接返回当前值
        return Observable.just(currentToken);
    } else {
        // Token过期，调用刷新接口并处理结果
        return service.refreshToken(PreferencesUtils.getRefreshToken())
                .subscribeOn(Schedulers.io())
                .doOnNext(refreshResponse -> {
                    if (refreshResponse.isSuccess()) {
                        // 保存新Token到本地
                        PreferencesUtils.saveAccessTokenKey(refreshResponse.getNewToken());
                        PreferencesUtils.saveRefreshToken(refreshResponse.getNewRefreshToken());
                    } else {
                        // 刷新失败时抛出异常，终止后续流程
                        throw new RuntimeException("Token刷新失败，请重新登录");
                    }
                })
                .map(refreshResponse -> refreshResponse.getNewToken());
    }
}

第二步：用操作符串联Token与业务请求 #

用flatMap把获取有效Token的Observable和业务请求Observable串起来，让它们按顺序执行：

getValidToken()
    .flatMap(validToken -> {
        // 拿到有效Token后，发起业务请求
        return service.getPosts(offset, limit, validToken)
                .subscribeOn(Schedulers.io());
    })
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(
        postResponse -> {
            // 处理业务请求成功的逻辑
            if (postResponse.isSuccess()) {
                // 更新UI、处理数据等操作
            } else {
                // 业务请求失败的处理
            }
        },
        error -> {
            // 统一处理所有错误：Token刷新失败、网络异常等
            Toast.makeText(context, error.getMessage(), Toast.LENGTH_SHORT).show();
        }
    );

为什么不推荐嵌套subscribe？ #

• 回调地狱：多层嵌套后代码可读性骤降，后期维护简直噩梦
• 线程混乱：嵌套订阅的线程调度容易冲突，可能导致UI线程阻塞或数据异常
• 生命周期失控：嵌套的Observable如果没正确绑定生命周期，很容易引发内存泄漏

额外优化小建议 #

• 可以给getValidToken加个短期缓存，避免短时间内重复检查Token
• 如果每个操作只会发射一次数据，用Single替代Observable更贴合业务场景
• 用CompositeDisposable管理所有订阅，在页面销毁时及时取消，防止内存泄漏

内容的提问来源于stack exchange，提问作者R R