早上好，我有一个问题要问 Qt 专家，我想知道使用 qrc 内部资源的正确形式和最佳性能是什么，例如我有：
1-
Image {
id: bg
anchors.bottomMargin: 60
anchors.fill: parent
source: "qrc:///assets/img/drawable-hdpi/bg.png"
}
阿拉伯数字-
Image {
id: bg
anchors.bottomMargin: 60
anchors.fill: parent
source: "../assets/img/drawable-hdpi/bg.png"
}
设计模式下的第一个 qtcreator 不显示 BG 图像，但在预览或模拟器中工作
设计模式下的第二个QtCreator显示图像并在预览中工作
也采用这种形式：
Image {
id: bg
anchors.bottomMargin: 60
anchors.fill: parent
source: "qrc:/assets/img/drawable-hdpi/bg.png"
}
在预览模式下工作，但设计模式下的 QTcreator 不显示 BG.png
我在一些QT博客文章中读到，如果你想使用缓存或类似的想法，你需要使用资源作为 qrc://，但我现在找不到链接。
但是我想知道什么是最好的形式，以及为什么在设计模式下使用 QtCreator qrc://无法显示资源。
Qt资源编译器(qrc)生成包含二进制文件的C文件，然后这些文件被编译并链接到可执行文件中，并且Qt中不涉及二进制数据的缓存。
您用于访问资源的路径在性能方面没有区别：如果使用绝对qrc://协议加载某些顶级 QML 文件，则所有具有相对路径的子级将从编译到可执行文件的资源加载，而不是从操作系统文件系统加载(这将失败，因为这些文件在可执行文件运行时不在构建/安装文件夹中)。
由于可执行文件通常是内存映射的(就像您对可执行文件进行了mmap一样)，因此访问资源与访问内存映射文件的内容一样快，即可能是通过操作系统访问任何内容的最快方法。
当然，路径必须被解析，但这具有相对较低的成本。我还没有检查过这个，但是Qt的qrc"文件系统"实现可以对URI进行哈希处理并将这些哈希值与资源表匹配，并且仅在失败时才解析路径 - 但我不确定任何性能改进是否值得，除非您使用的是资源非常有限的系统。现在，如果这种散列行为是API的一部分(即记录Qt必须以这种方式运行)，那么设计你的软件来利用它是谨慎的，以免过早地悲观。如果没有这样的API保证，我不会担心它，因为无论你基于实现细节进行什么微优化，都可能会在下一个Qt版本中使事情变得更糟。