Adapter中getView方法的陷阱

我们在为列表写适配器的时候通常是implements BaseAdapter，实现它的抽象方法，java用一些好的结构减小了findViewByID的次数（参考链接），可是这就需要程序员们注意个问题，每次从内存中取出来的item是随机从以往的ViewGroup取出来的，资源重复利用从而减小了内存消耗，但同时也由于之前对某部分内存的配置没有清理，再使用时就需要手动修改，否则会有意想不到的后果发生。

今天简单分析一下，希望给各位同胞留个前车之鉴。

这是个消息队列的适配器，只发送文本消息，每条消息的显示用MyMessageView来控制，消息发出后收到服务器的确定，MyMessageView的getIsUpLoad()方法才会返回true，所以我们要手动的控制进度条ProcessBar的显示与否。

class MessageAdpter implements BaseAdapter
{
//一些变量声明
//构造函数
//addView()
//一些必须完善的抽象方法
@Override
public View getView(int position,View convertView, Viewgroup parent)
{
ViewHolder holder = null;
MyMessageView msgView = ls_msgViews.get(position);
if(convertView==null)
{
holder = new ViewHolder();
convertView =  LayoutInflater.from(context).inflate(R.layout.view_message, null);
holder.content = (TextView)convertView.findViewByID(R.id.tv_message_content);
holder.process = (ProcessBar)convertView.findViewByID(R.id.pb_message_process);
convertView.setTag(holder);
}
else
{
holder = (ViewHolder) convertView.getTag();
}
//这句是关键，必须手动将processBar显示
holder.process.setVisibility(View.VISIBLE);
if(msgView.getIsUpLoad())
{
holder.process.setVisibility(View.GONE);
}
return convertView;
}
//(这里为什么要用static来修饰此内部类？希望和童鞋们交流)
static class ViewHolder
{
TextView content;
ProcessBar process;
}
}