gtk-rs移植GTK3到GTK4：回调引用差异与内存释放问题咨询

问题背景 #

正在将基于gtk-rs的GTK3应用移植到GTK4，以下是精简后的示例代码（GTK3版本，GTK4需修改部分已用注释标注）：

use gtk::prelude::*;
use gtk::{ApplicationWindow, DrawingArea};
use std::cell::RefCell;
use std::rc::Rc;

struct Ctx {
    text: String,
    _drawing_area: gtk::DrawingArea,
}

impl Drop for Ctx {
    fn drop(&mut self) {
        println!("DROP");
    }
}

fn on_activate(app: &gtk::Application) {
    let drawing_area = DrawingArea::builder().build();

    let win = ApplicationWindow::builder()
        .application(app)
        .child(&drawing_area)
        .build();

    // gtk3:
    //win.show_all();

    // gtk4:
    win.show();

    let ctx = Ctx {
        text: "Hallo".into(),
        _drawing_area: drawing_area.clone(),
    };
    let shared_context = Rc::new(RefCell::new(ctx));

    {
        let shared_context = shared_context.clone();

        // gtk3:
        //drawing_area.connect_draw(move |_area, _cairo| {
        //    let ctx = shared_context.borrow();
        //    println!("draw text= \"{}\"", ctx.text);
        //    gtk::Inhibit(false)
        //});

        // gtk4:
        drawing_area.set_draw_func(move |_area, _cairo, _width, _height| {
            let ctx = shared_context.borrow();
            println!("draw text= \"{}\"", ctx.text);
        });        
    }
}

fn main() {
    let app = gtk::Application::builder().build();
    app.connect_activate(on_activate);
    app.run();
    println!("main loop finished");
}

运行现象对比 #

• GTK3环境：关闭窗口时Ctx结构体正常释放，输出如下：

Running `target/debug/droptest`
draw text= "Hallo"
DROP
main loop finished

• GTK4环境：Ctx结构体未被释放，输出如下：

Running `target/debug/droptest`
draw text= "Hallo"
main loop finished

疑问与需求 #

推测原因是循环引用：ctx -> drawing_area -> draw_func -> 闭包 -> shared_context -> ctx，但预期GTK3与GTK4的gtk-rs绑定行为一致，需明确：

1. 行为差异的来源是什么？是否有相关文档说明？
2. GTK4下的优雅解决方案：使用弱引用会导致on_activate函数结束时Ctx提前释放，但实际场景中Ctx包含多个组件与数据，且存在多个回调。

原因分析 #

GTK3与GTK4在回调生命周期管理上存在核心差异：

• GTK3的connect_draw：基于GObject信号系统实现，信号连接默认通过弱引用绑定对象。当窗口销毁时，信号连接会被自动断开，闭包的引用计数下降，循环引用被打破，Ctx最终被释放。
• GTK4的set_draw_func：是直接设置持久化绘制回调的API，GTK会持有回调闭包的强引用，直到DrawingArea对象销毁。结合代码中Ctx持有DrawingArea强引用、闭包持有shared_context强引用的逻辑，形成了完整的循环引用链，所有对象的引用计数无法归0，导致Ctx无法自动释放。

该设计变化在gtk-rs迁移指南和GTK4官方文档中有隐含说明：GTK4简化绘制API的同时，调整了回调持有策略，更依赖开发者主动管理引用关系。

优雅解决方案 #

通过将Ctx生命周期与窗口绑定，结合弱引用+窗口销毁信号手动打破循环引用，既避免提前释放，又解决资源泄漏问题：

修改后的代码示例 #

use gtk::prelude::*;
use gtk::{ApplicationWindow, DrawingArea};
use std::cell::RefCell;
use std::rc::{Rc, Weak};

struct Ctx {
    text: String,
    _drawing_area: gtk::DrawingArea,
}

impl Drop for Ctx {
    fn drop(&mut self) {
        println!("DROP");
    }
}

fn on_activate(app: &gtk::Application) {
    let drawing_area = DrawingArea::builder().build();

    let win = ApplicationWindow::builder()
        .application(app)
        .child(&drawing_area)
        .build();

    win.show();

    let ctx = Ctx {
        text: "Hallo".into(),
        _drawing_area: drawing_area.clone(),
    };
    let shared_context = Rc::new(RefCell::new(ctx));
    // 创建弱引用供回调使用，避免强引用循环
    let weak_context = Rc::downgrade(&shared_context);

    // 绘制回调使用弱引用，仅在Ctx存在时执行逻辑
    drawing_area.set_draw_func(move |_area, _cairo, _width, _height| {
        if let Some(shared) = weak_context.upgrade() {
            let ctx = shared.borrow();
            println!("draw text= \"{}\"", ctx.text);
        }
    });

    // 绑定窗口销毁信号，手动释放强引用，打破循环
    win.connect_destroy(move |_| {
        // 销毁窗口时释放shared_context的强引用，让Ctx计数归0
        drop(shared_context);
    });
}

fn main() {
    let app = gtk::Application::builder().build();
    app.connect_activate(on_activate);
    app.run();
    println!("main loop finished");
}

方案说明 #

1. 弱引用回调：绘制回调使用Weak<RefCell<Ctx>>，避免闭包持有强引用，切断循环链的关键一环。
2. 生命周期绑定：窗口的destroy信号闭包持有shared_context的强引用，确保Ctx在窗口存活期间不会被提前释放；窗口销毁时，该强引用被drop，Ctx的引用计数归0，最终触发Drop逻辑。
3. 适配多场景：该模式可扩展到多组件、多回调场景，只需将所有回调的强引用替换为弱引用，并统一在窗口销毁时释放核心的shared_context强引用即可。

内容的提问来源于stack exchange，提问作者Donald