Android: Qt vs Java. Что лучше использовать?

Имею небольшой опыт разработки приложений под Android на Java. Сейчас поглядывая в сторону Qt, особенно ввиду выхода Qt 5.2.0. Так вот, что вы можете сказать по поводу Qt под Android (IOS) по сравнению с Java? Имеется ли смысл его использовать или хотя бы попробовать, или он по всем статьям проигрывает Java?

Заранее спасибо!
  • Вопрос задан
  • 34704 просмотра
Решения вопроса 2
@dplsoft
Посмею оспорить ход рассуждений lorus ( Android: Qt vs Java. Что лучше использовать? ).
Итог у нас почти один, но как в математике - когда ход рассуждений ошибочен - даже если ответ верен - то задача не решена. Возможно во много субъективно, но выскажусь, на правах личного мнения человека, который любит и писал и на Qt, и на Android с его "родным" Java тоже.
На Qt для Android не писал, потому что на момент начала последнего проекта технология была сырая.

И так: Не агитка за Qt но несколько слов в защиту Qt.

Забегая вперед скажу: топикстартеру - если есть небольшой опыт разработки под Андроид, вы не работали ранее с Qt, и вам не важна переносимость исходного кода между всем и вся - продолжайте осваивать Android SDK ( Java ) .
По крайней мере, сейчас.
Хорошее знание хотя бы одного инструмента, лучше чем посредственное знание двух. ;)
C Qt под Андроид потом разберетесь. Да и "пообкатаннее" оно будет.


1. Qt - это всё-таки C++. Разрабатывать на нём существенно сложнее, чем на Java. То есть дольше и с большим количеством ошибок.

Надо отличать "просто С++" и С++\Qt. В первую очередь, Qt - это фактически диалект языка С++. Например в объявлении Qt-класса появляются дополнительные секции signal и slots, а в процессе сборки существует фаза мета-компиляции, которая делает C++ код под вашу платформу. Не удивлюсь, если для андроида генерируется сместь Java и C++ кода которая потом скармливается Android NDK.

Во вторых, Qt - это _самодостаточный_ фреймворк. Никаких STL или "чего-что-ещё что представляют себе в комплекте с C++" типичные сторонние разработчики.
Многих проблем, которые приводят к сложности разработки "на простом C++" в "С++\Qt" просто нет "by design".

Например в Qt заложен замечательный механизм предотвращения от выхватывания "null-poiunter" - "сигнал-слоты". Это в разы упрощает и делает надежнее работу как с GUI, так и с например, объектами, работающими в разных потоках. В Qt это все сделать разы проще, чем городить аналогичные стандартные механизмы на Java. Я не говорю в итоге оно будет эффективнее - тут надо выяснять и можно поспорить - но вот то, что в Qt многие вопросы работы с потоками и межпоточным взаимодействием продуманы лучше а механизмы удобнее - на мой вгляд это факт.
(Хотя вот такого классного механизма аки runnable, в Qt нет. Но ждем 11-го стандарта С++.)

В третьих - "С++\Qt" - это хорошо продуманный фреймворк едва-ли не с лучшим дизайном классов, продуманными методлами, единым стилем решения проблем.

Как человек писавший на Qt 4.0-4.6 и сейчас закончивший первывый коммерческий проект для Android - могу выставить в сторону Java много минусов (в сравнении с Qt4/Qt5.) Просто потому, что Java - как в первую очередь коммерческая технология, был вынужден набирать нелогичности ради совместимости с предыдущими версиями - едва-ли не из первых версий Java. Посомтрите вопросы к сертификации - много вопросов, которые когда начинаешь разбирать "почему так" - уходят корнями в далекое темное прошлое развития Java. И в итоге - современная Java - это часто нелогичное, лоскутное одеяло, где в разных классах для решения одной и той-же задачи применяется если не разный подход и стиль, то как минимум разные имена методов. Ну вот зачем это?)))

Да Java детально описан, и в технически прогнозируем - но его надо зубрить, тупо зубрить все исключения и проблемы наследования логики первых версий, и зубрить где используется put(), а где add()....
... а Qt-можно _понять_ и не зубрить, понять и только изредка заглядывать в документацию. И в итоге писать на нем - легче.

