[Android]Выбор девайса для разработки

Почему не использовать эмулятор из SDK? Думаю работать будет точно так же, как на телефоне.

Эмулятор хорош, когда надо баги отлавливать.
В других ситуациях - он бесполезен. Например, эргономику на нем тестировать невозможно. Да и баги не все в эмуляторе выползают (во всяком случае в нокиевском).

Если эргономику тестировать, то логично брать самый популярный/распространенный.

Эмулятор андроида тормозит примерно так же, как гипотетический крайзис, запущенный на калькуляторе

Тестировать на любом, система одна, драйверов под линуксом не требует.

Nexus One/S же. Нормалное железо, современный андроид.

система одна

Однако косяки разные на разных телефонах могут быть...

Поговаривают, что эмулятор андроида такой, что лучше бы его вообще не было.

Он разве что тормозный, а так вроде норм.

Ну не знаю, в глаза не видел, у меня эмулятор windows phone 7 :3

Можно отлаживать не в эмуляторе, а в виртуальной машине. Намного быстрее. На хабре вроде подробное описание было.

>Пока что просто попробовать, как Qt чувствует себя на этой платформе и можно ли «по быстрому» портировать туда свои приложения.
qt на андроиде - зло

Собственно возник вопрос - на каком девайсе лучше тестировать свои разарботки? Естественно, не хочеться вкладываться в дорогую игрушку, которая мне совсем не нужна. Так что цена имеет значение, но все же не стоит на первом месте.

девайс берите Nexus One с ебея - дёшево и сердито (в смысле тормознуто)

Сильно ли отличаются между собой девайсы с одинаковой версией Android?

нет, но бывают тонкости

Насколько сильно все ломают при переходе от одной версии к другой?

формально заявляется полная обратная совместимость, в реальности дела обстоят чуть хуже, но для простых приложений совершенно некритично

> qt на андроиде - зло

Почему это?

можно, но это будет уже другой андроид, с qt, собранным по другаю платформу и своими багами

>qt на андроиде - зло
Объясни, а то я в изумлении полном.

в последнее время Qt на андроиде все лучше и лучше, уже можно всерьез думать о софте на Qt для него... своем софте

Сразу стоит оговориться, что следует приобретать телефон, который поддерживает Gingerbread+. Лично я отоварился Nexus S - из коробки поддержка перепрошивки и получение прав суперпользователя (с оговоркой потери поддержки), идеальный вариант для разработки Gingerbread. Для Honeycomb/Ice Cream Sandwich затрудняють ответить, думаю стоит посмотреть в сторону Motorola Xoom или подождать выхода Archos на OMAP4.

Ещё советую заглянуть на страничку поддерживаемых устройств Cyanogenmod: http://www.cyanogenmod.com/devices

P.S. Тестировать Андроид на эмуляторе - сразу забудьте.

например потому что это 10+ мегабайт без возможности переноса на карту.
ну или скажем, отсутствие нативных андроидовских контролов, если я правильно помню.

Всем спаибо за ответы.
Решил все-таки присмотреться к Samsung Galaxy S.

Кутя на андроиде - бессмыслица.
Тестировать на эмуляторе можно, но очень быстро достает.
Лучшие для разработки - телефоны самого гугла, как самые открытые.

>Кутя на андроиде - бессмыслица.
Буду благодарен за обоснование этого выражения.

trex6, в ноги покланишься в качестве благодарности?

Естественно, не хочеться вкладываться в дорогую игрушку, которая мне совсем не нужна.

Samsung Galaxy S.

Ну тут что-то не сходится. Тогда прикупи ещё МТС 916. Будет хоть с чем сравнить :)

И ещё. Поищи китайцев. Недорого, а для тестов на Г железе самое то.

nexus 1 и еще какойто специально для этого и создавались

> на каком девайсе лучше тестировать свои разарботки?

на как можно большем количестве разных девайсов, с разными версиями прошивок. почти каждая комбинация девайс+прошивка имеет ряд багов, которые дают о себе знать.

