c++ - Q_GADGET 与用于从 QML 操作 C++ 对象的多态树的访问器对象

Question

我有一个 C++ 类型的多态树，我需要从 QML 使用它。内存使用和性能是这里的关键，所以我想知道哪种方法更有效:

• Q_GADGET - 毫无疑问，这是一种更简单、更快捷的方法。我可以直接使用属性(没有通知，所以也没有绑定(bind))和插槽来访问每个对象的成员。它依赖于 qtquick 运行时中的元数据生成和某种对象识别。

• 使用全局访问器对象访问所有内容、获取或设置对象属性、调用函数等。这绝对是更慢、更冗长的解决方案。

我之前曾尝试将 QObject 派生类型注册为 QML 类型，但内存使用情况非常糟糕。仅 QObject 就有巨大的开销——基本 16 字节数据集的开销大约为 140 字节，而在 QML 中实例化对象使情况变得更糟，开销飙升至大约 2000 字节。考虑到我正在处理的大量对象，这是 Not Acceptable 。

所以现在我要走很长的路，放弃以前的设计，想知道采取什么是最有效的实现。此外，与 Q_GADGET 关联的元内容是否会在多态场景中很好地发挥作用。

Answer 1

所以我决定对这两种方法进行测试运行并进行比较。

谢天谢地，由于通常强制性的 Qt 限制，我的努力被缩短了，结果 Q_GADGET 不适用于指针，当在指针上使用它们时，属性和函数都不可用基础。

成员访问仅支持实例，因此该选项不适用于多态场景。它是手动访问器对象!

---

更新:

有一个解决方法，但需要额外的工作。实现 PIMPL 习惯用法，您可以让实现属性的对象实例简单地作为指向实际实现的指针，从而使所有复制都适用且高效。

但我最终没有使用该方法，主要是因为它仍然不支持通知，而且“第 3 方”通知实现效率太低。相反，我为每个对象选择了基于 QObject 的“代理”或“访问器”，由 QML 元素引用。代理是按需创建的，并且是引用计数的，所以它只在需要“对象-> qml”桥时存在，它总是只用于所有对象的一个​​非常小的子集。代理与对象紧密耦合以避免查找它的惩罚，同时 GUI 本身仍然被抽象掉。

与旧的基于 QML 对象的实现相比，该实现在现实世界中的优势令人印象深刻。从在 32 位构建大约 300k 个对象时内存不足，现在它能够处理大约 500M，提高了 1666 倍。