下面是转自百度上的一些回答，大家有什么看法？
（转）您好，很高兴为您解答： 不看好Qt for Android。以下简称QfA.
1. 跨平台只在PC上有优势，在移动设备上毫无优势。移动设备整体的应用风格需要保持一致，你外部加进来一个UI，倒是和平台保持一致了。你如何保持和原生UI的这种使用一致性。
2.在开发易用度上，Android(java) API 已经做得很好，包括事件，广播，服务等Qt里有的基本上Android API里已经做得很好，从Qt开发者转为java开发者也很容易。 而如果要写QfA应用，开发者不仅要懂Qt，同样也避免不了要写java代码。
3. 如果要写和其它app通信的时候,QfA的灾难性就来了。如果是上层的几乎等完整的搞一遍Android API吧。 另外对于和设备相关的一些调用(GPS/Telephony)等,QfA的工作量一下子就上来了，这时候你还指望QML么？
4.性能呢？ QfA对于图形渲染区的请求还得在java的接口请求，是不是又要绕了个大弯。
5. 软件体积。 终端用户要用Qt app，势必要先装一个Qt lib， 或者在你的app 中一起静态发布。 在有很多优秀的QfA app出现之前，大家不带乐意只为一个好的app 去装一个大的软件，而会愿意选择一个原生软件替代。
6.官方支持。目前Qt开发团队多少人？但目前他们要支持多少平台。 如果没有一个比较大的商业级别软件在用QfA,官方能做的就是让这个软件在Android平台能编译，运行，解决一些明显的bug。
7. Qt做mobile最好的机会就是被大款看上。她也曾经被看上过(Nokia 和 Intel)。 但是被Elop害死了。
------解决思路----------------------
没有一种框架是没有问题的，看你的需求了，你在意什么，决定了你的选择。
------解决思路----------------------
1. 跨平台只在PC上有优势，在移动设备上毫无优势。移动设备整体的应用风格需要保持一致，你外部加进来一个UI，倒是和平台保持一致了。你如何保持和原生UI的这种使用一致性。
=============================
个人觉得，第一点是有误，现在虽说界面风格很重要，但你看看很多主流的app都在保持统一的自家的风格（至少在排版上和配色上，操作逻辑可以不一样），但qt是跨平台的，这里的跨平台总被人说是gui的跨平台，说白了，就是一模一样的界面，其实这是不可能！即使我使用qt开发各个平台的app，我也是会重写界面的，至少我得写一个设置来进行不同平台界面的适配，但是，最重要的一点是，我的后台代码和业务代码不用重写，这不是当下最最最最流行的前端和后台业务的分离吗？不一样的风格界面却运行着一样的业务，对于大公司跨平台开发是有十分的诱惑力的。一个核心的业务团队，多个不同平台的界面设计和美化团队，只要数据对接成功，就可以了，好过雇佣多个平台的团队，在界面设计和美化是上不会重复，但在核心业务设计上，其实是有职务重叠的。
另一个，就安卓而言，现阶段各大厂商都在耍自己的安卓UI和风格，即使是使用java来开发也不可能和原生的UI保持一致。
再说到，界面设计和业务代码的分离，其实我真的得着重介绍一下qml，qml在诺记时代被推出时，本身定位就是界面描述语言，对界面只要进行描述就可以达到界面设计的目的，而且专门针对移动设备，当时诺记可是有两个不同的平台，那诺记当然是推出针对不同平台的UI库啦，但是即使是不同的UI库，但他们的控件名和使用方式完全一模一样！但渲染出来的样式则各有各的风格。
在 Digia 时代，QtQuick模块更是推出了QtQuick.Controls模块，还有QtQuick.Controls.Styles 模块，可以直接使用纯qml实现一些风格的界面。
例如：Metro风格的控件
https://github.com/wilfilho/qml.metro
https://github.com/qyvlik/Metro.qml
2.在开发易用度上，Android(java) API 已经做得很好，包括事件，广播，服务等Qt里有的基本上Android API里已经做得很好，从Qt开发者转为java开发者也很容易。 而如果要写QfA应用，开发者不仅要懂Qt，同样也避免不了要写java代码。
=============================
关于第二点，在转型上都会遇到的门槛，这里就不多说了
3. 如果要写和其它app通信的时候,QfA的灾难性就来了。如果是上层的几乎等完整的搞一遍Android API吧。 另外对于和设备相关的一些调用(GPS/Telephony)等,QfA的工作量一下子就上来了，这时候你还指望QML么？
=============================
这个 Digia 会搞定的，再说了qt当年在诺记手上时，那可是要顾到自家的两个平台呢！一个是塞班一个是MeeGo，系统内核完完全全不一样的，所以在系统调度上Qt可是会进行封装的哦（QtDBus话说在新的版本中已经可以通用了，但是在安卓上的话，就使用QAndroidJniObject）~
4.性能呢？ QfA对于图形渲染区的请求还得在java的接口请求，是不是又要绕了个大弯。
=============================
关于图形界面，安卓底层是c/c++ ，应用框架是java，怎么说呢？Qt作为一个正统的c++框架，这个Digia会搞定的
5. 软件体积。 终端用户要用Qt app，势必要先装一个Qt lib， 或者在你的app 中一起静态发布。 在有很多优秀的QfA app出现之前，大家不带乐意只为一个好的app 去装一个大的软件，而会愿意选择一个原生软件替代。
=============================
体积的话，qt版安卓应用，破天了，全部库都打包进app里，要200M，但是一个包含网络模块，数据库模块和用户界面模块的安卓app体积或许在50M，进行裁剪的话，或许可以瘦身到30M左右。看起来还是很悲剧的，要是用户或者厂商使用QtLib的话，多好啊~
=============================
6.官方支持。目前Qt开发团队多少人？但目前他们要支持多少平台。 如果没有一个比较大的商业级别软件在用QfA,官方能做的就是让这个软件在Android平台能编译，运行，解决一些明显的bug。
=============================
新东家 Digia 是个商业公司，不做赔本买卖，亏了就变成开源的~~~
7. Qt做mobile最好的机会就是被大款看上。她也曾经被看上过(Nokia 和 Intel)。 但是被 Elop 害死了。
=============================
这个我没异义，Elop还我诺基亚！！！！
写在最后，个人感觉，其实在国外（欧美）的话，C++相对会比国内使用得多点，国内早已是Java的半壁江山了，c++能否再次爆发呢？看来是不太可行的，另一个Qt仅仅只是以C++为主要编程语言的框架，使用其他编程语言也是可以实现核心的以及大部分机制，另外一方面安卓不光使用java开发，诸如c/c++、c#，Python、ruby等等，各个语言都来凑热闹，当然少不了Qt啦。
最后的最后，还缺什么没说到的，或者说错的，欢迎交流。