前言

Retrofit無疑是當(dāng)下最火的網(wǎng)絡(luò)請求庫,與同門師兄Okhttp配合使用,簡直是每個項目的標(biāo)配,因為Okhttp自帶緩存,所以很多人并不關(guān)心其他緩存庫,但是使用過Okhttp緩存的小伙伴,肯定知道Okhttp的緩存必須配合Header使用,比較麻煩,也不夠靈活,所以現(xiàn)在為大家推薦一款專門為Retrifit打造的緩存庫RxCache.

項目地址: RxCache Demo地址: RxCacheSample

簡介

RxCache使用注解來為Retrofit配置緩存信息,內(nèi)部使用動態(tài)代理和Dagger來實現(xiàn),這個庫的資料相對較少,官方教程又是全英文的,這無疑給開發(fā)者增加了使用難度,其實我英文也不好,但是源碼是通用的啊,所以我為大家從源碼的角度來講解此庫,此庫源碼的難點其實都在Dagger注入上,我先為大家講解用法,后面會再寫篇文章講解源碼,在學(xué)習(xí)Dagger的朋友除了建議看看我的MVPArms外,還可以看看這個RxCache的源碼,能學(xué)到很多東西,先給張RxCache的架構(gòu)圖,讓大家嘗嘗鮮,請期待我后面的源碼分析. 

使用

1.定義接口,和Retrofit類似,接口中每個方法和Retrofit接口中的方法一一對應(yīng),每個方法的參數(shù)中必須傳入對應(yīng)Retrofit接口方法的返回值(返回值必須為Observable,否則報錯),另外幾個參數(shù)DynamicKey,DynamicKeyGroup和EvictProvider不是必須的,但是如果要傳入,每個都只能傳入一個對象,否則報錯,這幾個參數(shù)的意義是初學(xué)者最困惑的,后面會分析.

/** 
 * 此為RxCache官方Demo 
 */ 
public interface CacheProviders { 
 
    @LifeCache(duration = 2, timeUnit = TimeUnit.MINUTES) 
    Observable<Reply<List<Repo>>> getRepos(Observable<List<Repo>> oRepos, DynamicKey userName, EvictDynamicKey evictDynamicKey); 
 
    @LifeCache(duration = 2, timeUnit = TimeUnit.MINUTES) 
    Observable<Reply<List<User>>> getUsers(Observable<List<User>> oUsers, DynamicKey idLastUserQueried, EvictProvider evictProvider); 
 
    Observable<Reply<User>> getCurrentUser(Observable<User> oUser, EvictProvider evictProvider); 
}  

2.將接口實例化,和Retrofit構(gòu)建方式類似,將接口通過using方法傳入,返回一個接口的動態(tài)代理對象,調(diào)用此對象的方法傳入對應(yīng)參數(shù)就可以實現(xiàn)緩存了,通過注解和傳入不同的參數(shù)可以實現(xiàn)一些自定義的配置, so easy～

CacheProviders cacheProviders = new RxCache.Builder() 
                .persistence(cacheDir, new GsonSpeaker()) 
                .using(CacheProviders.class);  

詳解

其實RxCache的使用比較簡單,上面的兩步就可以輕松的實現(xiàn)緩存,此庫的的特色主要集中在對緩存的自定義配置,所以我來主要講講那些參數(shù)和注解是怎么回事?

參數(shù)

Observable

此Observable的意義為需要將你想緩存的Retrofit接口作為參數(shù)傳入(返回值必須為Observable),RxCache會在沒有緩存,或者緩存已經(jīng)過期,或者EvictProvider為true時,通過這個Retrofit接口重新請求***的數(shù)據(jù),并且將服務(wù)器返回的結(jié)果包裝成Reply返回,返回之前會向內(nèi)存緩存和磁盤緩存中各保存一份.

值得一提的是,如果需要知道返回的結(jié)果是來自哪里(本地,內(nèi)存還是網(wǎng)絡(luò)),是否加密,則可以使用Observable<Reply<List<Repo>>>作為方法的返回值,這樣RxCache則會使用Reply包裝結(jié)果,如果沒這個需求則直接在范型中聲明結(jié)果的數(shù)據(jù)類型Observable<List<Repo>>

例外

