源码解析之ListView

摘要：大家元旦快乐好记性不如烂笔头，所以我准备弄个源码解析系列，不准备详细解析源码，但把基本原理和设计思想梳理清楚，也给自己留个笔记存档好在后面需要的时候翻起。所以可以理解为期间的一个临时产物。

大家元旦快乐~

好记性不如烂笔头，所以我准备弄个源码解析系列，不准备详细解析源码，但把基本原理和设计思想梳理清楚，也给自己留个笔记存档好在后面需要的时候翻起。

今天就从ListView开始。

ListView的核心在于layoutChildren函数，分两种情况，一种是全新加载，第二种是非全新加载。主要区别在于ListView内部的View缓存池的使用，下面依次来讲下。

在layoutChildren里面，会根据LayoutMode选择调用fillSpecific/fillUp/fillFromTop之类的函数来进行填充，这个只是策略问题不是很关键，最终这些函数都调用了makeAndAddView，然后再调用obtainView，再调用adapter.getView，拿到view之后再使用setupChild加入到ListView里面去并放好位置（包含child自己的measure），流程如下：

setupChild函数里面片段：

全新加载的很好理解，每个Item都是按照上面的流程走，并且每个Item的view都是通过getView里面inflate出来的（这种情况getView的convertView传过来是空，意味着ListView还没有缓存view可以使用）

非全新加载，比如页面滑动，或者adapter数据发生变化，这种情况下面整体流程和全新加载没有区别，但在部分函数调用里面有细微差别，比如：

layoutChildren里面首先将ListView的child都放入缓存池：

// Pull all children into the RecycleBin.
// These views will be reused if possible
final int firstPosition = mFirstPosition;
final RecycleBin recycleBin = mRecycler;
if (dataChanged) {
    for (int i = 0; i < childCount; i++) {
        recycleBin.addScrapView(getChildAt(i), firstPosition+i);
    }
} else {
    recycleBin.fillActiveViews(childCount, firstPosition);
}

缓存池管理就是这个RecycleBin对象，他里面有两种缓存，一种叫ActiveViews，看上面代码如果不是数据发生变化的非全新加载（比如页面滚动），则把所有子view都放入ActiveViews，然后重新计算位置重新摆放新的view的时候，就会首先从ActiveViews里面拿出缓存view，看makeAndAddView函数的第一段就是：

更巧妙的是，在拿ActiveView的缓存view的时候，会根据位置来拿，这样的view认为是不需要重新经过adapter的getView函数的，这样极大的提高了效率。（页面滚动的时候页面里面的item只是位置变化，不需要重新调用adapter.getView函数）

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;
}

假如ActiveViews里面拿不到缓存view了，比如ListView高度发生了变化，需要更多的view来填充，这个时候就会从另外一种缓存里面拿，叫做ScrapViews。这种缓存view是属于ListView被填满了，结果还剩余有view就会被放入到这个缓存池里面来。在layoutChildren函数的尾部可以看到有这样一段代码就是这个意思：

// Flush any cached views that did not get reused above
recycleBin.scrapActiveViews();

/**
 * Move all views remaining in mActiveViews to mScrapViews.
 */
void scrapActiveViews() {
    final View[] activeViews = mActiveViews;
    final boolean hasListener = mRecyclerListener != null;
    final boolean multipleScraps = mViewTypeCount > 1;

    ArrayList scrapViews = mCurrentScrap;
    final int count = activeViews.length;
    for (int i = count - 1; i >= 0; i--) {

.......

从ScrapViews拿缓存view的代码在obtainView里面：

final View scrapView = mRecycler.getScrapView(position);
final View child = mAdapter.getView(position, scrapView, this);
if (scrapView != null) {
    if (child != scrapView) {
        // Failed to re-bind the data, return scrap to the heap.
        mRecycler.addScrapView(scrapView, position);
    } else if (child.isTemporarilyDetached()) {
        outMetadata[0] = true;

        // Finish the temporary detach started in addScrapView().
        child.dispatchFinishTemporaryDetach();
    }
}

可以看到adapter.getView的第二个参数convertView就是从ScrapViews里面拿过来的缓存view，可能为空也可能不为空，所以我们的getView函数都要有null判断。

这样子我们就能串起来了，在makeAndAddView里面先看看ActiveViews里面有没有缓存view，有的话则直接成功返回也不需要调用adapter.getView。没有的话则继续调用obtainView，然后再去ScrapViews里面看看有没有缓存view，ScrapViews里面拿出来的view都需要重新经过adapter.getView进行重新刷数据。ScrapViews可能拿到缓存view也可能拿不到，所以getView实现需要null判断。

我们可以把ActiveViews和ScrapViews理解为一二级缓存，有效率上面的差别（很明显后者要经过getView重新绑定数据）

ListView的layoutChildren在开始的时候通过fillActiveViews将子view全部放到ActiveViews里面，然后等会重新布局的时候又首先从ActiveViews里面拿出来，不够用的时候再继续从ScrapViews里面拿，非常高效。所以ActiveViews可以理解为layout期间的一个临时产物。

整体流程就结束了，下面介绍下有些细节的地方可以从中学习到的。

View有onAttachedToWindow/onDetachFromWindow，还有一个不怎么常用的onStartTemporaryDetach/onFinishTemporaryDetach，表示开始和结束临时Detach，这种状态View其实没有真正触发onDetachFromWindow，只是临时的Detached了，在addScrapView函数里看到有调用start，view被放入ScrapViews缓存池了，临时被detach：

然后在obtainView里面，从ScrapViews里面重新拿出来要使用了，再调用finish：

这个临时detached挺有意思，结合ViewGroup的detachAllViewsFromParent（在layoutChildren里面一开始就会调用这个方法），让子view的parent都设成null，可以达到一些很巧妙的实现。

ScrapViews里面的缓存view有的是真正onDetachFromWindow，有的则是onStartTemporaryDetach，造成这个的原因主要是scrapActiveViews和addScrapView两个实现上的差异，不过这个不影响实际使用，obtainView里面会根据实际情况来决定拿到的缓存view是要重新attachToWindow还是finshTemporaryDetach，这个outMetData[0]（和mIsScrap[0]是同一个）就是标记缓存view是不是之前已经detachFromWiindow（之前是isTemporarilyDetached的，说明还未真正detachFromWindow）


然后setupChild里面会根据是不是attachedToWindow做不同的操作：重新指定parent（attachViewToParent）还是重新attachToWindow（addViewInLayout）

源码解析就怕别人看不懂，但愿对同学们有些帮助~

更多文章请关注微信公众号：安卓之美