一種android平臺下基于緩存的列表處理方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及計算機網(wǎng)絡技術(shù)領(lǐng)域，特別是涉及一種android平臺下基于緩存的列表處理方法。
【背景技術(shù)】
[0002]Android平臺下，cpu資源、內(nèi)存資源以及網(wǎng)絡資源都是非常緊張的資源。列表是android用來展示集合數(shù)據(jù)的常用控件，當集合中有需要從網(wǎng)絡或者數(shù)據(jù)庫中讀取的數(shù)據(jù)時，列表的顯示將是非常耗時的。
【發(fā)明內(nèi)容】
[0003]本發(fā)明的目的在于提供一種android平臺下基于緩存的列表處理方法，其提高用戶體驗，節(jié)省了資源。
[0004]為實現(xiàn)本發(fā)明目的而提供的一種android平臺下基于緩存的列表處理方法，包括如下步驟:
[0005]步驟S100,設置兩級緩存:第一級緩存 LinkedHashMap〈String, Bitmap) ;二級緩存 ConcurrentHashMap<String, SoftReference<Bitmap>> ；
[0006]步驟S200,第一級緩存用LinkedHashMap〈String, Bitmap〉保留 Bitmap 的強引用，控制緩存的大小MAX_CAPACITY=10 ；
[0007]步驟S300，當繼續(xù)向該緩存中存數(shù)據(jù)的時候，將一級緩存中的最近最少使用的元素放入二級緩存 ConcurrentHashMap〈String, SoftReference<Bitmap>>, 二級緩存中保留的 Bitmap 的軟引用 SoftReference。
[0008]較優(yōu)地，所述步驟S300還包括如下步驟:
[0009]步驟S310,在創(chuàng)建SoftReference對象的時候，使用了一個ReferenceQueue對象作為參數(shù)提供給SoftReference的構(gòu)造方法:
[0010]ReferenceQueue queue=new ReferenceQueueO ；
[0011]SoftReference ref=new SoftReference(aMyObject, queue);
[0012]步驟S320,當所述SoftReference所軟引用的aMyOhject被垃圾收集器回收的同時，ref所強引用的SoftReference對象被列入ReferenceQueue。
[0013]本發(fā)明的android平臺下基于緩存的列表處理方法，其通過設置兩級緩存，有效的提高了大數(shù)據(jù)量情況下列表的效率，提高用戶體驗，節(jié)省了資源。
【附圖說明】
[0014]圖1為依據(jù)本發(fā)明一個具體實施例的android平臺下基于緩存的列表處理方法流程圖。
【具體實施方式】
[0015]為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點更加清楚透徹，以下結(jié)合附圖及實施例，對本發(fā)明的android平臺下基于緩存的列表處理方法進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。
[0016]本發(fā)明android平臺下基于緩存的列表處理方法,如圖1所示,包括如下步驟:
[0017]步驟S100,設置兩級緩存:第一級緩存 LinkedHashMap〈String, Bitmap) ;二級緩存 ConcurrentHashMap<String, SoftReference<Bitmap>> ；
[0018]步驟S200,第一級緩存用LinkedHashMap〈String, Bitmap〉保留 Bitmap 的強引用，控制緩存的大小MAX_CAPACITY=10 ；
[0019]步驟S300，當繼續(xù)向該緩存中存數(shù)據(jù)的時候，將一級緩存中的最近最少使用的元素放入二級緩存 ConcurrentHashMap〈String, SoftReference<Bitmap>>, 二級緩存中保留的 Bitmap 的軟引用 SoftReference。
[0020]軟引用SoftReference保存的對象實例，除非JVM即將OutOfMemory,否則不會被GC回收。這個特性使得它特別適合設計對象Cache。對于Cache被緩存的對象最好始終常駐內(nèi)存，但是如果JVM內(nèi)存吃緊,為了不發(fā)生OutOfMemoryError導致系統(tǒng)崩潰,必要的時候也允許JVM回收Cache的內(nèi)存，待后續(xù)合適的時機再把數(shù)據(jù)重新Load到Cache中。這樣可以系統(tǒng)設計得更具彈性。
[0021]內(nèi)存優(yōu)化是將獲取到的數(shù)據(jù)存取到Map集合中，如果再次引用此數(shù)據(jù)，就直接從Map集合中獲取，這樣會導致一個問題，如果Map集合中的數(shù)據(jù)特別多，比如存取了 100萬條數(shù)據(jù)，這樣有可能就會導致內(nèi)存溢出。這是因為Map集合是強引用的集合，如何不把Map集合置為空的話，這個集合Java虛擬機就不會把它回收掉，當Map中的數(shù)據(jù)大小超過了內(nèi)存大小就會導致內(nèi)存溢出。為了避免這種異常要使用軟引用softreference，軟引用和強引用的區(qū)別如下:
[0022]har(!reference默認new出來的對象都是這種強應用的類型，只要一個對象還保留的有引用，他就不會被垃圾回收。
[0023]softreference他是java虛擬機給我們提供的一個包裝類型，java虛擬機會盡量長時間的保留這個對象，當java虛擬機內(nèi)存不足的時候java虛擬機就會回收softreference里面的對象。
[0024]SoftReference的特點是它的一個實例保存對一個Java對象的軟引用，該軟引用的存在不妨礙垃圾收集線程對該Java對象的回收。
[0025]也就是說,一旦SoftReference保存了對一個Java對象的軟引用后,在垃圾線程對這個Java對象回收前,SoftReference類所提供的get O方法返回Java對象的強引用。另外，一旦垃圾線程回收該Java對象之后，get O方法將返回null。
[0026]作為一個Java對象，SoftReference對象除了具有保存軟引用的特殊性之外，也具有Java對象的一般性。所以，當軟引用對象被回收之后,雖然這個SoftReference對象的get()方法返回null,但這個SoftReference對象已經(jīng)不再具有存在的價值,需要一個適當?shù)那宄龣C制，避免大量SoftReference對象帶來的內(nèi)存泄漏。
[0027]較佳地,本發(fā)明的android平臺下基于緩存的列表處理方法,在步驟S300中，還包括如下步驟:
[0028]步驟S310,在創(chuàng)建SoftReference對象的時候，使用了一個ReferenceQueue對象作為參數(shù)提供給SoftReference的構(gòu)造方法:
[0029]ReferenceQueue queue=new ReferenceQueueO ；
[0030]SoftReference ref=new SoftReference(aMyObject, queue);
[0031]步驟S320,當所述SoftReference所軟引用的aMyOhject被垃圾收集器回收的同時，ref所強引用的SoftReference對象被列入ReferenceQueue。
[0032]在java.lang.ref 包里還提供了 ReferenceQueue,在創(chuàng)建 SoftReference 對象的時候，使用了一個ReferenceQueue對象作為參數(shù)提供給SoftReference的構(gòu)造方法:
[0033]ReferenceQueue queue=new ReferenceQueueO ；
[0034]SoftReference ref=new SoftReference(aMyObject, queue);
[0035]那么當該SoftReference所軟引用的aMyOhject被垃圾收集器回收的同時,ref所強引用的SoftReference對象被列入ReferenceQueue。也就是說，ReferenceQueue中保存的對象是Reference對象,而且是已經(jīng)失去了它所軟引用的對象的Reference對象。另外從ReferenceQueue這個名字也可以看出，它是一個隊列，當我們調(diào)用它的poll O方法的時候，如果這個隊列中不是空隊列，那么將返回隊列前面的那個Reference對象。
[0036]在任何時候,都可以調(diào)用ReferenceQueue的poll O方法來檢查是否有它所關(guān)心的非強可及對象被回收。如果隊列為空，將返回一個null，否則該方法返回隊列中前面的一個Reference對象。利用這個方法,檢查哪個SoftReference所軟引用的對象已經(jīng)被回收。把這些失去所軟引用的對象的SoftReference對象清除掉。
[0037]訪問磁盤文件、訪問網(wǎng)絡資源、查詢數(shù)據(jù)庫等操作都是影響應用程序執(zhí)行性能的重要因素，如果能重新獲取那些尚未被回收的Java對象的引用，必將減少不必要的訪問，大大提聞程序的運行速度。
[0038]下面針對方案在實際系統(tǒng)中的應用進行分析。
[0039]需要從網(wǎng)絡上下載藥品的圖片顯示到列表中，并且會經(jīng)常查看這個列表。這時我們通常會有兩種程序?qū)崿F(xiàn)方式:一種是把過去查看過的圖片列表保存在內(nèi)存中，每一個存儲了藥品信息的Java對象的生命周期貫穿整個應用程序始終；另一種是當用戶每次查看藥品列表信息的時候，把存儲了當前所查看的藥品信息的Java對象結(jié)束引用，使得垃圾收集線程可以回收其所占用的內(nèi)存空間，當用戶再次需要瀏覽該列表信息的時候，重新構(gòu)建該藥品的信息。很顯然，第一種實現(xiàn)方法將造成大量的內(nèi)存浪費，而第二種實現(xiàn)的缺陷在于即使垃圾收集線程還沒有進行垃圾收集，包含藥品信息的對象仍然完好地保存在內(nèi)存中，應用程序也要重新構(gòu)建一個對象。
[0040]本發(fā)明的android平臺下基于緩存的列表處理方法，通過將網(wǎng)絡上下載的圖片進行二級緩存，節(jié)約了流量，并且提高了下一次顯示圖片的速度，提高了用戶體驗，同時防止了內(nèi)存溢出。
[0041]最后應當說明的是，很顯然，本領(lǐng)域的技術(shù)人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā)明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權(quán)利要求及其等同技術(shù)的范圍之內(nèi)，則本發(fā)明也意圖包含這些改動和變型。
【主權(quán)項】
1.一種android平臺下基于緩存的列表處理方法，其特征在于，包括如下步驟: 步驟S100，設置兩級緩存:第一級緩存LinkedHashMap〈String，Bitmap〉；二級緩存ConcurrentHashMap〈String，SoftReference〈Bitmap>> ； 步驟S200，第一級緩存用LinkedHashMap〈String，Bitmap〉保留Bitmap的強引用，控制緩存的大小 MAX—CAPACITY=10 ； 步驟S300，當繼續(xù)向該緩存中存數(shù)據(jù)的時候，將一級緩存中的最近最少使用的元素放入二級緩存 ConcurrentHashMap〈String，SoftReference〈Bitmap>>，二級緩存中保留的Bitmap 的軟引用 SoftReference。
2.根據(jù)權(quán)利要求1所述的android平臺下基于緩存的列表處理方法，其特征在于，所述步驟S300還包括如下步驟: 步驟S310，在創(chuàng)建SoftReference對象的時候，使用了一個ReferenceQueue對象作為參數(shù)提供給SoftReference的構(gòu)造方法:ReferenceQueue queue=new ReferenceQueueO ；SoftReference ref=new SoftReference(aMyObject, queue); 步驟S320，當所述SoftReference所軟引用的aMyOhject被垃圾收集器回收的同時，ref 所強引用的 SoftReference 對象被列入 ReferenceQueue。
【專利摘要】本發(fā)明公開一種android平臺下基于緩存的列表處理方法，包括如下步驟：步驟S100，設置兩級緩存：第一級緩存LinkedHashMap<String,Bitmap>；二級緩存ConcurrentHashMap<String,SoftReference<Bitmap>>；步驟S200，第一級緩存用LinkedHashMap<String,Bitmap>保留Bitmap的強引用，控制緩存的大小MAX_CAPACITY=10；步驟S300，當繼續(xù)向該緩存中存數(shù)據(jù)的時候，將一級緩存中的最近最少使用的元素放入二級緩存ConcurrentHashMap<String,SoftReference<Bitmap>>，二級緩存中保留的Bitmap的軟引用SoftReference。其提高用戶體驗，節(jié)省了資源。
【IPC分類】G06F12-08, G06F9-44
【公開號】CN104714897
【申請?zhí)枴緾N201310684441
【發(fā)明人】王洪波, 周強, 楊奇, 陳皓, 張偉, 劉冬娜, 金釗
【申請人】航天信息股份有限公司
【公開日】2015年6月17日
【申請日】2013年12月13日