摘要
本文原创,转载请注明地址: http://kymjs.com/code/2015/11/26/01
奇葩需求催生创新,记一次对 ListView 的性能优化。(当然,RecyclerView 也是一样)
- 引子
- 首次实现
- 首次优化
- 不够完美
- ListView实现原理简介
- 再次优化
- 最后的优化
引子
首先来看我们伟大的思想家设定的图:
没什么特别的?那是因为这只是我截的手机淘宝的一个图。而我们所要实现的是:一个列表列出这个人所有的历史评价的评价情况,其中星星部分还是根据后台数据动态改变的,例如可能这件商品有描述相符、服务态度、物流服务;而下一件商品就只有描述相符、服务态度;另一件商品又可能来个帅气度、物流服务。好吧,这的确不是什么奇葩的需求,我只是不爽这种数据传递格式。
首次实现
如果是你,你第一反应这种界面要怎么实现?ListView嵌套?擦,那岂不更是卡到死了,一不小心还造成个OOM的事儿来。我一上来直接就是在适配器里面,根据data返回来的那个评价项目数量来动态 new Layout。然后每个 Layout 就是一个 TextView 加一个 RatingBar 。
////此处省略一万行代码…
写完了,跑一下看看。嘿实现了,就是这效果。我草,等等,这怎么这么卡,我用了ViewHolder复用布局啊。
你他妈在逗我,动态new布局你跟我弹复用。
首次优化
仔细观察一下 item ,好像每个 item 都是至少2个评价选项,至多也就4个。 既然动态 new 会卡顿,那就减少动态 new 的次数呗。首先咱们先在 item 里面写三个布局项。然后在 adapter 的 getView()
方法里面判断,如果评价项少于当前布局中的 layout(即 TextView + Ratingbar 组合)数量,就隐藏多出来的 layout;如果多于布局中 layout 数,再动态 new 布局。
如上方法应该是比较好的了,也是我之前在 KJBlog
的 仿微信公众号界面 中使用的方法,代码请见: KJFrame的演示项目
不够完美
擦,一定是最近科技发布会看多了,一提到不完美,首先想到的是魅族那奇葩广告:“pro 5,轻易不说完美”。 尼玛,白老总,这是语病啊,你小学语文是数学老师上体育课教的吗?
吐槽完毕,说正事。
回想 ListView
实现原理,为什么 ListView
能够做到即使滚动浏览无数条数据时,程序所占用的内存竟然都不会跟着增长多少。
翻看 AbsListView
源码我们发现,其中有一个叫 RecycleBin
的内部类。 RecycleBin
,中有多个 ArrayList<View>
,就是因为这些个 ArrayList<View>
才使得 ListView
的滚动能够不耗费更多内存。
ListView实现原理简介
我们在编写 ListView
的 Adapter
都知道要用 ViewHolder
,目的是为了布局复用。而这其中的原理很简单,就是当 ListView
滚动的时候,一个 item 滾出了屏幕,就会把这个滚出屏幕的 item 回收,而另一个 item 滚入屏幕的时候,就会去之前回收的 item 里面找,如果有回收过的 item 那就直接拿来复用了。
而这个回收与复用的过程,就跟上面的 RecycleBin
类中的那些集合类有关。
当一个 item 被移出屏幕的时候,首先会被加入到 ArrayList<View>
中,这样下次我们再使用的时候就不用再去new View (inflate()方法本质也是new对象),而是可以直接从 List
中去取一个 View
来复用了。
具体的细节,大家可以看郭霖的这篇博客 ListView工作原理完全解析
再次优化
结合刚刚讲的,我们自己定义一个集合类用来复用View
public class RecyclerList extends LinkedList<View> { private Context cxt; private int layoutId; public RecyclerList(Context cxt, int id) { this.cxt = cxt; this.layoutId = id; } public View get() { View view; if (size() > 0) { view = getFirst(); removeFirst(); } else { view = View.inflate(cxt, layoutId, null); } return view; } }
这里使用Linked是考虑到我实际项目中会频繁的添加删除多个item,想想 LinkedList
和 ArrayList
各自的优势~~
于是项目中的适配器就可以这么写了(只挑有用的部分写出来了)
private RecyclerList recycler; public void function(){ LinearLayout root = vh.getView(R.id.root); int count = root.getChildCount(); int size = item.getList().size(); if (count >= size) { for (int i = 0; i < count - size; i++) { recycler.add(root.getChildAt(1)); root.removeViewAt(1); } } else { for (int i = 0; i < size - count; i++) { View view = recycler.get(); root.addView(view, 1); } } }
最后的优化
呵呵哒,在我写这篇文章的时候,界面又特么变了。
算了,就当是自己总结了。
结合 初次优化 的效果,我们预先在item里面写几个layout,不过呢,这次我们不是直接去写,而是用 ViewStub
,ViewStub相当于一个占位符,可以在控件 onMeasure()
和 onLayout()
的时候不去考虑内部的实现,而是在控件需要显示的时候才去通过代码调用加载到内存中。
利用这一特性,我们可以在 getView()
中判断,这个item是否需要显示,如果需要layout,则添加进来,而当不需要的时候,移除到 RecyclerList 中;下次再进来,如果需要layout,则从 RecyclerList 中拿。
由于代码我没有实现,这里就只简单的写一下 ViewStub
的相关代码。
首先是item的xml布局中使用ViewStub:
... <ViewStub android:id="@+id/view_stub" android:layout="@layout/layout" android:layout_width="match_parent" android:layout_height="wrap_content" /> ...
之后是 getView()
方法中的java代码
ViewStub viewStub = (ViewStub) findViewById(R.id.view_stub); if (viewStub != null) { View layout = viewStub.inflate(); // android:layout="@layout/layout" // layout就是xml中这句引入的View }
需要注意的是 findView 拿到 ViewStub
的时候一定要判空,因为如果我们上次已经调用了 viewStub.inflate()
,则 findview 就会返回 null 了。
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!