qt on android 有前途吗？

__Shakespeare 2015-03-04 09:57:07

下面是转自百度上的一些回答，大家有什么看法？

（转）您好，很高兴为您解答：　　不看好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害死了。

...全文

1154 21 打赏收藏转发到动态举报

写回复

用AI写文章

21 条回复

切换为时间正序

请发表友善的回复…

发表回复

yyxmm 2015-03-27

打赏
举报

前途不好说，现在问题太多，看Qt能不能解决

ronal7do 2015-03-24

打赏
举报

我起初用Qt的理由就是公司要做跨平台，后面越用觉得Qt也挺好的，尤其自带的帮助很有用。

彩阳 2015-03-24

打赏
举报

这个问题应该换成：放弃学习其它平台开发，只学习Android有没有前途呢？

天天程序员 2015-03-23

打赏
举报

没前途。Android本来就是在linux上架设了Java虚拟机，效率已经不算高了。上面再封装一层Qt的GUI，图啥呢？有那个精神头还不如仔细的弄个html5，套上APP使用。

xiaodong60606 2015-03-23

打赏
举报

估计没前途，直接做android多好啊。

xianqingzh 2015-03-23

打赏
举报

你管有前途没前途，做得high就好。

qyvlik 2015-03-20

打赏
举报

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啦。最后的最后，还缺什么没说到的，或者说错的，欢迎交流。

yxred 2015-03-06