前言

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

項目地址: RxCache Demo地址: RxCacheSample

簡介

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

使用

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

/** 
 * 此為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構建方式類似,將接口通過using方法傳入,返回一個接口的動態代理對象,調用此對象的方法傳入對應參數就可以實現緩存了,通過注解和傳入不同的參數可以實現一些自定義的配置, so easy～

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

詳解

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

參數

Observable

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

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

例外

如果構建RxCache的時候將useExpiredDataIfLoaderNotAvailable設置成true,會在數據為空或者發生錯誤時,忽視EvictProvider為true或者緩存過期的情況,繼續使用緩存(前提是之前請求過有緩存).

DynamicKey & DynamicKeyGroup

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

那是什么呢?

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

標識符規則為:

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

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

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

什么意思呢?

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

和我們有什么關系呢?

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

DynamicKey和DynamicKeyGroup有什么關系呢?

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

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

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

EvictProvider & EvictDynamicKey & EvictDynamicKeyGroup

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

這三個對象有什么關系呢?

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

不同在哪呢?

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

刪除規則是什么呢?

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

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

EvictDynamicKeyGroup 只會刪除對應分頁下,對應用戶的緩存.

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

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

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

注解

@LifeCache

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

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

@EncryptKey & @Encrypt

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

@EncryptKey是作用在接口上

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

而@Encrypt是作用在方法上

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

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

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

@Expirable

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

這個***容量和@Expirable又有什么關系呢?

當然有!還記得我之前說過在每次Retrofit重新獲取***數據時,返回數據前會將***數據在內存緩存和本地緩存中各存一份.

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

做的什么操作?

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

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

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

@SchemeMigration & @Migration

這兩個注解是用來數據遷移的,用法:

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

什么叫數據遷移呢?

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

有什么應用場景呢?

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

public class Mock{ 
    private int id; 
}  

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

public class Mock{ 
    private long id; 
}  

為了滿足現在的需求,我們使用long代替int,由于緩存中的Mock還是之前未改變的版本,并且未過期,在使用本地緩存時會將數據反序列化,將int變為long,就會出現問題.

數據遷移是怎么解決上面的問題呢?

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

RxCache是怎么操作的呢?

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

每次清理完需要數據遷移的緩存時,會將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保存到本地,每次調用using(),開始數據遷移時會將上次保存的version值從本地取出來,會在@SchemeMigration中查找大于這個version值的@Migration,取出里面evictClasses,去重后,遍歷所有本地緩存,只要緩存數據中含有你聲明的class,就將這個緩存清除.

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

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

@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 {}  

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

@Actionable

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

總結

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

但是在使用中發現了一個問題,如果使用BaseResponse< T >,包裹數據的時候會出現錯誤,如issue#41和issue#73.

分析問題

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

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

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

解決問題

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

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

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

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

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