Retrofit使用方法

一、整體思路

從使用方法出發(fā)，首先是怎么使用，其次是我們使用的功能在內(nèi)部是如何實(shí)現(xiàn)的，實(shí)現(xiàn)方案上有什么技巧，有什么范式。全文基本上是對(duì) Retrofit 源碼的一個(gè)分析與導(dǎo)讀，非常建議大家下載 Retrofit 源碼之后，跟著本文，過(guò)一遍源碼

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名與空間、虛擬主機(jī)、營(yíng)銷軟件、網(wǎng)站建設(shè)、文水網(wǎng)站維護(hù)、網(wǎng)站推廣。

二、基本用例

2.1 創(chuàng)建 Retrofit 對(duì)象

  Retrofit retrofit = new Retrofit.Builder() 
     .baseUrl("https://api.github.com/") 
     .addConverterFactory(GsonConverterFactory.create()) 
     .build();

2.2 定義 API 并獲取 API 實(shí)例

  public interface GitHubService { 
    @GET("users/{user}/repos") 
    Call<List<Repo>> listRepos(@Path("user") String user); 
   }
  GitHubService github = retrofit.create(GitHubService.class);

先看定義，非常簡(jiǎn)潔，也沒(méi)有什么特別之處，除了兩個(gè)注解：@GET和 @Path 。它們的用處稍后再分析，我們接著看創(chuàng)建 API 實(shí) 例： retrofit.create(GitHubService.class) 。這樣就創(chuàng)建了 API 實(shí)例了，就可以調(diào)用 API 的方法發(fā)起 HTTP 網(wǎng)絡(luò)請(qǐng)求了，太方便了。但 create 方法是怎么創(chuàng)建 API 實(shí)例的呢？

  public <T> T create(final Class<T> service) { 
    // 省略非關(guān)鍵代碼 
    return (T) Proxy.newProxyInstance(service.getClassLoader(), 
       new Class<?>[] { service }, 
       new InvocationHandler() { 
         @Override 
         public Object invoke(Object proxy, Method method, Object ... args) 
            throws Throwable { 
         // 先省略實(shí)現(xiàn) 
         } 
      }); 
  }

創(chuàng)建 API 實(shí)例使用的是動(dòng)態(tài)代理技術(shù)。

簡(jiǎn)而言之，就是動(dòng)態(tài)生成接口的實(shí)現(xiàn)類（當(dāng)然生成實(shí)現(xiàn)類有緩存機(jī)制），并創(chuàng)建其實(shí)例（稱之為代理），代理把對(duì)接口的調(diào)用轉(zhuǎn)發(fā)給 InvocationHandler 實(shí)例，而在 InvocationHandler 的實(shí)現(xiàn)中，除了執(zhí)行真正的邏輯（例如再次轉(zhuǎn)發(fā)給真正的實(shí)現(xiàn)類對(duì)象），我們還可以進(jìn)行一些有用的操作，例如統(tǒng)計(jì)執(zhí)行時(shí)間、進(jìn)行初始化和清理、對(duì)接口調(diào)用進(jìn)行檢查等。為什么要用動(dòng)態(tài)代理？因?yàn)閷?duì)接口的所有方法的調(diào)用都會(huì)集中轉(zhuǎn)發(fā)到 InvocationHandler#invoke 函數(shù)中，我們可以集中進(jìn)行處理，更方便了。你可能會(huì)想，我也可以手寫(xiě)這樣的代理類，把所有接口的調(diào)用都轉(zhuǎn)發(fā)到 InvocationHandler#invoke 呀，當(dāng)然可以，但是可靠地自動(dòng)生成豈不更方便？

2.3 調(diào)用 API 方法

獲取到 API 實(shí)例之后，調(diào)用方法和普通的代碼沒(méi)有任何區(qū)別：

  Call<List<Repo>> call = github.listRepos("square"); 
  List<Repo> repos = call.execute().body();

這兩行代碼就發(fā)出了 HTTP 請(qǐng)求，并把返回的數(shù)據(jù)轉(zhuǎn)化為了 List<Repo>，太方便了！

