Android中ListView的几种常见的优化方法

Android中的ListView应该算是布局中几种最常用的组件之一了,使用也十分方便,下面将介绍ListView几种比较常见的优化方法:

首先我们给出一个没有任何优化的Listview的Adapter类,我们这里都继承自BaseAdapter,这里我们使用一个包含100个字符串的List集合来作为ListView的项目所要显示的内容,每一个条目都是一个自定义的组件,这个组件中只包含一个textview:
这里写图片描述
Activity:

    package com.alexchen.listviewoptimize;  

    import java.util.ArrayList;  
    import java.util.List;  
    import android.app.Activity;  
    import android.os.Bundle;  
    import android.view.Menu;  
    import android.view.MenuItem;  
    import android.view.View;  
    import android.view.ViewGroup;  
    import android.widget.BaseAdapter;  
    import android.widget.ListView;  
    import android.widget.TextView;  

    public class MainActivity extends Activity {  

        private ListView lv_demo;  
        private List<String> list;  

        @Override  
        protected void onCreate(Bundle savedInstanceState) {  
            super.onCreate(savedInstanceState);  
            setContentView(R.layout.activity_main);  
            lv_demo = (ListView) findViewById(R.id.lv_demo);  
            //list为要加载的条目文本的集合,这里总共是100条  
            list = new ArrayList<String>();  
            for (int i = 0; i < 100; i++) {  
                list.add("条目" + i);  
            }  

            lv_demo.setAdapter(new MyAdapter());  
        }  

        private class MyAdapter extends BaseAdapter {  

            @Override  
            public int getCount() {  
                return list.size();  
            }  

            @Override  
            public View getView(int position, View convertView, ViewGroup parent) {  
                //listview_item里只有一个textview  
                View view = View.inflate(MainActivity.this, R.layout.listview_item,  
                        null);  
                //使用每一次都findviewById的方法来获得listview_item内部的组件  
                TextView tv_item = (TextView) view.findViewById(R.id.tv_item);  
                tv_item.setText(list.get(position));  
                return view;  
            }  

            @Override  
            public Object getItem(int position) {  
                return null;  
            }  

            @Override  
            public long getItemId(int position) {  
                return 0;  
            }  

        }  
    }  

优化一:复用convertView

也是最普通的优化,就在MyAdapter类中的getView方法中,我们注意到,上面的写法每次需要一个View对象时,都是去重新inflate一个View出来返回去,没有实现View对象的复用,而实际上对于ListView而言,只需要保留能够显示的最大个数的view即可,其他新的view可以通过复用的方式使用消失的条目的view,而getView方法里也提供了一个参数:convertView,这个就代表着可以复用的view对象,当然这个对象也可能为空,当它为空的时候,表示该条目view第一次创建,所以我们需要inflate一个view出来,所以在这里,我们使用下面这种方式来重写getView方法:

    @Override  
        public View getView(int position, View convertView, ViewGroup parent) {  
            View view;  
            // 判断convertView的状态,来达到复用效果  
            if (null == convertView) {  
                //如果convertView为空,则表示第一次显示该条目,需要创建一个view  
                view = View.inflate(MainActivity.this, R.layout.listview_item,  
                        null);  
            } else {  
                //否则表示可以复用convertView  
                view = convertView;  
            }  
            // listview_item里只有一个textview  
            TextView tv_item = (TextView) view.findViewById(R.id.tv_item);  
            tv_item.setText(list.get(position));  
            return view;  
        }  

优化二:使用viewHolder

上面是对view对象的复用做的优化,我们经过上面的优化之后,我们不需要每一个view都重新生成了。下面我们来解决下一个每一次都需要做的工作,那就是view中组件的查找:
TextView tv_item = (TextView) view.findViewById(R.id.tv_item);
实际上,findViewById是到xml文件中去查找对应的id,可以想象如果组件多的话也是挺费事的,如果我们可以让view内的组件也随着view的复用而复用,那该是多美好的一件事啊。。实际上谷歌也推荐了一种优化方法来做应对,那就是重新建一个内部静态类,里面的成员变量跟view中所包含的组件个数类型相同,我们这里的view只包含了一个TextView,所以我们的这个静态类如下:

    private static class ViewHolder {  
        private TextView tvHolder;  
    }  