如果構(gòu)建RxCache的時候?qū)seExpiredDataIfLoaderNotAvailable設(shè)置成true,會在數(shù)據(jù)為空或者發(fā)生錯誤時,忽視EvictProvider為true或者緩存過期的情況,繼續(xù)使用緩存(前提是之前請求過有緩存).

DynamicKey & DynamicKeyGroup

有很多開發(fā)者最困惑的就是這兩個參數(shù)的意義,兩個一起傳以及不傳會有影響嗎?說到這里就要提下,RxCache是怎么存儲緩存的,RxCache并不是通過使用URL充當(dāng)標(biāo)識符來儲存和獲取緩存的.

那是什么呢?

沒錯RxCache就是通過這兩個對象加上上面CacheProviders接口中聲明的方法名,組合起來一個標(biāo)識符,通過這個標(biāo)識符來存儲和獲取緩存.

標(biāo)識符規(guī)則為:

方法名 + $d$d$d$" + dynamicKey.dynamicKey + "$g$g$g$" + DynamicKeyGroup.group

dynamicKey或DynamicKeyGroup為空時則返回空字符串,即什么都不傳的標(biāo)識符為:

"方法名$d$d$d$$g$g$g$"

什么意思呢?

比如RxCache,的內(nèi)存緩存使用的是Map,它就用這個標(biāo)識符作為Key,put和get數(shù)據(jù)(本地緩存則是將這個標(biāo)識符作為文件名,使用流寫入或讀取這個文件,來儲存或獲取緩存),如果儲存和獲取的標(biāo)識符不一致那就取不到想取的緩存.

和我們有什么關(guān)系呢?

舉個例子,我們一個接口具有分頁功能,我們使用RxCache給他設(shè)置了3分鐘的緩存,如果這兩個對象都不傳入?yún)?shù)中,它會默認(rèn)使用這個接口的方法名去存儲和獲取緩存,意思是我們之前使用這個接口獲取到了***頁的數(shù)據(jù),三分鐘以內(nèi)多次調(diào)用這個接口,請求其他分頁的數(shù)據(jù),它返回的緩存還是***頁的數(shù)據(jù),直到緩存過期,所以我們現(xiàn)在想具備分頁功能,必須傳入DynamicKey,DynamicKey內(nèi)部存儲有一個key,我們在構(gòu)建的時候傳入頁數(shù),RxCache將會根據(jù)不同的頁數(shù)分別保存一份緩存,它內(nèi)部做的事就是將方法名+DynamicKey變成一個String類型的標(biāo)識符去獲取和存儲緩存.

DynamicKey和DynamicKeyGroup有什么關(guān)系呢?

DynamicKey存儲有一個Key,DynamicKey的應(yīng)用場景: 請求同一個接口,需要參照一個變量的不同返回不同的數(shù)據(jù),比如分頁,構(gòu)造時傳入頁數(shù)就可以了.

DynamicKeyGroup存儲有兩個key,DynamicKeyGroup是在DynamicKey基礎(chǔ)上的加強版,應(yīng)用場景:請求同一個接口不僅需要分頁,每頁又需要根據(jù)不同的登錄人返回不同的數(shù)據(jù),這時候構(gòu)造DynamicKeyGroup時,在構(gòu)造函數(shù)中***個參數(shù)傳頁數(shù),第二個參數(shù)傳用戶標(biāo)識符就可以了.

理論上DynamicKey和DynamicKeyGroup根據(jù)不同的需求只用傳入其中一個即可,但是也可以兩個參數(shù)都傳,以上面的需求為例,兩個參數(shù)都傳的話,它會先取DynamicKey的Key(頁數(shù))然后再取DynamicKeyGroup的第二個Key(用戶標(biāo)識符),加上接口名組成標(biāo)識符,來獲取和存儲數(shù)據(jù),這樣就會忽略DynamicKeyGroup的***個Key(頁數(shù)).

EvictProvider & EvictDynamicKey & EvictDynamicKeyGroup

這三個對象內(nèi)部都保存有一個boolean類型的字段,其意思為是否驅(qū)逐(使用或刪除)緩存,RxCache在取到未過期的緩存時,會根據(jù)這個boolean字段,考慮是否使用這個緩存,如果為true,就會重新通過Retrofit獲取新的數(shù)據(jù),如果為false就會使用這個緩存.

這三個對象有什么關(guān)系呢?