現(xiàn)在我們來(lái)看看調(diào)用 listRepos 是怎么發(fā)出 HTTP 請(qǐng)求的。上面 Retrofit#create 方法返回時(shí)省略的代碼如下：

  return (T) Proxy.newProxyInstance(service.getClassLoader(), 
     new Class<?>[] { service }, 
     new InvocationHandler() { 
        private final Platform platform = Platform.get(); 

        @Override 
        public Object invoke(Object proxy, Method method, Object.. . args) 
              throws Throwable { 
            // If the method is a method from Object then defer to n ormal invocation. 
            if (method.getDeclaringClass() == Object.class) { 
              return method.invoke(this, args); 
            }
            if (platform.isDefaultMethod(method)) { 
              return platform.invokeDefaultMethod(method, service, p roxy, args); 
            }
            ServiceMethod serviceMethod = loadServiceMethod(method); 
            OkHttpCall okHttpCall = new OkHttpCall<>(serviceMethod, args); 
            return serviceMethod.callAdapter.adapt(okHttpCall); 
            } 
   });

如果調(diào)用的是 Object 的方法，例如 equals， toString，那就直接調(diào)用。如果是 default 方法（Java 8 引入），就調(diào)用 default 方法。這些我們都先不管，因為我們?cè)诎沧科脚_(tái)調(diào)用 listRepos ，肯定不是這兩種情況，那這次調(diào)用真正干活的就是這三行代碼了（好好記住這三行代碼，因?yàn)榻酉聛?lái)很長(zhǎng)的篇幅都是在講它們 :) ）：

   ServiceMethod serviceMethod = loadServiceMethod(method); 
   OkHttpCall okHttpCall = new OkHttpCall<>(serviceMethod, args); 
   return serviceMethod.callAdapter.adapt(okHttpCall);

在繼續(xù)分析這三行代碼之前,先看一個(gè)流程圖

這三行代碼基本就是對(duì)應(yīng)于流程圖中軸上部了， ServiceMethod ， build OkHttpCall， CallAdapter adapt。

2.4 ServiceMethod

ServiceMethod<T> 類的作用正如其 JavaDoc所言：

Adapts an invocation of an interface method into an HTTP call. 把對(duì)接口方法的調(diào)用轉(zhuǎn)為一次 HTTP 調(diào)用。

一個(gè) ServiceMethod 對(duì)象對(duì)應(yīng)于一個(gè) API interface 的一個(gè)方法， loadServiceMethod(method) 方法負(fù)責(zé)加載 ServiceMethod ：

  ServiceMethod loadServiceMethod(Method method) { 
     ServiceMethod result; 
     synchronized (serviceMethodCache) { 
        result = serviceMethodCache.get(method); 
        if (result == null) { 
            result = new ServiceMethod.Builder(this, method).build(); 
            serviceMethodCache.put(method, result); 
        }
   }
   return result; 
  }

這里實(shí)現(xiàn)了緩存邏輯，同一個(gè) API 的同一個(gè)方法，只會(huì)創(chuàng)建一次。這里由于我們每次獲取 API 實(shí)例都是傳入的 class 對(duì)象，而 class 對(duì)象是進(jìn)程內(nèi)單例的，所以獲取到它的同一個(gè)方法 Method 實(shí)例也是單例的，所以這里的緩存是有效的。

我們?cè)倏纯?ServiceMethod 的構(gòu)造函數(shù)：

  ServiceMethod(Builder<T> builder) { 
    this.callFactory = builder.retrofit.callFactory(); 
    this.callAdapter = builder.callAdapter; 
    this.baseUrl = builder.retrofit.baseUrl(); 
    this.responseConverter = builder.responseConverter; 
    this.httpMethod = builder.httpMethod; 
    this.relativeUrl = builder.relativeUrl; 
    this.headers = builder.headers; 
    this.contentType = builder.contentType; 
    this.hasBody = builder.hasBody; 
    this.isFormEncoded = builder.isFormEncoded; 
    this.isMultipart = builder.isMultipart; 
    this.parameterHandlers = builder.parameterHandlers;
   }

成員很多，但這里我們重點(diǎn)關(guān)注四個(gè)成員： callFactory， callAdapter ， responseConverter 和 parameterHandlers 。

