关于框架

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架构：

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

关于跨平台和移植

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服务。