尽管笔者使用C++/Qt4、5很久了，但对QML的接触与应用仍然停留在复制粘贴的碎片认识中。最近几个月，由几个学生讨论QML的问题开始，我也忙里偷闲和他们一起利用下午茶的时间，系统地阅读了Qt官方QML教程《Qt5 Cadaques》。实际上本来没有打算系统的读它，直到同学聚会要重温星际争霸-1和魔兽3，安装了暴雪的魔兽争霸官方对战平台，惊奇地发现这东西是QML写的，才准备坐下来好好读一读。今天首先宏观上聊聊这本书。
小插曲
这个书名中的“Cadaques”貌似是地名，查了半天也不知道啥缩写。我曾经凝视下面的图好久，想拼写个Cadaques出来，结果是徒劳无功。
结果，最后从首页发现原来它真的只是个地名！狗血乎？
Why Cadaques? Because one of the authors had a great holiday in this rocky coastline in the north-east of Spain.
为什么起名 Cadaques? 因为一个作者曾在怪石嶙峋的西班牙东北海岸度了个很棒的假。
以老外的脾气，估计是发生了不可言喻的嗨皮事，就把书名改成这个，果然是非常的Geek、Hippie、OpenSource。言归正传，这本书写的还是很不错的，目前是Github上的项目。
QML 是一种面向最终用户的动态语言
这本书把QML归类为一种适合做面向最终用户应用的动态语言，读完之后，感觉整体设计理念还是很先进的。
- 聚焦于迅速地描述界面。QML用一种类似C/JAVA/JS的语法描述界面元素的关系、事件，使用JavaScript语言实现必要的逻辑。前提是，QML认为现代界面都是“集中精力于一件事情”，我觉得言下之意就是QML面向的是类似APP的开发，而不是IDE/CAD的开发。QML在锚定、元素的精细控制等方面很有特色，是不是很科学，需要大量项目的实践。
- 原生地为了现代UI敏捷开发设计。书中把QML和Html相比，认为QML是从一开始就为了App UI开发设计的，要比Html更为简单、高效。底层使用C++，这一点上应该是值得相信的。另外，GIMP等工具都有直接向QML的导出，UI设计起来应该比骄傲好用。
- 具有很多C++/Qt较少涉及的功能。QML似乎专攻动画与图像。
– 画布：与html5的画布（Canvas）神似，可以支持很多动态效果；
– 动画控制：书中给了大量篇幅描述动画技术以及对图元、渐变的控制、火焰等效果的模拟。
– 图像处理：支持对2D图像的各种变换。
书中的Model-View-Delegate、Network、存储等部分如果有C++/Qt的基础，应该很容易理解。看完全书后，笔者认为前面和朋友谈的"以后程序可以用QML做" 对了一半：App和桌面的轻量级UI比较适合，类似AutoDesk Maya、WPS、Wireshark、QGIS这样的软件，还是祭出传统工具吧。下图暴雪战网应该是QML写的。
与此相对，仔细查看WPS2019的文件夹，可以看到WPS是基于C++/Qt4，以及WebKit的。
PS. WPS团队目前是不是应该考虑升级到Qt5了，或者直接跳到6.
QML与C++结合紧密
依托Qt的元对象编译（moc这个东西实际上是扩展了C++，也是Qt始终和C++委员会的老头子们搞不到一起的原因），QObject派生类的属性、方法、信号、槽，可以直接向QML发布。这样，我们就能非常灵活的扩展QML：
- 扩展模型视图、插件。可以为QML的ListView提供C++的Model。也可以使用QML的插件系统，向QML中发布功能。
- 利用现有Qt模块。如串口（QtSerial）、网络、数据库、DBus、Location、多媒体等等，很多现有模块都提供了QML的操作对象，类似Qt3D所提供的功能更为复杂。
- 几乎无限的接入能力。自己写一个QObject的派生类，就能实现QML到硬件的连接。复杂的计算全部交给C++来做。
更为便于理解的是，所有的QML程序都是从C++的main函数引导的。所有的QML程序都有类似的入口，在这个入口里，可以绑定N多自定义的东东。
#include <QGuiApplication>
#include <QQmlApplicationEngine>
int main(int argc, char *argv[])
{
QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling);
QGuiApplication app(argc, argv);
QQmlApplicationEngine engine;
engine.load(QUrl(QStringLiteral("qrc:/main.qml")));
if (engine.rootObjects().isEmpty())
return -1;
return app.exec();
}这个engine，直接可以运行JS脚本，熟悉Qt Script的读者应该比较了解Qt强大的互操作能力。
不确定的未来
QML目前仍然不是一种主流的移动端语言。看完这本书后，感觉它的未来仍旧有待观察
局限性
感觉主要有三个局限性（或者说问题）：
- 不支持复杂控件。比如，目前似乎木有TreeView。这一点如果做App倒还好，毕竟手机上以List居多。但这样一搞，自己基本上就把桌面应用这一块让给C++/Qt了。
- 片面为移动端优化。在很多低端PC上，不匹配的显卡驱动容易导致黑屏、报错问题。Canvas以及opengl-ES 对集成显卡的千元台式电脑来说，兼容性已经非常严重的程度。Qt-Creator的qml设计师在旧机器上也存在类似的问题，这一点不知道Qt是不是默认开发人员都使用独立显卡的新PC了？
- 定位不清晰。Digia收购Qt后，一心奔着移动端和嵌入式SOC去了。先说移动端，就拿安卓的JAVA来说，感觉QML还没有达到与安卓相比让人眼前一亮的程度。至少，JAVA工程师再去学C++/Qt是不现实的。虽然用QML可以同时为桌面、Andriod、MAC写app，但是毕竟也是一套新的语言。
发展面临的挑战
在手机、Pad等移动端App开发方面，QML目前很不明朗。现在移动端的速度越来越快，Html5的应用也开始多起来了。QML与Web实际上是两伙人从不同方向朝着同一个目标前进的结果。QML宣称的省资源，将随着手机性能越来越高而变得缺乏竞争力。
在嵌入式/SOC方面，QML相对省资源的特点是有优势的，这也正是Qt官网例子的大部分案例：一台心肺监控仪器、一部汽车的数字化面板等等。然而，SOC也分很多场合。许多SOC的面板是没有彩色触摸屏幕的，有的就2个指示灯；另外一些，配备有传统点阵LCD的低成本方案，连C++/Qt都跑不起来，别说QML了。SOC上QML最大的对手就是C++/Qt。
在桌面App（PC）方面，还是可圈可点的，目前已经有一些娱乐应用采用了QML。然而，桌面一方面已经不断萎缩，另一方面，QML如果不解决低成本PC的显卡兼容性问题，也会影响到自己的声誉。
后记
后面会继续关注QML技术，并适时介绍一些典型的应用。