callFactory 負(fù)責(zé)創(chuàng)建 HTTP 請(qǐng)求，HTTP 請(qǐng)求被抽象為了okhttp3.Call 類，它表示一個(gè)已經(jīng)準(zhǔn)備好，可以隨時(shí)執(zhí)行的 HTTP 請(qǐng)求；
callAdapter 把 retrofit2.Call<T>轉(zhuǎn)為 T （注意和 okhttp3.Call 區(qū)分開(kāi)來(lái)，retrofit2.Call<T>表示的是對(duì)一個(gè) Retrofit 方法的調(diào)用），這個(gè)過(guò)程會(huì)發(fā)送一個(gè) HTTP 請(qǐng)求，拿到服務(wù)器返回的數(shù)據(jù)（通過(guò) okhttp3.Call實(shí)現(xiàn)），并把數(shù)據(jù)轉(zhuǎn)換為聲明的 T 類型對(duì)象（通過(guò) Converter<F, T> 實(shí)現(xiàn)）；
responseConverter 是 Converter<ResponseBody, T> 類型，負(fù)責(zé)把服務(wù)器返回的數(shù)據(jù)（JSON、XML、二進(jìn)制或者其他格式，由 ResponseBody封裝）轉(zhuǎn)化為 T 類型的對(duì)象；
parameterHandlers 則負(fù)責(zé)解析 API 定義時(shí)每個(gè)方法的參數(shù)，并在構(gòu)造 HTTP 請(qǐng)求時(shí)設(shè)置參數(shù)；

它們的使用稍后再分析，這里先看看它們的創(chuàng)建（代碼比較分散，就不貼太多代碼了，大多是結(jié)論）：

2.4.1 `callFactory`

this.callFactory = builder.retrofit.callFactory()，所以 callFactory 實(shí)際上由 Retrofit 類提供，而我們?cè)跇?gòu)造 Retrofit 對(duì)象時(shí)，可以指定 callFactory，如果不指定，將默認(rèn)設(shè)置為一個(gè) okhttp3.OkHttpClient。

2.4.2 `callAdapter`

  private CallAdapter<?> createCallAdapter() { 
    // 省略檢查性代碼 
    Annotation[] annotations = method.getAnnotations(); 
    try { 
      return retrofit.callAdapter(returnType, annotations); 
    } catch (RuntimeException e) { 
      // Wide exception range because factories are user code. 
     throw methodError(e, "Unable to create call adapter for %s", returnType); 
   }
  }

可以看到， callAdapter 還是由 Retrofit 類提供。在 Retrofit 類內(nèi)部，將遍歷一個(gè) CallAdapter.Factory 列表，讓工廠們提供，如果最終沒(méi)有工廠能（根據(jù) returnType 和 annotations ）提供需要的 CallAdapter ，那將拋出異常。而這個(gè)工廠列表我們可以在構(gòu)造 Retrofit 對(duì)象時(shí)進(jìn)行添加。

2.4.3， `responseConverter`

  private Converter<ResponseBody, T> createResponseConverter() { 
    Annotation[] annotations = method.getAnnotations(); 
    try { 
     return retrofit.responseBodyConverter(responseType, annotati ons); 
    } catch (RuntimeException e) { 
     // Wide exception range because factories are user code. 
    throw methodError(e, "Unable to create converter for %s", re sponseType); 
    } 
  }

同樣， responseConverter 還是由 Retrofit 類提供，而在其內(nèi)部，邏輯和創(chuàng) 建 callAdapter 基本一致，通過(guò)遍歷 Converter.Factory列表，看看有沒(méi)有工廠能夠提供需要的 responseBodyConverter。工廠列表同樣可以在構(gòu)造 Retrofit 對(duì)象時(shí)進(jìn)行添加。

2.4.4 `parameterHandlers`

