為了快速查詢會(huì)被多次調(diào)用的數(shù)據(jù)，或者構(gòu)建比較廢時(shí)的實(shí)例，我們一般使用緩存的方法。緩存的基本概念大體上差不多，這里就不再重復(fù)，有興趣的可以查看維基百科的介紹。

緩存有很多的實(shí)現(xiàn)方式，技巧性還有坑都很多，今天我給大家介紹一些非通用的方法，可以巧妙地幫大家簡(jiǎn)單實(shí)現(xiàn)一些內(nèi)存緩存。

SQLite是Android里常用的一種數(shù)據(jù)存儲(chǔ)方式，在訪問(wèn)數(shù)據(jù)庫(kù)數(shù)據(jù)時(shí)需要通過(guò)SQLiteOpenHelper。

一份好的數(shù)據(jù)庫(kù)連接代碼應(yīng)該能解決以下幾個(gè)問(wèn)題: a) 構(gòu)建實(shí)例比較費(fèi)資源 b) 數(shù)據(jù)庫(kù)連接最好能復(fù)用 c) onUpdate等方法在執(zhí)行時(shí)不能和其他實(shí)例構(gòu)成沖突。

這里可以很簡(jiǎn)單的這樣寫(xiě)

Suppliers.memoize(new Supplier<SQLiteOpenHelper>() { @Override public SQLiteOpenHelper get() { return new ...; }})

這段代碼利用了Guava提供的一些輔助方法實(shí)現(xiàn)Supplier和Memoize和邏輯。顧名思義，Supplier一般被用作factory，generator，builder，closure。Memoize類似于緩存這種概念，它一旦生成了一個(gè)實(shí)例，在以后的調(diào)用中都會(huì)返回同一實(shí)例，而且，線程安全。

這樣寫(xiě)有幾個(gè)好處，一是需要時(shí)才去構(gòu)建實(shí)例，并不會(huì)在一開(kāi)始就去阻塞程序的執(zhí)行，二是它很簡(jiǎn)單的用memoize實(shí)現(xiàn)了緩存，保證只有一個(gè)實(shí)例生成。

Glow是代碼注入的重度使用者，它使我們的代碼更加結(jié)構(gòu)化，清晰，簡(jiǎn)單，同時(shí)還節(jié)省了不少的開(kāi)發(fā)時(shí)間。

Dagger 2是我們實(shí)現(xiàn)注入的刀具，有興趣的同學(xué)應(yīng)該去網(wǎng)站多了解一下相關(guān)的內(nèi)容。除了注入，它還有一些附贈(zèng)功能，而這些恰巧能被我們用來(lái)實(shí)現(xiàn)緩存，而且還很簡(jiǎn)單，我們只需要額外用到幾個(gè)annotation或接口而已。

@Singleton

相信大家對(duì)這個(gè)應(yīng)該比較熟悉，這可是面試時(shí)的常問(wèn)問(wèn)題。簡(jiǎn)單來(lái)說(shuō)，它就是單例。因?yàn)樗裕昧怂悴挥迷贀?dān)心對(duì)這些實(shí)例怎么實(shí)現(xiàn)緩存了吧。

@Singleton public class SingletonClass { }

@Reusable

這是一個(gè)新的很酷的功能。單例雖然很好，但有些時(shí)候?qū)嵗赡苡行┨螅恢狈旁趦?nèi)存，又不能回收，暫時(shí)可能程序也用不到，怎么都感覺(jué)有些浪費(fèi)。很多情況下，我們并沒(méi)有那么嚴(yán)格的要求需要唯一的一個(gè)實(shí)例，能重用就重用，沒(méi)有重新實(shí)例化一個(gè)就行。這就是@Reusable的使用場(chǎng)景，假如已有一個(gè)生成的實(shí)例，重用它就行，不行重新實(shí)例化，不需要保證。

@Reusable public class ReusableClass { }

Lazy

Lazy使用的地方和前兩者有些不同。@Singleton和@Reusable一般用在provides或類型定義的地方，但Lazy則是用在使用時(shí)，它的使用效果和最開(kāi)始講到的Supplier和Memoize類似。

@Inject Lazy<SQLiteOpenHelper> lazySQLiteOpenHelper;

這里不會(huì)先生成SQLiteOpenHelper實(shí)例，直到你開(kāi)始調(diào)用lazySQLiteOpenHelper.get()。而一旦第一次實(shí)例化結(jié)束，以后的調(diào)用都會(huì)返回第一次的結(jié)果。

在使用app的過(guò)程中，很多數(shù)據(jù)需要從服務(wù)器端獲取。在我們app里，每天會(huì)為用戶提供一些訂制化內(nèi)容，這些內(nèi)容短期內(nèi)不會(huì)改變，每次從服務(wù)器端去取太過(guò)耗時(shí)，但放到數(shù)據(jù)庫(kù)或文件這些持久化存儲(chǔ)里似乎不太必要。綜合考慮后，似乎內(nèi)存緩存是個(gè)不錯(cuò)的選擇。

于是這個(gè)緩存需要提供以下功能，首先，它是個(gè)緩存，其次，它的結(jié)構(gòu)需要很簡(jiǎn)單，因?yàn)楹芏嗟胤叫枰玫剑俅危镁€程安全。

后來(lái)我們的實(shí)現(xiàn)方案很簡(jiǎn)單，利用Retrofit和Observable提供的一些方法。

private static final long EXPIRE_MS = 5 * 60 * 1000; private Pair<Long, Observable<Content>>

cache; public synchronized Observable<Content> getDailyContent() { if (cache == null || cache.first + EXPIRE_MS < System.currentTimeMillis()) { cache = Pair.create(System.currentTimeMillis(), serverApi.getContent()); } return cache.second; }

這個(gè)方法的本質(zhì)是利用Retrofit返回的Observable對(duì)象，然后Observable會(huì)提供一個(gè)類似緩存的cache方法，這樣在subscribe之前，這個(gè)網(wǎng)絡(luò)請(qǐng)求不會(huì)被發(fā)出，但一旦有了結(jié)果，后來(lái)的調(diào)用者都會(huì)得到同樣的結(jié)果。

注意

緩存雖好，用起來(lái)很快捷方便，但在使用過(guò)程中，大家一定要注意數(shù)據(jù)更新和線程安全，不要出現(xiàn)臟數(shù)據(jù)。

來(lái)自：http://www.jointforce.com/jfperiodical/article/3516