можно этого и не делать, но тогда будет куча недовольных юзеров, у которых будет криво выглядеть гуй, вылетать программа, и т.п.

впрочем, это будет в любом случае.

Сильно ли отличаются между собой девайсы с одинаковой версией Android?

одинаковая версия андроида бывает только на одинаковых девайсах.

Насколько сильно все ломают при переходе от одной версии к другой?

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

можно провести аналогию с дистрибутивами линуха. каждая комбинация девайс+прошивка - разные дистры, в которых мейнтейнеры напатчили всего что можно, поменяли тему gtk, и т.п, а на гугловских девайсах стоит «ванильная» версия.

p.s. qt на андроиде дохлый номер imho.

Есть развитая, достаточно удобная, поддерживаемая программно-аппаратная платформа, основанная на далвике. С managed языком и пр. плюшками. И, кстати, аппаратно-независимым результатом.

Кутя - это шаг назад. Бинарный код (зачем???), возможность испортить память (язык позволяет), неизвестность с поддержкой и развитием.

И - главное - зачем?? Вы собираетесь что-то жутко критичное к цпу делать?

> Бинарный код (зачем???), возможность испортить память (язык позволяет)

это как раз плюсы, на мой взгляд. бинарный код — скорость, куча уже готового кода (не надо переписывать на жабе), не нужно юзать jni, и т.п. возможность испортить код — это не аргумент. капля в море проблем разработки приложений. и таки возможность лучше невозможности.

С managed языком и пр. плюшками. И, кстати, аппаратно-независимым результатом.

для большинства более-менее крупных проектов это проблема. спортировать сишный проект с ифона или линуха на андроид было бы проще без жавы, чем с ней. аппаратная независимость условна — все игры, плееры, и т.п. требуют armeabi, т.к. написаны с помощью NDK, и это не изменить. жава не годится из-за проблем с производительностью и несовместимостью. и на жабе тоже вполне реально написать код, который на интелевом андроиде не взлетит из-за little endian. и все это - сущая мелочь по сравнению с поддержкой разных размеров экранов, отличия производительности девайсов в десятки раз, и различных багов сотен разных прошивок.

неизвестность с поддержкой и развитием.

а вот это важно. и то что оно к размеру добавит несколько мегабайт.

> бинарный код — скорость
Очень немного ниш на телефонах и таблетках, где это настолько важно. А вот компилировать под разные процы - придется.

куча уже готового кода (не надо переписывать на жабе),

Он не пойдет на телефоне с высокой вероятностью.

не нужно юзать jni,

Конечно, не нужно. Нефиг вообще без острой необходимости использовать С.

и таки возможность лучше невозможности.

Совсем не всегда.

более-менее крупных проектов это проблема.

Большинство проектов для мабил - ОЧЕНЬ некрупные. Автор сразу замахивается на офисный пакет?

сишный проект с ифона

Двоечник. На ифоне обжектив, с совсем другими интерфейсами.

было бы проще без жавы,

Не надо портировать графические интерфейсы. Категорически. Только делать заново. А функциональность переносится, и становится короче и безопаснее.

все игры, плееры, и т.п. требуют armeabi, т.к. написаны с помощью NDK

Вранье. Совсем не все.

жава не годится из-за проблем с производительностью и несовместимостью

Бред и заклинания. На телефоне очень мало задач, где эта разница в скорости играет. А совместимость как раз у бинарных приложений хромает. Чуть другой проц - и привет всем вылизанным опциям компилятора.

и на жабе тоже вполне реально написать код, который на интелевом андроиде не взлетит из-за little endian.

На жабе это надо ОЧЕНЬ сильно постараться. В самой жабке ендианнесс жестко забита.

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

Эти проблемы реальны, но никак не относятся к обсуждаемому. И незачем к ним добавлять еще те, которые связаны с неудачным выбором средства разработки.

и то что оно к размеру добавит несколько мегабайт.

Да.

В общем, мой пойнт - существует ОЧЕНЬ УЗКИЙ набор ситуаций, где имеет смысл уходить в сторону нативности. По умолчанию надо использовать дефолтную платформу.