這三個對象是相互繼承關(guān)系,繼承關(guān)系為EvictProvider < EvictDynamicKey < EvictDynamicKeyGroup,這三個對象你只能傳其中的一個,多傳一個都會報錯,按理說你不管傳那個對象都一樣,因為里面都保存有一個boolean字段,根據(jù)這個字段判斷是否使用緩存.

不同在哪呢?

如果有未過期的緩存,并且里面的boolean為false時,你傳這三個中的哪一個都是一樣的,但是在boolean為true時,這時就有區(qū)別了,RxCache會在Retrofit請求到新數(shù)據(jù)后,在boolean為true時刪除對應(yīng)的緩存.

刪除規(guī)則是什么呢?

還是以請求一個接口,該接口的數(shù)據(jù)會根據(jù)不同的分頁返回不同的數(shù)據(jù),并且同一個分頁還要根據(jù)不同用戶顯示不同的數(shù)據(jù)為例

三個都不傳,RxCache會自己new EvictProvider(false);,這樣默認(rèn)為false就不會刪除任何緩存

EvictDynamicKeyGroup 只會刪除對應(yīng)分頁下,對應(yīng)用戶的緩存.

EvictDynamicKey 會刪除那個分頁下的所有緩存,比如你請求的是***頁下user1的數(shù)據(jù),它不僅會刪除user1的數(shù)據(jù)還會刪除當(dāng)前分頁下其他user2,user3...的數(shù)據(jù).

EvictProvider 會刪除當(dāng)前接口下的所有緩存,比如你請求的是***頁的數(shù)據(jù),它不僅會刪除***頁的數(shù)據(jù),還會把這個接口下其他分頁的數(shù)據(jù)全刪除.

所以你可以根據(jù)自己的邏輯選擇傳那個對象,如果請求的這個接口沒有分頁功能,這時你不想使用緩存,按理說你應(yīng)該傳EvictProvider,并且在構(gòu)造時傳入true,但是你如果傳EvictDynamicKey和EvictDynamicKeyGroup達到的效果也是一樣.

注解

@LifeCache

@LifeCache顧名思義,則是用來定義緩存的生命周期,當(dāng)Retrofit獲取到***的數(shù)據(jù)時,會將數(shù)據(jù)及數(shù)據(jù)的配置信息封裝成Record,在本地和內(nèi)存中各保存一份,Record中則保存了@LifeCache的值(毫秒)和當(dāng)前數(shù)據(jù)請求成功的時間(毫秒)timeAtWhichWasPersisted.

以后每次取緩存時,都會判斷timeAtWhichWasPersisted+@LifeCache的值是否小于當(dāng)前時間(毫秒),小于則過期,則會立即清理當(dāng)前緩存,并使用Retrofit重新請求***的數(shù)據(jù),如果EvictProvider為true不管緩存是否過期都不會使用緩存.

@EncryptKey & @Encrypt

這兩個注解的作用都是用來給緩存加密,區(qū)別在于作用域不一樣

@EncryptKey是作用在接口上

@EncryptKey("123")public interface CacheProviders { 
 
}  

而@Encrypt是作用在方法上

@EncryptKey("123")public interface CacheProviders {    @Encrypt 
   Observable<Reply<User>> getCurrentUser(Observable<User> oUser, EvictProvider evictProvider); 
} 
}  

如果需要給某個接口的緩存做加密的操作,則在對應(yīng)的方法上加上@Encrypt,在存儲和獲取緩存時,RxCache就會使用@EncryptKey的值作為Key給緩存數(shù)據(jù)進行加解密,因此每個Interface中的所有的方法都只能使用相同的Key.

值得注意的時,RxCache只會給本地緩存進行加密操作,并不會給內(nèi)存緩存進行加密,給本地數(shù)據(jù)加密使用的是Java自帶的CipherInputStream,解密使用的是CipherOutputStream

@Expirable

還記得我們在構(gòu)建RxCache時,有一個setMaxMBPersistenceCache方法,這個可以設(shè)置,本地緩存的***容量,單位為MB,如果沒設(shè)置則默認(rèn)為100MB.

這個***容量和@Expirable又有什么關(guān)系呢?

當(dāng)然有!還記得我之前說過在每次Retrofit重新獲取***數(shù)據(jù)時,返回數(shù)據(jù)前會將***數(shù)據(jù)在內(nèi)存緩存和本地緩存中各存一份.

