Retrofit同步异步实现：统一声明异步调用用runBlocking实现同步是否可行？

这个方案整体是合理的，符合Kotlin协程的设计逻辑，也能满足你同时支持同步、异步调用的需求，但存在几个需要明确约束的问题：

• 统一声明suspend fun的收益远高于维护两套接口
  Retrofit 2.6及以上版本原生支持suspend函数，不需要额外引入CallAdapter即可完成异步请求的自动调度，底层默认会将IO操作切换到子线程执行，不需要调用方手动处理线程切换。仅维护一套suspend接口可以避免同步、异步接口重复声明的维护成本，也能统一异常、请求配置的处理逻辑，这部分设计是完全没问题的。
• runBlocking实现同步调用的使用约束
  runBlocking的本质是阻塞当前线程，等待内部协程执行完毕后返回结果，仅适合在本身没有协程上下文、允许线程阻塞的场景下使用，比如后端定时任务、命令行工具、测试用例等场景。

  禁止在Android主线程、服务UI线程、已经处于协程上下文的环境中调用runBlocking，否则会导致线程阻塞、ANR甚至死锁。在本身有协程作用域（比如Android的viewModelScope、lifecycleScope，后端服务的协程请求上下文）的场景下，直接在作用域内启动协程调用suspend函数即可，不需要用到runBlocking。

• 极限场景的性能损耗
  相比直接调用Retrofit的同步接口，用runBlocking包装suspend函数会多出协程调度、事件循环创建的额外开销，这个开销在常规业务场景下可以忽略，但如果是每秒数千次的高频同步请求场景，可以针对性单独声明同步接口，其余场景统一用suspend函数即可。
• 规范补充建议
  可以在开发规范中明确runBlocking的允许使用范围，同时统一suspend函数的异常处理规则：网络异常、业务异常直接抛出，异步场景在协程的try/catch中捕获，同步场景在runBlocking块内外捕获即可，避免未捕获异常导致的进程崩溃。

这个方案是可行的，统一接口的收益远大于潜在的问题，只要做好runBlocking的使用场景约束，完全可以作为团队开发规范落地。

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