ListView 在 Android 界面开发中出场率很高，它只负责维护屏幕内可见条目的测量、布局和绘制，数据如何变成条目视图完全由适配器决定。同一个 ListView，既可以用 BaseAdapter 显示一百条文本，也可以承载图片、按钮、多行布局等复杂结构。适配器的核心方法是 getView，系统每次准备展示一个条目都会调用它，因此 getView 的执行效率直接决定列表滑动是否流畅。先把无复用的基础写法梳理清楚，再逐步加入 convertView、ViewHolder、多类型支持和数据刷新优化，可以形成一套稳定的列表实现方式。

一、BaseAdapter 基础实现与常见性能陷阱

BaseAdapter 是 ListView 最常用的适配器基类，它需要实现 getCount、getItem、getItemId 和 getView 四个方法。其中 getCount 决定条目总数，getItem 返回对应位置的数据对象，getItemId 通常返回 position，而 getView 负责把数据填充到条目视图中并返回给 ListView。一个最直接的实现如下，它确实能显示数据，但在长列表滑动时会带来明显的性能问题。

public class FruitAdapter extends BaseAdapter {
    private List<String> data;
    private LayoutInflater inflater;
    public FruitAdapter(Context context, List<String> data) {
        this.inflater = LayoutInflater.from(context);
        this.data = data;
    }
    @Override
    public int getCount() {
        return data == null ? 0 : data.size();
    }
    @Override
    public Object getItem(int position) {
        return data.get(position);
    }
    @Override
    public long getItemId(int position) {
        return position;
    }
    @Override
    public View getView(int position, View convertView, ViewGroup parent) {
        // 没有复用 convertView，每次进入屏幕都创建新视图
        View itemView = inflater.inflate(R.layout.item_fruit, parent, false);
        TextView nameText = (TextView) itemView.findViewById(R.id.tv_name);
        ImageView icon = (ImageView) itemView.findViewById(R.id.iv_icon);
        nameText.setText(data.get(position));
        icon.setImageResource(R.drawable.ic_fruit);
        return itemView;
    }
}

这段代码最大的毛病在于没有利用 convertView 参数。ListView 滚动时，一个条目移出屏幕后，系统会把它对应的 View 作为 convertView 传给下一个进入屏幕的条目，目的就是让新条目复用旧条目的视图结构，避免重复 inflate。上面的写法每次都重新调用 inflate，然后重新 findViewById，这两步都是比较耗时的操作。inflate 需要解析 XML 并创建对象，findViewById 需要遍历视图树查找子控件，快速滑动时会在短时间内产生大量临时对象，导致内存分配频繁，垃圾回收压力增大，最终表现为滑动卡顿。

除了 inflate 和 findViewById 的开销，还有一个容易忽略的问题是 getView 中应尽量避免执行耗时操作。例如在 getView 里直接做数据库查询、网络请求或者加载未压缩的大图，都会阻塞 UI 线程。即使 convertView 已经复用，如果每次绑定数据时都同步读取文件或解码图片，列表依然不会流畅。优化适配器需要从视图复用、控件缓存和数据绑定三个层面同时下手。

二、convertView 复用与 ViewHolder 缓存

convertView 是 Android 提供给适配器的一个复用参数，它并非一定为 null。当 ListView 中有条目滑出屏幕时，系统会把这个条目的 View 对象回收并传给 getView 的下一次调用。如果 convertView 不为 null，表示可以直接复用这个旧视图，只需要更新里面的文字和图片，而不需要重新 inflate。利用这个机制可以大幅降低布局创建次数。

不过如果只做 convertView 判断，仍然需要为每次绑定调用 findViewById。例如视图里有三个文本和一个图片，滑动一百条就会额外执行几百次 findViewById。findViewById 虽然不复杂，但在 getView 这种高频调用路径中累积起来仍然可观。ViewHolder 模式就是解决这个问题的常见做法。它把条目内所有子控件的引用预先保存到一个静态内部类中，第一次创建视图时通过 findViewById 得到引用，然后用 setTag 把 holder 挂到 convertView 上。之后每次 convertView 不为 null 时，直接通过 getTag 取出 holder，跳过 findViewById。

