1,QML只适合写界面。绝大部分的逻辑还是要靠C++的,而QML和C++通信部分是蛋疼的(不难,但是确实蛋疼,各种Invoke)。假如你一部分逻辑用js,一部分用C++,到后期维护起来,估计就想买后悔药了。
2,QML成品控件太少,稍微复杂的控件都要你自己写。没有第三方控件。而widgets有非常多的选择。
3,QML没法调试(删除),开发效率没有吹的那么高。大多情况下,你面对的其实是一个TXT文档,而运行效率则有点呵呵(内存/CPU你可以写个例子看看)。
更正:QML是可以调试的。
4,如果你想用QML做移动平台的开发,那你要考虑到跟系统的原生样式匹配问题。
真心不明白QML的定位。
--------
问:
答:
0,QML是可以调试的。我的错。
1,开发效率问题高不高的问题:
QML是只适用于做界面,写复杂逻辑还是不够的。最终产品必须C++(业务逻辑)和QML(界面)一起写。而其成品控件,第三方控件肯定没有widgets多,那么开发效率从何谈起高呢?
2,运行效率问题。
这个自己写个例子即可看到。最初我们是实用的Qt4.8,Quick1,内存占用10倍于widgets。Qt5 也至少5倍于widgets。当然,现在大家都不怎么介意内存占用了。所以看具体场景吧。
3,不明白QML的定位。
看起来Qt是想使用Quick统一天下(桌面+移动端)。这个梦想有点远大,最终能否实现么,从目前来看,没戏。移动端是肯定没戏,因为除了能“跨平台”,没有任何优势,反而到现在都支持不完善,不少bug。而跨平台特性,它是连React Native都干不过的。到现在为止移动端使用quick进行开发的寥寥无几(请试举哪些移动端重量级的产品是Qt做的?)。桌面端优势又不比widgets明显。那他的定位是什么呢?
4,QML的优势和适用场景。
QML/Quick支持GPU加速,这是非常棒的特性。做动画界面很高效,比较适合做花哨的界面,在普通的桌面程序开发中,这个优点并不突出。