不过,如果item过多的话,建议不要使用。因为static是Java中的一个关键字,当用它来修饰成员变量时,那么该变量就属于该类,而不是该类的实例。所以用static修饰的变量,它的生命周期是很长的,如果用它来引用一些资源耗费过多的实例(比如Context的情况最多),这时就要尽量避免使用了。

那么这个viewHolder类我们要如何使用才可以达到复用效果呢?基本思路就是在convertView为null的时候,我们不仅重新inflate出来一个view,并且还需要进行findviewbyId的查找工作,但是同时我们还需要获取一个ViewHolder类的对象,并将findviewById的结果赋值给ViewHolder中对应的成员变量。最后将holder对象与该view对象“绑”在一块。

当convertView不为null时,我们让view=converView,同时取出这个view对应的holder对象,就获得了这个view对象中的TextView组件,它就是holder中的成员变量,这样在复用的时候,我们就不需要再去findViewById了,只需要在最开始的时候进行数次查找工作就可以了。这里的关键在于如何将view与holder对象进行绑定,那么就需要用到两个方法:setTag和getTag方法了:

    @Override  
        public View getView(int position, View convertView, ViewGroup parent) {  
            View view;  
            ViewHolder holder;  
            // 判断convertView的状态,来达到复用效果  
            if (null == convertView) {  
                // 如果convertView为空,则表示第一次显示该条目,需要创建一个view  
                view = View.inflate(MainActivity.this, R.layout.listview_item,  
                        null);  
                //新建一个viewholder对象  
                holder = new ViewHolder();  
                //将findviewbyID的结果赋值给holder对应的成员变量  
                holder.tvHolder = (TextView) view.findViewById(R.id.tv_item);  
                // 将holder与view进行绑定  
                view.setTag(holder);  
            } else {  
                // 否则表示可以复用convertView  
                view = convertView;  
                holder = (ViewHolder) view.getTag();  
            }  
            // 直接操作holder中的成员变量即可,不需要每次都findViewById  
            holder.tvHolder.setText(list.get(position));  
            return view;  
        }  

经过上面的做法,可能大家感觉不太到优化的效果,根据Google的文档,实际优化效果在百分之5左右。

优化三:分页加载

上面的两个例子中ListView都是显示的本地的List集合中的内容,List的长度也只有100个,我们可以毫不费力一次性加载完这100个数据;但是实际应用中,我们往往会需要使用Listview来显示网络上的内容,比如说我们拿使用ListView显示新闻为例:

其一:假如网络情况很好,我们使用的手机也许能够一下子加载完所有新闻数据,然后显示在ListView中,用户可能感觉还好,假如说在网络不太顺畅的情况下,用户加载完所有网络的数据,可能这个list是1000条新闻,那么用户可能需要面对一个空白的Activity好几分钟,这个显然是不合适的

其二:我们知道Android虚拟机给每个应用分配的运行时内存是一定的,一般性能不太好的机器只有16M,好一点的可能也就是64M的样子,假如说我们现在要浏览的新闻总数为一万条,即便是网络很好的情况下,我们可以很快的加载完毕,但是多数情况下也会出现内存溢出从而导致应用崩溃的情况。

那么为了解决上面的两个问题,我们需要进行分批加载,比如说1000条新闻的List集合,我们一次加载20条,等到用户翻页到底部的时候,我们再添加下面的20条到List中,再使用Adapter刷新ListView,这样用户一次只需要等待20条数据的传输时间,不需要一次等待好几分钟把数据都加载完再在ListView上显示。其次这样也可以缓解很多条新闻一次加载进行产生OOM应用崩溃的情况。

