Q_GADGET與訪問器對象，用於處理來自QML的C ++對象的多態樹

Question

我有一個需要在QML中使用的C ++類型的多態樹。 內存使用和性能在這里很關鍵，所以我想知道哪種方法會更有效：

• Q_GADGET毫無疑問，更簡單，更快捷的方法。 我可以直接使用屬性（無通知，也沒有綁定）和插槽來訪問每個對象的成員。 它依賴於qtquick運行時中的元數據生成和某種對象標識。

• 使用全局訪問器對象訪問所有內容，獲取或設置對象屬性，調用函數等。 這絕對是較慢且更詳細的解決方案。

我以前曾嘗試將QObject派生類型注冊為QML類型，但內存使用情況令人恐懼。 我僅QObject就有巨大的開銷-基本的16字節數據集大約有140字節的開銷，而在QML中實例化對象則使情況變得更糟，將開銷提高到了約2000字節。 考慮到我要處理的對象數量太多，這是不可接受的。

因此，現在我要走很長的路要走，放棄以前的設計，想知道哪種方法最有效。 同樣，與Q_GADGET相關聯的meta東西在多態情況下Q_GADGET很好地工作。

Answer 1

因此，我決定對這兩種方法進行測試並進行比較。

幸運的是，由於通常的強制性Qt限制，我的努力在嬰兒期就被縮短了-事實證明Q_GADGET不適用於指針，以指針為基礎使用它們時屬性和函數均不可用。

僅實例支持成員訪問，因此該選項不適用於多態方案。 是手動訪問器對象！

---

更新：

有一個解決方法，但這涉及額外的工作。 實現PIMPL習慣用法，您可以使實現屬性的對象實例只是指向實際實現的指針，從而使所有復制都適用且高效。

但是，我最終沒有使用該方法，主要是因為它仍然不支持通知，並且“第三方”通知的實現效率太低。 相反，我為QML元素引用的每個對象都使用了基於QObject的“代理”或“訪問器”。 代理是按需創建的，並按引用計數，因此，它僅在需要“對象-> qml”橋的情況下存在，該橋始終僅適用於所有對象的很小一部分。 代理與對象緊密結合在一起，避免了查找對象的麻煩，而GUI本身仍然是抽象的。

與舊的基於QML對象的實現相比，該實現的真實世界優勢令人印象深刻。 從32萬個構建約300k對象的內存用完之后，它現在能夠處理約500M，提高了1666倍。