> А вот компилировать под разные процы - придется.

под андроид это делается добавлением 1 строчки в Application.mk

Он не пойдет на телефоне с высокой вероятностью.

идет с минимальными модификациями

Нефиг вообще без острой необходимости использовать С.

переписывать все на жабе - гораздо хуже.

Совсем не всегда.

смотря в каком контексте.

Автор сразу замахивается на офисный пакет?

как раз офисный пакет должен и на жабе без проблем взлететь. зависит от навороченности.

Двоечник. На ифоне обжектив, с совсем другими интерфейсами.

сам двоечник. обжектив двусторонне совместим с сишным ABI, и не требует извратов типа jni. типично, приложения под ифон и макос не пишутся целиком на objc. основная часть на c/c++, гуй и интеграция с системой на objc. и интерфейсить это на порядок проще, чем через jni.

Вранье. Совсем не все.

ок, не все, но большинство

На телефоне очень мало задач, где эта разница в скорости играет.

это утверждение основано на личном опыте? или придумано с потолка?

На жабе это надо ОЧЕНЬ сильно постараться. В самой жабке ендианнесс жестко забита.

ну вот когда на андроеде появится официальная поддержка inteleabi — посмотрим сколько приложений на нем взлетят без изменений.

ОЧЕНЬ УЗКИЙ набор ситуаций, где имеет смысл уходить в сторону нативности

если приложение пишется эксклюзивно под андроед, с нуля, и реализует что-то вроде календаря или будильника - то я согласен.

> под андроид это делается добавлением 1 строчки в Application.mk
Почему-то в свое время RockPlayer имел с этим геморрой.

идет с минимальными модификациями

Все-таки напильник...

переписывать все на жабе - гораздо хуже.

Смотря что. Некоторые вещи, особенно со сложными пользовательскими интерфейсами - все равно переписывать.

как раз офисный пакет должен и на жабе без проблем взлететь

Правда. Что такое «большой проект» для мобильного устройства? Ну кроме навороченных игр.

обжектив двусторонне совместим с сишным ABI

Если проект написан на обжектив целиком - его совсем нетривиально перетащить на голый С. Так что уж лучше сразу на жабку.

приложения под ифон и макос не пишутся целиком на objc

Можно источник? У меня ровно противоположное представление.

это утверждение основано на личном опыте? или придумано с потолка?

Впечатление на основе андроид маркета.

посмотрим сколько приложений на нем взлетят без изменений.

Посмотрим. Не ожидаю неприятностей. И наверняка изменения будут нужны только прикладухам с нативным кодом.

то я согласен.

Вот и славно. Главное, что большинство этих приложений - именно что не сложнее календарика-будильника. И для них нативность - идиотизм.

Кстати, у vplayer тоже до сих пор какие-то шероховатости с нативным кодом, приходится поддерживать «быстрый» и «безопасный» варианты.

> жава не годится из-за проблем с производительностью
ну не java тормозит же, сколько раз обсуждалось

Во-первых, в андроиде совсем не jvm, а частично совместимая dalvik, код под которую хорошо обрабатывается jit.
Во-вторых, после jit компиляции главные источники оверхеда в яве - вызов виртуального метода, вызов метода интерфейса (самый тормозной), обращение к полю класса - становятся почти бесплатными, о чем, кстати, написано в руководстве.

Несовместимость - не проблема явы, это недоработка первых версий окружения андроида.

На чистой яве невозможно написать код, неправильно работающий с порядком байт. Если пишете java + native, то не думать о порядке - ССЗБ.

Большое количество разных устройств: это плохо для разработчиков, но с этим ничего не поделаешь. Для пользователей это лучше, чем 2 актуальные версии айфона.

Согласен только с тем, что андроид слишком ява-ориентированный. Возможно, это изменится. Не так сложно написать костыль - классы-обертки на с++ и посредники на ява для нативного интерфейса.

> Почему-то в свое время RockPlayer имел с этим геморрой.