К слову: дизайн классов гуглековских классов - хотя и очень-очень-оченьсвоеобразен и местами диковенен, но он, имхо, достаточно "строен" и в общей совокупности, не страдает такой уж сильной лоскутностью логики, какая имеется в стандартных классах Java. С какого-то момента ты понимаешь "как думали в гугле" и все становится несколько проще.

Ещё к слову про миф "на Java писать проще чем на C++"(если сравнивается Java под DalvikVM и C++\Qt5):
Не забывайте - DalvikVM - это вам не JavaVM.
В DalvikVM вы легко отхватите "null-pointer-exception" если вы вдруг наивно думаете, что коли у вас есть в локальной переменной ссылка на фрагмент, активити или вью - то машина не уничтожит объект "когда ей вздумается", а у вас ваша переменная не об-null-ится.

На понимание того, какие привычки десктопного написания и дизайна приложений нельзя переносить во фреймворки Android SDK и на перестройку собственного мышления - у вас уйдет несколько месяцев. А вы _начнете_ это понимать и отхватывать такие проблемы - как только начнете писать что-то бОольшее, чем набор разрозненных активити да пары фрагментов из учебных курсов.
И в итоге - первый ваш серьезный проект на Андроиде - может влететь вам в хорошие переработки.
Например, в том числе и потому что нет в Android SDK v17 жизненного цикла для класса Application. Нет механизмов для созранения состояния singleton-окружения и тд.и тп.

А когда вы пишете на Qt - у вас гарантирована поддержка единых механизмов для всех платформ.
Вам не надо перекраивать мозг, выработанные решения и отлаженные и проверенные паттерны.
В итоге - писать на Qt - может статься и будет быстрее. В ряде случаев.
Но из Qt - может быть сложно поиметь доступ к сугубо-андроидным сервисам типа поставщика данных.

В общем я к чему. нет тут однозначного ответа что лучше а что хуже.
Каждый инструмент достаточно мощный и у него много плюсов, минусов, и особенностей.

2. Инструментарий разработки для C++ однозначно хуже такового для Java в силу, опять-таки, особенностей языка.

Простите, но тоже малообоснованное утверждение. См пункт 1.

Кроме того, отмечу:
Qt-шный инструментарий позволяет вам получать одинаковое поведение на всех поддерживаемых платформах. Включая поведение GUI, Форм и одинаковую для всех систем архитектуру приложения. В идеале - с Qt - вы можете писать под Андроид так, как будто вы пишете под десктоп - не меняя архитектуру и структуру приложения.

А когда вы пишете под Android на Java - вы всегда пишете кусок кода работающий в колнтексте DalvikVM и должны жить по предусмотренным данной машиной паттернам и сценариям, причем многие аспекты того "как это работает" - явно мало где прописаны. И если вдруг вы отсутпаете от стандартных шаблонов фреймворка Dalvik-машины - вы рискуете отгрести непонятные, трудно отловимые косяки, причем _вне_ вашего контроля, которые вы не можете корректно перехватить и обработать. Кто не знает - попробуйте уничтожить ViewGroup, id которого вы использовали как контейнер для размещения внутри него фрагмента. Как только вы делаете FragmentTransaction.commit() - вы ставите машине задачу, которую она будет выполнять "когда-то позже", вне вашего контроля, и не соизволит позволить вам корректно обработать исключение. Вплоть до возникновения ситуации, когда фрагмент пытается быть добавленным в Activity который уже отработал стандартные процедуры по Activity.finush(). Ладно бы оно выкинуло код ошибки куда, и тихо проигнорило - но это же Java - она выкинет исключение. А обернуть это дело в try...catch - вы не сможете - это не ваш кусок кода. Максимум что вы сможете - это "поймать перед смертью" Thread.UncaughtExceptionHandler. И все.
(если я не прав - поправляйте меня, я же тоже не инженер гугля)

3. Java - родная платформа для Android. Отсюда потенциальные проблемы с совместимостью у Qt.