每個(gè)參數(shù)都會(huì)有一個(gè) ParameterHandler ，由 ServiceMethod#parseParameter 方法負(fù)責(zé)創(chuàng)建，其主要內(nèi)容就是解析每個(gè)參數(shù) 使用的注解類型（諸如 Path ， Query ， Field 等），對(duì)每種類型進(jìn)行單獨(dú)的處理。構(gòu)造 HTTP 請(qǐng)求時(shí)，我們傳遞的參數(shù)都是字符串，那 Retrofit 是如何把我們傳遞的各種參數(shù)都轉(zhuǎn)化為 String 的呢？還是由 Retrofit 類提供 converter！

Converter.Factory 除了提供上一小節(jié)提到的 responseBodyConverter，還提供 requestBodyConverter 和 stringConverter，API 方法中除了 @Body 和 @Part 類型的參數(shù)，都利用 stringConverter 進(jìn)行轉(zhuǎn)換，而 @Body 和 @Part 類型的參數(shù)則利用 requestBodyConverter 進(jìn)行轉(zhuǎn)換。

這三種 converter 都是通過(guò)“詢問(wèn)”工廠列表進(jìn)行提供，而工廠列表我們可以在構(gòu)造 Retrofit 對(duì)象時(shí)進(jìn)行添加。

2.4.5 工廠讓各個(gè)模塊得以高度解耦

上面提到了三種工廠： okhttp3.Call.Factory ， CallAdapter.Factory 和 Converter.Factory ，分別負(fù)責(zé)提供不同的模塊，至于怎么提供、提供何種模塊，統(tǒng)統(tǒng)交給工廠，Retrofit 完全不摻和，它只負(fù)責(zé)提供用于決策的信息，例如參數(shù)/返回值類型、注解等。

這不正是我們苦苦追求的高內(nèi)聚低耦合效果嗎？解耦的第一步就是面向接口編程，模塊之間、類之間通過(guò)接口進(jìn)行依賴，創(chuàng)建怎樣的實(shí)例，則交給工廠負(fù)責(zé)，工廠同樣也是接口，添加（Retrofit doc 中使用 install 安裝一詞，非常貼切）怎樣的工廠，則在最初構(gòu)造 Retrofit 對(duì)象時(shí)決定，各個(gè)模塊之間完全解耦，每個(gè)模塊只專注于自己的職責(zé)，全都是套路，值得反復(fù)玩味、學(xué)習(xí)與模仿。

除了上面重點(diǎn)分析的這四個(gè)成員， ServiceMethod 中還包含了 API 方法的 url 解析等邏輯，包含了眾多關(guān)于泛型和反射相關(guān)的代碼，有類似需求的時(shí)候，也非常值得學(xué)習(xí)模仿

2.5 OkHttpCall

終于把 ServiceMethod 看了個(gè)大概，接下來(lái)我們看看 OkHttpCall 。 OkHttpCall 實(shí)現(xiàn)了 retrofit2.Call ，我們通常會(huì)使用它的 execute() 和 enqueue(Callback<T> callback) 接口。前者用于同步執(zhí)行 HTTP 請(qǐng)求，后者用于異步執(zhí)行。

2.5.1，先看 `execute()`

  @Override 
  public Response<T> execute() throws IOException { 
    okhttp3.Call call; 
    synchronized (this) { 
     // 省略部分檢查代碼 

    call = rawCall;
    if (call == null) { 
      try { 
        call = rawCall = createRawCall(); 
      } catch (IOException | RuntimeException e) { 
        creationFailure = e; 
        throw e; 
     } 
    } 
  }
   return parseResponse(call.execute()); 
   ......
 }

主要包括三步：

創(chuàng)建 okhttp3.Call ，包括構(gòu)造參數(shù)；
執(zhí)行網(wǎng)絡(luò)請(qǐng)求；
解析網(wǎng)絡(luò)請(qǐng)求返回的數(shù)據(jù)；

createRawCall() 函數(shù)中，我們調(diào)用了 serviceMethod.toRequest(args) 來(lái)創(chuàng)建 okhttp3.Request ，而在后者中，我們之前準(zhǔn)備好的 parameterHandlers 就派上了用場(chǎng)。

