Android中如何实现类似JavaScript Promise的串行网络请求？

嘿，我来帮你梳理下Android里实现这种非主线程顺序执行异步网络操作的几种方案，尤其是贴近你熟悉的JS Promise风格的方式：

1. 首选：Kotlin协程（Coroutines）+ Retrofit（如果用网络框架） #

如果你的项目用Kotlin，这绝对是最简洁直观的方案，和JS的Promise逻辑几乎一致，代码可读性拉满：

步骤： #

• 首先给Retrofit的接口方法加上suspend关键字（Retrofit 2.6+支持协程），让它们变成可挂起的异步函数：

  interface ApiService {
      @GET("access-token")
      suspend fun getAccessToken(): Response<TokenResponse>
  
      @GET("more-info")
      suspend fun getMoreInformation(@Query("token") token: String, @Query("bar") bar: String): Response<InfoResponse>
  }
  

• 然后在非主线程（比如IO调度器）里顺序执行这些网络请求，就像写同步代码一样：

  // 在ViewModel或者Repository里调用，用viewModelScope或者CoroutineScope(Dispatchers.IO)
  CoroutineScope(Dispatchers.IO).launch {
      try {
          // 第一步：获取AccessToken
          val tokenResponse = apiService.getAccessToken()
          if (!tokenResponse.isSuccessful) {
              // 处理错误
              return@launch
          }
          val accToken = tokenResponse.body()?.access_token ?: return@launch
  
          // 第二步：用token获取更多信息
          val infoResponse = apiService.getMoreInformation(accToken, foo.bar)
          if (infoResponse.isSuccessful) {
              val response = infoResponse.body()
              if (isValid(response)) {
                  // 成功：切换回主线程更新UI或者返回结果
                  withContext(Dispatchers.Main) {
                      // 比如通知UI状态
                  }
              } else {
                  // 验证失败
              }
          } else {
              // 网络请求失败
          }
      } catch (e: Exception) {
          // 处理异常（比如网络错误）
      }
  }
  

  这种方式完全不需要嵌套回调，和JS里的async/await写法几乎一模一样，而且协程自带线程切换，非常省心。

2. Java环境下：CompletableFuture（类似Promise的链式调用） #

如果你的项目还在用Java，CompletableFuture是最接近Promise的方案（Java 8+支持，Android API 24+可用，低版本可以引入androidx.concurrent:concurrent-futures兼容库）：

示例代码： #

// 定义网络请求的Callable（或者用Retrofit的同步Call）
Callable<TokenResponse> getAccessTokenTask = () -> {
    // 这里执行同步的网络请求（比如Retrofit的call.execute()）
    Response<TokenResponse> response = apiService.getAccessToken().execute();
    if (response.isSuccessful()) {
        return response.body();
    } else {
        throw new IOException("Failed to get token");
    }
};

// 用CompletableFuture链式执行
CompletableFuture.supplyAsync(getAccessTokenTask, Executors.newSingleThreadExecutor())
        .thenApplyAsync(token -> {
            // 拿到token后，执行第二个网络请求
            Response<InfoResponse> infoResponse = apiService.getMoreInformation(token.getAccessToken(), foo.getBar()).execute();
            if (infoResponse.isSuccessful()) {
                return infoResponse.body();
            } else {
                throw new CompletionException(new IOException("Failed to get info"));
            }
        })
        .thenAcceptAsync(info -> {
            // 处理最终结果
            if (isValid(info)) {
                // 成功逻辑
            } else {
                // 验证失败
            }
        })
        .exceptionally(e -> {
            // 处理所有异常
            e.printStackTrace();
            return null;
        });

supplyAsync会在指定的线程池（非主线程）执行任务，thenApplyAsync则会在上一个任务完成后，继续在后台线程执行下一个操作，完全对应JS里的Promise.then()链式调用。

3. 你提到的Future：原生Future的基础用法 #

原生的Future确实可以获取异步任务的结果，但它本身不支持链式调用，需要手动阻塞等待结果，代码会比较繁琐：

ExecutorService executor = Executors.newSingleThreadExecutor();

// 提交第一个任务
Future<TokenResponse> tokenFuture = executor.submit(getAccessTokenTask);
try {
    // 阻塞等待第一个任务完成
    TokenResponse token = tokenFuture.get();
    // 提交第二个任务
    Future<InfoResponse> infoFuture = executor.submit(() -> {
        return apiService.getMoreInformation(token.getAccessToken(), foo.getBar()).execute().body();
    });
    // 阻塞等待第二个任务完成
    InfoResponse info = infoFuture.get();
    // 处理结果
    if (isValid(info)) {
        // 成功
    }
} catch (InterruptedException | ExecutionException e) {
    e.printStackTrace();
} finally {
    executor.shutdown();
}

这种方式需要手动调用get()阻塞线程，等待上一个任务完成才能执行下一个，虽然能实现顺序执行，但代码可读性不如前两种方案，而且容易因为阻塞导致线程占用问题。

总结 #

• 如果用Kotlin，协程+Retrofit是最简最优雅的方案，和你熟悉的JS Promise逻辑对齐；
• 如果用Java，CompletableFuture是最接近Promise的链式实现；
• 原生Future可以用，但代码繁琐，不推荐作为首选。

另外，你之前用接口（回调）的方式其实是传统的Callback Hell模式，上面的方案都能避免嵌套回调，让代码更清晰。

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