ListView是Android中最常用的視圖之一，使用的頻率僅僅次于幾大基礎布局，雖然由于使用性和擴充性等原因備受争議，且盡管後來出現了RecyclerView的替代方案，但是ListView仍然廣泛地使用在我們的項目中。

自從ListView出道至今，已經不知道衍生出了多少問題，然而很多人隻關心功能功能的實作，卻極少關注ListView過度調用導緻的性能問題。在實際項目中，即使你正确使用了ViewHolder機制來優化ListView性能，但是在某些場景下依然會感覺卡頓嚴重，到底是什麼原因導緻的呢，我們來分析下

1 問題示範

很多時候，我們在使用ListView的時候，都是随手寫上一個layout_height=”wrap_content”或者layout_height=”match_parent”，非常正常的寫法，乍一看，并沒有什麼問題，尤其是功能實作上也是無可挑剔。

然而，就是layout_height=”wrap_content”這個屬性是導緻嚴重的性能問題的根源，下面以一個簡單的例子說明一下：

布局如上，接下來，假設ListView一共有5項，那麼顯示邏輯代碼如下：

下面，我們來看看log列印的情況:

數一數，一共是15次getView調用，其中6次convertView為null，剩餘9次convertView為複用，而ListView的資料源真正隻有5項！

當然，為了場景的簡單化，我們先不考慮ListView内容超過一螢幕的情況（也就是不考慮其複用機制），是以我們期待的情況應該是getView調用5次且convertView全部為null，而事實上getView多調用了10次且有一次convertView為null。

同樣的，我們測試一下當layout_height=”match_parent”的情況：

另外，ListView内容超過一螢幕的情況下（考慮複用機制），測試結果一樣，這裡就不再示範了。

在實際項目中，Adapter的getView方法承載着大量的業務邏輯，在性能方面，除去建立視圖的損耗，不正确的ListView使用方式導緻的性能損耗大約是正常的3倍左右！那麼到底是什麼原因導緻的呢？我們下面來簡單分析下ListView源碼。

2 ListView代碼分析

在示範了layout_height=”wrap_content”導緻性能問題的現象之後，我們來從源碼的角度分析下，出現這種過度調用問題的根本原因。（源碼以API 29為例）

2.1 onMeasure

首先，layout_height=”wrap_content”屬性意味着ListView的高度需要由子View決定，即在onMeasure的時候，需要一一測量子View的高度，是以我們先從其onMeasure方法入手。

wrap_content對應的mode為MeasureSpec.AT_MOST，是以很容易就能找測量子視圖高度的代碼measureHeightOfChildren，當然方法名也展現出來了，是以具體來看這個方法

核心代碼如上，很明顯，所有的子View執行個體都是由obtainView方法傳回的，然後再調用具體measureScrapChild來具體測量子View的高度，正常情況下這裡for循環的次數就等于所有子項的個數，不過特殊的是已測量的子View高度之和大于maxHeight就直接return出循環了。這種做法其實很好了解，ListView能顯示的最大高度就是螢幕的高度，如果有1000個子項，前面10項已經占滿了一螢幕了，那後面的990項就沒必要繼續測量高度了，這樣可以大大提高性能。

另外，當一個子View測量完了之後，會通過recycleBin加到複用緩存之中，畢竟這個View隻是測量了，還沒有加到視圖樹之中，完全是可以繼續複用的。

繼續來看obtainView方法的實作，源碼在AbsListView中。

obtainView方法裡面核心的代碼其實就兩行，首先從複用緩存中取出一個可以複用的View，然後作為參傳入getView中，也就是convertView。

這時我們梳理一下measure過程中調用getView的全過程：

A、測量第0項的時候，convertView肯定是null的，通常需要我們Inflate一個View傳回；

B、第0項測量結束，這個第0項的View就被加入到複用緩存當中了；

C、開始測量第1項，這時因為是有第0項的View緩存的，是以getView的參數convertView就是這個第0項的View緩存，然後重複B步驟添加到緩存，隻不過這個View緩存還是第0項的View；

D、繼續測量3、4、5…項，重複C。

是以，我們log中的情況是position=0，convertView=null，而position 1，2 … convertView都是同一個對象執行個體，即被複用第0項。

2.2 Layout

當Measure過程結束了，下面就要開始Layout過程了，由于onLayout方法代碼較多，我們直接pass，來看makeAndAddView方法，也就是真真建立View的代碼。

同樣的，子View執行個體都是由obtainView方法傳回的。這時候就有個小細節了，由于前面Measure的時候，第0項的View已經建立了并且加入到了複用緩存當中，這一次就可以直接拿出來繼續用了。接着建立第1，2 … 後面項的時候就沒複用緩存了，隻能一次次地Inflate。

是以，我們log中的情況是position=0，convertView複用第0項，而position 1，2 … convertView=null。

按理說，Layout之後，應該就不會在調用getView方法了，但是我們明顯能看到log仍然多了5次調用，那麼這又是怎麼回事呢？

前面說到onMeasure方法會導緻getView調用，而一個View的onMeasure方法調用時機并不是由自身決定，而是由其父視圖來決定。

ListView放在FrameLayout和RelativeLayout中其onMeasure方法的調用次數是完全不同的。

2.3 小結

由于onMeasure方法會多次被調用，例子中是兩次，其實完整的調用順序是onMeasure - onLayout - onMeasure - onLayout - onDraw。是以我們又會看到5次調用，和最前面5次是一模一樣的。

那麼，肯定有童鞋又要問，既然onLayout也被執行兩次，那為何不是調用5x2+5x2=20次呢？

在第2次onLayout的時候，由于資料并沒有變化，即mDataChanged=false，這時候可以直接用目前項已經存在的View了，不要再通過getView方法重新綁定資料，是以getView是不需要被調用的。

從上面的分析中，我們可以得到wrap_content情況下getView被調用的時機和次數，假設onMeasure（heightMeasureSpec為AT_MOST）次數為n，onLayout次數為m，ListView控件内同時顯示的子項數為i，那麼getView次數=（n + 1） i，正常情況match_parent時，getView次數= i，多餘的getView調用次數應該是（n + 1） i - i = n * i；

由公式可以看出getView多餘調用次數與onMeasure次數n以及顯示子項數i成正比關系。

3 三大基礎布局性能比較

1層嵌套：

A = FrameLayout