源码解析之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)

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

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

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,390评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,821评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,632评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,170评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,033评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,098评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,511评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,204评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,479评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,572评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,341评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,213评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,576评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,893评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,171评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,486评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,676评论 2 335

推荐阅读更多精彩内容