Qt5及模块架构分析

关于框架

Qt这个框架历史悠久，因为当年桌面操做系统的GUI程序开发比较费劲，通常使用普通语言如c、c++或者平台自身提供的难用框架，windows、Linux、mac各有各的不一样机制。1991–Haavard Nord和Eirik Chambe-Eng开始开发将会支持X11和Windows的Qt，1994–奇趣科技公司成立，主要提供跨平台、面向对象、易用的GUI程序开发框架。另外随着Qt诞生的还有KDE，一个为Linux提供图形界面的开发库和框架。

随着逐渐的发展和社会的需求，Qt版本不断演化，功能不断增多。好比经典的Qt4系列，当年为知足嵌入式开发提供的Qt/Embedded。如今这些版本已经退出舞台。一直以来，对Qt影响比较大的转折点一是2008 Nokia从Trolltech公司收购Qt,二是2012 Aug 09 诺基亚正式放弃该框架。

诺基亚收购Qt是由于从那时起，智能手机开始流行，最先的iphone发布，android也开始发展，而Qt是当时是比较流行的嵌入式设备开发框架。单从时间节点看，诺基亚在智能手机发展初期并没用太落后，只是后来的发展过程比较缓慢，逐渐和苹果、android拉开了距离。

Qt被诺基亚收购后，其开发方向在跨平台的同时，主要面向新的基于Linux的智能手机操做系统。因为Qtwidget自己不适合触摸操做，因而伟大的QML技术诞生，QML是专为可触摸界面定制的开发语言，构成了meego系统的界面框架。随着不断的发展，诺基亚在智能手机方面被苹果和谷歌甩的更远，最终放弃手机业务。Qt也被移交给了另外一家芬兰公司。

从这时候起，Qt开始进入5的时代。技术架构方面有了完全的变化，主要是更细粒度的模块化和重点转向基于opengl的QML、QtQuick技术开发。这个时候的QML继承了诺基亚的遗产，而且完全转向以opengl为底层，使得绘图性能更好，更适合现代图形界面开发。Qt技术的演变一直以来都是很天然的，符合社会对不少方面的须要，固然，因为其是一个开源项目，没有了实力资本的支持，Qt一直以来 不少模块要么缺乏功能，要么bug比较多。直到目前（2016），Qt5.6系列发布长期支持版本，这才标志着Qt5系列已经相对比较稳定。固然，新功能的增长和优化仍是会根据需求继续发展。

关于架构和模块

Qt5开始更加注重模块化，从上层逻辑上分为Qt Essentials、Qt Add-Ons、Technology Preview、商业模块和tools 几部分。代码层面，Qt Essentials中除QML部分模块如qtdeclarative.git、qtquickcontrols.git为独立仓库，其包含的多数模块在qtbase.git仓库，如Core, Gui, Widgets, Network等。其它Add-Ons、技术预览模块通常为独立仓库。另外还有工具类如widget设计器、帮助系统、安装程序制做、构建系统、QtCreator、SDK等周边项目。

随着需求的不断变化，Qt5新增了不少功能，已经不只仅是开发界面，而是成为功能丰富的多用途框架。其中一些新功能放进了基础模块，一些以独立的附件模块提供。下面是Qt Essentials架构：

Module	Description
Qt Core	被其它模块用到的非图形模块类
Qt GUI	用于GUI界面开发的基础类，包含 OpenGL.
Qt Multimedia	用于多媒体开发的音频、视频、无线和相机功能
Qt Multimedia Widgets	上述功能的widgets实现，方便开发
Qt Network	网络功能
Qt QML	QML和javascript解析引擎
Qt Quick	基于上述语言的现代界面和功能开发框架
Qt Quick Controls	用于开发具备传统桌面风格的qml控件
Qt Quick Dialogs	各类qml实现的对话框
Qt Quick Layouts	用于qml界面开发的布局工具
Qt SQL	数据库抽象
Qt Test	测试
Qt Widgets	基于widget的GUI开发控件

其它附加模块请参考官方文档。

关于跨平台和移植

Qt自身的属性就是跨平台，即相同功能的api能够在各个平台编译运行。为了尽量达到此目的，势必会照顾各平台共有的特性和约束，另一些平台专有的功能以Extras模块提供。由于跨平台的特性，因此注定了其在各平台上并非最优化方案，通常各平台的原生开发语言和框架在不少方面要优于Qt。

虽然Qt自己是C++，但因为各平台有本身的原生语言，如android，而且上层的api都是经过这些语言导出，虽然Qt能够经过封装的形式调用，但无形中添加了不少步骤，性能上可能会有点折扣。

关于Linux移植方面，对于Qt Essentials的多数模块，通常只须要移植widget的窗口系统、QtQuick的opengl层、Multimedia须要的音视频库，驱动的移植较少。而对于其它模块，如传感器，这些模块和设备绑定的关系比较密切，除了中间库，很大程度上还须要本身移植对应的硬件驱动。

通常若是想要搭建一个基于Qt的平台，建议的途径是选一个适合应用场景的开源Linux分之，通常要对Qt有较好的支持。在这些分之中，Qt移植相关的工做如安装包文件的创建等基本已经作好，本身参考修改用于新的Qt版本便可。另外所选的Linux分之要尽量有着不错的activity和维护支持，不到无可奈何，不建议本身维护Linux分之。

移植工做有时候是很恶心的事情，Qt自己是一个上层api框架，不少功能须要调用其它中间件实现。而Linux上比较麻烦的就是软件的管理，一是版本二是依赖关系。可能为了使某功能工做，须要依赖库A，而A又依赖B，B又依赖其它乱七八糟的库。依赖解决后，若是库的版本不符合要求，通常会产生二进制兼容问题致使程序没法运行和莫名其妙问题。

现状评价和方案选择

整体上，现阶段的Qt已经能够知足不少需求，性能和体验上有所提高（固然还有各类缺陷）。目前，真正的基于操做系统的嵌入设备开发通常会选择改造的android，因为android系统的完善及应用支持，这方面的优点要远远大于Linux+Qt。而Qt通常能够用于一些对应用数量要求很少，驱动设备不是不少，界面须要灵活定制的应用场景，这方面Qt具备必定的优点。

而若是能将硬件驱动支持、应用数量、Qt的灵活性结合，则优点会更好。具体须要根据应用场景选择，好比作手机系统，Qt虽然灵活，但缺少丰富的应用生态，在如今的市场下，不太适合。通常选择Qt，要么是应用数量要求不高，要么就得本身搭建生态环境。另外硬件的驱动支持也是重要的参考。不少方案都只提供android开发包，Linux的东西较少。虽然有技术可让Linux利用android驱动，但这种绕弯子的方式可能没有直接使用android有效率。

另外对于物联网等应用，通常不须要图形界面，所用的芯片通常为单片机，跑Linux不合适。固然，在设备成本不敏感的状况下，不以为浪费或者跑Linux更合适的场景下，Linux+Qt也是选择之一，另外还能够用嵌入式web服务。