4. LVGL内存管理机制

触摸输入这事儿，看着简单，其实坑不少。我早期做的一个产品，就因为在触摸驱动上没做优化，结果用户双指缩放时界面卡得不行。后来一查，内存碎片加上事件处理不及时，直接拖垮了渲染帧率。

这一章，咱们就聊聊怎么管好输入事件这块的内存。说白了，就是让触摸响应又快又稳，还不浪费资源。

4.1 输入事件的生命周期与内存消耗

每次触摸，LVGL内部都会创建一个 lv_indev_data_t 结构体。这个结构体不大，但架不住数量多。特别是多点触控，每个手指都对应一个独立的事件流。

事件类型	结构体大小	典型数量（同时）	总内存开销
单点触摸	~32 字节	1	~32 字节
两点触控	~32 字节 × 2	2	~64 字节
五点触控	~32 字节 × 5	5	~160 字节
事件队列缓冲	~32 字节 × 队列深度	深度 10	~320 字节

你看，单看一次事件不大。但如果你没有缓冲池，每次触摸都动态 malloc 和 free，内存碎片就会慢慢累积。我见过一个项目，跑了三天后触摸突然失灵，一查就是堆碎片把事件分配堵死了。

4.2 事件缓冲池的设计思路

缓冲池的核心思想很简单：提前分配，重复使用。说白了，就是别每次触摸都去堆上申请内存，而是预先准备好一批固定大小的槽位。

我习惯这样设计缓冲池：

1. 确定池大小：根据最大同时触控点数 × 2（留一个余量）来计算。比如支持5点触控，池深度设为10。
2. 预分配内存：在初始化时，一次性分配所有槽位。
3. 使用位图或空闲链表：管理哪些槽位空闲，哪些被占用。
4. 事件入队出队：触摸事件到来时，从池中取一个空闲槽；处理完后，归还槽位。

4.3 代码实现：一个轻量级事件缓冲池

下面是我在一个实际项目中用过的实现。它不依赖LVGL的默认内存管理，而是自己管自己。

/* 事件缓冲池配置 */
#define TOUCH_POOL_SIZE    10
#define TOUCH_EVENT_SIZE   sizeof(lv_indev_data_t)

/* 池结构体 */
typedef struct {
    lv_indev_data_t buffer[TOUCH_POOL_SIZE];
    uint8_t         free_mask;      /* 位图，1表示空闲 */
    uint8_t         head;           /* 环形队列头 */
    uint8_t         tail;           /* 环形队列尾 */
    uint8_t         count;          /* 当前使用数量 */
} touch_pool_t;

static touch_pool_t pool;

/* 初始化：所有槽位标记为空闲 */
void touch_pool_init(void) {
    pool.free_mask = 0xFF;   /* 低8位全1 */
    pool.head = 0;
    pool.tail = 0;
    pool.count = 0;
}

/* 从池中获取一个事件槽 */
lv_indev_data_t* touch_pool_alloc(void) {
    if (pool.count >= TOUCH_POOL_SIZE) {
        return NULL;   /* 池满，丢弃事件 */
    }
    /* 找到第一个空闲位 */
    uint8_t slot = __builtin_ctz(pool.free_mask);
    pool.free_mask &= ~(1 << slot);
    pool.count++;
    return &pool.buffer[slot];
}

/* 归还事件槽 */
void touch_pool_free(lv_indev_data_t* data) {
    uint8_t slot = data - pool.buffer;
    pool.free_mask |= (1 << slot);
    pool.count--;
}

4.4 多点触控的内存开销控制

多点触控的难点在于：每个手指独立跟踪，而且手指的按下、移动、抬起状态需要持续维护。如果每个手指都单独分配一个事件结构，内存开销会线性增长。

我建议的做法是：复用事件结构，按手指ID索引。

具体来说：

• 在触摸驱动层，为每个手指分配一个唯一的 finger_id（0~4）。
• 缓冲池中的每个槽位，除了存储事件数据，还存储对应的 finger_id。
• 当手指抬起时，立即释放槽位，而不是等到事件处理完。

这样，同时最多只有5个槽位被占用。即使触摸事件频率很高，内存开销也是可控的。

4.5 缓冲池与LVGL输入设备的集成

LVGL的输入设备驱动通过 lv_indev_drv_register 注册。我们需要把缓冲池挂接到这个流程中。

/* 触摸读取回调 */
static void touch_read_cb(lv_indev_drv_t* drv, lv_indev_data_t* data) {
    /* 从硬件读取触摸数据 */
    touch_point_t point;
    if (touch_hw_read(&point)) {
        /* 从池中分配事件槽 */
        lv_indev_data_t* pool_data = touch_pool_alloc();
        if (pool_data) {
            pool_data->point.x = point.x;
            pool_data->point.y = point.y;
            pool_data->state  = point.pressed ? LV_INDEV_STATE_PR : LV_INDEV_STATE_REL;
            /* 注意：这里不能直接返回 pool_data，因为 LVGL 期望 data 参数是固定的 */
            /* 正确做法：将 pool_data 内容拷贝到 data */
            memcpy(data, pool_data, sizeof(lv_indev_data_t));
            touch_pool_free(pool_data);
        } else {
            /* 池满，丢弃事件 */
            data->state = LV_INDEV_STATE_REL;
        }
    } else {
        data->state = LV_INDEV_STATE_REL;
    }
}

4.6 性能对比：动态分配 vs 缓冲池

指标	动态分配（malloc/free）	缓冲池（预分配）
分配时间（平均）	~12 μs	~0.5 μs
分配时间（最坏）	~200 μs（碎片严重时）	~1 μs
内存碎片	随时间增长	无碎片
最大同时触控数	受堆大小限制	固定（池深度）
代码复杂度	低	中

你看，缓冲池在实时性上优势明显。特别是最坏情况下的分配时间，差了200倍。对于触摸这种对响应时间敏感的场景，这个差距是致命的。

4.7 知识体系：输入事件缓冲池管理核心逻辑

下面这张图，把整个流程串起来了。从硬件触摸中断，到缓冲池分配，再到LVGL事件处理，最后归还槽位。

这个流程里，最关键的就是那个判断“池满？”的分支。如果池满了，直接丢弃事件，而不是阻塞等待。这样保证了系统不会因为触摸事件堆积而崩溃。你想想看，用户手指乱摸的时候，丢几个事件总比系统死机强吧？

4.8 避坑指南

最后，分享几个我踩过的坑：

• 坑一：池大小设得太小。 我曾经为了省内存，把池深度设为3，结果用户三指操作时频繁丢事件。后来改成5，问题解决。建议至少比最大触控点多2个。
• 坑二：忘记处理池满的情况。 如果不做池满判断，直接越界写内存，后果很严重。轻则触摸失灵，重则系统跑飞。
• 坑三：在中断中直接操作池。 触摸中断频率很高，如果在中断里分配和释放池，可能会和主循环冲突。我建议在中断里只做标记，在主循环里统一处理。
• 坑四：没有考虑手指ID的复用。 如果手指抬起后不立即释放槽位，新手指可能分配到旧的ID，导致跟踪混乱。记得在手指抬起时立即释放。