ListView列表控件

一、ListView顯示數(shù)據(jù)的原理:mvc模式

m:mode 數(shù)據(jù)(用javabean規(guī)范封裝)

v:view ListView

c:adapter 適配器,負(fù)責(zé)把數(shù)據(jù)展示到ListView上

二、ListView最常用適配器

BaseAdapter、SimpleAdapter、ArrayAdapter

三、ListView顯示數(shù)據(jù)的步驟

1.創(chuàng)建ListView

2.自定義ListView的適配器繼承BaseAdapter，重寫baseAdapter的getCount方法和getView方法

3.創(chuàng)建自定義ListView的適配器

4.ListView設(shè)置適配器：listView.setAdapter(adapter);

private class ListViewAdapter extends BaseAdapter{
    //返回需要展示的數(shù)據(jù)的條數(shù)
    @Override
    public int getCount() {
      return 200;
    }
    //返回指定position位置對應(yīng)的數(shù)據(jù)對象，一般很少用
    @Override
    public Object getItem(int position) {
      return null;
    }
    //返回position位置對應(yīng)id
    @Override
    public long getItemId(int position) {
      return 0;
    }
    /**
     * 獲取一個view，會作為listview的第position個item條目出現(xiàn)，用來顯示listview的數(shù)據(jù)
     * 
     * @param convertView 歷史緩存對象
     */
    @Override
    public View getView(int position, View convertView, ViewGroup parent) {
      View view ;
      if (convertView == null) {
        //創(chuàng)建新的View對象 
        view = View.inflate(MainActivity.this, R.layout.listview_item,null);
      }else{
        //復(fù)用歷史緩存View對象
        view = convertView;
      }
      TextView tv=(TextView)view.findViewById(R.id.tv);
      tv.setText("item：" + position);
      return view;
    }      
  }

四、ListView的性能優(yōu)化

1.ListView的奇怪現(xiàn)象

問題：

如果ListView的高度設(shè)為包裹內(nèi)容，getView方法會多次調(diào)用

原因：

如果height設(shè)為”wrap_content”，為了把所有條目都顯示出來，會多次校驗數(shù)據(jù)是否可在屏幕顯示完，(校驗1次不保準(zhǔn)，再多次校驗)將多次調(diào)用getView方法

解決：以后再使用ListView的時候，高度設(shè)置為填充父窗體 android:layout_height=”match_parent”

2.避免內(nèi)存溢出優(yōu)化：ListView復(fù)用歷史緩存View對象

問題：如果不復(fù)用歷史緩存View對象，當(dāng)ListView的條目數(shù)過多，向下滑的很深時，會報錯。

報錯信息： E/dalvikvm-heap(2636): Out of memory on a -294967280-byte allocation. 內(nèi)存溢出

原因：不停創(chuàng)建新的View,消耗內(nèi)存。為每一個Item都創(chuàng)建一個View對象，必將占用很多內(nèi)存空間。從xml中生成View，這是屬于IO操作，是耗時操作，所以必將影響性能

解決：可以對消失在屏幕的View進(jìn)行緩存，當(dāng)往下拖動時復(fù)用歷史緩存，這樣就只創(chuàng)建屏幕能顯示的View個數(shù)的數(shù)量的View。getView方法有個參數(shù)convertView就是可以復(fù)用的歷史緩存View對象。這個對象也可能為空，當(dāng)它為空的時候，表示該條目view第一次創(chuàng)建，所以我們需要inflate一個view出來。

原理：Android提供了一個叫做Recycler(反復(fù)循環(huán))的構(gòu)件，就是當(dāng)ListView的Item從滾出屏幕視角之外，對應(yīng)Item的View會被緩存到Recycler中，相應(yīng)的會從生成一個Item，而此時調(diào)用的getView中的convertView參數(shù)就是滾出屏幕的緩存Item的View，所以說如果能重用這個convertView，就會大大改善性能。

public View getView(int position, View convertView, ViewGroup parent) { 
TextView tv; 
if (convertView == null) { 
// 創(chuàng)建新的view 對象 
tv = new TextView(MainActivity.this); 
System.out.println(“創(chuàng)建新的view對象—” + position); 
} else { 
System.out.println(“復(fù)用歷史緩存對象—” + position); 
view = (TextView) convertView; 
} 
tv.setText(“4月14日科比告別戰(zhàn)倒計時：” + position); 
return tv; 
}

3.item子控件顯示卡頓優(yōu)化：ViewHolder重用機(jī)制