никогда не слышал о rockplayer, но в моем проекте мне понадобилось добавить ровно 1 строчку в Application.mk, чтобы собирать под 2й проц. без геморроя.

Все-таки напильник...

по-другому не бывает.

Cмотря что. Некоторые вещи, особенно со сложными пользовательскими интерфейсами - все равно переписывать.

угу.. но я бы предпочел переписывать с Си на Си, копируя куски кода которые не нуждаются в переписывании, чем переписывать гуй полностью, как мне это пришлось сделать.

Что такое «большой проект» для мобильного устройства? Ну кроме навороченных игр.

медиа-плееры, музыкальные синтезаторы, программы для работы с графикой. вобщем, практически вся мультимедия. еще веб-браузеры, эмуляторы.. короче, достаточно много.

Если проект написан на обжектив целиком - его совсем нетривиально перетащить на голый С

я это не предлагаю.

Можно источник? У меня ровно противоположное представление.

личный опыт разработки под макос, и общение с другими ифон/макос девелоперами.

Впечатление на основе андроид маркета.

маркет наполнен программами, которые чуть ли не сгенерированы, типа «сонеты шекспира» или «программа которая показывает портрет аллы пугачевой». не имею ничего против того, чтобы эти проги хоть на брейнфаке писали.

И наверняка изменения будут нужны только прикладухам с нативным кодом.

... для которых выпустят апдейт, пересобранный новым NDK с добавлением строчки inteleabi в Application.mk, и исправлением пары мелких косяков.

Главное, что большинство этих приложений - именно что не сложнее календарика-будильника. И для них нативность - идиотизм.

само существование большинства из этих прог - идиотизм.

>> жава не годится из-за проблем с производительностью

ну не java тормозит же, сколько раз обсуждалось

не надо коверкать контекст. я не писал что жава тормозит.

моя реплика о том, что писать на жабе высокопроизводительный код, с оптимизациями под SIMD и т.п. невозможно.

Возможно, это изменится.

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

