Qt与Dear ImGui：C++跨平台GUI框架选型与实战对比

1. 项目概述为什么我们需要跨平台GUI框架做C开发尤其是涉及到需要和用户交互的桌面应用时选对GUI框架几乎决定了项目一半的命运。我经历过不少项目从早期的MFC到后来的wxWidgets再到如今主流的Qt和新兴的Dear ImGui每个选择背后都是一堆坑和一堆经验。今天想聊的就是这两个当前在C跨平台GUI领域里风格迥异但都极具代表性的选手Qt和Dear ImGui。简单来说Qt就像一个功能齐全、装修豪华的“精装房”。你拿到手从门窗、水电到家具家电一应俱全甚至还有物业庞大的社区和商业支持。用它来开发一个功能复杂、界面标准、需要长期维护的工业软件或商业应用非常合适。而Dear ImGui则更像一个“毛坯房”或者“自建工具房”。它只给你最核心的墙体结构一个立即模式的GUI渲染库里面的布局、装修、管线怎么走全凭你自己发挥。它特别适合需要深度定制渲染、对性能极其敏感、或者界面需要频繁变动的场景比如游戏开发中的调试工具、3D建模软件的插件界面或者任何需要“把GUI画到任何地方”的奇特需求。对于刚入行的朋友可能会困惑我到底该学哪个对于有经验的开发者可能在纠结新项目用哪个更合适这篇文章我就结合自己这些年踩过的坑和做的项目从设计哲学、上手成本、性能表现、适用场景等几个维度把这两个框架掰开揉碎了讲清楚。目标不是分个高下而是帮你建立一个清晰的认知地图知道在什么路口该转向哪个方向。2. 核心理念与架构设计两种截然不同的世界观要理解这两个框架必须从它们最底层的设计哲学开始。这决定了你写代码的思维方式也框定了它们能力的边界。2.1 Qt基于信号与槽的面向对象“保留模式”GUIQt的核心是“保留模式”Retained Mode。你可以这样理解你在代码里创建了一个按钮QPushButton对象这个对象在内存中“保留”了按钮的所有状态文字、颜色、是否禁用等。Qt框架内部维护着一个控件树负责管理这些对象的状态、布局并在需要时比如窗口移动、按钮被点击由主事件循环驱动进行重绘。它的王牌机制是“信号与槽”Signals Slots。这是一种类型安全、松耦合的对象间通信方式。一个按钮被点击了它会“发射”emit一个clicked()信号你的业务逻辑函数可以作为一个“槽”slot“连接”connect到这个信号上。当信号发射时槽函数就会被自动调用。这种机制让界面逻辑和业务逻辑的解耦变得非常优雅。// 一个典型的Qt代码片段 QPushButton *button new QPushButton(“点击我”, this); QLabel *label new QLabel(“初始文本”, this); // 连接信号与槽当按钮被点击就调用lambda函数改变标签文本 connect(button, QPushButton::clicked, []() { label-setText(“按钮被点击了”); });这种面向对象和保留模式的架构带来了极佳的结构性和可维护性。你的界面元素是实实在在的对象可以通过Qt Designer进行可视化拖拽设计生成.ui文件再由uic工具编译成C代码。这对于开发复杂的、表单式的企业级应用如数据库管理前端、配置工具来说生产力极高。所有的控件、布局、样式都有成熟的、文档齐全的类支持。注意Qt的信号与槽虽然强大但连接管理不当会导致内存泄漏或无效调用。特别是使用lambda表达式或涉及对象生命周期时要特别注意在对象销毁前断开连接或使用QObject::connect的五参数形式管理上下文对象。2.2 Dear ImGui基于立即渲染模式的“过程式”GUIDear ImGui走了一条完全相反的路“立即模式”Immediate Mode。它没有“按钮对象”的概念。每一帧你都需要在代码里“描述”一遍当前这一帧的界面应该长什么样。// 一个典型的ImGui代码片段在渲染循环中 ImGui::Begin(“我的窗口”); if (ImGui::Button(“点击我”)) { // 按钮在这一帧被点击了 buttonClicked true; } if (buttonClicked) { ImGui::Text(“按钮被点击了”); } ImGui::End();注意看这里没有创建Button对象也没有Label对象。ImGui::Button(“点击我”)这个函数调用同时完成了三件事1. 计算按钮的几何形状2. 处理输入鼠标点击、悬停3. 渲染按钮。它的返回值就是一个简单的bool告诉你这一帧这个按钮是否被按下了。状态比如buttonClicked完全由用户代码自己管理。这种模式带来了几个革命性的特性极简的集成ImGui不关心你的渲染后端是OpenGL、DirectX、Vulkan还是Metal也不关心你的窗口系统是GLFW、SDL还是原生的Win32/ Cocoa。它只提供一堆绘制顶点和纹理的命令你需要自己实现一个简单的绑定层将这些命令转换到你的图形API上。官方已经为几乎所有主流组合提供了后端示例。无状态的自由界面结构完全由你的代码流决定。你可以用if/else、for循环等任何C逻辑来动态生成界面。今天按钮在左边明天根据条件它就可以跑到右边代码表达非常直接。接近零的初始化开销没有复杂的控件树构建过程启动速度快得惊人。与渲染引擎的深度集成因为绘制命令是你控制的你可以轻松地将ImGui界面渲染到纹理Texture上然后把这个纹理贴到3D场景中的一个模型表面实现“世界空间UI”。这在游戏开发中非常有用。当然代价就是所有高级功能如复杂的布局、表格、树形控件都需要你自己基于基本的绘图原语去搭建或者寻找第三方扩展库。它更像一个GUI“工具箱”而非“套件”。3. 开发体验与生产力对比从“开箱即用”到“深度定制”理念的不同直接导致了开发体验的天壤之别。我们可以从项目初始化、界面构建、数据绑定、工具链支持几个方面来感受。3.1 项目搭建与“Hello World”Qt通常你会使用Qt Creator这个强大的IDE。新建一个Qt Widgets Application项目向导会帮你生成main.cpp、mainwindow.h/cpp、*.pro项目文件。你几乎不用写一行代码直接点击运行就能看到一个带菜单栏、工具栏和中心区域的窗口。如果你想手动集成通过CMake或qmake管理依赖和构建步骤也相对标准但需要正确链接Qt的核心模块如Core, Gui, Widgets。跨平台编译通常意味着在每个目标平台都要安装对应版本的Qt SDK或自己从源码编译。Dear ImGui没有安装程序没有向导。你需要做以下几件事从GitHub下载imgui.cpp和imgui.h等核心文件。选择并集成一个后端例如imgui_impl_glfw.cppimgui_impl_opengl3.cpp。在你的渲染循环中正确调用ImGui的帧开始、构建界面、帧结束、渲染命令提交的函数。实现字体加载和纹理管理。这个过程对于新手可能有些吓人但一旦跑通第一个例子后续就都是一样的模式。它的“项目搭建”本质上就是“把几个源文件拖进你的工程里”。跨平台性极好因为你的代码不依赖平台特定的GUI库只依赖你选择的后端如GLFW/SDL而这些库本身也是跨平台的。3.2 界面构建与工具支持这是两者差异最大的地方。Qt的优势在于其成熟的可视化设计工具Qt Designer。你可以像拼图一样拖放按钮、列表、输入框用布局管理器自动排列直观地设置属性并通过Qt的样式表QSS一种类似CSS的机制来美化界面。设计好的界面保存为.ui文件在编译时自动生成C代码。这种“所见即所得”的方式对于构建数据录入、信息展示等传统桌面界面效率是碾压级的。此外Qt提供了海量的内置控件从基础的按钮到复杂的图表Qt Charts、3D视图Qt 3D、Web引擎Qt WebEngine几乎涵盖了所有你能想到的需求。Dear ImGui的界面构建是纯代码驱动的。所有的窗口、控件位置都是通过函数调用在代码中定义的。这听起来很原始但却带来了无与伦比的灵活性和动态性。你的界面逻辑可以紧密地和你应用程序的状态绑定在一起。// 动态生成一个属性编辑器 for (auto property : object.properties) { ImGui::Text(“%s:”, property.name.c_str()); switch (property.type) { case PropertyType::Float: ImGui::DragFloat(property.name.c_str(), property.value.floatValue, 0.1f); break; case PropertyType::Color: ImGui::ColorEdit3(property.name.c_str(), property.value.colorValue[0]); break; // ... 其他类型 } }这种模式特别适合开发工具软件因为工具软件的界面本身就是程序逻辑的直观反映。没有.ui文件需要同步界面改了就是代码改了版本管理清晰。但缺点也很明显调整像素级布局、实现复杂的多列对齐需要手动计算位置比较繁琐。社区也有一些布局辅助库如ImGuiLayout和扩展控件库如ImGuiColorTextEdit但生态和Qt完全不在一个量级。3.3 数据绑定与状态管理Qt使用模型/视图Model/View架构来处理数据与显示的分离。例如你要显示一个文件列表不会直接往QListWidget里塞字符串而是创建一个继承自QAbstractItemModel的模型类在里面管理实际的数据。视图QListView会自动监听模型的变化并更新显示。这种架构对于显示大型、结构化数据如数据库查询结果非常高效和优雅。状态由各个控件对象和自定义的数据模型共同管理。Dear ImGui是无状态的状态管理完全交给用户。这既是自由也是负担。简单的状态如一个布尔开关、一个浮点数可以直接用局部变量。复杂的状态就需要你自己设计数据结构来管理ImGui只负责读取和修改这些数据。这种直接性使得调试非常方便你可以在任何地方修改状态并立即看到界面反馈但大型应用的状态管理需要你引入类似MVC的模式来组织代码否则容易变得混乱。4. 性能、资源与部署考量轻量化与重型化的抉择选择框架时性能和应用体积往往是硬性指标。4.1 运行时性能与内存占用Qt作为一个完整的应用框架其运行时开销是显著的。启动时需要初始化庞大的元对象系统、事件循环、样式引擎等。一个最简单的空Qt Widgets应用内存占用可能在几十MB到百MB级别取决于链接方式和编译器优化。它的渲染通过平台原生的绘图API如Windows上的GDI/Direct2DmacOS上的Core Graphics或自身的渲染引擎如RHI完成通常不是性能瓶颈但在需要每秒60帧以上高频率、大量动态元素更新的场景下如实时数据仪表盘需要精心优化避免频繁的布局计算和重绘。Dear ImGui的性能特点非常鲜明CPU端每一帧都需要重新构建整个界面的绘制命令列表Draw List。对于静态界面这看起来是浪费。但实际上由于ImGui的代码极其紧凑且避免了复杂的对象管理和事件分发这个重建过程非常快。在典型的工具界面下几百个控件每帧的CPU时间通常小于1毫秒。GPU端ImGui将所有界面的绘制合并为尽可能少的绘制调用Draw Call。它通常只生成一个或少数几个顶点/索引缓冲区并使用一张包含所有字形和图标的小纹理图集Atlas。这使得它的GPU开销极低几乎可以忽略不计。内存一个集成了ImGui的应用程序其内存增量通常只有几百KB到几MB因为它不创建永久的控件对象。实操心得ImGui的性能优势在界面频繁变化时尤为突出。比如一个实时显示传感器数据的监控窗口数据每秒更新几十次。用Qt你需要调用setText()可能触发重绘和布局计算。用ImGui你只是在下一次帧循环中传入了新的字符串值重建命令列表的开销恒定且很低。但对于一个拥有几十个复杂标签页、数千个静态控件的配置对话框Qt的首次构建可能更慢但之后因为状态被保留交互响应可能更灵敏而ImGui则需要每帧重建这数千个控件的命令CPU压力会增大。不过在实际中这种巨型静态界面很少见。4.2 应用体积与依赖Qt的应用体积一直是个痛点。即使用静态链接并剥离调试符号一个简单的控制台程序加上Qt Core和Gui模块也很容易超过10MB。如果使用了更多模块如Network, Multimedia体积会迅速膨胀。动态链接可以减小可执行文件但需要随应用分发对应的Qt DLLWindows或FrameworkmacOS部署包依然不小。商业应用还需要考虑Qt的许可证LGPL要求动态链接或提供对象文件商业版则需付费。Dear ImGui在这方面是极致的轻量。核心库只有几个头文件和源文件编译后体积增加极小。它没有任何外部依赖除了你选择的图形和窗口后端部署极其简单几乎就是“把exe扔过去就能跑”。这对于开发需要内嵌到其他大型软件中的工具、插件或者对分发体积有严格要求的场景如一些独立游戏是巨大的优势。4.3 部署与跨平台一致性Qt的跨平台能力是其立身之本。“一次编写到处编译”的理念执行得很好。但“一致性”有两面性优点Qt在不同平台上会尽量使用原生风格通过Fusion等样式也可以统一为自定义风格让应用看起来像是系统原生的。行为也经过适配符合各平台习惯。挑战为了达到这种一致性Qt在底层做了大量抽象和封装。当你遇到一个平台特有的bug或需要调用原生API时可能需要使用#ifdef进行条件编译或者使用Qt提供的平台抽象类如QWindow这有时会引入复杂性。Dear ImGui提供的是视觉和交互的一致性。因为界面是自己绘制的它在Windows、macOS、Linux上看起来和操作起来完全一样。这对于开发工具类软件是优点因为用户希望操作逻辑统一。但对于面向大众的消费级应用这种“非原生”感有时会被认为不够精致。不过ImGui的高度可定制性允许你通过修改样式颜色、圆角、字体来打造独特的视觉风格甚至可以模仿原生系统的外观虽然比较费力。5. 适用场景与选型指南没有最好只有最合适经过上面的对比我们可以清晰地画出它们的势力范围。5.1 坚定选择 Qt 的场景开发传统桌面应用程序这是Qt的主场。需要复杂的窗口管理多文档界面MDI、停靠窗口、丰富的标准控件表格、树形视图、富文本编辑、完整的键盘导航和支持无障碍访问的应用。例如办公软件、集成开发环境IDE、音视频编辑软件、CAD/CAM软件。需要快速原型开发或对UI设计效率要求极高Qt Designer能极大加速界面布局和迭代。产品经理或设计师可以通过设计器快速产出界面原型。项目庞大需要清晰的架构和长期维护Qt的面向对象设计、信号槽机制、模型/视图架构为大型项目提供了良好的工程实践基础。其成熟的文档、庞大的社区和商业支持Qt Company能降低长期维护风险。需要用到Qt生态中的其他强大模块例如你需要内嵌一个功能完整的浏览器Qt WebEngine需要操作蓝牙设备Qt Bluetooth或者需要一套现成的图表解决方案Qt Charts。直接使用Qt的这些模块比寻找第三方库并集成要省心得多。5.2 坚定选择 Dear ImGui 的场景游戏开发工具链这是ImGui诞生的土壤。游戏引擎的编辑器、调试器、性能分析器、关卡编辑器等需要深度集成到渲染管线中界面需要随游戏视图实时更新并且要求极低的输入延迟。ImGui是事实上的标准。3D图形/科学可视化软件的辅助界面例如在你自己写的渲染器、物理模拟器或数据可视化程序中需要一些参数调节面板、摄像机控制窗口。ImGui可以无缝地和你自己的OpenGL/Vulkan/DirectX渲染代码结合在一起。需要高度定制或非标准界面的应用你想做一个完全圆形的控制盘、一个节点式编程界面、或者一个模仿物理旋钮的控件。用Qt实现这些需要自定义绘制QPainter可能很复杂。而ImGui从底层就是让你“画”界面实现这种定制反而更直接。嵌入式或资源受限环境在一些非x86的嵌入式平台上内存和存储空间紧张无法承载完整的Qt运行时。ImGui极小的体积和简单的依赖使其成为可行选项。快速迭代的内部工具当你需要为某个特定任务快速开发一个一次性或短期使用的工具时ImGui的“代码即界面”模式允许你边写逻辑边构建界面开发调试循环非常快。5.3 混合使用与折中方案现实中的选择不总是非此即彼。有些聪明的做法是混合使用主应用用Qt调试/工具面板用ImGui在一个大型的Qt应用中你可以将ImGui集成到某个OpenGL WidgetQOpenGLWidget中用于渲染一些需要高性能实时更新的可视化调试信息比如一个3D场景的调试视图。使用Qt for Python (PySide6)如果你喜欢Qt的完备性但又觉得C开发较慢可以考虑使用PySide6。它提供了Qt的全部功能但用Python开发能极大提升工具开发效率。而性能关键的核心部分仍可用C实现。关注其他轻量级选项如果你喜欢ImGui的理念但需要更多现成的控件可以关注基于ImGui的扩展项目如ImGui的ImPlot绘图库、ImNodes节点编辑器。或者评估其他立即模式GUI库如Nuklear比ImGui更小。6. 常见问题与实战避坑指南在实际项目中切换或使用这两个框架会遇到一些典型问题。这里记录一些我的踩坑经验。6.1 Qt 开发中的典型“坑”内存管理Qt使用父子对象parent-child机制进行内存管理。当父对象被销毁时会自动销毁其所有子对象。这很方便但也容易导致问题。比如如果你将一个局部变量窗口的父对象设置为nullptr又忘了手动delete就会内存泄漏。反之如果错误地设置了父对象可能导致对象被意外提前销毁。使用智能指针QSharedPointer,QScopedPointer是现代Qt代码的好习惯。多线程Qt的GUI组件不是线程安全的。所有对界面元素的更新都必须在主线程即GUI线程中进行。如果从工作线程更新UI必须使用信号槽Qt::QueuedConnection连接方式或QMetaObject::invokeMethod来将调用“投递”到主线程事件队列。忘记这点是导致程序随机崩溃的常见原因。样式表QSS性能QSS非常强大但滥用会影响性能。特别是对可滚动区域内的众多项目使用复杂选择器会导致滚动时的重绘性能下降。尽量使用ID选择器并避免在paintEvent中动态设置样式。部署时的依赖地狱在Windows上使用动态链接需要借助windeployqt工具来收集所有必需的DLL。但即使这样有时还是会漏掉某些插件如图像格式插件qjpeg.dll、平台插件qwindows.dll。务必在目标系统或干净的虚拟机上进行充分的部署测试。6.2 Dear ImGui 集成与使用中的挑战输入处理冲突ImGui需要独占处理鼠标和键盘输入。你必须确保在ImGui处理完输入后阻止这些输入事件继续传递给你自己的3D摄像机控制器或其他逻辑。通常在后端的实现文件如imgui_impl_glfw.cpp中会有设置回调函数来“偷走”输入事件的代码。如果集成后发现鼠标点击UI时背后的3D场景摄像机也在乱动就是这里没处理好。字体管理与图标集成ImGui默认使用Proggy字体很丑。加载TTF字体文件是必须的。但要注意中文字体文件很大全加载会占用大量显存。通常的解决方案是只加载所需字符范围的字体ImFontGlyphRanges或者使用字体合并工具。添加自定义图标如FontAwesome也需要将图标打包成纹理图集并正确设置UV坐标。界面状态持久化ImGui本身不保存窗口位置、大小、折叠状态。你需要手动调用ImGui::SaveIniSettingsToMemory()和ImGui::LoadIniSettingsFromMemory()来保存/加载这些状态到磁盘。很多新手会忘记这个功能导致每次打开工具窗口都要重新调整布局。复杂布局的实现实现一个类似属性网格Property Grid那样整齐排列“标签-控件”的布局需要手动计算文本宽度和对齐。虽然ImGui提供了ImGui::Columns()等辅助函数但相比Qt的布局管理器还是需要更多的手动计算。社区库ImGuiLayout或ImGuiKnobs用于旋钮可以解决部分问题。6.3 选型决策速查表为了更直观我将核心决策因素总结成下表考量维度QtDear ImGui点评与建议应用类型传统桌面应用、商业软件、工业控制HMI游戏开发工具、实时调试面板、图形学工具、嵌入式UI目标用户和使用场景是首要判断依据。开发效率高可视化设计控件丰富中高代码即界面迭代快但复杂布局费时对于标准表单Qt效率碾压对于动态生成、工具类UIImGui更直接。学习曲线陡峭元对象系统、信号槽、模型/视图等概念多平缓API直观概念少但需理解立即模式ImGui更容易“跑起来”但精通并构建大型工具也需要良好设计。运行时性能中等启动慢内存占用大渲染优化后流畅极高启动快内存占用极小每帧重建开销低对60FPS以上实时界面、资源紧张环境ImGui优势明显。部署体积大动辄几十MB极小仅增加几百KB~几MB分发体积敏感如游戏内置工具、小工具软件选ImGui。界面定制性高可通过QPainter自绘但较复杂极高像素级控制想画什么就画什么需要完全自定义、非矩形、动态视觉效果ImGui是首选。跨平台一致性高模拟原生风格行为适配极高自己绘制完全一致需要“一个样子走天下”选ImGui需要“像本地软件”选Qt。长期维护性高架构清晰文档齐全商业支持中代码简单直接但大型项目需自己设计架构大型团队、长期项目Qt的工程化支持更好。生态与扩展极其丰富官方模块多第三方库海量活跃但小众核心稳定扩展库由社区贡献需要现成的图表、报表、Web视图等Qt是唯一选择。7. 从零开始两个框架的极简入门示例最后让我们用最简短的代码分别感受一下用Qt和Dear ImGui创建一个带按钮的窗口是什么感觉。这能最直观地体现两者的思维差异。7.1 Qt 极简示例 (使用 CMake)CMakeLists.txt:cmake_minimum_required(VERSION 3.16) project(HelloQt) set(CMAKE_CXX_STANDARD 17) set(CMAKE_AUTOMOC ON) # 自动处理Qt的元对象编译 find_package(Qt6 REQUIRED COMPONENTS Core Gui Widgets) add_executable(HelloQt main.cpp) target_link_libraries(HelloQt Qt6::Core Qt6::Gui Qt6::Widgets)main.cpp:#include QApplication #include QPushButton #include QMessageBox int main(int argc, char *argv[]) { QApplication app(argc, argv); // 创建应用对象管理事件循环 QPushButton button(“点击我”); button.resize(200, 100); // 设置按钮大小 button.show(); // 显示按钮窗口 // 连接信号与槽点击按钮时弹出消息框 QObject::connect(button, QPushButton::clicked, []() { QMessageBox::information(nullptr, “提示”, “你好Qt”); }); return app.exec(); // 进入主事件循环 }要点你需要先创建QApplication然后创建控件对象设置属性连接信号槽最后启动事件循环。控件对象在堆栈或堆上创建由框架管理其生命周期和绘制。7.2 Dear ImGui GLFW OpenGL3 极简示例假设你已经集成了imgui、imgui_impl_glfw、imgui_impl_opengl3这几个源文件。main.cpp:#include “imgui.h” #include “imgui_impl_glfw.h” #include “imgui_impl_opengl3.h” #include GLFW/glfw3.h int main() { // 1. 初始化GLFW窗口和OpenGL上下文 glfwInit(); GLFWwindow* window glfwCreateWindow(1280, 720, “Hello ImGui”, NULL, NULL); glfwMakeContextCurrent(window); glfwSwapInterval(1); // 开启垂直同步 // 2. 初始化Dear ImGui上下文 IMGUI_CHECKVERSION(); ImGui::CreateContext(); ImGuiIO io ImGui::GetIO(); (void)io; // 3. 设置ImGui样式可选 ImGui::StyleColorsDark(); // 4. 初始化平台和渲染器后端 ImGui_ImplGlfw_InitForOpenGL(window, true); ImGui_ImplOpenGL3_Init(“#version 130”); bool show_demo_window false; bool show_another_window false; // 5. 主渲染循环 while (!glfwWindowShouldClose(window)) { glfwPollEvents(); // 处理系统事件 // 开始新一帧的ImGui构建 ImGui_ImplOpenGL3_NewFrame(); ImGui_ImplGlfw_NewFrame(); ImGui::NewFrame(); // 构建我们的界面 { ImGui::Begin(“主窗口”); if (ImGui::Button(“点击我”)) { // 按钮在这一帧被点击了 show_another_window true; } ImGui::SameLine(); ImGui::Text(“这是一个按钮。”); if (show_another_window) { ImGui::Begin(“另一个窗口”, show_another_window); ImGui::Text(“你好ImGui”); if (ImGui::Button(“关闭我”)) show_another_window false; ImGui::End(); } ImGui::End(); } // 渲染 ImGui::Render(); int display_w, display_h; glfwGetFramebufferSize(window, display_w, display_h); glViewport(0, 0, display_w, display_h); glClearColor(0.45f, 0.55f, 0.60f, 1.00f); glClear(GL_COLOR_BUFFER_BIT); ImGui_ImplOpenGL3_RenderDrawData(ImGui::GetDrawData()); // 执行ImGui的绘制命令 glfwSwapBuffers(window); } // 6. 清理 ImGui_ImplOpenGL3_Shutdown(); ImGui_ImplGlfw_Shutdown(); ImGui::DestroyContext(); glfwDestroyWindow(window); glfwTerminate(); return 0; }要点你需要自己管理窗口和OpenGL上下文。在每一帧的循环中先调用NewFrame()然后通过一系列ImGui::Begin()/ImGui::End()和控件函数“描述”界面最后调用Render()和渲染后端的提交函数。界面状态如show_another_window完全由你自己的变量控制。对比这两个例子你可以深刻感受到“对象与事件”和“立即描述”两种思维模式的差异。Qt的代码更像是“设置和配置”而ImGui的代码更像是“每帧的绘制脚本”。我个人在实际项目中的体会是不要试图用一个框架解决所有问题。评估新项目时我会先问几个问题这个工具的最终用户是谁界面是静态表单居多还是动态调试面板居多是否需要和现有的3D渲染引擎深度集成对安装包大小和启动速度有多敏感团队更熟悉哪种开发模式回答完这些问题选择往往就清晰了。很多时候甚至在同一个大项目中不同的子模块根据其特性分别选用Qt和ImGui让它们各司其职才是最优解。工具是为人服务的搞清楚你要解决的核心问题才能选出最趁手的那把“锤子”。