然后我們?cè)僬{(diào)用 serviceMethod.callFactory.newCall(request) 來(lái)創(chuàng)建 okhttp3.Call ，這里之前準(zhǔn)備好的 callFactory 同樣也派上了用場(chǎng)，由于工廠在構(gòu)造 Retrofit 對(duì)象時(shí)可以指定，所以我們也可以指定其他的工廠（例如使用過(guò)時(shí)的 HttpURLConnection 的工廠），來(lái)使用其它的底層 HttpClient 實(shí)現(xiàn)。

我們調(diào)用 okhttp3.Call#execute() 來(lái)執(zhí)行網(wǎng)絡(luò)請(qǐng)求，這個(gè)方法是阻塞的，執(zhí)行完畢之后將返回收到的響應(yīng)數(shù)據(jù)。收到響應(yīng)數(shù)據(jù)之后，我們進(jìn)行了狀態(tài)碼的檢查，通過(guò)檢查之后我們調(diào)用了 serviceMethod.toResponse(catchingBody) 來(lái)把響應(yīng)數(shù)據(jù)轉(zhuǎn)化為了我們需要的數(shù)據(jù)類型對(duì)象。在 toResponse 函數(shù)中，我們之前準(zhǔn) 備好的 responseConverter 也派上了用場(chǎng)。

好了，之前準(zhǔn)備好的東西都派上了用場(chǎng)，還好沒(méi)有白費(fèi) :)

2.5.2 再看 `enqueue(Callback<T> callback)`

這里的異步交給了 okhttp3.Call#enqueue(Callback responseCallback) 來(lái) 實(shí)現(xiàn)，并在它的 callback 中調(diào)用 parseResponse 解析響應(yīng)數(shù)據(jù)，并轉(zhuǎn)發(fā)給傳入的 callback。

2.6 `CallAdapter`

終于到了最后一步了， CallAdapter<T>#adapt(Call<R> call) 函數(shù)負(fù)責(zé)把 retrofit2.Call<R> 轉(zhuǎn)為 T 。這里 T 當(dāng)然可以就是 retrofit2.Call<R> ，這時(shí)我們直接返回參數(shù)就可以了，實(shí)際上這正是 DefaultCallAdapterFactory創(chuàng)建的 CallAdapter 的行為。至于其他類型的工廠返回的 CallAdapter 的行為，這里暫且不表，后面再單獨(dú)分析。

至此，一次對(duì) API 方法的調(diào)用是如何構(gòu)造并發(fā)起網(wǎng)絡(luò)請(qǐng)求、以及解析返回?cái)?shù)據(jù)，這整個(gè)過(guò)程大致是分析完畢了。對(duì)整個(gè)流程的概覽非常重要，結(jié)合 stay 畫(huà)的流程圖，應(yīng)該能夠比較輕松地看清整個(gè)流程了。

雖然我們還沒(méi)分析完，不過(guò)也相當(dāng)于到了萬(wàn)里長(zhǎng)征的遵義，終于可以舒一口氣了 :)

三、retrofit-adapters 模塊

retrofit 模塊內(nèi)置了 DefaultCallAdapterFactory 和 ExecutorCallAdapterFactory ，它們都適用于 API 方法得到的類型為 retrofit2.Call 的情形，前者生產(chǎn)的 adapter 啥也不做，直接把參數(shù)返回，后者生產(chǎn)的 adapter 則會(huì)在異步調(diào)用時(shí)在指定的 Executor 上執(zhí)行回調(diào)。

retrofit-adapters 的各個(gè)子模塊則實(shí)現(xiàn)了更多的工廠： GuavaCallAdapterFactory ， Java8CallAdapterFactory 和 RxJavaCallAdapterFactory 。這里我主要分析 RxJavaCallAdapterFactory ，下面的內(nèi)容就需要一些 RxJava 的知識(shí)了，不過(guò) 我想使用 Retrofit 的你，肯定也在使用RxJava :)

RxJavaCallAdapterFactory#get 方法中對(duì)返回值的類型進(jìn)行了檢查，只支持 rx.Single ， rx.Completable 和 rx.Observable ，這里我主要關(guān)注對(duì) rx.Observable 的支持。