public class FruitAdapter extends BaseAdapter {
    private List<String> data;
    private LayoutInflater inflater;
    public FruitAdapter(Context context, List<String> data) {
        this.inflater = LayoutInflater.from(context);
        this.data = data;
    }
    private static class ViewHolder {
        TextView nameText;
        ImageView icon;
    }
    @Override
    public View getView(int position, View convertView, ViewGroup parent) {
        ViewHolder holder;
        if (convertView == null) {
            convertView = inflater.inflate(R.layout.item_fruit, parent, false);
            holder = new ViewHolder();
            holder.nameText = (TextView) convertView.findViewById(R.id.tv_name);
            holder.icon = (ImageView) convertView.findViewById(R.id.iv_icon);
            convertView.setTag(holder);
        } else {
            holder = (ViewHolder) convertView.getTag();
        }
        holder.nameText.setText(data.get(position));
        holder.icon.setImageResource(R.drawable.ic_fruit);
        return convertView;
    }
}

加入 ViewHolder 后，条目创建次数从每次滑动都 inflate 变为只在首次进入屏幕时 inflate，findViewById 也只在首次绑定时执行。实际测试中，这种优化对快速滑动的帧率提升非常明显，尤其是条目布局复杂、子控件较多时。静态内部类 ViewHolder 本身不持有外部适配器的引用，也避免了隐式持有 Activity 导致的内存泄漏风险。需要注意的是，getTag 取出的对象要做类型判断或确保 setTag 时一定传入对应类型的 ViewHolder，否则在混用不同 tag 的情况下可能出现 ClassCastException。

除了 ViewHolder，getView 内部还应保持数据绑定逻辑简洁。如果条目中有图片，应使用异步图片加载库或自带缓存机制，不要在 getView 里同步解码大图。图片加载完成后如果 convertView 已经被复用到其他条目，还需要通过 view 的 tag 或 position 校验避免图片错位。对于点击事件，最好在 ViewHolder 初始化时绑定，避免每次都重复 setOnClickListener 创建新的监听器对象。

三、多布局类型与 ViewType 使用

当列表需要混合不同结构的条目时，例如第一条是头部标题，中间是普通水果项，底部是加载更多提示，单一布局已经无法满足需求。此时可以使用不同的 XML 布局文件，并重写 getItemViewType 和 getViewTypeCount。系统会根据 getItemViewType 返回的类型值为不同布局建立不同的回收池，这样 convertView 在复用时就不会把头部标题的布局错误地交给普通条目使用。

getViewTypeCount 返回列表中共有多少种视图类型，getItemViewType 则返回 position 对应的类型值。类型值必须是从 0 到 getViewTypeCount 减去 1 的整数，并且对于相同类型的位置要返回相同的类型值。如果返回值不稳定，或者在 position 变化时随意返回不同类型，系统会误判 convertView 的复用资格，可能导致复用错误布局甚至抛出类型转换异常。下面是一个双类型列表的示例。

private static final int TYPE_HEADER = 0;
private static final int TYPE_ITEM = 1;
@Override
public int getViewTypeCount() {
    return 2;
}
@Override
public int getItemViewType(int position) {
    return position == 0 ? TYPE_HEADER : TYPE_ITEM;
}
@Override
public View getView(int position, View convertView, ViewGroup parent) {
    int type = getItemViewType(position);
    if (convertView == null) {
        if (type == TYPE_HEADER) {
            convertView = inflater.inflate(R.layout.item_header, parent, false);
            HeaderHolder headerHolder = new HeaderHolder();
            headerHolder.titleText = (TextView) convertView.findViewById(R.id.tv_header_title);
            convertView.setTag(headerHolder);
        } else {
            convertView = inflater.inflate(R.layout.item_fruit, parent, false);
            FruitHolder fruitHolder = new FruitHolder();
            fruitHolder.nameText = (TextView) convertView.findViewById(R.id.tv_name);
            fruitHolder.icon = (ImageView) convertView.findViewById(R.id.iv_icon);
            convertView.setTag(fruitHolder);
        }
    }
    if (type == TYPE_HEADER) {
        HeaderHolder headerHolder = (HeaderHolder) convertView.getTag();
        headerHolder.titleText.setText("水果列表");
    } else {
        FruitHolder fruitHolder = (FruitHolder) convertView.getTag();
        fruitHolder.nameText.setText(data.get(position - 1));
        fruitHolder.icon.setImageResource(R.drawable.ic_fruit);
    }
    return convertView;
}
private static class HeaderHolder {
    TextView titleText;
}
private static class FruitHolder {
    TextView nameText;
    ImageView icon;
}