問題：item中的子控件很多時加載慢。findViewById是到xml文件中去查找對應(yīng)的id，可以想象如果組件多的話也是挺費事的，如果我們可以讓view內(nèi)的組件也隨著view的復(fù)用而復(fù)用，那該是多美好的一件事。

原因：在getView()方法中的操作是先從xml中創(chuàng)建view對象（inflate操作，我們采用了重用convertView方法優(yōu)化），然后在這個view去findViewById，找到每一個item的子View的控件對象，如：ImageView、TextView等。這里的findViewById操作是一個樹查找過程，也是一個耗時的操作。

解決：谷歌推薦了一種優(yōu)化方法來做應(yīng)對，那就是重新建一個內(nèi)部靜態(tài)類，里面的成員變量跟view中所包含的組件個數(shù)類型相同

private static class ViewHolder {}

基本思路就是在convertView為null的時候，我們不僅重新inflate出來一個view，并且還需要進(jìn)行findviewbyId的查找工作，但是同時我們還需要獲取一個ViewHolder類的對象，并將findviewById的結(jié)果賦值給ViewHolder中對應(yīng)的成員變量。最后將holder對象與該view對象“綁”在一塊。當(dāng)convertView不為null時，我們讓view=converView，同時取出這個view對應(yīng)的holder對象，就獲得了這個view對象中的子控件，就是holder中的成員變量，這樣在復(fù)用的時候，我們就不需要再去findViewById了，只需要在最開始的時候進(jìn)行數(shù)次查找工作就可以了。這里的關(guān)鍵在于如何將view與holder對象進(jìn)行綁定，那么就需要用到兩個方法：View中的setTag和getTag方法了。

經(jīng)過上面的做法，可能大家感覺不太到優(yōu)化的效果，根據(jù)Google的文檔，實際優(yōu)化效果在百分之5左右。

4.網(wǎng)絡(luò)數(shù)據(jù)過多加載緩慢優(yōu)化

問題：

ListView如果顯示本地的List集合中的內(nèi)容，List的長度也只有100個，我們可以毫不費力一次性加載完這100個數(shù)據(jù)；但是實際應(yīng)用中，我們往往會需要使用Listview來顯示網(wǎng)絡(luò)上的內(nèi)容，比如說我們拿使用ListView顯示新聞為例：假如網(wǎng)絡(luò)情況很好，我們使用的手機(jī)也許能夠一下子加載完所有新聞數(shù)據(jù)，然后顯示在ListView中，用戶可能感覺還好，假如說在網(wǎng)絡(luò)不太順暢的情況下，用戶加載完所有網(wǎng)絡(luò)的數(shù)據(jù)，可能這個list是1000條新聞，那么用戶可能需要面對一個空白的Activity好幾分鐘，這個顯然是不合適的。

解決：

我們需要進(jìn)行分批加載，比如說1000條新聞的List集合，我們一次加載20條，等到用戶翻頁到底部的時候，我們再添加下面的20條到List中，再使用Adapter刷新ListView，這樣用戶一次只需要等待20條數(shù)據(jù)的傳輸時間，不需要一次等待好幾分鐘把數(shù)據(jù)都加載完再在ListView上顯示。其次這樣也可以緩解很多條新聞一次加載進(jìn)行產(chǎn)生OOM應(yīng)用崩潰的情況。

5.加載數(shù)據(jù)過多內(nèi)存溢出優(yōu)化

問題：

我們知道Android虛擬機(jī)給每個應(yīng)用分配的運(yùn)行時內(nèi)存是一定的，一般性能不太好的機(jī)器只有16M，好一點的可能也就是64M的樣子，假如說我們現(xiàn)在要瀏覽的新聞總數(shù)為一萬條，即便是網(wǎng)絡(luò)很好的情況下，我們可以很快的加載完畢，但是多數(shù)情況下也會出現(xiàn)內(nèi)存溢出從而導(dǎo)致應(yīng)用崩潰的情況。

解決：

實際上，分批加載也不能完全解決問題，因為雖然我們在分批中一次只增加20條數(shù)據(jù)到List集合中，然后再刷新到ListView中去，假如有10萬條數(shù)據(jù)，如果我們順利讀到最后這個List集合中還是會累積海量條數(shù)的數(shù)據(jù)，還是可能會造成OOM的情況，這時候我們就需要用到分頁，比如說我們將這10萬條數(shù)據(jù)分為1000頁，每一頁100條數(shù)據(jù)，每一頁加載時都覆蓋掉上一頁中List集合中的內(nèi)容，然后每一頁內(nèi)再使用分批加載，這樣用戶的體驗就會相對好一些。

最新評論