-
Android異步加載總結(jié)查看全部
-
1212查看全部
-
將URL轉(zhuǎn)化為Bitmap查看全部
-
public Bitmap getBitmapFromUrl(String urlString){ Bitmap bitmap; InputStream is; try { URL url = new URL(urlString); HttpURLConnection connection = (HttpURLConnection) url.openConnection(); is = new BufferedInputStream(connection.getInputStream()); bitmap = BitmapFactory.decodeStream(is); connection.disconnect(); return bitmap; } catch (MalformedURLException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); }finally { is.close(); } return null; }查看全部
-
visbleitemcount 在初始化調(diào)用的時(shí)候，他的值為0，這時(shí)item還沒有加載，所以要講這個(gè)過程跳過，所以在判斷第一次加載的時(shí)候判斷，是否為第一次顯示，而且listview的item是否已經(jīng)畫出查看全部
-
通過findviewbytag，通過tag在listview中尋找指定的imageview查看全部
-
ListView的加載對(duì)于流暢度的要求是很高的，當(dāng)在異步加載的過程中，在更新UI的時(shí)候是在新的線程中進(jìn)行的，并沒有阻塞主線程，但是在加載過之后更新UI線程，會(huì)導(dǎo)致UI線程發(fā)生一次重繪，如果重繪發(fā)生在滾動(dòng)的時(shí)候就會(huì)卡頓 ******************************************************* ListView滑動(dòng)停止后才加載可見項(xiàng)； listview滑動(dòng)的時(shí)候，取消所有加載項(xiàng)查看全部
-
LruCache類中的sizeof方法用于獲得所存入數(shù)據(jù)的大小，重寫sizeof方法，指定所需的數(shù)據(jù)的大小，在每次存入緩存之內(nèi)調(diào)用 ******************************************* 創(chuàng)建方法存入cache和取出Cache 通過與Bitmap相連的url返回所存取的BitMap查看全部
-
LRU近期最少使用算法，Android提供了LruCache類來實(shí)現(xiàn)這個(gè)緩存算法查看全部
-
ImageLoder中對(duì)應(yīng)的方法查看全部
-
對(duì)ListView進(jìn)行滑動(dòng)監(jiān)聽 滑動(dòng)的時(shí)候停止加載所有的圖片,不滑動(dòng)的時(shí)候加載可見的Item的圖片 在ImageLoder 新增對(duì)應(yīng)的方法 加載可見項(xiàng),停止加載查看全部
-
http://idcbgp.cn/api/teacher?type=4&num=30查看全部
-
異步加載的第一層：通過AsyncTask訪問網(wǎng)絡(luò)，獲取json或者XML字符串，然后解析他們產(chǎn)生若干object，將每個(gè)object放入到ListVIew中（adapter需要使用view holder pattern去寫），AsyncTask中的訪問網(wǎng)絡(luò)獲取json或者XML字符串，并且產(chǎn)生若干個(gè)object的工作就是在doInBackground()方法中進(jìn)行的，所以這個(gè)方法總的來說就是用來準(zhǔn)備數(shù)據(jù)源的。查看全部
-
From @xiaoc024 我來說一下為什么會(huì)閃。這是【同時(shí)】使用ConvertView和異步機(jī)制造成的。一個(gè)屏幕一次顯示8個(gè)item，當(dāng)?shù)?個(gè)item劃進(jìn)屏幕時(shí)，ListView對(duì)adapter說，返給我一個(gè)view，我要顯示。adapter調(diào)用getView（）方法，由于使用了緩存機(jī)制，getView（）在初始化8個(gè)item以后所有返回的view（ConvertView）內(nèi)存地址都是這8個(gè)中的。如果【不使用】異步機(jī)制加載圖片，那么返回的這個(gè)ConvertView是被更新以后返給ListView使用的。效果是上滑屏幕沒反應(yīng)，等了半天，突然加載出來，但是不會(huì)閃。 然而這里使用了異步機(jī)制，也就是說先返回ConvertView，再等異步線程修改，這是閃的本質(zhì)！由于教程里使每個(gè)異步線程人工阻塞了1s，那么上來有8個(gè)異步線程在運(yùn)行（編號(hào)1-8），如果1s之內(nèi)下滑了ListView比如說下滑了8個(gè)，那么新更新的8個(gè)item還是用的以前的內(nèi)存，【并且】又開啟了8個(gè)異步線程（編號(hào)9-16）。因?yàn)轭A(yù)先設(shè)定了一個(gè)默認(rèn)圖片，所以先顯示綠色的默認(rèn)icon圖片。然后1-8號(hào)異步線程運(yùn)行完畢，更新ImageView（閃），緊跟著9-16異步線程運(yùn)行完畢，又更新imageView（閃），最終顯示正確結(jié)果。這就是下滑時(shí)先顯示默認(rèn)圖片，再閃一下錯(cuò)誤圖片，最后閃一下正確圖片的本質(zhì)過程。 如果給每個(gè)ImageView設(shè)置了tag以后，當(dāng)1-8號(hào)異步線程運(yùn)行完畢后，會(huì)發(fā)消息給handler，讓他進(jìn)行更新ui的操作，可是在1-8號(hào)線程發(fā)消息之前，9-16號(hào)線程已經(jīng)更新了1-8和9-16共用的ImageView控件的tag,所以1-8號(hào)線程的消息雖然發(fā)給了handler，但是不滿足條件，handler不會(huì)進(jìn)行ui更新。 p.s.完全理解這整個(gè)過程真的不容易，希望對(duì)你們有幫助。 至于說“然而如果不顯示ic_lanucher的話，圖片依然會(huì)錯(cuò)誤跳動(dòng)”其實(shí)這個(gè)時(shí)候圖片不是在跳動(dòng)，而是正在做加載的工作，只是在加載工作完成之前，依然會(huì)顯示先前加載的圖片。 比如1-8加載完成了，我要查看第9個(gè)項(xiàng)目，系統(tǒng)就將第1個(gè)項(xiàng)目放入緩存，然后加載第9個(gè)，然而加載第1個(gè)需要時(shí)間，系統(tǒng)就會(huì)默認(rèn)地使用最近加入緩存的對(duì)象，也就是第1個(gè)項(xiàng)目的圖片先抗一會(huì)，等待第1個(gè)項(xiàng)目加載完成接手。 這應(yīng)該是convertView的小弊端查看全部
-
處理加載listview時(shí)的 使用了viewhold造成的圖片錯(cuò)亂 用setTag來解決 講解了LruCache方法查看全部
舉報(bào)
0/150
提交
取消