RxJavaCallAdapterFactory#getCallAdapter 方法中對(duì)返回值的泛型類型進(jìn)行了進(jìn)一步檢查，例如我們聲明的返回值類型為 Observable<List<Repo>>，泛型類型就是 List<Repo> ，這里對(duì) retrofit2.Response 和retrofit2.adapter.rxjava.Result 進(jìn)行了特殊處理，有單獨(dú)的 adapter 負(fù)責(zé) 進(jìn)行轉(zhuǎn)換，其他所有類型都由 SimpleCallAdapter負(fù)責(zé)轉(zhuǎn)換。

那我們就來(lái)看看 SimpleCallAdapter#adapt ：

  @Override 
  public <R> Observable<R> adapt(Call<R> call) { 
    Observable<R> observable = Observable.create(new CallOnSubscri be<>(call)) 
       .lift(OperatorMapResponseToBodyOrError.<R>instance()); if (scheduler != null) { 
      return observable.subscribeOn(scheduler); 
    }
    return observable; 
  }

這里創(chuàng)建了一個(gè) Observable ，它的邏輯由 CallOnSubscribe 類實(shí)現(xiàn)，同時(shí)使用了一個(gè) OperatorMapResponseToBodyOrError 操作符，用來(lái)把 retrofit2.Response 轉(zhuǎn)為我們聲明的類型，或者錯(cuò)誤異常類型。

我們接著看 CallOnSubscribe#call ：

  @Override 
  public void call(final Subscriber<? super Response<T>> subscribe r) {
    // Since Call is a one-shot type, clone it for each new subscr iber. 
    Call<T> call = originalCall.clone(); 
   // Wrap the call in a helper which handles both unsubscription and backpressure. 
   RequestArbiter<T> requestArbiter = new  RequestArbiter<>(call, subscriber); 
   subscriber.add(requestArbiter); 
   subscriber.setProducer(requestArbiter); 
  }

代碼很簡(jiǎn)短，只干了三件事：

clone 了原來(lái)的 call，因?yàn)?okhttp3.Call 是只能用一次的，所以每次都是新 clone 一個(gè)進(jìn)行網(wǎng)絡(luò)請(qǐng)求；
創(chuàng)建了一個(gè)叫做 RequestArbiter 的 producer，別被它的名字嚇懵了，它就是個(gè) producer；
把這個(gè) producer設(shè)置給 subscriber；

簡(jiǎn)言之，大部分情況下 Subscriber 都是被動(dòng)接受 Observable push 過(guò)來(lái)的數(shù)據(jù)，但要是 Observable 發(fā)得太快，Subscriber 處理不過(guò)來(lái)，那就有問(wèn)題了，所以就有了一種 Subscriber 主動(dòng) pull 的機(jī)制，而這種機(jī)制就是通過(guò) Producer 實(shí)現(xiàn)的。給 Subscriber 設(shè)置 Producer 之后（通過(guò) Subscriber#setProducer 方法）， Subscriber 就會(huì)通過(guò) Producer 向上游根據(jù)自己的能力請(qǐng)求數(shù)據(jù)（通過(guò) Producer#request 方法），而 Producer 收到請(qǐng)求之后（通常都是 Observable 管理 Producer，所以“相當(dāng)于”就是 Observable 收到了請(qǐng)求），再根據(jù)請(qǐng)求的量給 Subscriber 發(fā)數(shù)據(jù)。

那我們就看看 RequestArbiter#request：

  @Override 
  public void request(long n) { 
     if (n < 0) throw new IllegalArgumentException("n < 0: " + n); 
     if (n == 0) return; // Nothing to do when requesting 0. 
     if (!compareAndSet(false, true)) return; // Request was alread y triggered. 
     try { 
       Response<T> response = call.execute(); 
       if (!subscriber.isUnsubscribed()) { 
         subscriber.onNext(response); 
       } 
     } catch (Throwable t) { 
       Exceptions.throwIfFatal(t); 
       if (!subscriber.isUnsubscribed()) { 
         subscriber.onError(t); 
       }
       return; 
     }

    if (!subscriber.isUnsubscribed()) { 
       subscriber.onCompleted(); 
    } 
   }

producer 相關(guān)的邏輯非常簡(jiǎn)單，這里就不在贅述。實(shí)際干活的邏輯就是執(zhí)行 call.execute() ，并把返回值發(fā)送給下游。

