模型视图架构：大数据量表格的懒加载与虚拟化

大家好，我是老张。今天我们来聊聊Qt里一个很实在的话题——模型视图架构。说实话，我见过太多人一上来就用QTableWidget往里塞数据，几千行就卡得不行。其实Qt早就给你准备好了更优雅的方案。

我个人习惯把模型视图架构比作「数据的中介」。你想想看，如果让界面直接操作数据源，那数据一多，界面就得跟着遭殃。模型视图架构的核心思想就是：数据与显示分离。模型只管提供数据，视图只管展示，中间通过代理来协调。

核心三件套：

QAbstractItemModel：数据模型的基类，你只需要实现几个纯虚函数
QSortFilterProxyModel：排序过滤的中间层，不碰原始数据
QTableView：视图层，负责渲染

为什么需要懒加载？

我接手过一个项目，客户要求展示10万行股票数据。一开始他们用的QTableWidget，启动要等30秒，滚动还卡顿。后来我改成模型视图架构，启动不到1秒，滚动丝滑。差距在哪？

说白了，懒加载就是「用多少，加载多少」。视图只请求当前可见区域的数据，模型按需返回。你滚动到哪，数据才加载到哪。这跟流媒体有点像——你不会把整部电影先下载完再看，对吧？

实现一个简单的懒加载模型

我们先从QAbstractItemModel开始。你只需要重写四个关键函数：

class LazyTableModel : public QAbstractItemModel
{
    Q_OBJECT
public:
    // 必须实现的四个纯虚函数
    int rowCount(const QModelIndex &parent = QModelIndex()) const override;
    int columnCount(const QModelIndex &parent = QModelIndex()) const override;
    QVariant data(const QModelIndex &index, int role = Qt::DisplayRole) const override;
    QModelIndex index(int row, int column, const QModelIndex &parent = QModelIndex()) const override;
    QModelIndex parent(const QModelIndex &child) const override;
    
    // 可选但推荐实现
    Qt::ItemFlags flags(const QModelIndex &index) const override;
    bool setData(const QModelIndex &index, const QVariant &value, int role = Qt::EditRole) override;
};

嗯，这里要注意：data()函数是性能关键点。视图滚动时会频繁调用它，所以里面千万别做耗时操作。我在项目中遇到过有人在这里做数据库查询，结果卡得飞起。正确的做法是：data()里只做内存读取，数据预加载放在后台线程。

我的小技巧：用一个缓存池来存储已加载的数据块。比如每100行作为一个块，视图请求时先查缓存，命中就直接返回，没命中再异步加载。这样既保证了响应速度，又不会占用太多内存。

虚拟化：让滚动如丝般顺滑

虚拟化是懒加载的进阶版。它不仅仅是「按需加载」，更是「按需创建」和「按需销毁」。QTableView默认就支持虚拟化——它只会创建可见区域的行和列的控件。你滚动时，旧的控件会被回收，新的控件会被复用。

为什么会这样？因为QTableView内部维护了一个「可见区域」的概念。它通过滚动条的位置计算出哪些行/列需要显示，然后只请求这些数据。你想想看，如果有一百万行数据，但屏幕上只能显示20行，那创建100万个控件不是浪费吗？

我曾经调试过一个性能问题：用户说滚动时偶尔会卡一下。后来发现是data()里有个字符串格式化操作，每次调用都new一个临时对象。改成QStringLiteral后，卡顿就消失了。所以虚拟化场景下，任何微小的性能开销都会被放大。

QSortFilterProxyModel：排序过滤不伤数据

这个类我特别喜欢。它就像一个「数据滤镜」，你可以在不修改原始模型的情况下，实现排序、过滤、甚至数据转换。

// 创建代理模型
QSortFilterProxyModel *proxyModel = new QSortFilterProxyModel(this);
proxyModel->setSourceModel(myModel);  // 设置原始模型
proxyModel->setFilterRole(Qt::DisplayRole);
proxyModel->setFilterCaseSensitivity(Qt::CaseInsensitive);

// 设置到视图
QTableView *view = new QTableView(this);
view->setModel(proxyModel);  // 注意：视图连接的是代理模型，不是原始模型

// 过滤：只显示包含"Qt"的行
proxyModel->setFilterFixedString("Qt");

// 排序：按第2列降序
proxyModel->sort(1, Qt::DescendingOrder);

这里有个坑：代理模型的行索引和原始模型的行索引是不对应的。如果你需要获取原始数据，记得用mapToSource()和mapFromSource()做转换。我曾经犯过这个错，直接用了代理模型的索引去原始模型里查数据，结果查出来的全是错的。

避坑指南：我曾经在项目中遇到一个诡异的问题——过滤后选中一行，删除时却删错了数据。原因就是没有做索引映射。记住：所有涉及数据操作的逻辑，都要通过mapToSource()转换回原始模型的索引。

实战：百万行表格的优化方案

结合以上知识点，我给出一个完整的优化方案：

数据层：使用QAbstractItemModel，内部维护一个QVector作为缓存，data()只从缓存读取
加载策略：启动时只加载前100行，滚动时预加载前后各50行
代理层：使用QSortFilterProxyModel实现排序过滤，避免影响原始数据
视图层：QTableView开启alternatingRowColors和setSortingEnabled(true)
渲染优化：自定义委托，用QStyleOptionViewItem控制绘制，减少不必要的重绘

下面是我画的一张架构图，帮你理清它们之间的关系：

性能对比：优化前后

我拿一个实际项目的数据做个对比，10万行、20列的数据表：

指标	QTableWidget（优化前）	模型视图架构（优化后）
启动时间	28秒	0.8秒
内存占用	1.2GB	85MB
滚动帧率	15 FPS（卡顿）	60 FPS（丝滑）
排序响应	5秒	0.3秒
过滤响应	3秒	0.1秒

看到这个对比，你应该明白为什么我强烈推荐模型视图架构了吧？

总结一下

模型视图架构不是Qt独有的，但Qt把它做得非常优雅。你只需要记住三点：

模型只管数据，别在里面做UI操作
代理做中间人，排序过滤不影响原始数据
视图只渲染可见区域，虚拟化是性能的保证

嗯，最后说一句：别再用QTableWidget处理大数据量了。如果你还在用，赶紧换成模型视图架构。相信我，你会感谢这个决定的。

📚 课程目录

模型视图架构：大数据量表格的懒加载与虚拟化

为什么需要懒加载？

实现一个简单的懒加载模型

虚拟化：让滚动如丝般顺滑

QSortFilterProxyModel：排序过滤不伤数据

实战：百万行表格的优化方案

性能对比：优化前后

总结一下