listview优化
首先来了解一下ListView的工作原理（可参见http://mobile.51cto.com/abased-410889.htm），如图：
1、如果你有几千几万甚至更多的选项(item)时，其中只有可见的项目存在内存（内存内存哦，说的优化就是说在内存中的优化！！！）中，其他的在Recycler中
2、ListView先请求一个type1视图(getView)然后请求其他可见的项目。convertView在getView中是空(null)的
3、当item1滚出屏幕，并且一个新的项目从屏幕低端上来时，ListView再请求一个type1视图。convertView此时不是空值了，它的值是item1。你只需设定新的数据然后返回convertView，不必重新创建一个视图
一、复用convertView，减少findViewById的次数
1、优化一：复用convertView
Android系统本身为我们考虑了ListView的优化问题，在复写的Adapter的类中，比较重要的两个方法是getCount()和getView()。界面上有多少个条显示，就会调用多少次的getView()方法；因此如果在每次调用的时候，如果不进行优化，每次都会使用View.inflate(….)的方法，都要将xml文件解析，并显示到界面上，这是非常消耗资源的：因为有新的内容产生就会有旧的内容销毁，所以，可以复用旧的内容。
优化：
在getView()方法中，系统就为我们提供了一个复用view的历史缓存对象convertView，当显示第一屏的时候，每一个item都会新创建一个view对象，这些view都是可以被复用的；如果每次显示一个view都要创建一个，是非常耗费内存的；所以为了节约内存，可以在convertView不为null的时候，对其进行复用
2、优化二：缓存item条目的引用——ViewHolder
findViewById()这个方法是比较耗性能的操作，因为这个方法要找到指定的布局文件，进行不断地解析每个节点：从最顶端的节点进行一层一层的解析查询，找到后在一层一层的返回，如果在左边没找到，就会接着解析右边，并进行相应的查询，直到找到位置（如图）。因此可以对findViewById进行优化处理，需要注意的是：
》》》》特点：xml文件被解析的时候，只要被创建出来了，其孩子的id就不会改变了。根据这个特点，可以将孩子id存入到指定的集合中，每次就可以直接取出集合中对应的元素就可以了。
优化：
在创建view对象的时候，减少布局文件转化成view对象的次数；即在创建view对象的时候，把所有孩子全部找到，并把孩子的引用给存起来
①定义存储控件引用的类ViewHolder
这里的ViewHolder类需要不需要定义成static，根据实际情况而定，如果item不是很多的话，可以使用，这样在初始化的时候，只加载一次，可以稍微得到一些优化
不过，如果item过多的话，建议不要使用。因为static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（比如Context的情况最多），这时就要尽量避免使用了。
class ViewHolder{
//定义item中相应的控件
}
②创建自定义的类：ViewHolder holder = null;
③将子view添加到holder中：
在创建新的listView的时候，创建新的ViewHolder，把所有孩子全部找到，并把孩子的引用给存起来
通过view.setTag(holder)将引用设置到view中
通过holder，将孩子view设置到此holder中，从而减少以后查询的次数
④在复用listView中的条目的时候，通过view.getTag()，将view对象转化为holder，即转化成相应的引用，方便在下次使用的时候存入集合。
通过view.getTag(holder)获取引用（需要强转）
示例代码：
public class ActivityDemo extends Activity {
private ListView listview1;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
listview1 = (ListView) findViewById(R.id.listview1);
MyAdapter adapter = new MyAdapter();
listview1.setAdapter(adapter);
}
private class MyAdapter extends BaseAdapter{
@Override
public int getCount() {
return 40;
}
@Override
public Object getItem(int position) {
return position;
}
@Override
public long getItemId(int position) {
return position;
}
@Override
public View getView(int position, View convertView, ViewGroup parent) {
ViewHolder holder = null;
if(convertView!=null && convertView instanceof RelativeLayout){ //注意：这里不一定用RelativeLayout，根据XML文件中的根节点来确定
holder = (ViewHolder) convertView.getTag();
}else{
//1、复用历史缓存view对象，检索布局问转化成view对象的次数
convertView = View.inflate(ActivityDemo.this, R.layout.item, null);
//2、在创建view对象的时候，把所有的子view找到，把子view的引用存起来
holder = new ViewHolder();
holder.ivIcon = (ImageView) convertView.findViewById(R.id.iv_icon);
holder.tvContent = (TextView) convertView.findViewById(R.id.tv_content);
convertView.setTag(holder);
/* 实现存储子view引用的另一种方式：
convertView.setTag(holder.ivIcon);
convertView.setTag(holder.tvContent); */
}
//直接复用系统提供的历史缓存对象convertView
return convertView;
}
}
class ViewHolder{
public ImageView ivIcon;
public TextView tvContent;
}
}
二、ListView中数据的分批及分页加载：
需求：
ListView有一万条数据，如何显示；如果将十万条数据加载到内存，很消耗内存
解决办法：
优化查询的数据：先获取几条数据显示到界面上
进行分批处理---à优化了用户体验
进行分页处理---à优化了内存空间
说明：
一般数据都是从数据库中获取的，实现分批（分页）加载数据，就需要在对应的DAO中有相应的分批（分页）获取数据的方法，如findPartDatas ()
1、准备数据：
在dao中添加分批加载数据的方法：findPartDatas ()
在适配数据的时候，先加载第一批的数据，需要加载第二批的时候，设置监听检测何时加载第二批
2、设置ListView的滚动监听器：setOnScrollListener(new OnScrollListener{….})
①、在监听器中有两个方法：滚动状态发生变化的方法(onScrollStateChanged)和listView被滚动时调用的方法(onScroll)
②、在滚动状态发生改变的方法中，有三种状态：
手指按下移动的状态： SCROLL_STATE_TOUCH_SCROLL: // 触摸滑动
惯性滚动（滑翔（flgin）状态）： SCROLL_STATE_FLING: // 滑翔
静止状态： SCROLL_STATE_IDLE: // 静止
3、对不同的状态进行处理：
分批加载数据，只关心静止状态：关心最后一个可见的条目，如果最后一个可见条目就是数据适配器（集合）里的最后一个，此时可加载更多的数据。在每次加载的时候，计算出滚动的数量，当滚动的数量大于等于总数量的时候，可以提示用户无更多数据了。
示例代码:（详细代码请参见【6.3-ListView数据的分批加载.doc】）
// 给listview注册一个滚动的监听器.
lv_call_sms_safe.setOnScrollListener(new OnScrollListener() {
// 当滚动状体发生变化的时候调用的方法
@Override
public void onScrollStateChanged(AbsListView view, int scrollState) {
switch (scrollState) {
case SCROLL_STATE_FLING: // 滑翔
break;
case SCROLL_STATE_IDLE: // 静止
// 在静止状态下 关心最后一个可见的条目 如果最后一个可见条目就是 数据适配器里面的最后一个 , 加载更多数据.
int position = lv_call_sms_safe.getLastVisiblePosition(); // 位置从0开始
int size = blackNumbers.size();// 从1开始的.
if (position == (size - 1)) {
Log.i(TAG, "拖动到了最后一个条目,加载更多数据");
startIndex += maxNumber;
if(startIndex>=totalCount){
Toast.makeText(getApplicationContext(), "没有更多数据了..", 0).show();
return;
}
fillData();
break;
}
break;
case SCROLL_STATE_TOUCH_SCROLL: // 触摸滑动
break;
}
}
// 当listview被滚动的时候 调用的方法
@Override
public void onScroll(AbsListView view, int firstVisibleItem, int visibleItemCount, int totalItemCount) {
}
});
/**
* 填充数据
*/
private void fillData() {
// 通知用户一下正在获取数据
ll_loading.setVisibility(View.VISIBLE);
new Thread() {
public void run() {
// 获取全部的黑名单号码
if (blackNumbers != null) {
blackNumbers.addAll(dao.findPartBlackNumbers(startIndex,maxNumber));
} else {
blackNumbers = dao.findPartBlackNumbers(startIndex,maxNumber);
}
handler.sendEmptyMessage(0);
// lv_call_sms_safe.setAdapter(new CallSmsSafeAdapter());
};
}.start();
}
三、复杂ListView的处理：（待进一步总结）
说明：
listView的界面显示是通过getCount和getView这两个方法来控制的
getCount：返回有多少个条目
getView：返回每个位置条目显示的内容
提供思路：
对于含有多个类型的item的优化处理：由于ListView只有一个Adapter的入口，可以定义一个总的Adapter入口，存放各种类型的Adapter
以安全卫士中的进程管理的功能为例。效果如图：
1、定义两个（或多个）集合
每个集合中存入的是对应不同类型的内容（这里为：用户程序（userAppinfos）和系统程序的集合（systemAppinfos））
2、在初始化数据（填充数据）中初始化两个集合
如，此处是在fillData方法中初始化
3、在数据适配器中，复写对应的方法
getCount()：计算所有需要显示的条目个数，这里包括listView和textView
getView()：对显示在不同位置的条目进行if处理
4、数据类型的判断
需要注意的是，在复用view的时候，需要对convertView进行类型判断，是因为这里含有各种不同类型的view，在view滚动显示的时候，对于不同类型的view不能复用，所有需要判断
示例代码：
获取条目个数
public int getCount() {
// 用户程序个数 + 系统程序个数
return userAppinfos.size() + 1 + systemAppinfos.size() + 1;
}
类型判断：
if (convertView != null && convertView instanceof RelativeLayout) {
view = convertView;
holder = (ViewHolder) view.getTag();
} else {
//……..
}
getView中条目位置的选择：
if (position == 0) {// 显示一个textview的标签 , 告诉用户用户程序有多少个
TextView tv = new TextView(getApplicationContext());
tv.setBackgroundColor(Color.GRAY);
tv.setTextColor(Color.WHITE);
tv.setText("用户程序:" + userAppinfos.size() + "个");
return tv;
} else if (position == (userAppinfos.size() + 1)) {
TextView tv = new TextView(getApplicationContext());
tv.setBackgroundColor(Color.GRAY);
tv.setTextColor(Color.WHITE);
tv.setText("系统程序:" + systemAppinfos.size() + "个");
return tv;
} else if (position <= userAppinfos.size()) {// 用户程序
appInfo = userAppinfos.get(position - 1);
} else {// 系统程序
appInfo = systemAppinfos.get(position - 1 - userAppinfos.size() - 1);
}
四、ListView中图片的优化：
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集，在显示前判断处理一下即可。
Adapter示例代码：
public class LoaderAdapter extends BaseAdapter{
private static final String TAG = "LoaderAdapter";
private boolean mBusy = false; //是否处于滑动中
public void setFlagBusy(boolean busy) {
this.mBusy = busy;
}
private ImageLoader mImageLoader;
private int mCount;
private Context mContext;
private String[] urlArrays;
public LoaderAdapter(int count, Context context, String []url) {
this.mCount = count;
this.mContext = context;
urlArrays = url;
mImageLoader = new ImageLoader(context);
}
public ImageLoader getImageLoader(){
return mImageLoader;
}
@Override
public int getCount() {
return mCount;
}
@Override
public Object getItem(int position) {
return position;
}
@Override
public long getItemId(int position) {
return position;
}
@Override
public View getView(int position, View convertView, ViewGroup parent) {
ViewHolder viewHolder = null;
if (convertView == null) { //加载新创建的view
convertView = LayoutInflater.from(mContext).inflate(R.layout.list_item, null);
viewHolder = new ViewHolder();
viewHolder.mTextView = (TextView) convertView.findViewById(R.id.tv_tips);
viewHolder.mImageView = (ImageView) convertView.findViewById(R.id.iv_image);
convertView.setTag(viewHolder);
} else {
viewHolder = (ViewHolder) convertView.getTag();
}
String url = "";
url = urlArrays[position % urlArrays.length];
viewHolder.mImageView.setImageResource(R.drawable.ic_launcher);
if (!mBusy) {
mImageLoader.DisplayImage(url, viewHolder.mImageView, false);
viewHolder.mTextView.setText("--" + position + "--IDLE ||TOUCH_SCROLL");
} else {
mImageLoader.DisplayImage(url, viewHolder.mImageView, true);
viewHolder.mTextView.setText("--" + position + "--FLING");
}
//复用历史缓存view
return convertView;
}
static class ViewHolder {
TextView mTextView;
ImageView mImageView;
}
}
3、内存缓冲机制：
首先限制内存图片缓冲的堆内存大小，每次有图片往缓存里加时判断是否超过限制大小，超过的话就从中取出最少使用的图片并将其移除。
当然这里如果不采用这种方式，换做软引用也是可行的，二者目的皆是最大程度的利用已存在于内存中的图片缓存，避免重复制造垃圾增加GC负担；OOM溢出往往皆因内存瞬时大量增加而垃圾回收不及时造成的。只不过二者区别在于LinkedHashMap里的图片缓存在没有移除出去之前是不会被GC回收的，而SoftReference里的图片缓存在没有其他引用保存时随时都会被GC回收。所以在使用LinkedHashMap这种LRU算法缓存更有利于图片的有效命中，当然二者配合使用的话效果更佳，即从LinkedHashMap里移除出的缓存放到SoftReference里，这就是内存的二级缓存。
本例采用的是LRU算法，先看看MemoryCache的实现
public class MemoryCache {
private static final String TAG = "MemoryCache";
// 放入缓存时是个同步操作
// LinkedHashMap构造方法的最后一个参数true代表这个map里的元素将按照最近使用次数由少到多排列，即LRU
// 这样的好处是如果要将缓存中的元素替换，则先遍历出最近最少使用的元素来替换以提高效率
private Map<String, Bitmap> cache = Collections
.synchronizedMap(new LinkedHashMap<String, Bitmap>(10, 1.5f, true));
// 缓存中图片所占用的字节，初始0，将通过此变量严格控制缓存所占用的堆内存
private long size = 0;// current allocated size
// 缓存只能占用的最大堆内存
private long limit = 1000000;// max memory in bytes
public MemoryCache() {
// use 25% of available heap size
setLimit(Runtime.getRuntime().maxMemory() / 10);
}
public void setLimit(long new_limit) {
limit = new_limit;
Log.i(TAG, "MemoryCache will use up to " + limit / 1024. / 1024. + "MB");
}
public Bitmap get(String id) {
try {
if (!cache.containsKey(id))
return null;
return cache.get(id);
} catch (NullPointerException ex) {
return null;
}
}
public void put(String id, Bitmap bitmap) {
try {
if (cache.containsKey(id))
size -= getSizeInBytes(cache.get(id));
cache.put(id, bitmap);
size += getSizeInBytes(bitmap);
checkSize();
} catch (Throwable th) {
th.printStackTrace();
}
}
/**
* 严格控制堆内存，如果超过将首先替换最近最少使用的那个图片缓存
*
*/
private void checkSize() {
Log.i(TAG, "cache size=" + size + " length=" + cache.size());
if (size > limit) {
// 先遍历最近最少使用的元素
Iterator<Entry<String, Bitmap>> iter = cache.entrySet().iterator();
while (iter.hasNext()) {
Entry<String, Bitmap> entry = iter.next();
size -= getSizeInBytes(entry.getValue());
iter.remove();
if (size <= limit)
break;
}
Log.i(TAG, "Clean cache. New size " + cache.size());
}
}
public void clear() {
cache.clear();
}
/**
* 图片占用的内存
* <a href="\"http://www.eoeandroid.com/home.php?mod=space&uid=2768922\"" target="\"_blank\"">@Param</a> bitmap
* @return
*/
long getSizeInBytes(Bitmap bitmap) {
if (bitmap == null)
return 0;
return bitmap.getRowBytes() * bitmap.getHeight();
}
}
五、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引用
示例代码：
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
}
}
六、ScrollView和ListView的冲突问题：【摘自网络】
解决方法之一：
在ScrollView添加一个ListView会导致listview控件显示不全，这是因为两个控件的滚动事件冲突导致。所以需要通过listview中的item数量去计算listview的显示高度，从而使其完整展示，如下提供一个方法供大家参考。
示例代码：
public void setListViewHeightBasedOnChildren(ListView listView) {
ListAdapter listAdapter = listView.getAdapter();
if (listAdapter == null) {
return;
}
int totalHeight = 0;
for (int i = 0; i < listAdapter.getCount(); i++) {
View listItem = listAdapter.getView(i, null, listView);
listItem.measure(0, 0);
totalHeight += listItem.getMeasuredHeight();
}
ViewGroup.LayoutParams params = listView.getLayoutParams();
params.height = totalHeight + (listView.getDividerHeight() * (listAdapter.getCount() - 1));
params.height += 5;//if without this statement,the listview will be a little short
listView.setLayoutParams(params);
}
ListView的工作原理
首先来了解一下ListView的工作原理（可参见http://mobile.51cto.com/abased-410889.htm），如图：
1、如果你有几千几万甚至更多的选项(item)时，其中只有可见的项目存在内存（内存内存哦，说的优化就是说在内存中的优化！！！）中，其他的在Recycler中
2、ListView先请求一个type1视图(getView)然后请求其他可见的项目。convertView在getView中是空(null)的
3、当item1滚出屏幕，并且一个新的项目从屏幕低端上来时，ListView再请求一个type1视图。convertView此时不是空值了，它的值是item1。你只需设定新的数据然后返回convertView，不必重新创建一个视图
一、复用convertView，减少findViewById的次数
1、优化一：复用convertView
Android系统本身为我们考虑了ListView的优化问题，在复写的Adapter的类中，比较重要的两个方法是getCount()和getView()。界面上有多少个条显示，就会调用多少次的getView()方法；因此如果在每次调用的时候，如果不进行优化，每次都会使用View.inflate(….)的方法，都要将xml文件解析，并显示到界面上，这是非常消耗资源的：因为有新的内容产生就会有旧的内容销毁，所以，可以复用旧的内容。
优化：
在getView()方法中，系统就为我们提供了一个复用view的历史缓存对象convertView，当显示第一屏的时候，每一个item都会新创建一个view对象，这些view都是可以被复用的；如果每次显示一个view都要创建一个，是非常耗费内存的；所以为了节约内存，可以在convertView不为null的时候，对其进行复用
2、优化二：缓存item条目的引用——ViewHolder
findViewById()这个方法是比较耗性能的操作，因为这个方法要找到指定的布局文件，进行不断地解析每个节点：从最顶端的节点进行一层一层的解析查询，找到后在一层一层的返回，如果在左边没找到，就会接着解析右边，并进行相应的查询，直到找到位置（如图）。因此可以对findViewById进行优化处理，需要注意的是：
》》》》特点：xml文件被解析的时候，只要被创建出来了，其孩子的id就不会改变了。根据这个特点，可以将孩子id存入到指定的集合中，每次就可以直接取出集合中对应的元素就可以了。
优化：
在创建view对象的时候，减少布局文件转化成view对象的次数；即在创建view对象的时候，把所有孩子全部找到，并把孩子的引用给存起来
①定义存储控件引用的类ViewHolder
这里的ViewHolder类需要不需要定义成static，根据实际情况而定，如果item不是很多的话，可以使用，这样在初始化的时候，只加载一次，可以稍微得到一些优化
不过，如果item过多的话，建议不要使用。因为static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（比如Context的情况最多），这时就要尽量避免使用了。
class ViewHolder{
//定义item中相应的控件
}
②创建自定义的类：ViewHolder holder = null;
③将子view添加到holder中：
在创建新的listView的时候，创建新的ViewHolder，把所有孩子全部找到，并把孩子的引用给存起来
通过view.setTag(holder)将引用设置到view中
通过holder，将孩子view设置到此holder中，从而减少以后查询的次数
④在复用listView中的条目的时候，通过view.getTag()，将view对象转化为holder，即转化成相应的引用，方便在下次使用的时候存入集合。
通过view.getTag(holder)获取引用（需要强转）
示例代码：
public class ActivityDemo extends Activity {
private ListView listview1;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
listview1 = (ListView) findViewById(R.id.listview1);
MyAdapter adapter = new MyAdapter();
listview1.setAdapter(adapter);
}
private class MyAdapter extends BaseAdapter{
@Override
public int getCount() {
return 40;
}
@Override
public Object getItem(int position) {
return position;
}
@Override
public long getItemId(int position) {
return position;
}
@Override
public View getView(int position, View convertView, ViewGroup parent) {
ViewHolder holder = null;
if(convertView!=null && convertView instanceof RelativeLayout){ //注意：这里不一定用RelativeLayout，根据XML文件中的根节点来确定
holder = (ViewHolder) convertView.getTag();
}else{
//1、复用历史缓存view对象，检索布局问转化成view对象的次数
convertView = View.inflate(ActivityDemo.this, R.layout.item, null);
//2、在创建view对象的时候，把所有的子view找到，把子view的引用存起来
holder = new ViewHolder();
holder.ivIcon = (ImageView) convertView.findViewById(R.id.iv_icon);
holder.tvContent = (TextView) convertView.findViewById(R.id.tv_content);
convertView.setTag(holder);
/* 实现存储子view引用的另一种方式：
convertView.setTag(holder.ivIcon);
convertView.setTag(holder.tvContent); */
}
//直接复用系统提供的历史缓存对象convertView
return convertView;
}
}
class ViewHolder{
public ImageView ivIcon;
public TextView tvContent;
}
}
二、ListView中数据的分批及分页加载：
需求：
ListView有一万条数据，如何显示；如果将十万条数据加载到内存，很消耗内存
解决办法：
优化查询的数据：先获取几条数据显示到界面上
进行分批处理---à优化了用户体验
进行分页处理---à优化了内存空间
说明：
一般数据都是从数据库中获取的，实现分批（分页）加载数据，就需要在对应的DAO中有相应的分批（分页）获取数据的方法，如findPartDatas ()
1、准备数据：
在dao中添加分批加载数据的方法：findPartDatas ()
在适配数据的时候，先加载第一批的数据，需要加载第二批的时候，设置监听检测何时加载第二批
2、设置ListView的滚动监听器：setOnScrollListener(new OnScrollListener{….})
①、在监听器中有两个方法：滚动状态发生变化的方法(onScrollStateChanged)和listView被滚动时调用的方法(onScroll)
②、在滚动状态发生改变的方法中，有三种状态：
手指按下移动的状态： SCROLL_STATE_TOUCH_SCROLL: // 触摸滑动
惯性滚动（滑翔（flgin）状态）： SCROLL_STATE_FLING: // 滑翔
静止状态： SCROLL_STATE_IDLE: // 静止
3、对不同的状态进行处理：
分批加载数据，只关心静止状态：关心最后一个可见的条目，如果最后一个可见条目就是数据适配器（集合）里的最后一个，此时可加载更多的数据。在每次加载的时候，计算出滚动的数量，当滚动的数量大于等于总数量的时候，可以提示用户无更多数据了。
示例代码:（详细代码请参见【6.3-ListView数据的分批加载.doc】）
// 给listview注册一个滚动的监听器.
lv_call_sms_safe.setOnScrollListener(new OnScrollListener() {
// 当滚动状体发生变化的时候调用的方法
@Override
public void onScrollStateChanged(AbsListView view, int scrollState) {
switch (scrollState) {
case SCROLL_STATE_FLING: // 滑翔
break;
case SCROLL_STATE_IDLE: // 静止
// 在静止状态下 关心最后一个可见的条目 如果最后一个可见条目就是 数据适配器里面的最后一个 , 加载更多数据.
int position = lv_call_sms_safe.getLastVisiblePosition(); // 位置从0开始
int size = blackNumbers.size();// 从1开始的.
if (position == (size - 1)) {
Log.i(TAG, "拖动到了最后一个条目,加载更多数据");
startIndex += maxNumber;
if(startIndex>=totalCount){
Toast.makeText(getApplicationContext(), "没有更多数据了..", 0).show();
return;
}
fillData();
break;
}
break;
case SCROLL_STATE_TOUCH_SCROLL: // 触摸滑动
break;
}
}
// 当listview被滚动的时候 调用的方法
@Override
public void onScroll(AbsListView view, int firstVisibleItem, int visibleItemCount, int totalItemCount) {
}
});
/**
* 填充数据
*/
private void fillData() {
// 通知用户一下正在获取数据
ll_loading.setVisibility(View.VISIBLE);
new Thread() {
public void run() {
// 获取全部的黑名单号码
if (blackNumbers != null) {
blackNumbers.addAll(dao.findPartBlackNumbers(startIndex,maxNumber));
} else {
blackNumbers = dao.findPartBlackNumbers(startIndex,maxNumber);
}
handler.sendEmptyMessage(0);
// lv_call_sms_safe.setAdapter(new CallSmsSafeAdapter());
};
}.start();
}
三、复杂ListView的处理：（待进一步总结）
说明：
listView的界面显示是通过getCount和getView这两个方法来控制的
getCount：返回有多少个条目
getView：返回每个位置条目显示的内容
提供思路：
对于含有多个类型的item的优化处理：由于ListView只有一个Adapter的入口，可以定义一个总的Adapter入口，存放各种类型的Adapter
以安全卫士中的进程管理的功能为例。效果如图：
1、定义两个（或多个）集合
每个集合中存入的是对应不同类型的内容（这里为：用户程序（userAppinfos）和系统程序的集合（systemAppinfos））
2、在初始化数据（填充数据）中初始化两个集合
如，此处是在fillData方法中初始化
3、在数据适配器中，复写对应的方法
getCount()：计算所有需要显示的条目个数，这里包括listView和textView
getView()：对显示在不同位置的条目进行if处理
4、数据类型的判断
需要注意的是，在复用view的时候，需要对convertView进行类型判断，是因为这里含有各种不同类型的view，在view滚动显示的时候，对于不同类型的view不能复用，所有需要判断
示例代码：
获取条目个数
public int getCount() {
// 用户程序个数 + 系统程序个数
return userAppinfos.size() + 1 + systemAppinfos.size() + 1;
}
类型判断：
if (convertView != null && convertView instanceof RelativeLayout) {
view = convertView;
holder = (ViewHolder) view.getTag();
} else {
//……..
}
getView中条目位置的选择：
if (position == 0) {// 显示一个textview的标签 , 告诉用户用户程序有多少个
TextView tv = new TextView(getApplicationContext());
tv.setBackgroundColor(Color.GRAY);
tv.setTextColor(Color.WHITE);
tv.setText("用户程序:" + userAppinfos.size() + "个");
return tv;
} else if (position == (userAppinfos.size() + 1)) {
TextView tv = new TextView(getApplicationContext());
tv.setBackgroundColor(Color.GRAY);
tv.setTextColor(Color.WHITE);
tv.setText("系统程序:" + systemAppinfos.size() + "个");
return tv;
} else if (position <= userAppinfos.size()) {// 用户程序
appInfo = userAppinfos.get(position - 1);
} else {// 系统程序
appInfo = systemAppinfos.get(position - 1 - userAppinfos.size() - 1);
}
四、ListView中图片的优化：
1、处理图片的方式：
如果自定义Item中有涉及到图片等等的，一定要狠狠的处理图片，图片占的内存是ListView项中最恶心的，处理图片的方法大致有以下几种：
①、不要直接拿路径就去循环decodeFile();使用Option保存图片大小、不要加载图片到内存去
②、拿到的图片一定要经过边界压缩
③、在ListView中取图片时也不要直接拿个路径去取图片，而是以WeakReference（使用WeakReference代替强引用。
比如可以使用WeakReference mContextRef）、SoftReference、WeakHashMap等的来存储图片信息，是图片信息不是图片哦！
④、在getView中做图片转换时，产生的中间变量一定及时释放
2、异步加载图片基本思想：
（待进一步总结，详见曹睿新闻案例【E:\JAVA\SOURCE\TSource\lessons\Android\PROJECT\PhoneLottory\day06\Optimization】）
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集，在显示前判断处理一下即可。
Adapter示例代码：
public class LoaderAdapter extends BaseAdapter{
private static final String TAG = "LoaderAdapter";
private boolean mBusy = false; //是否处于滑动中
public void setFlagBusy(boolean busy) {
this.mBusy = busy;
}
private ImageLoader mImageLoader;
private int mCount;
private Context mContext;
private String[] urlArrays;
public LoaderAdapter(int count, Context context, String []url) {
this.mCount = count;
this.mContext = context;
urlArrays = url;
mImageLoader = new ImageLoader(context);
}
public ImageLoader getImageLoader(){
return mImageLoader;
}
@Override
public int getCount() {
return mCount;
}
@Override
public Object getItem(int position) {
return position;
}
@Override
public long getItemId(int position) {
return position;
}
@Override
public View getView(int position, View convertView, ViewGroup parent) {
ViewHolder viewHolder = null;
if (convertView == null) { //加载新创建的view
convertView = LayoutInflater.from(mContext).inflate(R.layout.list_item, null);
viewHolder = new ViewHolder();
viewHolder.mTextView = (TextView) convertView.findViewById(R.id.tv_tips);
viewHolder.mImageView = (ImageView) convertView.findViewById(R.id.iv_image);
convertView.setTag(viewHolder);
} else {
viewHolder = (ViewHolder) convertView.getTag();
}
String url = "";
url = urlArrays[position % urlArrays.length];
viewHolder.mImageView.setImageResource(R.drawable.ic_launcher);
if (!mBusy) {
mImageLoader.DisplayImage(url, viewHolder.mImageView, false);
viewHolder.mTextView.setText("--" + position + "--IDLE ||TOUCH_SCROLL");
} else {
mImageLoader.DisplayImage(url, viewHolder.mImageView, true);
viewHolder.mTextView.setText("--" + position + "--FLING");
}
//复用历史缓存view
return convertView;
}
static class ViewHolder {
TextView mTextView;
ImageView mImageView;
}
}
3、内存缓冲机制：
首先限制内存图片缓冲的堆内存大小，每次有图片往缓存里加时判断是否超过限制大小，超过的话就从中取出最少使用的图片并将其移除。
当然这里如果不采用这种方式，换做软引用也是可行的，二者目的皆是最大程度的利用已存在于内存中的图片缓存，避免重复制造垃圾增加GC负担；OOM溢出往往皆因内存瞬时大量增加而垃圾回收不及时造成的。只不过二者区别在于LinkedHashMap里的图片缓存在没有移除出去之前是不会被GC回收的，而SoftReference里的图片缓存在没有其他引用保存时随时都会被GC回收。所以在使用LinkedHashMap这种LRU算法缓存更有利于图片的有效命中，当然二者配合使用的话效果更佳，即从LinkedHashMap里移除出的缓存放到SoftReference里，这就是内存的二级缓存。
本例采用的是LRU算法，先看看MemoryCache的实现
public class MemoryCache {
private static final String TAG = "MemoryCache";
// 放入缓存时是个同步操作
// LinkedHashMap构造方法的最后一个参数true代表这个map里的元素将按照最近使用次数由少到多排列，即LRU
// 这样的好处是如果要将缓存中的元素替换，则先遍历出最近最少使用的元素来替换以提高效率
private Map<String, Bitmap> cache = Collections
.synchronizedMap(new LinkedHashMap<String, Bitmap>(10, 1.5f, true));
// 缓存中图片所占用的字节，初始0，将通过此变量严格控制缓存所占用的堆内存
private long size = 0;// current allocated size
// 缓存只能占用的最大堆内存
private long limit = 1000000;// max memory in bytes
public MemoryCache() {
// use 25% of available heap size
setLimit(Runtime.getRuntime().maxMemory() / 10);
}
public void setLimit(long new_limit) {
limit = new_limit;
Log.i(TAG, "MemoryCache will use up to " + limit / 1024. / 1024. + "MB");
}
public Bitmap get(String id) {
try {
if (!cache.containsKey(id))
return null;
return cache.get(id);
} catch (NullPointerException ex) {
return null;
}
}
public void put(String id, Bitmap bitmap) {
try {
if (cache.containsKey(id))
size -= getSizeInBytes(cache.get(id));
cache.put(id, bitmap);
size += getSizeInBytes(bitmap);
checkSize();
} catch (Throwable th) {
th.printStackTrace();
}
}
/**
* 严格控制堆内存，如果超过将首先替换最近最少使用的那个图片缓存
*
*/
private void checkSize() {
Log.i(TAG, "cache size=" + size + " length=" + cache.size());
if (size > limit) {
// 先遍历最近最少使用的元素
Iterator<Entry<String, Bitmap>> iter = cache.entrySet().iterator();
while (iter.hasNext()) {
Entry<String, Bitmap> entry = iter.next();
size -= getSizeInBytes(entry.getValue());
iter.remove();
if (size <= limit)
break;
}
Log.i(TAG, "Clean cache. New size " + cache.size());
}
}
public void clear() {
cache.clear();
}
/**
* 图片占用的内存
* <a href="\"http://www.eoeandroid.com/home.php?mod=space&uid=2768922\"" target="\"_blank\"">@Param</a> bitmap
* @return
*/
long getSizeInBytes(Bitmap bitmap) {
if (bitmap == null)
return 0;
return bitmap.getRowBytes() * bitmap.getHeight();
}
}
五、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引用
示例代码：
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
}
}