多布局场景下，不同 ViewHolder 必须分别设计，不能强行共用一个包含所有控件的 ViewHolder，因为某些布局中不存在对应的子控件，findViewById 会返回 null，后续强制转型或访问成员会报错。同时，getItemViewType 应该只根据 position 和数据源类型做判断，不要在其中进行耗时计算。若数据源中有多种对象类型，可以通过 instanceof 或对象中的类型字段来区分。返回类型值后，getView 里再次调用 getItemViewType 保持判断逻辑一致，可以避免两边类型判断不同导致的复用错误。

合理使用 ViewType 还能让不同复杂度的布局互不干扰。例如头部布局图片较多、加载较慢，普通条目布局轻量，如果没有区分类型，头部 View 被回收后可能被普通条目复用，导致普通条目出现头部控件的残留状态。区分类型之后，每种布局只在同类型内部复用，状态错乱的概率也会明显降低。

四、数据刷新与进一步优化

ListView 适配器更新数据最常用的做法是修改数据集合后调用 notifyDataSetChanged。这个方法会通知 ListView 重新计算并重绘当前所有可见条目，对一个已经绑定好 ViewHolder 的适配器来说，重绘本身不一定很慢，但如果数据频繁变化，或者列表条目很多，频繁调用仍然会造成明显的性能损耗。尤其是只更新其中一条数据时，整表刷新会做很多无用功。

更精细的做法是更新数据后，找到目标条目在当前可见范围内的 View，直接修改这个 View 上的控件内容。例如通过 ListView 的 getChildAt 结合 getFirstVisiblePosition 定位到对应条目的 View，然后更新文本或图片。这种方式不需要重新走 getView 的完整绑定流程，响应更快。不过要小心维护 position 与可见索引的对应关系，并且数据集合必须先更新，否则 UI 和数据会不一致。

另外，getItemId 不应该默认返回 position。返回 position 在数据删除或插入后会发生错位，影响一些依赖稳定 id 的操作，比如状态保存或局部刷新。如果数据对象有唯一标识，可以让 getItemId 返回该标识的哈希值或稳定长整型值。虽然 BaseAdapter 默认没有强制使用 stableIds，但在复杂业务中稳定 id 能减少很多不可预期的列表错乱。

对于长列表，还可以结合分页加载或按需加载来减少一次性创建大量对象。滑动到底部时再加载下一批数据，能缩短首屏渲染时间。图片加载则配合内存缓存和磁盘缓存，避免同一张图片反复解码。若列表中包含富文本或复杂控件，可以考虑对 getView 中不必要的对象分配进行优化，比如文本格式化提前完成、字符串拼接使用 StringBuilder、减少临时 Drawable 创建等。这些优化虽然单点收益不大，但叠加在高频 getView 路径上效果会很明显。

总体来看，ListView 适配器的优化核心在于控制 getView 的耗时和对象创建。convertView 复用避免重复 inflate，ViewHolder 缓存避免重复 findViewById，ViewType 保证多布局复用安全，局部刷新避免无意义重绘。理解和落实这几点后，传统的 ListView 仍然可以胜任大多数普通列表需求。如果后续需要更复杂的动画、嵌套滚动和细粒度数据更新，再考虑迁移到 RecyclerView 也不迟，但适配器设计和复用的思想在两者之间是完全相通的。