Вот зачем вы занимаетесь запугиванием?
Android NDK (для разработки на С++) такой же родной как как и Android SDK (для разработки на Java).

И с совместимостью у Qt с платформой Android проблем не больше, чем у любого другого приложения, которое использует вставки C++ кода и разработано с использованием стандартного Android NDK.

--------------------------------------------
Резюмируя: автору надо просто взвесить что зачем и как он собирается использовать.
Если автору нужно одинаковое поведение на различных платформах - включая огрызочные поделия, Linux, разные Windows RT недопланшеты - то выбор ознозначен - курите Qt. Это возхитительнейший, ясный, хорошо продуманный и максимально логичный фреймворк, который не побоялись пересоздать с нуля ради устранения накопленных сложностей (вспоминайте переход с Qt3 на Qt4) Лично я приходил в восторг, когда работал с ним (2005-2009 гг)

Но - в части Андроидного приклада : подозреваю, могут быть "технические риски" с использованием каких-либо особых "мобильных кусков" типа "работа со звонками, "работа с контактами", "работа с почтой" или "поставщиками контента", и пр.
Я отошел от мира Qt когда Qt был 4.8 и я не искал там классы которые этим занимаются. Думаю что-то потомки троллей должны были создать в 5.2, но лучше проверить.
В крайнем случае - может потребоваться стыковка с джава-объектами, и тут вам потребуется изучать Android NDK, и возможно даже писать немного оберточного кода на Java.

Если же вам _нужна_ обязательная работа с описанными выше функциями, а на переносимость исполняемого кода - наплевать, или же у вас _уже_ есть опыт разработки с Android SDK - то конечно писать лучше на Java.

Но в этом случае бутьте готовы к тому, что это не JavaVM, и сохранности ссылок _для_ряда_классов_ вам никто не обещает, а т.к. Java не предполагает наличия деструктора - вы _будете_ иметь определенные архитектурные сложности при построении сложных приложений.
Например то, что в десктоп-приложении вы решили бы "простым" "синглтон-объектом" с простой функциональностью типа записал-прочитал из файла - тут вам _придется_ решать путем построения "поставщика контента" и т.п. - что значительно повышает "порог входа" для тех кто погруждается в разработку для Android.

Но - надо отдать должное инженерам гугля - у них _были_ весомые основания поступать итак, и они максимально вас обезопасили от попадания в многие проблемы - если, конечно, вы используете фреймворк именно так, как это предполагается. И сделали многие механизмы достаточно элегантными, и приятными в использовании. Дизайн гуглековских классов мне в большей части нравится. В общем не забывайте понимать почему в примерах делается именно так как делается, а не иначе.
Ответ написан
Учтите сложность разработки:
1. Qt - это всё-таки C++. Разрабатывать на нём существенно сложнее, чем на Java. То есть дольше и с большим количеством ошибок.
2. Инструментарий разработки для C++ однозначно хуже такового для Java в силу, опять-таки, особенностей языка.
3. Java - родная платформа для Android. Отсюда потенциальные проблемы с совместимостью у Qt.

Так что это субъективный выбор, на мой взгляд. Если вы опытный С++ разработчик, то вам, наверное, будет удобнее использовать Qt. В противном случае - не вижу преимуществ перед Java (мы ведь говорим о разработке под Android - и только).

Если же вы не работаете с C++ и Qt, но они вам интересны, то имеет смысл осваивать их безотносительно к Android.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
нативная технология всегда лучше. Хотя попробовать (именно попробовать) стоит.
Ответ написан
@svd71_1
в чем преимущестал java? - мультиплатворменность.
что генерит qt? - платформозависимый код.

к чему это я? про различные процессоры, на которых андроид запускают.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Barbatum Барнаул
от 25 000 до 80 000 руб.
Dialog Москва
от 180 000 до 240 000 руб.
ManyChat Москва
от 180 000 до 300 000 руб.
26 мая 2019, в 11:23
20000 руб./за проект
26 мая 2019, в 04:47
3000 руб./за проект
26 мая 2019, в 01:44
5000 руб./за проект