存儲完畢后,會檢查現(xiàn)在的本地緩存大小,如果現(xiàn)在本地緩存中存儲的所有緩存大小加起來大于或者等于setMaxMBPersistenceCache中設(shè)置的大小(默認(rèn)為100MB)的百分之95,RxCache就會做一些操作,將總的緩存大小控制在百分之70以下.

做的什么操作?

很簡單,RxCache會遍歷,構(gòu)建RxCache時傳入的cacheDirectory中的所有緩存數(shù)據(jù),一個個刪除直到總大小小于百分70,遍歷的順序不能保證,所以搞不好對你特別重要的緩存就被刪除了,這時@Expirable就派上用場了,在方法上使用它并且給它設(shè)置為false(如果沒使用這個注解,則默認(rèn)為true),就可以保證這個接口的緩存數(shù)據(jù),在每次需要清理時都幸免于難.

@Expirable(false) 
   Observable<Reply<User>> getCurrentUser(Observable<User> oUser, EvictProvider evictProvider);  

值得注意的是: 構(gòu)建RxCache時persistence方法傳入的cacheDirectory,是用來存放RxCache本地緩存的文件夾,這個文件夾里***不要有除RxCache之外的任何數(shù)據(jù),這樣會在每次需要遍歷清理緩存時,節(jié)省不必要的開銷,因為RxCache并沒檢查文件名,不管是不是自己的緩存,他都會去遍歷獲取

@SchemeMigration & @Migration

這兩個注解是用來數(shù)據(jù)遷移的,用法:

@SchemeMigration({ 
            @Migration(version = 1, evictClasses = {Mock.class}), 
            @Migration(version = 2, evictClasses = {Mock2.class}) 
    }) 
interface Providers {}  

什么叫數(shù)據(jù)遷移呢?

簡單的說就是在***的版本中某個接口返回值類型內(nèi)部發(fā)生了改變,從而獲取數(shù)據(jù)的方式發(fā)生了改變,但是存儲在本地的數(shù)據(jù),是未改變的版本,這樣在反序列化時就可能發(fā)生錯誤,為了規(guī)避這個風(fēng)險,作者就加入了數(shù)據(jù)遷移的功能.

有什么應(yīng)用場景呢?

可能上面的話,不是很好理解,舉個非常簡單的例子:

public class Mock{ 
    private int id; 
}  

Mock里面有一個字段id,現(xiàn)在是一個整型int,能滿足我們現(xiàn)在的需求,但是隨著產(chǎn)品的迭代,發(fā)現(xiàn)int不夠用了

public class Mock{ 
    private long id; 
}  

為了滿足現(xiàn)在的需求,我們使用long代替int,由于緩存中的Mock還是之前未改變的版本,并且未過期,在使用本地緩存時會將數(shù)據(jù)反序列化,將int變?yōu)閘ong,就會出現(xiàn)問題.

數(shù)據(jù)遷移是怎么解決上面的問題呢?

其實非常簡單,就是使用注解聲明,之前有緩存并且內(nèi)部修改過的class,RxCache會把含有這些class的緩存全部清除掉.

RxCache是怎么操作的呢?

值得一提的是,在每次創(chuàng)建接口的動態(tài)代理時,也就是在每次調(diào)用RxCache.using(CacheProviders.class)時,會執(zhí)行兩個操作,清理含有@Migration中聲明的evictClasses的緩存,以及遍歷本地緩存文件夾清理所有已經(jīng)過期的緩存.

每次清理完需要數(shù)據(jù)遷移的緩存時,會將version值***的@Migration的version值保存到本地.

@SchemeMigration({ 
            @Migration(version = 1, evictClasses = {Mock.class}), 
            @Migration(version = 3, evictClasses = {Mock3.class}), 
            @Migration(version = 2, evictClasses = {Mock2.class}) 
    }) 
interface Providers {}  

如上面的聲明方式,它會將3保存到本地,每次調(diào)用using(),開始數(shù)據(jù)遷移時會將上次保存的version值從本地取出來,會在@SchemeMigration中查找大于這個version值的@Migration,取出里面evictClasses,去重后,遍歷所有本地緩存,只要緩存數(shù)據(jù)中含有你聲明的class,就將這個緩存清除.

