源码解析之ListView

你们元旦快乐~缓存

好记性不如烂笔头,因此我准备弄个源码解析系列,不许备详细解析源码,但把基本原理和设计思想梳理清楚,也给本身留个笔记存档好在后面须要的时候翻起。微信

今天就从ListView开始。函数

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

在layoutChildren里面,会根据LayoutMode选择调用fillSpecific/fillUp/fillFromTop之类的函数来进行填充,这个只是策略问题不是很关键,最终这些函数都调用了makeAndAddView,而后再调用obtainView,再调用adapter.getView,拿到view以后再使用setupChild加入到ListView里面去并放好位置(包含child本身的measure),流程以下:学习

640?wx_fmt=png&wxfrom=5&wx_lazy=1

640?wx_fmt=png&wxfrom=5&wx_lazy=1

640?wx_fmt=png&wxfrom=5&wx_lazy=1

640?wx_fmt=png&wxfrom=5&wx_lazy=1

setupChild函数里面片断:
640?wx_fmt=png&wxfrom=5&wx_lazy=1this

全新加载的很好理解,每一个Item都是按照上面的流程走,而且每一个Item的view都是经过getView里面inflate出来的(这种状况getView的convertView传过来是空,意味着ListView尚未缓存view可使用)spa

非全新加载,好比页面滑动,或者adapter数据发生变化,这种状况下面总体流程和全新加载没有区别,但在部分函数调用里面有细微差异,好比:设计

layoutChildren里面首先将ListView的child都放入缓存池:3d

// 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函数的第一段就是:
640?wx_fmt=png&wxfrom=5&wx_lazy=1
更巧妙的是,在拿ActiveView的缓存view的时候,会根据位置来拿,这样的view认为是不须要从新通过adapter的getView函数的,这样极大的提升了效率。(页面滚动的时候页面里面的item只是位置变化,不须要从新调用adapter.getView函数)code

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<View> 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:
640?wx_fmt=png&wxfrom=5&wx_lazy=1
而后在obtainView里面,从ScrapViews里面从新拿出来要使用了,再调用finish:
640?wx_fmt=png&wxfrom=5&wx_lazy=1

这个临时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)
640?wx_fmt=png&wxfrom=5&wx_lazy=1
640?wx_fmt=png&wxfrom=5&wx_lazy=1
而后setupChild里面会根据是否是attachedToWindow作不一样的操做:从新指定parent(attachViewToParent)仍是从新attachToWindow(addViewInLayout)
640?wx_fmt=png&wxfrom=5&wx_lazy=1

源码解析就怕别人看不懂,希望对同窗们有些帮助~

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

相关文章
相关标签/搜索