实际上,分批加载也不能完全解决问题,因为虽然我们在分批中一次只增加20条数据到List集合中,然后再刷新到ListView中去,假如有10万条数据,如果我们顺利读到最后这个List集合中还是会累积海量条数的数据,还是可能会造成OOM的情况,这时候我们就需要用到分页,比如说我们将这10万条数据分为1000页,每一页100条数据,每一页加载时都覆盖掉上一页中List集合中的内容,然后每一页内再使用分批加载,这样用户的体验就会相对好一些。

优化四:图片优化,详看OOM异常中图片的优化

1、处理图片的方式:
如果自定义Item中有涉及到图片等等的,一定要狠狠的处理图片,图片占的内存是ListView项中最恶心的,处理图片的方法大致有以下几种:
①、不要直接拿路径就去循环decodeFile();使用Option保存图片大小、不要加载图片到内存去
②、拿到的图片一定要经过边界压缩
③、在ListView中取图片时也不要直接拿个路径去取图片,而是以WeakReference(使用WeakReference代替强引用。
比如可以使用WeakReference mContextRef)、SoftReference、WeakHashMap等的来存储图片信息,是图片信息不是图片哦!
④、在getView中做图片转换时,产生的中间变量一定及时释放
2、异步加载图片基本思想:
1)、 先从内存缓存中获取图片显示(内存缓冲)
2)、获取不到的话从SD卡里获取(SD卡缓冲)
3)、都获取不到的话从网络下载图片并保存到SD卡同时加入内存并显示(视情况看是否要显示)
原理:
优化一:先从内存中加载,没有则开启线程从SD卡或网络中获取,这里注意从SD卡获取图片是放在子线程里执行的,否则快速滑屏的话会不够流畅。
优化二:与此同时,在adapter里有个busy变量,表示listview是否处于滑动状态,如果是滑动状态则仅从内存中获取图片,没有的话无需再开启线程去外存或网络获取图片。
优化三:ImageLoader里的线程使用了线程池,从而避免了过多线程频繁创建和销毁,有的童鞋每次总是new一个线程去执行这是非常不可取的,好一点的用的AsyncTask类,其实内部也是用到了线程池。在从网络获取图片时,先是将其保存到sd卡,然后再加载到内存,这么做的好处是在加载到内存时可以做个压缩处理,以减少图片所占内存。
Tips:这里可能出现图片乱跳(错位)的问题:
图片错位问题的本质源于我们的listview使用了缓存convertView,假设一种场景,一个listview一屏显示九个item,那么在拉出第十个item的时候,事实上该item是重复使用了第一个item,也就是说在第一个item从网络中下载图片并最终要显示的时候,其实该item已经不在当前显示区域内了,此时显示的后果将可能在第十个item上输出图像,这就导致了图片错位的问题。所以解决之道在于可见则显示,不可见则不显示。在ImageLoader里有个imageViews的map对象,就是用于保存当前显示区域图像对应的url集,在显示前判断处理一下即可。

ListView的其他优化:

1、尽量避免在BaseAdapter中使用static 来定义全局静态变量:
static是Java中的一个关键字,当用它来修饰成员变量时,那么该变量就属于该类,而不是该类的实例。所以用static修饰的变量,它的生命周期是很长的,如果用它来引用一些资源耗费过多的实例(比如Context的情况最多),这时就要尽量避免使用了。
2、尽量使用getApplicationContext:
如果为了满足需求下必须使用Context的话:Context尽量使用Application Context,因为Application的Context的生命周期比较长,引用它不会出现内存泄露的问题
3、尽量避免在ListView适配器中使用线程:
因为线程产生内存泄露的主要原因在于线程生命周期的不可控制。之前使用的自定义ListView中适配数据时使用AsyncTask自行开启线程的,这个比用Thread更危险,因为Thread只有在run函数不结束时才出现这种内存泄露问题,然而AsyncTask内部的实现机制是运用了线程执行池(ThreadPoolExcutor),这个类产生的Thread对象的生命周期是不确定的,是应用程序无法控制的,因此如果AsyncTask作为Activity的内部类,就更容易出现内存泄露的问题。解决办法如下:
①、将线程的内部类,改为静态内部类。
②、在线程内部采用弱引用保存Context引用

原文: http://blog.csdn.net/zhangli_/article/details/50908437

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值