而 OperatorMapResponseToBodyOrError#call 也相當(dāng)簡(jiǎn)短：

  @Override 
  public Subscriber<? super Response<T>> call(final Subscriber<? s uper T> child) { 
    return new Subscriber<Response<T>>(child) { 
       @Override 
       public void onNext(Response<T> response) { 
         if (response.isSuccessful()) { 
          child.onNext(response.body()); 
         } else { 
          child.onError(new HttpException(response)); 
        } 
      }

      @Override 
      public void onCompleted() { 
         child.onCompleted(); 
      }

      @Override
      public void onError(Throwable e) { 
         child.onError(e); 
      } 
    }; 
  }

關(guān)鍵就是調(diào)用了 response.body() 并發(fā)送給下游。這里， body() 返回的就是我們聲明的泛型類型了，至于 Retrofit 是怎么把服務(wù)器返回的數(shù)據(jù)轉(zhuǎn)為我們聲明的類型的，這就是 responseConverter 的事了，還記得嗎？

最后看一張返回 Observable 時(shí)的調(diào)用棧：

執(zhí)行路徑就是：

Observable.subscribe ，觸發(fā) API 調(diào)用的執(zhí)行；
CallOnSubscribe#call ，clone call，創(chuàng)建并設(shè)置 producer；
RequestArbiter#request ，subscriber 被設(shè)置了 producer 之后最終調(diào)用 request，在 request 中發(fā)起請(qǐng)求，把結(jié)果發(fā)給下游；
OperatorMapResponseToBodyOrError$1#onNext ，把 response的 body 發(fā) 給下游；
最終就到了我們subscribe 時(shí)傳入的回調(diào)里面了；

四、retrofit-converters 模塊

retrofit 模塊內(nèi)置了 BuiltInConverters ，只能處理 ResponseBody ， RequestBody 和 String 類型的轉(zhuǎn)化（實(shí)際上不需要轉(zhuǎn)）。而 retrofit- converters 中的子模塊則提供了 JSON，XML，ProtoBuf 等類型數(shù)據(jù)的轉(zhuǎn)換功能，而且還有多種轉(zhuǎn)換方式可以選擇。這里我主要關(guān)注 GsonConverterFactory 。

代碼非常簡(jiǎn)單：

  @Override 
  public Converter<ResponseBody, ?> responseBodyConverter(Type typ e, Annotation[] annotations, Retrofit retrofit) { 
    TypeAdapter<?> adapter = gson.getAdapter(TypeToken.get(type)); 
    return new GsonResponseBodyConverter<>(gson, adapter); 
  }

  final class GsonResponseBodyConverter<T> implements Converter<Re sponseBody, T> { 
    private final Gson gson; 
    private final TypeAdapter<T> adapter; 

    GsonResponseBodyConverter(Gson gson, TypeAdapter<T> adapter) { 
      this.gson = gson; 
      this.adapter = adapter; 
    }

    @Override public T convert(ResponseBody value) throws IOExcept ion {
      JsonReader jsonReader = gson.newJsonReader(value.charStream( )); 
      try { 
        return adapter.read(jsonReader); } finally { 
           value.close(); 
           } 
       } 
  }

根據(jù)目標(biāo)類型，利用 Gson#getAdapter 獲取相應(yīng)的 adapter，轉(zhuǎn)換時(shí)利用 Gson 的 API 即可。

當(dāng)前標(biāo)題：Retrofit使用方法
當(dāng)前鏈接：http://redsoil1982.com.cn/article8/gsoeop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、品牌網(wǎng)站制作、全網(wǎng)營(yíng)銷推廣、自適應(yīng)網(wǎng)站、面包屑導(dǎo)航、網(wǎng)站設(shè)計(jì)公司

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容

Retrofit使用方法

一、整體思路

二、基本用例

2.1 創(chuàng)建 Retrofit 對(duì)象

2.2 定義 API 并獲取 API 實(shí)例

2.3 調(diào)用 API 方法

2.4 ServiceMethod

2.4.1 callFactory

2.4.2 callAdapter

2.4.3， responseConverter

2.4.4 parameterHandlers