> чем переписывать гуй полностью, как мне это пришлось сделать.
Гуй для мобильных устройств в большинстве случаев НЕОБХОДИМО переписывать полностью, с учетом принятых на данной платформе конвенций. Ну, кроме сугубо кастомных гуев, которыми не надо злоупотреблять без необходимости (вообще, кроме игрушек

медиа-плееры, музыкальные синтезаторы, программы для работы с графикой

Они все разного уровня бывают. Совсем не всем из них нужна нативность. И если взять долю этих прог на маркете - это слезы.

Кстати, вот интересно было б знать - знаменитый и дорогущий спб шелл 3д на чем написан?

само существование большинства из этих прог - идиотизм.

Это деньги. Это ЧСВ. Да мало ль..

> Гуй для мобильных устройств в большинстве случаев НЕОБХОДИМО переписывать полностью, с учетом принятых на данной платформе конвенций.

это не совсем так. кроме визуального представления и обработки событий, есть еще куча кода, типа сортировки, поиска, генерации строк для отображения в гуе, загрузка/кеширование графики с диска и сети, и многое другое, которое без проблем могло бы быть реюзнуто, если бы не жаба. переписывание всего этого занимает очень много времени. подключить его через jni тоже достаточно проблематично и долго.

Они все разного уровня бывают. Совсем не всем из них нужна нативность. И если взять долю этих прог на маркете - это слезы.

это уже следствие ограниченных возможностей того, что на андроиде можно делать. на жабе нормальный синтюк под андроид не написать в принципе - уложит cpu на лопатки. на сях+асм написать можно, но из-за latency на нем играть не получится. потому и не пишут. с плеерами чуть проще - для них latency не критично. но и с ними куча проблем. чтобы проиграть поток, декодированный сишным кодеком, буфер приходится через jni прокидывать в жабу, которая, в свою очередь, прокидывает его через пайп или сокет в алсу (или что там на нижнем уровне), которая уже нативно поток микширует, регулирует ему громкость, делает неизвестно какую пост-обработку, и играет. штук 5 лишних копирований данных, часть из которых между процессами (надеюсь, хотя бы через shared memory). в итоге, там где можно было уложиться в 3% cpu — тратятся все 10%... потом народ пишет «как такое может быть что mp3+эквалайзер тормозит на 1GHz, когда винамп 15 лет назад не тормозил на 100MHz». а вот так..

знаменитый и дорогущий спб шелл 3д на чем написан?

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

>И - главное - зачем??
Я же уже писал:

«по быстрому» портировать туда свои приложения

написанные для Symbian с использованием пресловутых кутей.

Если бы я нацеливался именно на андроид и толко на него, то, наверное, подучил бы жабку для этого. А сейчас мне хочеться понять, можно ли взять мой страй код и получить еще немножко профита с андроид девайсов.

*страй = старый

> есть еще куча кода, типа сортировки, поиска, генерации строк для отображения в гуе, загрузка/кеширование графики с диска и сети,
Все, что на чистые алгоритмы - в любом случае завязано на конкретные платформенные интерфейсы («диска и сети»). А создание уровней абстракции может вам стоить дороже, чем использование жабки, которая, как указано выше, с использованием жита практически не тормозит (если забыть о памяти, но кого она колышет?)

это уже следствие ограниченных возможностей того, что на андроиде можно делать

Вы не поверите - но андроид не является универсальной _десктопной_ платформой. И достаточно молод. С ним будет то же, что с жабкой - постепенный рост стандартных интерфейсов вширь (в стандартной жабке тоже не сразу адекватная мультимедия появилась). Да, пока что есть темные углы, где приходится использовать jni. Но их будет все меньше. И надо четко знать, ЗАЧЕМ используешь нативный код. И в любом случае - НЕМНОГО минимально необходимого нативного кода в большом проекте намного лучше (=дешевле), с т.зр. цены мейнтенанса, чем целый нативный проект.

штук 5 лишних копирований данных, часть из которых между процессами

Было бы нечестно утверждать, что высокоуровневые платформы бесплатны. Но для этого гугл и вылизывает свою платформу, чтобы тормозило все меньше. Они и жит-то ввели всего пару версий назад. Ну и плюс уже двуядерные телефоны стали реальностью:)

судя по скриншотам

Я тоже пришел к такому выводу. И ничего - они уже почти мульон бабла на нем сделали, народ прецца (АКА пипл хавает).

> написанные для Symbian с использованием пресловутых кутей.
Извините, пропустил это. А какой процент кода - пользовательский интерфейс?

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

> Все, что на чистые алгоритмы - в любом случае завязано на конкретные платформенные интерфейсы («диска и сети»).

ничего подобного. curl и open/read/close работают :)

А создание уровней абстракции может вам стоить дороже, чем использование жабки

с какой стати вдруг использование абстракций жабки стало дешевле прямых syscalls?

с использованием жита практически не тормозит

это «практически» варьируется от «работает так же быстро как на скорую руку налобаный неоптимизированный сишный код» до «не взлетит».

вылизывает свою платформу, чтобы тормозило все меньше

orly? чего ж тогда андроид 2.3 тормозит настолько сильнее чем 1.6?

И ничего - они уже почти мульон бабла на нем сделали, народ прецца (АКА пипл хавает).

ну не все же делают новые оболочки для рабочего стола.

> curl и open/read/close работают :)
Одних open/read/close может оказаться недостаточно.

с какой стати вдруг использование абстракций жабки стало дешевле прямых syscalls?

Я как раз говорю, что сисколлы будут запрятаны за абстракциями, чтобы спрятать особенности платформы.

«работает так же быстро как на скорую руку налобаный неоптимизированный сишный код» до «не взлетит».

На более другом форуме мы устроили пузомерку по обработки матриц. Вылизанный до полного нарушения программных приличий (абстракций) жабский код оказался шустрее средневылизанного сишного. Жит творит чудеса.

orly? чего ж тогда андроид 2.3 тормозит настолько сильнее чем 1.6?

Где почитать??

ну не все же делают новые оболочки для рабочего стола.

