利用ViewHolder来优化ListView数据加载,仅仅就此一条吗?其实不是的,首先,想要优化ListView就得先了解ListView加载数据原理,这是前提,但是小马在这个地方先做一些简单的补充,大家一定仔细看下,保证会有收获的。
AD:
在整理前几篇文章的时候有朋友提出写一下ListView的性能优化方面的东西,这个问题也是小马在面试过程中被别人问到的…..今天小马就借此机会来整理下,网上类似的资料蛮多的,倒不如自己写一篇,记录在这个地方,供自己以后使用,不用再翻来翻去的找了,用自己写的…呵呵,不多讲其它了,说起优化我想大家第一反应跟小马一样吧?想到利用ViewHolder来优化ListView数据加载,仅仅就此一条吗?其实不是的,首先,想要优化ListView就得先了解ListView加载数据原理,这是前提,但是小马在这个地方先做一些简单的补充,大家一定仔细看下,保证会有收获的:
列表的显示需要三个元素:
-
ListVeiw:
用来展示列表的View。 -
适配器
: 用来把数据映射到ListView上 -
数据:
具体的将被映射的字符串,图片,或者基本组件。
根据列表的适配器类型,列表分为三种,ArrayAdapter,SimpleAdapter和SimpleCursorAdapter,这三种适配器的使用大家可学习下官网上面的使用或者自行百度谷歌,一堆DEMO!!!其中以ArrayAdapter最为简单,只能展示一行字。SimpleAdapter有最好的扩充性,可以自定义出各种效果。SimpleCursorAdapter可以认为是SimpleAdapter对数据库的简单结合,可以方便的把数据库的内容以列表的形式展示出来。
系统要绘制ListView了,他首先用getCount()函数得到要绘制的这个列表的长度,然后开始绘制第一行,怎么绘制呢?调用getView()函数。在这个函数里面首先获得一个View(这个看实际情况,如果是一个简单的显示则是View,如果是一个自定义的里面包含很多控件的时候它其实是一个ViewGroup),然后再实例化并设置各个组件及其数据内容并显示它。好了,绘制完这一行了。那
ListView的工作原理如下:
下面简单说下上图的原理:
- 如果你有几千几万甚至更多的选项(item)时,其中只有可见的项目存在内存(内存内存哦,说的优化就是说在内存中的优化!!!)中,其他的在Recycler中
- ListView先请求一个type1视图(getView)然后请求其他可见的项目。convertView在getView中是空(null)的
- 当item1滚出屏幕,并且一个新的项目从屏幕低端上来时,ListView再请求一个type1视图。convertView此时不是空值了,它的值是item1。你只需设定新的数据然后返回convertView,不必重新创建一个视图
- 下面来看下小马从网上找来的示例代码,网址搞丢了,只有一个word文档,只能 copy过来,不然直接贴网址,结合上面的原理图一起加深理解,如下:
- public class MultipleItemsList extends ListActivity {
- private MyCustomAdapter mAdapter;
- @Override
- public void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- mAdapter = new MyCustomAdapter();
- for (int i = 0; i < 50; i++) {
- mAdapter.addItem("item " + i);
- }
- setListAdapter(mAdapter);
- }
- private class MyCustomAdapter extends BaseAdapter {
- private ArrayList mData = new ArrayList();
- private LayoutInflater mInflater;
- public MyCustomAdapter() {
- mInflater = (LayoutInflater)getSystemService(Context.LAYOUT_INFLATER_SERVICE);
- }
- public void addItem(final String item) {
- mData.add(item);
- notifyDataSetChanged();
- }
- @Override
- public int getCount() {
- return mData.size();
- }
- @Override
- public String getItem(int position) {
- return mData.get(position);
- }
- @Override
- public long getItemId(int position) {
- return position;
- }
- @Override
- public View getView(int position, View convertView, ViewGroup parent) {
- System.out.println("getView " + position + " " + convertView);
- ViewHolder holder = null;
- if (convertView == null) {
- convertView = mInflater.inflate(R.layout.item1, null);
- holder = new ViewHolder();
- holder.textView = (TextView)convertView.findViewById(R.id.text);
- convertView.setTag(holder);
- } else {
- holder = (ViewHolder)convertView.getTag();
- }
- holder.textView.setText(mData.get(position));
- return convertView;
- } }
- public static class ViewHolder {
- public TextView textView;
- } }
执行程序,查看日志:
getView 被调用 9 次 ,convertView 对于所有的可见项目是空值(如下):
然后稍微向下滚动List,直到item10出现:
此时的convertView非空了,在item11离开屏幕之后,它的视图(…0f8)作为convertView容纳item12了,好啦,结合以上原理,下面来看看今天最主要的话题,主角ListView的优化:
下面是小记:图片用完了正确的释放…
- if(!bmp.isRecycle() ){
- bmp.recycle() //回收图片所占的内存
- system.gc() //提醒系统及时回收
- }
下面来列举下真正意义上的优化吧:
-
ViewHolder Tag 必不可少,这个不多说! - 如果自定义Item中有涉及到图片等等的,一定要狠狠的处理图片,图片占的内存是ListView项中最恶心的,处理图片的方法大致有以下几种:
2.1:不要直接拿个路径就去循环decodeFile();这是找死….用Option保存图片大小、不要加载图片到内存去;
2.2:拿到的图片一定要经过边界压缩
2.3:在ListView中取图片时也不要直接拿个路径去取图片,而是以WeakReference(使用WeakReference代替强引用。比如可以使用WeakReference mContextRef)、SoftReference、WeakHashMap等的来存储图片信息,是图片信息不是图片哦!
2.4:在getView中做图片转换时,产生的中间变量一定及时释放,用以下形式: - 尽量避免在BaseAdapter中使用static 来定义全局静态变量,我以为这个没影响 ,这个影响很大,static是Java中的一个关键字,当用它来修饰成员变量时,那么该变量就属于该类,而不是该类的实例。所以用static修饰的变量,它的生命周期是很长的,如果用它来引用一些资源耗费过多的实例(比如Context的情况最多),这时就要尽量避免使用了..
- 如果为了满足需求下必须使用Context的话:Context尽量使用Application Context,因为Application的Context的生命周期比较长,引用它不会出现内存泄露的问题
- 尽量避免在ListView适配器中使用线程,因为线程产生内存泄露的主要原因在于线程生命周期的不可控制
-
记下小马自己的错误: - 之前使用的自定义ListView中适配数据时使用AsyncTask自行开启线程的,这个比用Thread更危险,因为Thread只有在run函数不 结束时才出现这种内存泄露问题,然而AsyncTask内部的实现机制是运用了线程执行池(ThreadPoolExcutor,要想了解这个类的话大家加下我们的Android开发群五号,因为其它群的存储空间快满了,所以只上传到五群里了,看下小马上传的Gallery源码,你会对线程执行池、软、弱、强引用有个更深入的认识),这个类产生的Thread对象的生命周期是不确定的,是应用程序无法控制的,因此如果AsyncTask作为Activity的内部类,就更容易出现内存泄露的问题。这个问题的解决办法小马当时网上查到了记在txt里了,如下:
6.1:将线程的内部类,改为静态内部类。
6.2:在线程内部采用弱引用保存Context引用
示例代码如下:
- public abstract class WeakAsyncTask extends AsyncTask {
- protected WeakReference mTarget;
- public WeakAsyncTask(WeakTarget target) {
- mTarget = new WeakReference(target);
- }
- @Override
- protected final void onPreExecute() {
- final WeakTarget target = mTarget.get();
- if (target != null) {
- this.onPreExecute(target);
- }
- }
- @Override
- protected final Result doInBackground(Params... params) {
- final WeakTarget target = mTarget.get();
- if (target != null) {
- return this.doInBackground(target, params);
- } else {
- return null;
- }
- }
- @Override
- protected final void onPostExecute(Result result) {
- final WeakTarget target = mTarget.get();
- if (target != null) {
- this.onPostExecute(target, result);
- }
- }
- protected void onPreExecute(WeakTarget target) {
- // No default action }
- protected abstract Result doInBackground(WeakTarget target, Params... params);
- protected void onPostExecute(WeakTarget target, Result result) {
- // No default action } }
好啦,ListVIew的优化问题,小马就暂时先理解记录这么多了,如果朋友们有什么更好的优化建议什么的,留言指点下小马,一定会及时添加到进来的,先谢谢啦,其实在ListView适配器的getView()方法中可以做很多的优化,我记得还有可以优化findViewById()这个方法来寻址资源信息效率的方法,资料太多了,小马发现了会及时更新的哦,天太晚了,先休息了,吼吼,大家加油,一起努力学习!!!O_O