轉載請標明出處:
http://blog.csdn.net/lmj623565791/article/details/51304204;
本文出自:【張鴻洋的博客】
一、概述
之前寫了個okhttputils的工具類,然後有很多同學詢問這個工具類和retrofit
什麼區別,於是上了下官網,發現其底層對網絡的訪問默認也是基於okhttp
,不過retrofit
非常適合於restful
url
格式的請求,更多使用註解的方式提供功能。
既然這樣,我們本篇博文首先研究其所提供的常用的用法:
- 一般的get、post請求
- 動態url,動態參數設置,各種註解的使用
- 上傳文件(單文件,多文件上傳等)
- 下載文件等(這個不推薦retrofit去做,具體看下文)
此外,由於其內部提供了ConverterFactory
用於對返回的requestBody
進行轉化和特殊的requestBody
的構造,所以本文也包含:
- 如何自定義
ConverterFactory
最後呢,因爲其源碼並不複雜,本文將對源碼進行整體的介紹,即
- retrofit 源碼分析
ok,說這麼多,既然需要restful url
,我只能撿起我那個半桶水的spring mvc
搭建一個服務端的小例子~~
最後本文使用版本:
- 1
- 1
主要是源碼解析,自定義Converter.Factory
等一些細節的探索。
恩,寫完後,發現本文很長,中途請沒事站起來走兩步。
retrofit2官網地址:https://github.com/square/retrofit/
二、retrofit 用法示例
二、retrofit 用法示例
(1)一般的get請求
retrofit
在使用的過程中,需要定義一個接口對象,我們首先演示一個最簡單的get請求,接口如下所示:
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
可以看到有一個getUsers()方法,通過@GET
註解標識爲get請求,@GET
中所填寫的value和baseUrl
組成完整的路徑,baseUrl
在構造retrofit對象時給出。
下面看如何通過retrofit
完成上述的請求:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
依然是構造者模式,指定了baseUrl
和Converter.Factory
,該對象通過名稱可以看出是用於對象轉化的,本例因爲服務器返回的是json格式的數組,所以這裏設置了GsonConverterFactory
完成對象的轉化。
ok,這裏可以看到很神奇,我們通過Retrofit.create
就可以拿到我們定義的IUserBiz
的實例,調用其方法即可拿到一個Call
對象,通過call.enqueue
即可完成異步的請求。
具體retrofit怎麼得到我們接口的實例的,以及對象的返回結果是如何轉化的,我們後面具體分析。
這裏需要指出的是:
- 接口中的方法必須有返回值,且比如是
Call<T>
類型 -
.addConverterFactory(GsonConverterFactory.create())
這裏如果使用gson,需要額外導入:compile 'com.squareup.retrofit2:converter-gson:2.0.2'
當然除了gson以外,還提供了以下的選擇:
Gson: com.squareup.retrofit2:converter-gson Jackson: com.squareup.retrofit2:converter-jackson Moshi: com.squareup.retrofit2:converter-moshi Protobuf: com.squareup.retrofit2:converter-protobuf Wire: com.squareup.retrofit2:converter-wire Simple XML: com.squareup.retrofit2:converter-simplexml Scalars (primitives, boxed, and String): com.squareup.retrofit2:converter-scalars
當然也支持自定義,你可以選擇自己寫轉化器完成數據的轉化,這個後面將具體介紹。
-
既然
call.enqueue
是異步的訪問數據,那麼同步的訪問方式爲call.execute
,這一點非常類似okhttp的API,實際上默認情況下內部也是通過okhttp3.Call
實現。
那麼,通過這麼一個簡單的例子,應該對retrofit
已經有了一個直觀的認識,下面看更多其支持的特性。
(2)動態的url訪問@PATH
@PATH
文章開頭提過,retrofit
非常適用於restful
url
的格式,那麼例如下面這樣的url:
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
即通過不同的username訪問不同用戶的信息,返回數據爲json字符串。
那麼可以通過retrofit提供的@PATH
註解非常方便的完成上述需求。
我們再定義一個方法:
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
可以看到我們定義了一個getUser方法,方法接收一個username參數,並且我們的@GET
註解中使用{username}
聲明瞭訪問路徑,這裏你可以把{username}
當做佔位符,而實際運行中會通過@PATH("username")
所標註的參數進行替換。
那麼訪問的代碼很類似:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
(3)查詢參數的設置@Query
@Query
看下面的url
- 1
- 2
- 1
- 2
即一般的傳參,我們可以通過@Query
註解方便的完成,我們再次在接口中添加一個方法:
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
訪問的代碼,其實沒什麼寫的:
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
ok,這樣我們就完成了參數的指定,當然相同的方式也適用於POST,只需要把註解修改爲@POST
即可。
對了,我能剛纔學了@PATH
,那麼會不會有這樣嘗試的衝動,對於剛纔的需求,我們這麼寫:
- 1
- 2
- 1
- 2
乍一看別說好像有點感覺,哈,實際上運行是不支持的~估計是@ Path
的定位就是用於url的路徑而不是參數,對於參數還是選擇通過@Query
來設置。
(4)POST請求體的方式向服務器傳入json字符串@Body
@Body
大家都清楚,我們app很多時候跟服務器通信,會選擇直接使用POST方式將json字符串作爲請求體發送到服務器,那麼我們看看這個需求使用retrofit
該如何實現。
再次添加一個方法:
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
提交的代碼其實基本都是一致的:
- 1
- 2
- 3
- 1
- 2
- 3
ok,可以看到其實就是使用@Body
這個註解標識我們的參數對象即可,那麼這裏需要考慮一個問題,retrofit是如何將user對象轉化爲字符串呢?下文將詳細解釋~
下面對應okhttp,還有兩種requestBody,一個是FormBody
,一個是MultipartBody
,前者以表單的方式傳遞簡單的鍵值對,後者以POST表單的方式上傳文件可以攜帶參數,retrofit
也二者也有對應的註解,下面繼續~
(5)表單的方式傳遞鍵值對@FormUrlEncoded
@FormUrlEncoded
這裏我們模擬一個登錄的方法,添加一個方法:
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
訪問的代碼:
- 1
- 2
- 3
- 1
- 2
- 3
ok,看起來也很簡單,通過@POST
指明url,添加FormUrlEncoded
,然後通過@Field
添加參數即可。
(6)單文件上傳@Multipart
@Multipart
下面看一下單文件上傳,依然是再次添加個方法:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 1
- 2
- 3
- 4
- 5
- 6
- 7
這裏@MultiPart
的意思就是允許多個@Part
了,我們這裏使用了3個@Part
,第一個我們準備上傳個文件,使用了MultipartBody.Part
類型,其餘兩個均爲簡單的鍵值對。
使用:
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
ok,這裏感覺略爲麻煩。不過還是蠻好理解~~多個@Part
,每個Part對應一個RequestBody。
這裏插個實驗過程,其實我最初對於文件,也是嘗試的@Part RequestBody
,因爲@Part("key")
,然後傳入一個代表文件的RequestBody
,我覺得更加容易理解,後來發現試驗無法成功,而且查了下issue,給出了一個很奇怪的解決方案,這裏可以參考:retrofit#1063。
給出了一個類似如下的方案:
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
可以看到對於文件的那個@Part
value竟然寫了這麼多奇怪的東西,而且filename竟然硬編碼了~~這個不好吧,我上傳的文件名竟然不能動態指定。
爲了文件名不會被寫死,所以給出了最上面的上傳單文件的方法,ps:上面這個方案經測試也是可以上傳成功的。
恩,這個奇怪方案,爲什麼這麼做可行,下文會給出非常詳細的解釋。
最後看下多文件上傳~
(7)多文件上傳@PartMap
@PartMap
再添加一個方法~~~
- 1
- 2
- 3
- 4
- 5
- 6
- 1
- 2
- 3
- 4
- 5
- 6
這裏使用了一個新的註解@PartMap
,這個註解用於標識一個Map,Map的key爲String類型,代表上傳的鍵值對的key(與服務器接受的key對應),value即爲RequestBody,有點類似@Part
的封裝版本。
執行的代碼:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
可以看到,可以在Map中put進一個或多個文件,鍵值對等,當然你也可以分開,單獨的鍵值對也可以使用@Part
,這裏又看到設置文件的時候,相對應的key很奇怪,例如上例"photos\";
filename=\"icon.png"
,前面的photos就是與服務器對應的key,後面filename是服務器得到的文件名,ok,參數雖然奇怪,但是也可以動態的設置文件名,不太影響使用~~
(8)下載文件
這個其實我覺得直接使用okhttp就好了,使用retrofit去做這個事情真的有點瞎用的感覺~~
增加一個方法:
- 1
- 2
- 1
- 2
調用:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
可以看到可以返回ResponseBody
,那麼很多事都能幹了~~
but,也看出這種方式下載感覺非常雞肋,並且onReponse回調雖然在UI線程,但是你還是要處理io操作,也就是說你在這裏還要另外開線程操作,或者你可以考慮同步的方式下載。
最後還是建議使用okhttp去下載,例如使用okhttputils.
有人可能會問,使用okhttp,和使用retrofit會不會造成新建多個OkHttpClient
對象呢,其實是可設置的,參考下文。
ok,上面就是一些常用的方法,當然還涉及到一些沒有介紹的註解,但是通過上面這麼多方法的介紹,再多一二個註解的使用方式,相信大家能夠解決。
三、配置OkHttpClient
這個需要簡單提一下,很多時候,比如你使用retrofit需要統一的log管理,給每個請求添加統一的header等,這些都應該通過okhttpclient去操作,比如addInterceptor
例如:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
或許你需要更多的配置,你可以單獨寫一個OkhttpClient的單例生成類,在這個裏面完成你所需的所有的配置,然後將OkhttpClient
實例通過方法公佈出來,設置給retrofit。
設置方式:
- 1
- 2
- 3
- 1
- 2
- 3
callFactory
方法接受一個okhttp3.Call.Factory
對象,OkHttpClient
即爲一個實現類。
四、retrofit 源碼解析
ok,接下來我們隊retrofit的源碼做簡單的分析,首先我們看retrofit如何爲我們的接口實現實例;然後看整體的執行流程;最後再看詳細的細節;
(1)retrofit如何爲我們的接口實現實例
通過上文的學習,我們發現使用retrofit需要去定義一個接口,然後可以通過調用retrofit.create(IUserBiz.class);
方法,得到一個接口的實例,最後通過該實例執行我們的操作,那麼retrofit如何實現我們指定接口的實例呢?
其實原理是:動態代理。但是不要被動態代理這幾個詞嚇唬到,Java中已經提供了非常簡單的API幫助我們來實現動態代理。
看源碼前先看一個例子:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
輸出結果爲:
- 1
- 2
- 3
- 1
- 2
- 3
可以看到我們通過Proxy.newProxyInstance
產生的代理類,當調用接口的任何方法時,都會調用InvocationHandler#invoke
方法,在這個方法中可以拿到傳入的參數,註解等。
試想,retrofit也可以通過同樣的方式,在invoke方法裏面,拿到所有的參數,註解信息然後就可以去構造RequestBody
,再去構建Request
,得到Call
對象封裝後返回。
ok,下面看retrofit#create
的源碼:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 1
- 2
- 3
- 4
- 5
- 6
- 7
哈,和上面對應。到這裏,你應該明白retrofit爲我們接口生成實例對象並不神奇,僅僅是使用了Proxy
這個類的API而已,然後在invoke
方法裏面拿到足夠的信息去構建最終返回的Call而已。
哈,其實真正的動態代理一般是有具體的實現類的,只是在這個類調用某個方法的前後去執行一些別的操作,比如開事務,打log等等。當然,本博文並不需要涉及這些詳細的內容,如果你希望詳細去了解,可以搜索關鍵字:Proxy InvocationHandler
。
(2)retrofit整體實現流程
4.2.1 Retrofit的構建
這裏依然是通過構造者模式進行構建retrofit對象,好在其內部的成員變量比較少,我們直接看build()方法。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- baseUrl必須指定,這個是理所當然的;
- 然後可以看到如果不着急設置callFactory,則默認直接
new OkHttpClient()
,可見如果你需要對okhttpclient進行詳細的設置,需要構建OkHttpClient
對象,然後傳入; - 接下來是callbackExecutor,這個想一想大概是用來將回調傳遞到UI線程了,當然這裏設計的比較巧妙,利用platform對象,對平臺進行判斷,判斷主要是利用
Class.forName("")
進行查找,具體代碼已經被放到文末,如果是Android平臺,會自定義一個Executor
對象,並且利用Looper.getMainLooper()
實例化一個handler對象,在Executor
內部通過handler.post(runnable)
,ok,整理憑大腦應該能構思出來,暫不貼代碼了。 - 接下來是adapterFactories,這個對象主要用於對Call進行轉化,基本上不需要我們自己去自定義。
- 最後是converterFactories,該對象用於轉化數據,例如將返回的
responseBody
轉化爲對象等;當然不僅僅是針對返回的數據,還能用於一般備註解的參數的轉化例如@Body
標識的對象做一些操作,後面遇到源碼詳細再描述。
ok,總體就這幾個對象去構造retrofit,還算比較少的~~
4.2.2 具體Call構建流程
我們構造完成retrofit,就可以利用retrofit.create方法去構建接口的實例了,上面我們已經分析了這個環節利用了動態代理,而且我們也分析了具體的Call的構建流程在invoke方法中,下面看代碼:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
主要也就三行代碼,第一行是根據我們的method將其包裝成ServiceMethod,第二行是通過ServiceMethod和方法的參數構造retrofit2.OkHttpCall
對象,第三行是通過serviceMethod.callAdapter.adapt()
方法,將OkHttpCall
進行代理包裝;
下面一個一個介紹:
- ServiceMethod應該是最複雜的一個類了,包含了將一個method轉化爲Call的所有的信息。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
直接看build方法,首先拿到這個callAdapter最終拿到的是我們在構建retrofit裏面時adapterFactories時添加的,即爲:new ExecutorCallbackCall<>(callbackExecutor, call)
,該ExecutorCallbackCall
唯一做的事情就是將原本call的回調轉發至UI線程。
接下來通過callAdapter.responseType()
返回的是我們方法的實際類型,例如:Call<User>
,則返回User
類型,然後對該類型進行判斷。
接下來是createResponseConverter
拿到responseConverter對象,其當然也是根據我們構建retrofit時,addConverterFactory
添加的ConverterFactory對象來尋找一個合適的返回,尋找的依據主要看該converter能否處理你編寫方法的返回值類型,默認實現爲BuiltInConverters
,僅僅支持返回值的實際類型爲ResponseBody
和Void
,也就說明了默認情況下,是不支持Call<User>
這類類型的。
接下來就是對註解進行解析了,主要是對方法上的註解進行解析,那麼可以拿到httpMethod以及初步的url(包含佔位符)。
後面是對方法中參數中的註解進行解析,這一步會拿到很多的ParameterHandler
對象,該對象在toRequest()
構造Request的時候調用其apply方法。
ok,這裏我們並沒有去一行一行查看代碼,其實意義也不太大,只要知道ServiceMethod主要用於將我們接口中的方法
轉化爲一個Request對象
,於是根據我們的接口返回值確定了responseConverter,解析我們方法上的註解拿到初步的url,解析我們參數上的註解拿到構建RequestBody所需的各種信息,最終調用toRequest的方法完成Request的構建。
- 接下來看OkHttpCall的構建,構造函數僅僅是簡單的賦值
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
- 最後一步是
serviceMethod.callAdapter.adapt(okHttpCall)
我們已經確定這個callAdapter是ExecutorCallAdapterFactory.get()
對應代碼爲:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
可以看到adapt
返回的是ExecutorCallbackCall
對象,繼續往下看:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
可以看出ExecutorCallbackCall僅僅是對Call對象進行封裝,類似裝飾者模式,只不過將其執行時的回調通過callbackExecutor進行回調到UI線程中去了。
4.2.3 執行Call
在4.2.2我們已經拿到了經過封裝的ExecutorCallbackCall
類型的call對象,實際上就是我們實際在寫代碼時拿到的call對象,那麼我們一般會執行enqueue
方法,看看源碼是怎麼做的
首先是ExecutorCallbackCall.enqueue
方法,代碼在4.2.2,可以看到除了將onResponse和onFailure回調到UI線程,主要的操作還是delegate完成的,這個delegate實際上就是OkHttpCall對象,我們看它的enqueue方法
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
沒有任何神奇的地方,內部實際上就是okhttp的Call對象,也是調用okhttp3.Call.enqueue
方法。
中間對於okhttp3.Call
的創建代碼爲:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
可以看到,通過serviceMethod.toRequest
完成對request的構建,通過request去構造call對象,然後返回.
中間還涉及一個parseResponse
方法,如果順利的話,執行的代碼如下:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
通過serviceMethod對ResponseBody進行轉化,然後返回,轉化實際上就是通過responseConverter
的convert方法。
- 1
- 2
- 3
- 4
- 1
- 2
- 3
- 4
ok,關於responseConverter
後面還會細說,不用擔心。
到這裏,我們整個源碼的流程分析就差不多了,目的就掌握一個大體的原理和執行流程,瞭解下幾個核心的類。
那麼總結一下:
- 首先構造retrofit,幾個核心的參數呢,主要就是baseurl,callFactory(默認okhttpclient),converterFactories,adapterFactories,excallbackExecutor。
- 然後通過create方法拿到接口的實現類,這裏利用Java的
Proxy
類完成動態代理的相關代理 - 在invoke方法內部,拿到我們所聲明的註解以及實參等,構造ServiceMethod,ServiceMethod中解析了大量的信息,最痛可以通過
toRequest
構造出okhttp3.Request
對象。有了okhttp3.Request
對象就可以很自然的構建出okhttp3.call
,最後calladapter對Call進行裝飾返回。 - 拿到Call就可以執行enqueue或者execute方法了
ok,瞭解這麼多足以。
下面呢,有幾個地方需要注意,一方面是一些特殊的細節;另一方面就是Converter
。
五、retrofit中的各類細節
(1)上傳文件中使用的奇怪value值
第一個問題涉及到文件上傳,還記得我們在單文件上傳那裏所說的嗎?有種類似於hack的寫法,上傳文件是這麼做的?
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
首先我們一點明確,因爲這裏使用了@ Multipart
,那麼我們認爲@Part
應當支持普通的key-value,以及文件。
對於普通的key-value是沒問題的,只需要這樣@Part("username") String username
。
那麼對於文件,爲什麼需要這樣呢?@Part("file_key\"; filename=\"pp.png")
這個value設置的值不用看就會覺得特別奇怪,然而卻可以正常執行,原因是什麼呢?
原因是這樣的:
當上傳key-value的時候,實際上對應這樣的代碼:
- 1
- 2
- 1
- 2
也就是說,我們的@Part
轉化爲了
- 1
- 1
這麼一看,很隨意,只要把key放進去就可以了。
但是,retrofit2並沒有對文件做特殊處理,文件的對應的字符串應該是這樣的
- 1
- 1
與鍵值對對應的字符串相比,多了個;filename="filename.png
,就因爲retrofit沒有做特殊處理,所以你現在看這些hack的做法
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
ok,到這裏我相信你已經理解了,爲什麼要這麼做,而且爲什麼這麼做可以成功!
恩,值得一提的事,因爲這種方式文件名寫死了,我們上文使用的的是@Part MultipartBody.Part file
,可以滿足文件名動態設置,這個方式貌似也是2.0.1的時候支持的。
上述相關的源碼:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
可以看到呢,並沒有對文件做特殊處理,估計下個版本說不定@Part
會多個isFile=true|false
屬性,甚至修改對應形參,然後在這裏做簡單的處理。
ok,最後來到關鍵的ConverterFactory
了~
六、自定義Converter.Factory
(1)responseBodyConverter
關於Converter.Factory
,肯定是通過addConverterFactory
設置的
- 1
- 2
- 3
- 1
- 2
- 3
該方法接受的是一個Converter.Factory factory
對象
該對象呢,是一個抽象類,內部包含3個方法:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
可以看到呢,3個方法都是空方法而不是抽象的方法,也就表明了我們可以選擇去實現其中的1個或多個方法,一般只需要關注requestBodyConverter
和responseBodyConverter
就可以了。
ok,我們先看如何自定義,最後再看GsonConverterFactory.create
的源碼。
先來個簡單的,實現responseBodyConverter
方法,看這個名字很好理解,就是將responseBody進行轉化就可以了。
ok,這裏呢,我們先看一下上述中我們使用的接口:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
不知不覺,方法還蠻多的,假設哈,我們這裏去掉retrofit構造時的GsonConverterFactory.create
,自己實現一個Converter.Factory
來做數據的轉化工作。
首先我們解決responseBodyConverter
,那麼代碼很簡單,我們可以這麼寫:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
使用的時候呢,可以
- 1
- 2
- 3
- 4
- 5
- 1
- 2
- 3
- 4
- 5
ok,這樣的話,就可以完成我們的ReponseBody
到List<User>
或者User
的轉化了。
可以看出,我們這裏用的依然是Gson,那麼有些同學肯定不希望使用Gson就能實現,如果不使用Gson的話,一般需要針對具體的返回類型,比如我們針對返回List<User>
或者User
你可以這麼寫:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
這裏簡單讀取了一個屬性,大家肯定能看懂,這樣就能滿足返回值是Call<List<User>>
或者Call<User>
.
這裏鄭重提醒:如果你針對特定的類型去寫Converter
,一定要在UserConverterFactory#responseBodyConverter
中對類型進行檢查,發現不能處理的類型return
null
,這樣的話,可以交給後面的Converter.Factory
處理,比如本例我們可以按照下列方式檢查:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
好了,到這呢responseBodyConverter
方法告一段落了,謹記就是將reponseBody->返回值返回中的實際類型,例如Call<User>中的User
;還有對於該converter不能處理的類型一定要返回null。
(2)requestBodyConverter
ok,上面接口一大串方法呢,使用了我們的Converter之後,有個方法我們現在還是不支持的。
- 1
- 2
- 1
- 2
ok,這個@Body
需要用到這個方法,叫做requestBodyConverter
,根據參數轉化爲RequestBody
,下面看下我們如何提供支持。
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
然後在UserConverterFactory中複寫requestBodyConverter方法,返回即可:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
這裏偷了個懶,使用Gson將對象轉化爲json字符串了,如果你不喜歡使用框架,你可以選擇拼接字符串,或者反射寫一個支持任何對象的,反正就是對象->json字符串的轉化。最後構造一個RequestBody返回即可。
ok,到這裏,我相信如果你看的細緻,自定義Converter.Factory
是幹嘛的,但是我還是要總結下:
- responseBodyConverter 主要是對應
@Body
註解,完成ResponseBody到實際的返回類型的轉化,這個類型對應Call<XXX>
裏面的泛型XXX,其實@Part
等註解也會需要responseBodyConverter,只不過我們的參數類型都是RequestBody
,由默認的converter處理了。 - requestBodyConverter 完成對象到RequestBody的構造。
- 一定要注意,檢查type如果不是自己能處理的類型,記得return null (因爲可以添加多個,你不能處理return null ,還會去遍歷後面的converter).
七、值得學習的API
其實一般情況下看源碼呢,可以讓我們更好的去使用這個庫,當然在看的過程中如果發現了一些比較好的處理方式呢,是非常值得記錄的。如果每次看別人的源碼都能吸取一定的精華,比你單純的去理解會好很多,因爲你的記憶力再好,源碼解析你也是會忘的,而你記錄下來並能夠使用的優越的代碼,可能用久了就成爲你的代碼了。
我舉個例子:比如retrofit2中判斷當前運行的環境代碼如下,如果下次你有這樣的需求,你也可以這麼寫,甚至源碼中根據不同的運行環境還提供了不同的Executor
都很值得記錄:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28