Android開發中經過源碼完全理解ListView工做原理【超詳細】
Adapter的做用
Adapter 相信你們都不會陌生，咱們平時使用ListView的時候必定都會用到它。那麼話說回來你們有沒有仔細想過，爲何須要Adapter這個東西呢？總感受 正由於有了Adapter，ListView的使用變得要比其它控件複雜得多。那麼這裏咱們就先來學習一下Adapter到底起到了什麼樣的一個做用。
其 實說到底，控件就是爲了交互和展現數據用的，只不過ListView更加特殊，它是爲了展現不少不少數據用的，可是ListView只承擔交互和展現工做 而已，至於這些數據來自哪裏，ListView是不關心的。所以，咱們能設想到的最基本的ListView工做模式就是要有一個ListView控件和一 個數據源。
不過若是真的讓ListView和數據源直接打交道的話，那ListView所要作的適配工做就很是繁雜了。由於數據源這個概念太模糊了，咱們只知道它包含了不少數據而已，至於這個數據源究竟是什麼樣類型，並無嚴格的定義，有多是數組，也有多是集合，甚至有多是 數據庫表 中查詢出來的遊標。因此說若是ListView真的去爲每一種數據源都進行適配操做的話，一是擴展性會比較差，內置了幾種適配就只有幾種適配，不能動態進 行添加。二是超出了它自己應該負責的工做範圍，再也不是僅僅承擔交互和展現工做就能夠了，這樣ListView就會變得比較臃腫。
那麼顯然 Android開發團隊是不會容許這種事情發生的，因而就有了Adapter這樣一個機制的出現。顧名思義，Adapter是適配器的意思，它在 ListView和數據源之間起到了一個橋樑的做用，ListView並不會直接和數據源打交道，而是會藉助Adapter這個橋樑來去訪問真正的數據 源，與以前不一樣的是，Adapter的接口都是統一的，所以ListView不用再去擔憂任何適配方面的問題。而Adapter又是一個接口 (interface)，它能夠去實現各類各樣的子類，每一個子類都能經過本身的邏輯來去完成特定的功能，以及與特定數據源的適配操做，好比說 ArrayAdapter能夠用於數組和List類型的數據源適配，SimpleCursorAdapter能夠用於遊標類型的數據源適配，這樣就很是巧 妙地把數據源適配困難的問題解決掉了，而且還擁有至關不錯的擴展性。 php
固然Adapter的做用不只僅只有數據源適配這一點，還有一個很是很是重要的方法也須要咱們在Adapter當中去重寫，就是getView()方法，這個在下面的文章中還會詳細講到。 html
RecycleBin機制
那麼在開始分析ListView的源碼以前，還有一個東西是咱們提早須要了 解的，就是RecycleBin機制，這個機制也是ListView可以實現成百上千條數據都不會OOM最重要的一個緣由。其實RecycleBin的代 碼並很少，只有300行左右，它是寫在AbsListView中的一個內部類，因此全部繼承自AbsListView的子類，也就是ListView和 GridView，均可以使用這個機制。那咱們來看一下RecycleBin中的主要代碼，以下所示： android
/**
* The RecycleBin facilitates reuse of views across layouts. The RecycleBin
* has two levels of storage: ActiveViews and ScrapViews. ActiveViews are
* those views which were onscreen at the start of a layout. By
* construction, they are displaying current information. At the end of
* layout, all views in ActiveViews are demoted to ScrapViews. ScrapViews
* are old views that could potentially be used by the adapter to avoid
* allocating views unnecessarily.
*
* @see android.widget.AbsListView#setRecyclerListener(android.widget.AbsListView.RecyclerListener)
* @see android.widget.AbsListView.RecyclerListener
*/
class RecycleBin {
private RecyclerListener mRecyclerListener;
/**
* The position of the first view stored in mActiveViews.
*/
private int mFirstActivePosition;
/**
* Views that were on screen at the start of layout. This array is
* populated at the start of layout, and at the end of layout all view
* in mActiveViews are moved to mScrapViews. Views in mActiveViews
* represent a contiguous range of Views, with position of the first
* view store in mFirstActivePosition.
*/
private View[] mActiveViews = new View[0];
/**
* Unsorted views that can be used by the adapter as a convert view.
*/
private ArrayList[] mScrapViews;
private int mViewTypeCount;
private ArrayList mCurrentScrap;
/**
* Fill ActiveViews with all of the children of the AbsListView.
*
* @param childCount
* The minimum number of views mActiveViews should hold
* @param firstActivePosition
* The position of the first view that will be stored in
* mActiveViews
*/
void fillActiveViews(int childCount, int firstActivePosition) {
if (mActiveViews.length < childCount) {
mActiveViews = new View[childCount];
}
mFirstActivePosition = firstActivePosition;
final View[] activeViews = mActiveViews;
for (int i = 0; i < childCount; i++) {
View child = getChildAt(i);
AbsListView.LayoutParams lp = (AbsListView.LayoutParams) child.getLayoutParams();
// Don't put header or footer views into the scrap heap
if (lp != null && lp.viewType != ITEM_VIEW_TYPE_HEADER_OR_FOOTER) {
// Note: We do place AdapterView.ITEM_VIEW_TYPE_IGNORE in
// active views.
// However, we will NOT place them into scrap views.
activeViews[i] = child;
}
}
}
/**
* Get the view corresponding to the specified position. The view will
* be removed from mActiveViews if it is found.
*
* @param position
* The position to look up in mActiveViews
* @return The view if it is found, null otherwise
*/
View getActiveView(int position) {
int index = position - mFirstActivePosition;
final View[] activeViews = mActiveViews;
if (index >= 0 && index < activeViews.length) {
final View match = activeViews[index];
activeViews[index] = null;
return match;
}
return null;
}
/**
* Put a view into the ScapViews list. These views are unordered.
*
* @param scrap
* The view to add
*/
void addScrapView(View scrap) {
AbsListView.LayoutParams lp = (AbsListView.LayoutParams) scrap.getLayoutParams();
if (lp == null) {
return;
}
// Don't put header or footer views or views that should be ignored
// into the scrap heap
int viewType = lp.viewType;
if (!shouldRecycleViewType(viewType)) {
if (viewType != ITEM_VIEW_TYPE_HEADER_OR_FOOTER) {
removeDetachedView(scrap, false);
}
return;
}
if (mViewTypeCount == 1) {
dispatchFinishTemporaryDetach(scrap);
mCurrentScrap.add(scrap);
} else {
dispatchFinishTemporaryDetach(scrap);
mScrapViews[viewType].add(scrap);
}
if (mRecyclerListener != null) {
mRecyclerListener.onMovedToScrapHeap(scrap);
}
}
/**
* @return A view from the ScrapViews collection. These are unordered.
*/
View getScrapView(int position) {
ArrayList scrapViews;
if (mViewTypeCount == 1) {
scrapViews = mCurrentScrap;
int size = scrapViews.size();
if (size > 0) {
return scrapViews.remove(size - 1);
} else {
return null;
}
} else {
int whichScrap = mAdapter.getItemViewType(position);
if (whichScrap >= 0 && whichScrap < mScrapViews.length) {
scrapViews = mScrapViews[whichScrap];
int size = scrapViews.size();
if (size > 0) {
return scrapViews.remove(size - 1);
}
}
}
return null;
}
public void setViewTypeCount(int viewTypeCount) {
if (viewTypeCount < 1) {
throw new IllegalArgumentException("Can't have a viewTypeCount < 1");
}
// noinspection unchecked
ArrayList[] scrapViews = new ArrayList[viewTypeCount];
for (int i = 0; i < viewTypeCount; i++) {
scrapViews[i] = new ArrayList();
}
mViewTypeCount = viewTypeCount;
mCurrentScrap = scrapViews[0];
mScrapViews = scrapViews;
}
} 算法
這裏的RecycleBin代碼並不全，我只是把最主要的幾個方法提了出來。那麼咱們先來對這幾個方法進行簡單解讀，這對後面分析ListView的工做原理將會有很大的幫助。
fillActiveViews() 這個方法接收兩個參數，第一個參數表示要存儲的view的數量，第二個參數表示ListView中第一個可見元素的position值。 RecycleBin當中使用mActiveViews這個數組來存儲View，調用這個方法後就會根據傳入的參數來將ListView中的指定元素存儲 到mActiveViews數組當中。
getActiveView() 這個方法和fillActiveViews()是對應的，用於從mActiveViews數組當中獲取數據。該方法接收一個position參數，表示元 素在ListView當中的位置，方法內部會自動將position值轉換成mActiveViews數組對應的下標值。須要注意的 是，mActiveViews當中所存儲的View，一旦被獲取了以後就會從mActiveViews當中移除，下次獲取一樣位置的View將會返回 null，也就是說mActiveViews不能被重複利用。
addScrapView() 用於將一個廢棄的View進行緩存，該方法接收一個View參數，當有某個View肯定要廢棄掉的時候(好比滾動出了屏幕)，就應該調用這個方法來對 View進行緩存，RecycleBin當中使用mScrapViews和mCurrentScrap這兩個List來存儲廢棄View。
getScrapView 用於從廢棄緩存中取出一個View，這些廢棄緩存中的View是沒有順序可言的，所以getScrapView()方法中的算法也很是簡單，就是直接從mCurrentScrap當中獲取尾部的一個scrap view進行返回。
setViewTypeCount() 咱們都知道Adapter當中能夠重寫一個getViewTypeCount()來表示ListView中有幾種類型的數據項，而 setViewTypeCount()方法的做用就是爲每種類型的數據項都單獨啓用一個RecycleBin緩存機制。實際 上，getViewTypeCount()方法一般狀況下使用的並非不少，因此咱們只要知道RecycleBin當中有這樣一個功能就好了。
了 解了RecycleBin中的主要方法以及它們的用處以後，下面就能夠開始來分析ListView的工做原理了，這裏我將仍是按照之前分析源碼的方式來進 行，即跟着主線執行流程來逐步閱讀並點到即止，否則的話要是把ListView全部的代碼都貼出來，那麼本篇文章將會很長很長了。 數據庫
第一次Layout
無論怎麼說，ListView即便再特殊最終仍是繼承自View的，所以它的執行流程還將會按照View的規則來執行，對於這方面不太熟悉的朋友能夠參考我以前寫的 Android視圖繪製流程徹底解析，帶你一步步深刻了解View(二) 。
View 的執行流程無非就分爲三步，onMeasure()用於測量View的大小，onLayout()用於肯定View的佈局，onDraw()用於將 View繪製到界面上。而在ListView當中，onMeasure()並無什麼特殊的地方，由於它終歸是一個View，佔用的空間最多而且一般也就 是整個屏幕。onDraw()在ListView當中也沒有什麼意義，由於ListView自己並不負責繪製，而是由ListView當中的子元素來進行 繪製的。那麼ListView大部分的神奇功能其實都是在onLayout()方法中進行的了，所以咱們本篇文章也是主要分析的這個方法裏的內容。
若是你到ListView源碼中去找一找，你會發現ListView中是沒有onLayout()這個方法的，這是由於這個方法是在ListView的父類AbsListView中實現的，代碼以下所示： 數組
/**
* Subclasses should NOT override this method but {@link #layoutChildren()}
* instead.
*/
@Override
protected void onLayout(boolean changed, int l, int t, int r, int b) {
super.onLayout(changed, l, t, r, b);
mInLayout = true;
if (changed) {
int childCount = getChildCount();
for (int i = 0; i < childCount; i++) {
getChildAt(i).forceLayout();
}
mRecycler.markChildrenDirty();
}
layoutChildren();
mInLayout = false;
} 緩存
能夠看到，onLayout()方法中並無作什麼複雜的邏輯操做，主要就是一個判斷，若是ListView的大小或者位置發生了變化，那麼 changed變量就會變成true，此時會要求全部的子佈局都強制進行重繪。除此以外倒沒有什麼難理解的地方了，不過咱們注意到，在第16行調用了 layoutChildren()這個方法，從方法名上咱們就能夠猜出這個方法是用來進行子元素佈局的，不過進入到這個方法當中你會發現這是個空方法，沒 有一行代碼。這固然是能夠理解的了，由於子元素的佈局應該是由具體的實現類來負責完成的，而不是由父類完成。那麼進入ListView的 layoutChildren()方法，代碼以下所示： app
@Override
protected void layoutChildren() {
final boolean blockLayoutRequests = mBlockLayoutRequests;
if (!blockLayoutRequests) {
mBlockLayoutRequests = true;
} else {
return;
}
try {
super.layoutChildren();
invalidate();
if (mAdapter == null) {
resetList();
invokeOnItemScrollListener();
return;
}
int childrenTop = mListPadding.top;
int childrenBottom = getBottom() - getTop() - mListPadding.bottom;
int childCount = getChildCount();
int index = 0;
int delta = 0;
View sel;
View oldSel = null;
View oldFirst = null;
View newSel = null;
View focusLayoutRestoreView = null;
// Remember stuff we will need down below
switch (mLayoutMode) {
case LAYOUT_SET_SELECTION:
index = mNextSelectedPosition - mFirstPosition;
if (index >= 0 && index < childCount) {
newSel = getChildAt(index);
}
break;
case LAYOUT_FORCE_TOP:
case LAYOUT_FORCE_BOTTOM:
case LAYOUT_SPECIFIC:
case LAYOUT_SYNC:
break;
case LAYOUT_MOVE_SELECTION:
default:
// Remember the previously selected view
index = mSelectedPosition - mFirstPosition;
if (index >= 0 && index < childCount) {
oldSel = getChildAt(index);
}
// Remember the previous first child
oldFirst = getChildAt(0);
if (mNextSelectedPosition >= 0) {
delta = mNextSelectedPosition - mSelectedPosition;
}
// Caution: newSel might be null
newSel = getChildAt(index + delta);
}
boolean dataChanged = mDataChanged;
if (dataChanged) {
handleDataChanged();
}
// Handle the empty set by removing all views that are visible
// and calling it a day
if (mItemCount == 0) {
resetList();
invokeOnItemScrollListener();
return;
} else if (mItemCount != mAdapter.getCount()) {
throw new IllegalStateException("The content of the adapter has changed but "
+ "ListView did not receive a notification. Make sure the content of "
+ "your adapter is not modified from a background thread, but only "
+ "from the UI thread. [in ListView(" + getId() + ", " + getClass()
+ ") with Adapter(" + mAdapter.getClass() + ")]");
}
setSelectedPositionInt(mNextSelectedPosition);
// Pull all children into the RecycleBin.
// These views will be reused if possible
final int firstPosition = mFirstPosition;
final RecycleBin recycleBin = mRecycler;
// reset the focus restoration
View focusLayoutRestoreDirectChild = null;
// Don't put header or footer views into the Recycler. Those are
// already cached in mHeaderViews;
if (dataChanged) {
for (int i = 0; i < childCount; i++) {
recycleBin.addScrapView(getChildAt(i));
if (ViewDebug.TRACE_RECYCLER) {
ViewDebug.trace(getChildAt(i),
ViewDebug.RecyclerTraceType.MOVE_TO_SCRAP_HEAP, index, i);
}
}
} else {
recycleBin.fillActiveViews(childCount, firstPosition);
}
// take focus back to us temporarily to avoid the eventual
// call to clear focus when removing the focused child below
// from messing things up when ViewRoot assigns focus back
// to someone else
final View focusedChild = getFocusedChild();
if (focusedChild != null) {
// TODO: in some cases focusedChild.getParent() == null
// we can remember the focused view to restore after relayout if the
// data hasn't changed, or if the focused position is a header or footer
if (!dataChanged || isDirectChildHeaderOrFooter(focusedChild)) {
focusLayoutRestoreDirectChild = focusedChild;
// remember the specific view that had focus
focusLayoutRestoreView = findFocus();
if (focusLayoutRestoreView != null) {
// tell it we are going to mess with it
focusLayoutRestoreView.onStartTemporaryDetach();
}
}
requestFocus();
}
// Clear out old views
detachAllViewsFromParent();
switch (mLayoutMode) {
case LAYOUT_SET_SELECTION:
if (newSel != null) {
sel = fillFromSelection(newSel.getTop(), childrenTop, childrenBottom);
} else {
sel = fillFromMiddle(childrenTop, childrenBottom);
}
break;
case LAYOUT_SYNC:
sel = fillSpecific(mSyncPosition, mSpecificTop);
break;
case LAYOUT_FORCE_BOTTOM:
sel = fillUp(mItemCount - 1, childrenBottom);
adjustViewsUpOrDown();
break;
case LAYOUT_FORCE_TOP:
mFirstPosition = 0;
sel = fillFromTop(childrenTop);
adjustViewsUpOrDown();
break;
case LAYOUT_SPECIFIC:
sel = fillSpecific(reconcileSelectedPosition(), mSpecificTop);
break;
case LAYOUT_MOVE_SELECTION:
sel = moveSelection(oldSel, newSel, delta, childrenTop, childrenBottom);
break;
default:
if (childCount == 0) {
if (!mStackFromBottom) {
final int position = lookForSelectablePosition(0, true);
setSelectedPositionInt(position);
sel = fillFromTop(childrenTop);
} else {
final int position = lookForSelectablePosition(mItemCount - 1, false);
setSelectedPositionInt(position);
sel = fillUp(mItemCount - 1, childrenBottom);
}
} else {
if (mSelectedPosition >= 0 && mSelectedPosition < mItemCount) {
sel = fillSpecific(mSelectedPosition,
oldSel == null ? childrenTop : oldSel.getTop());
} else if (mFirstPosition < mItemCount) {
sel = fillSpecific(mFirstPosition,
oldFirst == null ? childrenTop : oldFirst.getTop());
} else {
sel = fillSpecific(0, childrenTop);
}
}
break;
}
// Flush any cached views that did not get reused above
recycleBin.scrapActiveViews();
if (sel != null) {
// the current selected item should get focus if items
// are focusable
if (mItemsCanFocus && hasFocus() && !sel.hasFocus()) {
final boolean focusWasTaken = (sel == focusLayoutRestoreDirectChild &&
focusLayoutRestoreView.requestFocus()) || sel.requestFocus();
if (!focusWasTaken) {
// selected item didn't take focus, fine, but still want
// to make sure something else outside of the selected view
// has focus
final View focused = getFocusedChild();
if (focused != null) {
focused.clearFocus();
}
positionSelector(sel);
} else {
sel.setSelected(false);
mSelectorRect.setEmpty();
}
} else {
positionSelector(sel);
}
mSelectedTop = sel.getTop();
} else {
if (mTouchMode > TOUCH_MODE_DOWN && mTouchMode < TOUCH_MODE_SCROLL) {
View child = getChildAt(mMotionPosition - mFirstPosition);
if (child != null) positionSelector(child);
} else {
mSelectedTop = 0;
mSelectorRect.setEmpty();
}
// even if there is not selected position, we may need to restore
// focus (i.e. something focusable in touch mode)
if (hasFocus() && focusLayoutRestoreView != null) {
focusLayoutRestoreView.requestFocus();
}
}
// tell focus view we are done mucking with it, if it is still in
// our view hierarchy.
if (focusLayoutRestoreView != null
&& focusLayoutRestoreView.getWindowToken() != null) {
focusLayoutRestoreView.onFinishTemporaryDetach();
}
mLayoutMode = LAYOUT_NORMAL;
mDataChanged = false;
mNeedSync = false;
setNextSelectedPositionInt(mSelectedPosition);
updateScrollIndicators();
if (mItemCount > 0) {
checkSelectionChanged();
}
invokeOnItemScrollListener();
} finally {
if (!blockLayoutRequests) {
mBlockLayoutRequests = false;
}
}
} ide
這段代碼比較長，咱們挑重點的看。首先能夠肯定的是，ListView當中目前尚未任何子View，數據都仍是由Adapter管理的，並無展現到界 面上，所以第19行getChildCount()方法獲得的值確定是0。接着在第81行會根據dataChanged這個布爾型的值來判斷執行邏 輯，dataChanged只有在數據源發生改變的狀況下才會變成true，其它狀況都是false，所以這裏會進入到第90行的執行邏輯，調用 RecycleBin的fillActiveViews()方法。按理來講，調用fillActiveViews()方法是爲了將ListView的子 View進行緩存的，但是目前ListView中尚未任何的子View，所以這一行暫時還起不了任何做用。
接下來在第114行會根據 mLayoutMode的值來決定佈局模式，默認狀況下都是普通模式LAYOUT_NORMAL，所以會進入到第140行的default語句當中。而下 面又會緊接着進行兩次if判斷，childCount目前是等於0的，而且默認的佈局順序是從上往下，所以會進入到第145行的 fillFromTop()方法，咱們跟進去瞧一瞧： 佈局
/**
* Fills the list from top to bottom, starting with mFirstPosition
*
* @param nextTop The location where the top of the first item should be
* drawn
*
* @return The view that is currently selected
*/
private View fillFromTop(int nextTop) {
mFirstPosition = Math.min(mFirstPosition, mSelectedPosition);
mFirstPosition = Math.min(mFirstPosition, mItemCount - 1);
if (mFirstPosition < 0) {
mFirstPosition = 0;
}
return fillDown(mFirstPosition, nextTop);
}
從這個方法的註釋中能夠看出，它所負責的主要任務就是從mFirstPosition開始，自頂至底去填充ListView。而這個方法自己並無什麼邏 輯，就是判斷了一下mFirstPosition值的合法性，而後調用fillDown()方法，那麼咱們就有理由能夠猜想，填充ListView的操做 是在fillDown()方法中完成的。進入fillDown()方法，代碼以下所示：
/**
* Fills the list from pos down to the end of the list view.
*
* @param pos The first position to put in the list
*
* @param nextTop The location where the top of the item associated with pos
* should be drawn
*
* @return The view that is currently selected, if it happens to be in the
* range that we draw.
*/
private View fillDown(int pos, int nextTop) {
View selectedView = null;
int end = (getBottom() - getTop()) - mListPadding.bottom;
while (nextTop < end && pos < mItemCount) {
// is this the selected item?
boolean selected = pos == mSelectedPosition;
View child = makeAndAddView(pos, nextTop, true, mListPadding.left, selected);
nextTop = child.getBottom() + mDividerHeight;
if (selected) {
selectedView = child;
}
pos++;
}
return selectedView;
}
能夠看到，這裏使用了一個while循環來執行重複邏輯，一開始nextTop的值是第一個子元素頂部距離整個ListView頂部的像素值，pos則是 剛剛傳入的mFirstPosition的值，而end是ListView底部減去頂部所得的像素值，mItemCount則是Adapter中的元素數 量。所以一開始的狀況下nextTop一定是小於end值的，而且pos也是小於mItemCount值的。那麼每執行一次while循環，pos的值都 會加1，而且nextTop也會增長，當nextTop大於等於end時，也就是子元素已經超出當前屏幕了，或者pos大於等於mItemCount時， 也就是全部Adapter中的元素都被遍歷結束了，就會跳出while循環。
那麼while循環當中又作了什麼事情呢？值得讓人留意的就是第18行調用的makeAndAddView()方法，進入到這個方法當中，代碼以下所示
private View makeAndAddView(int position, int y, boolean flow, int childrenLeft,
View obtainView(int position, boolean[] isScrap) {
那麼咱們平時寫ListView的Adapter時，getView()方法一般會怎麼寫呢？這裏我舉個簡單的例子：
public View getView(int position, View convertView, ViewGroup parent) {
那麼這個View也會做 爲obtainView()的結果進行返回，並最終傳入到setupChild()方法當中。其實也就是說，第一次layout過程中，全部的子 View都是調用LayoutInflater的inflate()方法加載出來的，這樣就會相對比較耗時，可是不用擔憂，後面就不會再有這種狀況了，那 麼咱們繼續往下看：
/**
那麼到此爲止，第一次Layout過程結束。
第二次Layout
雖 然我在源碼中並無找出具體的緣由，但若是你本身作一下實驗的話就會發現，即便是一個再簡單的View，在展現到界面上以前都會經歷至少兩次 onMeasure()和兩次onLayout()的過程。其實這只是一個很小的細節，平時對咱們影響並不大，由於無論是onMeasure()或者 onLayout()幾回，反正都是執行的相同的邏輯，咱們並不須要進行過多關心。可是在ListView中狀況就不同了，由於這就意味着 layoutChildren()過程會執行兩次，而這個過程中涉及到向ListView中添加子元素，若是相同的邏輯執行兩遍的話，那麼 ListView中就會存在一份重複的數據了。所以ListView在layoutChildren()過程中作了第二次Layout的邏輯處理，很是 巧妙地解決了這個問題，下面咱們就來分析一下第二次Layout的過程。
其實第二次Layout和第一次Layout的基本流程是差很少的，那麼咱們仍是從layoutChildren()方法開始看起：
protected void layoutChildren() {
接下來將會是很是很是重要的一個操 做，在第113行調用了detachAllViewsFromParent()方法。這個方法會將全部ListView當中的子View所有清除掉，從而 保證第二次Layout過程不會產生一份重複的數據。那有的朋友可能會問了，這樣把已經加載好的View又清除掉，待會還要再從新加載一遍，這不是嚴重影 響效率嗎？不用擔憂，還記得咱們剛剛調用了RecycleBin的fillActiveViews()方法來緩存子View嗎，待會兒將會直接使用這些緩 存好的View來進行加載，而並不會從新執行一遍inflate過程，所以效率方面並不會有什麼明顯的影響。
那麼咱們接着看，在第141 行的判斷邏輯當中，因爲再也不等於0了，所以會進入到else語句當中。而else語句中又有三個邏輯判斷，第一個邏輯判斷不成立，由於默認狀況下咱們沒有 選中任何子元素，mSelectedPosition應該等於-1。第二個邏輯判斷一般是成立的，由於mFirstPosition的值一開始是等於0 的，只要adapter中的數據大於0條件就成立。那麼進入到fillSpecific()方法當中，代碼以下所示：
/**
* Put a specific item at a specific location on the screen and then build
* up and down from there.
*
* @param position The reference view to use as the starting point
* @param top Pixel offset from the top of this view to the top of the
* reference view.
*
* @return The selected view, or null if the selected view is outside the
* visible area.
*/
private View fillSpecific(int position, int top) {
boolean tempIsSelected = position == mSelectedPosition;
View temp = makeAndAddView(position, top, true, mListPadding.left, tempIsSelected);
// Possibly changed again in fillUp if we add rows above this one.
mFirstPosition = position;
View above;
View below;
final int dividerHeight = mDividerHeight;
if (!mStackFromBottom) {
above = fillUp(position - 1, temp.getTop() - dividerHeight);
// This will correct for the top of the first view not touching the top of the list
adjustViewsUpOrDown();
below = fillDown(position + 1, temp.getBottom() + dividerHeight);
int childCount = getChildCount();
if (childCount > 0) {
correctTooHigh(childCount);
}
} else {
below = fillDown(position + 1, temp.getBottom() + dividerHeight);
// This will correct for the bottom of the last view not touching the bottom of the list
adjustViewsUpOrDown();
above = fillUp(position - 1, temp.getTop() - dividerHeight);
int childCount = getChildCount();
if (childCount > 0) {
correctTooLow(childCount);
}
}
if (tempIsSelected) {
return temp;
} else if (above != null) {
return above;
} else {
return below;
}
}
fillSpecific()這算是一個新方法了，不過其實它和fillUp()、fillDown()方法功能也是差很少的，主要的區別在 於，fillSpecific()方法會優先將指定位置的子View先加載到屏幕上，而後再加載該子View往上以及往下的其它子View。那麼因爲這裏 咱們傳入的position就是第一個子View的位置，因而fillSpecific()方法的做用就基本上和fillDown()方法是差很少的了， 這裏咱們就不去關注太多它的細節，而是將精力放在makeAndAddView()方法上面。再次回到makeAndAddView()方法，代碼以下所 示：
private View makeAndAddView(int position, int y, boolean flow, int childrenLeft,
注意在第23行，setupChild()方法的最後一個參數傳入的是true，這個參數代表當前的View是以前被回收過的，那麼咱們再次回到setupChild()方法當中：
private void setupChild(View child, int position, int y, boolean flowDown, int childrenLeft,
經歷了這樣一個detach又attach的過程，ListView中全部的子View又均可以正常顯示出來了，那麼第二次Layout過程結束。
滑動加載更多數據
經 歷了兩次Layout過程，雖然說咱們已經能夠在ListView中看到內容了，然而關於ListView最神奇的部分咱們卻尚未接觸到，由於目前 ListView中只是加載並顯示了第一屏的數據而已。好比說咱們的Adapter當中有1000條數據，可是第一屏只顯示了10條，ListView中 也只有10個子View而已，那麼剩下的990是怎樣工做並顯示到界面上的呢？這就要看一下ListView滑動部分的源碼了，由於咱們是經過手指滑動來 顯示更多數據的。
因爲滑動部分的機制是屬於通用型的，即ListView和GridView都會使用一樣的機制，所以這部分代碼就確定是 寫在AbsListView當中的了。那麼監聽觸控事件是在onTouchEvent()方法當中進行的，咱們就來看一下AbsListView中的這個 方法：
@Override
public boolean onTouchEvent(MotionEvent ev) {
if (!isEnabled()) {
// A disabled view that is clickable still consumes the touch
// events, it just doesn't respond to them.
return isClickable() || isLongClickable();
}
final int action = ev.getAction();
View v;
int deltaY;
if (mVelocityTracker == null) {
mVelocityTracker = VelocityTracker.obtain();
}
mVelocityTracker.addMovement(ev);
switch (action & MotionEvent.ACTION_MASK) {
case MotionEvent.ACTION_DOWN: {
mActivePointerId = ev.getPointerId(0);
final int x = (int) ev.getX();
final int y = (int) ev.getY();
int motionPosition = pointToPosition(x, y);
if (!mDataChanged) {
if ((mTouchMode != TOUCH_MODE_FLING) && (motionPosition >= 0)
&& (getAdapter().isEnabled(motionPosition))) {
// User clicked on an actual view (and was not stopping a
// fling). It might be a
// click or a scroll. Assume it is a click until proven
// otherwise
mTouchMode = TOUCH_MODE_DOWN;
// FIXME Debounce
if (mPendingCheckForTap == null) {
mPendingCheckForTap = new CheckForTap();
}
postDelayed(mPendingCheckForTap, ViewConfiguration.getTapTimeout());
} else {
if (ev.getEdgeFlags() != 0 && motionPosition < 0) {
// If we couldn't find a view to click on, but the down
// event was touching
// the edge, we will bail out and try again. This allows
// the edge correcting
// code in ViewRoot to try to find a nearby view to
// select
return false;
}
if (mTouchMode == TOUCH_MODE_FLING) {
// Stopped a fling. It is a scroll.
createScrollingCache();
mTouchMode = TOUCH_MODE_SCROLL;
mMotionCorrection = 0;
motionPosition = findMotionRow(y);
reportScrollStateChange(OnScrollListener.SCROLL_STATE_TOUCH_SCROLL);
}
}
}
if (motionPosition >= 0) {
// Remember where the motion event started
v = getChildAt(motionPosition - mFirstPosition);
mMotionViewOriginalTop = v.getTop();
}
mMotionX = x;
mMotionY = y;
mMotionPosition = motionPosition;
mLastY = Integer.MIN_VALUE;
break;
}
case MotionEvent.ACTION_MOVE: {
final int pointerIndex = ev.findPointerIndex(mActivePointerId);
final int y = (int) ev.getY(pointerIndex);
deltaY = y - mMotionY;
switch (mTouchMode) {
case TOUCH_MODE_DOWN:
case TOUCH_MODE_TAP:
case TOUCH_MODE_DONE_WAITING:
// Check if we have moved far enough that it looks more like a
// scroll than a tap
startScrollIfNeeded(deltaY);
break;
case TOUCH_MODE_SCROLL:
if (PROFILE_SCROLLING) {
if (!mScrollProfilingStarted) {
Debug.startMethodTracing("AbsListViewScroll");
mScrollProfilingStarted = true;
}
}
if (y != mLastY) {
deltaY -= mMotionCorrection;
int incrementalDeltaY = mLastY != Integer.MIN_VALUE ? y - mLastY : deltaY;
// No need to do all this work if we're not going to move
// anyway
boolean atEdge = false;
if (incrementalDeltaY != 0) {
atEdge = trackMotionScroll(deltaY, incrementalDeltaY);
}
// Check to see if we have bumped into the scroll limit
if (atEdge && getChildCount() > 0) {
// Treat this like we're starting a new scroll from the
// current
// position. This will let the user start scrolling back
// into
// content immediately rather than needing to scroll
// back to the
// point where they hit the limit first.
int motionPosition = findMotionRow(y);
if (motionPosition >= 0) {
final View motionView = getChildAt(motionPosition - mFirstPosition);
mMotionViewOriginalTop = motionView.getTop();
}
mMotionY = y;
mMotionPosition = motionPosition;
invalidate();
}
mLastY = y;
}
break;
}
break;
}
case MotionEvent.ACTION_UP: {
switch (mTouchMode) {
case TOUCH_MODE_DOWN:
case TOUCH_MODE_TAP:
case TOUCH_MODE_DONE_WAITING:
final int motionPosition = mMotionPosition;
final View child = getChildAt(motionPosition - mFirstPosition);
if (child != null && !child.hasFocusable()) {
if (mTouchMode != TOUCH_MODE_DOWN) {
child.setPressed(false);
}
if (mPerformClick == null) {
mPerformClick = new PerformClick();
}
final AbsListView.PerformClick performClick = mPerformClick;
performClick.mChild = child;
performClick.mClickMotionPosition = motionPosition;
performClick.rememberWindowAttachCount();
mResurrectToPosition = motionPosition;
if (mTouchMode == TOUCH_MODE_DOWN || mTouchMode == TOUCH_MODE_TAP) {
final Handler handler = getHandler();
if (handler != null) {
handler.removeCallbacks(mTouchMode == TOUCH_MODE_DOWN ? mPendingCheckForTap
: mPendingCheckForLongPress);
}
mLayoutMode = LAYOUT_NORMAL;
if (!mDataChanged && mAdapter.isEnabled(motionPosition)) {
mTouchMode = TOUCH_MODE_TAP;
setSelectedPositionInt(mMotionPosition);
layoutChildren();
child.setPressed(true);
positionSelector(child);
setPressed(true);
if (mSelector != null) {
Drawable d = mSelector.getCurrent();
if (d != null && d instanceof TransitionDrawable) {
((TransitionDrawable) d).resetTransition();
}
}
postDelayed(new Runnable() {
public void run() {
child.setPressed(false);
setPressed(false);
if (!mDataChanged) {
post(performClick);
}
mTouchMode = TOUCH_MODE_REST;
}
}, ViewConfiguration.getPressedStateDuration());
} else {
mTouchMode = TOUCH_MODE_REST;
}
return true;
} else if (!mDataChanged && mAdapter.isEnabled(motionPosition)) {
post(performClick);
}
}
mTouchMode = TOUCH_MODE_REST;
break;
case TOUCH_MODE_SCROLL:
final int childCount = getChildCount();
if (childCount > 0) {
if (mFirstPosition == 0
&& getChildAt(0).getTop() >= mListPadding.top
&& mFirstPosition + childCount < mItemCount
&& getChildAt(childCount - 1).getBottom() mMinimumVelocity) {
if (mFlingRunnable == null) {
mFlingRunnable = new FlingRunnable();
}
reportScrollStateChange(OnScrollListener.SCROLL_STATE_FLING);
mFlingRunnable.start(-initialVelocity);
} else {
mTouchMode = TOUCH_MODE_REST;
reportScrollStateChange(OnScrollListener.SCROLL_STATE_IDLE);
}
}
} else {
mTouchMode = TOUCH_MODE_REST;
reportScrollStateChange(OnScrollListener.SCROLL_STATE_IDLE);
}
break;
}
setPressed(false);
// Need to redraw since we probably aren't drawing the selector
// anymore
invalidate();
final Handler handler = getHandler();
if (handler != null) {
handler.removeCallbacks(mPendingCheckForLongPress);
}
if (mVelocityTracker != null) {
mVelocityTracker.recycle();
mVelocityTracker = null;
}
mActivePointerId = INVALID_POINTER;
if (PROFILE_SCROLLING) {
if (mScrollProfilingStarted) {
Debug.stopMethodTracing();
mScrollProfilingStarted = false;
}
}
break;
}
case MotionEvent.ACTION_CANCEL: {
mTouchMode = TOUCH_MODE_REST;
setPressed(false);
View motionView = this.getChildAt(mMotionPosition - mFirstPosition);
if (motionView != null) {
motionView.setPressed(false);
}
clearScrollingCache();
final Handler handler = getHandler();
if (handler != null) {
handler.removeCallbacks(mPendingCheckForLongPress);
}
if (mVelocityTracker != null) {
mVelocityTracker.recycle();
mVelocityTracker = null;
}
mActivePointerId = INVALID_POINTER;
break;
}
case MotionEvent.ACTION_POINTER_UP: {
onSecondaryPointerUp(ev);
final int x = mMotionX;
final int y = mMotionY;
final int motionPosition = pointToPosition(x, y);
if (motionPosition >= 0) {
// Remember where the motion event started
v = getChildAt(motionPosition - mFirstPosition);
mMotionViewOriginalTop = v.getTop();
mMotionPosition = motionPosition;
}
mLastY = y;
break;
}
}
return true;
}
這個方法中的代碼就很是多了，由於它所處理的邏輯也很是多，要監聽各類各樣的觸屏事件。可是咱們目前所關心的就只有手指在屏幕上滑動這一個事件而已，對應的是ACTION_MOVE這個動做，那麼咱們就只看這部分代碼就能夠了。
可 以看到，ACTION_MOVE這個case裏面又嵌套了一個switch語句，是根據當前的TouchMode來選擇的。那這裏我能夠直接告訴你們，當 手指在屏幕上滑動時，TouchMode是等於TOUCH_MODE_SCROLL這個值的，至於爲何那又要牽扯到另外的好幾個方法，這裏限於篇幅緣由 就再也不展開講解了，喜歡尋根究底的朋友們能夠本身去源碼裏找一找緣由。
這樣的話，代碼就應該會走到第78行的這個case裏面去了，在這 個case當中並無什麼太多須要注意的東西，惟一一點很是重要的就是第92行調用的trackMotionScroll()方法，至關於咱們手指只要在 屏幕上稍微有一點點移動，這個方法就會被調用，而若是是正常在屏幕上滑動的話，那麼這個方法就會被調用不少次。那麼咱們進入到這個方法中瞧一瞧，代碼以下 所示：
boolean trackMotionScroll(int deltaY, int incrementalDeltaY) {
final int childCount = getChildCount();
if (childCount == 0) {
return true;
}
final int firstTop = getChildAt(0).getTop();
final int lastBottom = getChildAt(childCount - 1).getBottom();
final Rect listPadding = mListPadding;
final int spaceAbove = listPadding.top - firstTop;
final int end = getHeight() - listPadding.bottom;
final int spaceBelow = lastBottom - end;
final int height = getHeight() - getPaddingBottom() - getPaddingTop();
if (deltaY < 0) {
deltaY = Math.max(-(height - 1), deltaY);
} else {
deltaY = Math.min(height - 1, deltaY);
}
if (incrementalDeltaY < 0) {
incrementalDeltaY = Math.max(-(height - 1), incrementalDeltaY);
} else {
incrementalDeltaY = Math.min(height - 1, incrementalDeltaY);
}
final int firstPosition = mFirstPosition;
if (firstPosition == 0 && firstTop >= listPadding.top && deltaY >= 0) {
// Don't need to move views down if the top of the first position
// is already visible
return true;
}
if (firstPosition + childCount == mItemCount && lastBottom <= end && deltaY <= 0) {
// Don't need to move views up if the bottom of the last position
// is already visible
return true;
}
final boolean down = incrementalDeltaY < 0;
final boolean inTouchMode = isInTouchMode();
if (inTouchMode) {
hideSelector();
}
final int headerViewsCount = getHeaderViewsCount();
final int footerViewsStart = mItemCount - getFooterViewsCount();
int start = 0;
int count = 0;
if (down) {
final int top = listPadding.top - incrementalDeltaY;
for (int i = 0; i < childCount; i++) {
final View child = getChildAt(i);
if (child.getBottom() >= top) {
break;
} else {
count++;
int position = firstPosition + i;
if (position >= headerViewsCount && position < footerViewsStart) {
mRecycler.addScrapView(child);
}
}
}
} else {
final int bottom = getHeight() - listPadding.bottom - incrementalDeltaY;
for (int i = childCount - 1; i >= 0; i--) {
final View child = getChildAt(i);
if (child.getTop() = headerViewsCount && position < footerViewsStart) {
mRecycler.addScrapView(child);
}
}
}
}
mMotionViewNewTop = mMotionViewOriginalTop + deltaY;
mBlockLayoutRequests = true;
if (count > 0) {
detachViewsFromParent(start, count);
}
offsetChildrenTopAndBottom(incrementalDeltaY);
if (down) {
mFirstPosition += count;
}
invalidate();
final int absIncrementalDeltaY = Math.abs(incrementalDeltaY);
if (spaceAbove < absIncrementalDeltaY || spaceBelow < absIncrementalDeltaY) {
fillGap(down);
}
if (!inTouchMode && mSelectedPosition != INVALID_POSITION) {
final int childIndex = mSelectedPosition - mFirstPosition;
if (childIndex >= 0 && childIndex < getChildCount()) {
positionSelector(getChildAt(childIndex));
}
}
mBlockLayoutRequests = false;
invokeOnItemScrollListener();
awakenScrollBars();
return false;
}
這個方法接收兩個參數，deltaY表示從手指按下時的位置到當前手指位置的距離，incrementalDeltaY則表示據上次觸發event事件手 指在Y方向上位置的改變量，那麼其實咱們就能夠經過incrementalDeltaY的正負值狀況來判斷用戶是向上仍是向下滑動的了。如第34行代碼所 示，若是incrementalDeltaY小於0，說明是向下滑動，不然就是向上滑動。
下面將會進行一個邊界值檢測的過程，能夠看到，從第43行開始，當ListView向下滑動的時候，就會進入一個for循環當 中，從上往下依次獲取子View，第47行當中，若是該子View的bottom值已經小於top值了，就說明這個子View已經移出屏幕了，因此會調用 RecycleBin的addScrapView()方法將這個View加入到廢棄緩存當中，並將count計數器加1，計數器用於記錄有多少個子 View被移出了屏幕。那麼若是是ListView向上滑動的話，其實過程是基本相同的，只不過變成了從下往上依次獲取子View，而後判斷該子View 的top值是否是大於bottom值了，若是大於的話說明子View已經移出了屏幕，一樣把它加入到廢棄緩存中，並將計數器加1。
接下來 在第76行，會根據當前計數器的值來進行一個detach操做，它的做用就是把全部移出屏幕的子View所有detach掉，在ListView的概念當 中，全部看不到的View就沒有必要爲它進行保存，由於屏幕外還有成百上千條數據等着顯示呢，一個好的回收策略才能保證ListView的高性能和高效 率。緊接着在第78行調用了offsetChildrenTopAndBottom()方法，並將incrementalDeltaY做爲參數傳入，這個 方法的做用是讓ListView中全部的子View都按照傳入的參數值進行相應的偏移，這樣就實現了隨着手指的拖動，ListView的內容也會隨着滾動 的效果。
而後在第84行會進行判斷，若是ListView中最後一個View的底部已經移入了屏幕，或者ListView中第一個 View的頂部移入了屏幕，就會調用fillGap()方法，那麼所以咱們就能夠猜出fillGap()方法是用來加載屏幕外數據的，進入到這個方法中瞧 一瞧，以下所示：
*/
private View makeAndAddView(int position, int y, boolean flow, int childrenLeft,
既然getActiveView()方法返回的值是null，那麼就仍是會走到第28行的obtainView()方法當中，代碼以下所示：
View obtainView(int position, boolean[] isScrap) {
那麼另外還有一點是須要你們留意的，這裏獲取到了一個scrapView，而後咱們在第22行將它做爲第二個參數傳入到了Adapter的getView()方法當中。那麼第二個參數是什麼意思呢？咱們再次看一下一個簡單的getView()方法示例
@Override
- 1. 經過自制CPU來完全理解CPU的工做原理
- 2. Android ListView工做原理徹底解析，帶你從源碼的角度完全理解
- 3. Android ListView原理之layout 源碼解析
- 4. 經過源碼理解Hystrix緩存的工做原理
- 5. android開發--ListView中的getView原理
- 6. 【超詳細】詳解！經典MOS 管電路工作原理
- 7. epoll詳細工做原理
- 8. 解析Android ListView工做原理及其緩存機制 解析Android ListView工做原理及其緩存機制
- 9. Android ListView工作原理完全解析，帶你從源碼的角度徹底理解
- 10. Kafka基本原理詳解（超詳細！）
- 更多相關文章...
- • MyBatis的工作原理 - MyBatis教程
- • TiDB數據庫的存儲原理（非常詳細） - NoSQL教程
- • PHP開發工具
- • Scala 中文亂碼解決
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. python的安裝和Hello，World編寫
- 2. 重磅解讀：K8s Cluster Autoscaler模塊及對應華爲雲插件Deep Dive
- 3. 鴻蒙學習筆記2（永不斷更）
- 4. static關鍵字 和構造代碼塊
- 5. JVM筆記
- 6. 無法啓動 C/C++ 語言服務器。IntelliSense 功能將被禁用。錯誤: Missing binary at c:\Users\MSI-NB\.vscode\extensions\ms-vsc
- 7. 【Hive】Hive返回碼狀態含義
- 8. Java樹形結構遞歸（以時間換空間）和非遞歸（以空間換時間）
- 9. 數據預處理---缺失值
- 10. 都要2021年了，現代C++有什麼值得我們學習的？
- 1. 經過自制CPU來完全理解CPU的工做原理
- 2. Android ListView工做原理徹底解析，帶你從源碼的角度完全理解
- 3. Android ListView原理之layout 源碼解析
- 4. 經過源碼理解Hystrix緩存的工做原理
- 5. android開發--ListView中的getView原理
- 6. 【超詳細】詳解！經典MOS 管電路工作原理
- 7. epoll詳細工做原理
- 8. 解析Android ListView工做原理及其緩存機制 解析Android ListView工做原理及其緩存機制
- 9. Android ListView工作原理完全解析，帶你從源碼的角度徹底理解
- 10. Kafka基本原理詳解（超詳細！）