Glide的圖片內(nèi)存優(yōu)化

首先省容,內(nèi)存總量有限抖拴,必須限制圖片加載的內(nèi)存

弱引用

這個大家都懂,好多第三方加載組件也體現(xiàn)了這個思路腥椒。

最早阿宅,大家將Bitmap用弱引用管理起來,當(dāng)內(nèi)存不足時笼蛛,系統(tǒng)會自動GC回收掉部分引用洒放,從而達(dá)到內(nèi)存管理的目的。 這種方式很簡單滨砍,組件本身不管理圖片內(nèi)存往湿,而是交給GC,有GC來自動回收內(nèi)存惋戏。

這種方法會有幾個問題:

應(yīng)用占有的內(nèi)存量會不斷攀升领追,知道內(nèi)存不足時,出現(xiàn)斷崖時的內(nèi)存回收

GC的時間可能會比較長日川,造成界面會有明顯的卡頓蔓腐。

GC回收的內(nèi)存矩乐,沒有區(qū)分龄句,可能回收了最近在使用的Bitmap回论,造成二次加載。

最嚴(yán)重的分歇,新的Android系統(tǒng)開始每次GC都會回收弱引用傀蓉,這就使內(nèi)存緩存沒有用處。

強引用+LRU算法

基于以上問題职抡,有些組件開始用強引用+LRU算法的方式處理圖片加載的問題葬燎,其思路大概是:

給定一個固定圖片緩存大小,將所有的使用的Bitmap用強引用的方式管理起來缚甩,并利用LRU算法谱净,將舊的Bitmap釋放,新的bitmap增加擅威。

這樣壕探,圖片緩存不會無限制的增長,內(nèi)存量也能處在一個較理想的范圍郊丛,申請和釋放李请。UIL就是采用這種方法。

但這個思路也會有問題:

圖片緩存的內(nèi)存不會無限制增長厉熟,但會周期性的釋放和申請导盅。特別是對于一個長列表頁面,圖片會不斷的申請揍瑟,不斷的釋放白翻。因為最終的內(nèi)存釋放還是GC去處理,快速滑動時月培,會造成大量的圖片申請內(nèi)存嘁字,大量的圖片釋放,系統(tǒng)的GC會很頻繁杉畜,就產(chǎn)生了所謂的內(nèi)存抖動纪蜒。

內(nèi)存的抖動同樣也會造成界面卡頓,在快速滑動時此叠,會非常明顯纯续。

提到界面卡頓,我要說明下卡頓的原因灭袁。

人眼能識別的幀數(shù)是一秒24幀猬错,就是所若一個屏幕以每秒24幀顯示時,人眼是看不出什么的茸歧,感覺很流暢倦炒。但若少于24幀,我們就能感覺出卡頓软瞎,不流暢逢唤。 最佳的幀數(shù)是每秒60幀拉讯,再高就沒有任何意義了,一般顯卡會跟屏幕的刷新速率保持一致鳖藕,大部分都是60hz魔慷。

那我們來計算下,最高60幀著恩,1000ms/60幀=16ms/幀院尔,最低24幀,1000ms/24幀=42ms喉誊,也就是說每次ui線程里面的計算最佳的情況是少于16ms邀摆,最高則不能超過42ms。

以ListView為例伍茄,getView的運行時間不能大于42ms, 推薦大家用hugo統(tǒng)計運行時間隧熙,很方便。

特殊情況下幻林,即便是不大于42ms贞盯,接近也會造成卡頓,因為還會有其他的函數(shù)運行沪饺。

在這種情況下躏敢,若出現(xiàn)內(nèi)存抖動,就會頻繁的暫停進(jìn)程整葡,釋放內(nèi)存件余,極易出現(xiàn)卡頓。

GLide的BitmapPool

Glide對這個環(huán)節(jié)做了非常好的優(yōu)化遭居,解決了內(nèi)存抖動的問題啼器。

Glide構(gòu)建了一個BitmapPool,Bitmap申請和回收都是透過BitmapPool來處理的俱萍。新加載圖片時端壳,會先從BitmapPool里面找有沒有相應(yīng)大小的Bitmap,有則直接使用枪蘑,沒有才會申請新的Bitmap损谦;回收時,則會提交給BitmapPool, 供下次使用岳颇。

這種方式極大的減少了Bitmap的申請和回收操作照捡,使得GC頻度降低了很多。

圖片與顯示區(qū)域大小一致