Ну вот то, что делают большинство - не требует нативности. Для (очень условно!) 80% приложений на андроид маркете нативность не нужна вовсе. Еще для 15% вполне достаточно критичных реализуемых кусков через жни. И только оставшиеся 5% реально должны делаться целиком нативно (и то - часть из них по историческим причинам). Разумеется, это только личные оценки. Кстати, можете свои привести для этих трех категорий?

> оказался шустрее средневылизанного сишного

видимо, какого-то совершенно кривого.

Где почитать??

лучше один раз увидеть. запустить cm6 или cm7 на каком-нибудь htc hero.

Ну вот то, что делают большинство - не требует нативности

большинство делает оболочки рабочих столов? смелое утверждение.

Кстати, можете свои привести для этих трех категорий?

моя субъективная оценка простая - жава не нужна. я никогда не понимал, и не пойму, зачем нужны эти слои абстракции, и кому они помогают.

единственный плюс жавы, который мне известен — возможность осуществлять поддержку обратной совместимости через динамическую проверку наличия классов/методов (что в андроиде и делается).

но это же можно делать и в objc, а при наличии определенной сноровки — даже в c.

в контексте андроида — жава нужна там, где без нее невозможно обойтись по техническим причинам. на нее все завязано.

> видимо, какого-то совершенно кривого.
Вполне адекватного. Просто жабка сегодня действительно быстра, если не очень думать о памяти.

большинство делает оболочки рабочих столов? смелое утверждение.

Если бы. Калькуляторы, клиенты веб-сервисов и пр.

я никогда не понимал, и не пойму,

Поймете. Не старайтесь казаться глупее, чем есть. Просто подумайте не о технологиях, а о деньгах. Которые первичны. Технологии - вторичны. Тогда все встанет на свои места.

> оно уже изменилось — можно создать работающее приложение под андроид 2.3+, без единой строчки жабы. раньше было нельзя

Технически — можно. Но мой опыт портирования Qt на Андроид говорит обратное, что практически нереально. Native API в GB очень куцый (циклы событий, ввод, фреймбуфер), за малейшим чихом приходится лезть через JNI в стабильный API Java. В HC 3.1/3.2 ситуация практически не изменилась, добавили рендер в текстуры, расширили устройства ввода. Есть InputMethod, но лучше бы его не было. Про работу с оконным менеджером Андроида вообще молчу.

Я полностью согласен с идеей, что если в GUI-приложении доминирует native код, то лучше его полностью написать на C/C++, один раз создав бекенд. Qt очень хорошо подходит для этой цели. А если рассматривать с точки зрения кроссплатформенности, то вообще практически вне конкуренции.

P.S. Даже с учётом того, что сейчас в моей реализации Qt фреймбуффер построен не на Gralloc, а на внутренних буферах, которые гоняются через стабильнй API ANativeWindow в SurfaceFlinger — скорость работы графической подсистемы Qt даёт очень и очень впечатляющие результаты что на Nexus S, что на Motorola Xoom. Сомневаюсь, что на Андроидовском Canvas можно будет приблизиться по скорости к растеризатору Qt.

> Технически — можно. Но мой опыт портирования Qt на Андроид говорит обратное, что практически нереально.

спасибо за информацию, очень интересно. я знал, что все плоховато, но не знал что настолько.

а вы автор порта qt под андроид? можно поинтересоваться, сколько веса к приложению добавляет qt, и поддерживает ли автоматический down/upscale интерфейса под разные dpi? я очень заинтересован в нативном графическом тулките под андроид, чтобы от жабы избавиться. c++ тоже не очень, но лучше чем жаба.

> Поймете. Не старайтесь казаться глупее, чем есть.

дело скорее в личных предпочтениях, чем в глупости/умности. лично я разрабатываю приложение в т.ч. для себя, и писать на жабе меня не радует совсем - ни процесс, ни результат.

Спасибо за интересную инфу. Так я и думал.

Сомневаюсь, что на Андроидовском Canvas можно будет приблизиться по скорости к растеризатору Qt.

Почему? Тем более все можно гонять через графический сопроц.