比如evictClasses中聲明了Mock.class,會把以O(shè)bservable< List< Mock >>,Observable< Map< String,Mock > >,Observable < Mock[] >或者Observable< Mock >作為返回值的接口緩存全部清理掉,然后在將***version值記錄到本地.

所以每次有需要數(shù)據(jù)遷移的類時,必須在@SchemeMigration中添加新的@Migration,并且注解中version的值必須+1,這樣才會達到數(shù)據(jù)遷移的效果.

@SchemeMigration({ 
            @Migration(version = 1, evictClasses = {Mock.class}), 
            @Migration(version = 3, evictClasses = {Mock3.class}), 
            @Migration(version = 2, evictClasses = {Mock2.class}), 
            @Migration(version = 4, evictClasses = {Mock2.class}) 
 
    }) 
interface Providers {}  

如在上面的基礎(chǔ)上,Mock2內(nèi)部又發(fā)生改變,又需要數(shù)據(jù)遷移,就要新添加個@Migration,version = 4(3+1),這時在調(diào)用using()時只會將version = 4的@Migration中evictClasses聲明的class進行數(shù)據(jù)遷移(即清理含有這個class的緩存數(shù)據(jù)).

@Actionable

這個注解在官方介紹中說明了會使用注解處理器給使用了這個注解的Interface,自動生成一個相同類名以Actionable結(jié)尾的類文件,使用這個類的APi方便更好的執(zhí)行寫操作,沒使用過,不做過多介紹.

總結(jié)

到這里RxCache的介紹就告一段落了,相信看完這篇文章后,基本使用肯定是沒問題的

但是在使用中發(fā)現(xiàn)了一個問題,如果使用BaseResponse< T >,包裹數(shù)據(jù)的時候會出現(xiàn)錯誤,如issue#41和issue#73.

分析問題

上面說了RxCache會將Retrofit返回的數(shù)據(jù)封裝到Record對象里,Record會判斷這個數(shù)據(jù)是那種類型,會先判斷這個數(shù)據(jù)是否是Collection(List的父類),數(shù)組還是Map,如果都不是他會默認(rèn)這個數(shù)據(jù)就是普通的對象.

Record里有三個字段分別儲存這個數(shù)據(jù)的,容器類名,容器里值的類名,和Map的Key類名,意思為如果數(shù)據(jù)類型為List< String >,容器類名為List,值類名為String,Key類名為空,如果數(shù)據(jù)類型為Map< String,Integer >,容器類名為Map,值類名為Integer,key類名為String.

這三個字段的作用就是,在取本地緩存時可以使用Gson根據(jù)字段類型恢復(fù)真實數(shù)據(jù)的類型,問題就在這,因為使用的是BaseResponse< T >包裹數(shù)據(jù),在上面的判斷里,他排除了這個數(shù)據(jù)是List,數(shù)組或Map后它只會認(rèn)定這個數(shù)據(jù)是普通的對象,這時他只會把三個字段里中值類名保存為BaseResponse其他則為空,范型的類型它并沒通過字段記錄,所以它在取的時候自然不會正確返回T的類型.

解決問題

知道問題所在后,我們現(xiàn)在就來解決問題,解決這個問題現(xiàn)在有兩個方向,一個是內(nèi)部解決,一個是外部解決,外部解決的方式就可以通過上面issue#73所提到的方式.

所謂內(nèi)部解決就要改這個框架的內(nèi)部代碼了,問題就出在Record在數(shù)據(jù)為普通對象的時候,他不會使用字段保存范型的類型名,所以在取本地緩存的時候就無法正確恢復(fù)數(shù)據(jù)類型

解決的思路就是我們必須對數(shù)據(jù)為普通對象的時候做特殊處理,最簡單的方式就是如果數(shù)據(jù)為對象時我們再判斷instanceof BaseResponse,如果為true我們就重復(fù)做上面的判斷.

即判斷BaseResponse中,T的類型是否為List,數(shù)組,Map還是對象?

然后在用對應(yīng)的字段保存對應(yīng)的類型名,取本地緩存的時候就可以用Gson按這些字段恢復(fù)正確的數(shù)據(jù)類型,但是這樣強制的判斷instanceof對于一個框架來說靈活性和擴展性會大打折扣,所以我后面寫源碼分析的時候會認(rèn)真考慮下這個問題,可以的話我會Pull Request給Rxcache.