圖片加載最終的目的是顯示到界面上话侧,因此若是圖片緩存的尺寸大于顯示區(qū)域的尺寸是沒有必要的栗精。不光是造成內(nèi)存浪費,占用較大的內(nèi)存瞻鹏,而且會造成圖片解析速度比較慢悲立。

因此赢赊,不管是UIL,Glide和Freso等等都建議ImageView需要給定固定的長和寬级历,這樣圖片加載時,就可以根據(jù)顯示區(qū)域的大小叭披,加載最小的圖片寥殖,又不會造成損失。

另外涩蜘,七牛的云服務(wù)提供了imageView2參數(shù)嚼贡,可以給定長寬,在網(wǎng)絡(luò)加載層次上就可以降低加載的圖片尺寸同诫,提高加載速度粤策。

另外,UIL误窖,Glide都將縮放后的圖片緩存到本地叮盘,下次加載時直接從磁盤緩存加載,也會有比原始尺寸加載更好的速度霹俺。

圖片的加載優(yōu)化有很多內(nèi)容可以做柔吼,比如現(xiàn)在的圖片加載,都是等將要顯示時開始加載丙唧,這樣圖片可能需要等待一下才能加載出來愈魏,我們是不是可以提前加載呢?

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末想际,一起剝皮案震驚了整個濱河市培漏,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌胡本,老刑警劉巖牌柄,帶你破解...
    沈念sama閱讀 218,122評論 6 505
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異侧甫,居然都是意外死亡友鼻,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,070評論 3 395
  • 文/潘曉璐 我一進(jìn)店門闺骚,熙熙樓的掌柜王于貴愁眉苦臉地迎上來彩扔,“玉大人,你說我怎么就攤上這事僻爽〕娴铮” “怎么了?”我有些...
    開封第一講書人閱讀 164,491評論 0 354
  • 文/不壞的土叔 我叫張陵胸梆,是天一觀的道長敦捧。 經(jīng)常有香客問我须板,道長,這世上最難降的妖魔是什么兢卵? 我笑而不...
    開封第一講書人閱讀 58,636評論 1 293
  • 正文 為了忘掉前任习瑰,我火速辦了婚禮,結(jié)果婚禮上秽荤,老公的妹妹穿的比我還像新娘甜奄。我一直安慰自己,他們只是感情好窃款,可當(dāng)我...
    茶點故事閱讀 67,676評論 6 392
  • 文/花漫 我一把揭開白布课兄。 她就那樣靜靜地躺著,像睡著了一般晨继。 火紅的嫁衣襯著肌膚如雪烟阐。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,541評論 1 305
  • 那天紊扬,我揣著相機與錄音蜒茄,去河邊找鬼。 笑死餐屎,一個胖子當(dāng)著我的面吹牛扩淀,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播啤挎,決...
    沈念sama閱讀 40,292評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼驻谆,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了庆聘?” 一聲冷哼從身側(cè)響起胜臊,我...
    開封第一講書人閱讀 39,211評論 0 276
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎伙判,沒想到半個月后象对,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,655評論 1 314
  • 正文 獨居荒郊野嶺守林人離奇死亡宴抚,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,846評論 3 336
  • 正文 我和宋清朗相戀三年勒魔,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片菇曲。...
    茶點故事閱讀 39,965評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡冠绢,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出常潮,到底是詐尸還是另有隱情弟胀,我是刑警寧澤,帶...
    沈念sama閱讀 35,684評論 5 347
  • 正文 年R本政府宣布,位于F島的核電站孵户,受9級特大地震影響萧朝,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜夏哭,卻給世界環(huán)境...
    茶點故事閱讀 41,295評論 3 329
  • 文/蒙蒙 一释簿、第九天 我趴在偏房一處隱蔽的房頂上張望攒磨。 院中可真熱鬧削茁,春花似錦地梨、人聲如沸酿联。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,894評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽座享。三九已至运悲,卻和暖如春龄减,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背班眯。 一陣腳步聲響...
    開封第一講書人閱讀 33,012評論 1 269
  • 我被黑心中介騙來泰國打工希停, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人署隘。 一個月前我還...
    沈念sama閱讀 48,126評論 3 370
  • 正文 我出身青樓宠能,卻偏偏與公主長得像,于是被迫代替她去往敵國和親磁餐。 傳聞我的和親對象是個殘疾皇子违崇,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 44,914評論 2 355

推薦閱讀更多精彩內(nèi)容