F1oyd Aug 2 2013 at 12:33

Фрагментация Android

4 min

41K

Development for Android*

Translation

+18

Comments 48

kAIST Aug 2 2013 at 12:36

Про 4.3 в голосовании забыли

F1oyd Aug 2 2013 at 12:38

Спасибо добавил

ElleSolomina Aug 2 2013 at 15:13

del

mekegi Aug 2 2013 at 12:43

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

+28

Indexator Aug 2 2013 at 12:51

А за что вы человека минусуете? У меня вот несколько устройств с разными версиями и теперь я не знаю как проголосовать…

F1oyd Aug 2 2013 at 12:53

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

NoEscape Aug 2 2013 at 13:18

btw на секунду вылез баг хабра (после обновления страницы исчез)
см 2й вариант ответа

gildor Aug 2 2013 at 13:54

Графики хорошие, но не согласен с большинством выводов.
Это не такие большие проблемы для разработчиков (говорю как разработчик), особенно это касается физических размеров экрана и уж тем более фрагментация брендов. Просто разработка под Android подразумевает другой подход, чем под iOS, где в порядке вещей указывать размеры в пикселях или использовать не тянущиеся фоны страниц, которые поехали на iPhone 5 после изменений пропорций экрана. Просто при разработке под Android изначально лейауты делаются тянущимися, что не сильно увеличивает сложность, зато представляет пользоваться приложением без проблем на огромном числе устройств различных форм-факторов.
В Android никто не пытается до пикселя высчитать размеры например ActionBar, или делать лейауты под каждый размер экрана.
Даже не уверен что следует использовать тут термин «фрагментация», т.к. это изначальное свойство системы и ее преимущество.
Кстати очень странно сравнивать физические размеры экрана, намного важнее их разрешение и плотность.

Не понятно откуда взялся странный тезис про проблему с кастомными оболчками: «Первая, бренды имеют тенденцию производить собственные системные UI (например, Touchwhizz для Samsung и HTC Sense), которые могут поменять вид многих стандартных элементов».
Максимум на что может повлиять измененный UI это на отображение уведомлений (и то это касается только Android 2.3), но в самом приложение подобные элементы напрямую не используются, а на Android > 4.0 это совсем не проблема, т.к. всегда есть стандартная тема Holo, вне зависимости от производителя и оболочки.

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

Единственный важный момент может заключаться в фрагментации версии Android, но с учетом множества библиотек (включая Android Support Library, holoeverywhere и т; п;) этот момент далеко не так важен, как пару лет назад и большинство возможных проблем обратной совместимости легко решается.

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

+17

F1oyd Aug 2 2013 at 14:03

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

gildor Aug 2 2013 at 14:34

А что вы подразумеваете под «понять какое API использовать для своего проекта»?
Всегда используется последняя версия API, просто оставляя обратную совместимость, пусть даже с урезанным функционалом. Например сейчас Android 2.1 можно уже не поддерживать, там всего 1.5% пользователей и он не поддерижвает новый API карт и in-app billing v3, но если вы не используете ни то, ни другое, то оставить для него обратную совместимость не проблема.

-2

silentnuke Aug 4 2013 at 14:02

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

VolCh Aug 4 2013 at 21:32

Она международная и общая. Могу предположить, что опрос на хабре нацелен на оценку фрагментированности андроидов среди русскоговорящей и (даже без «или») айтишной аудитории. Может анализатор реестра РКН например :)

-1

Divers Aug 2 2013 at 15:14

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

Кстати, скажите, а под IOS есть возможность писать «растягивающиеся» интерфейсы? Если есть, то почему каждые пару лет случается тупняк с приложениями на половина экрана и черными полосами?

gildor Aug 2 2013 at 16:37

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

-1

Jihar Aug 2 2013 at 21:10

То что вы перечислили есть.

gildor Aug 5 2013 at 10:11

В iOS есть 9-patch из коробки?

Jihar Aug 5 2013 at 12:12

Да. В iOS7 добавили еще автоматическое определение областей.

Jihar Aug 2 2013 at 21:10

Вы не делали игры под ПК, вот там фрагментация доставляет дикую головную боль. Уверен что и разработка 3Д под Андроид тоже то еще удовольствие, хотя бы тем небольшим примером, что каждый производитель GPU поддерживает какой-то свой формат сжатых текстур.

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

MrShoor Aug 3 2013 at 03:56

Не могу с вами согласиться. Головная боль от производителей GPU не больше, чем от фрагментации ОС. Я бы даже сказал что производители GPU гораздо жестче придерживаются спецификации API, нежели производители ОС. Здесь основные проблемы — интелы, потому что много чего не поддерживают, а то что поддерживают — делают это так медленно, что по неволе думаешь «лучше бы не поддерживали». ATI раньше часто имели проблемы с драйверами, в особенности для новых видеокарт, но на сегодняшний день этой проблемы уже практически нет. И наконец Matrox-ы — вот эти звери брыкаются очень сильно, но для разработчика игр данной картой можно пренебречь.

Jihar Aug 5 2013 at 13:00

Рад что ситуация изменилась. Я застал еще времена, когда в OpenGL расширения для шейдеров были разные у Ati и Nvidia, плюс разные возможности. ARB расширения еще не было, но и его появление не всегда спасало. С выходом OpenGL 2 стало лучше конечно. Это просто пример того, как собственные спецификации производителей усложняют жизнь разработчикам Для Андроида тут пример — свои форматы сжатых текстур у разных производителей.

VolCh Aug 3 2013 at 03:35

Просто при разработке под Android изначально лейауты делаются тянущимися

Тянущийся лэйаут это примитивная адаптация под разные размеры. Хочется видеть действительно адаптивные дизайны. Скажем на 3" экране видеть несколько табов с настройками, а на 10" — все на одном экране.

Кстати очень странно сравнивать физические размеры экрана, намного важнее их разрешение и плотность.

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

gildor Aug 4 2013 at 20:14

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

Физические размеры контролов может контролировать производитель устройства просто меняя такой софтварный параметр как размеры экрана в dpi, которые и следует использовать в своем коде. А еще производитель устройства может указать sp, т.е. относительный размер шрифта.
Соответсвено производитель например тв приставки может установить такие размеры в конфиге системы, что бы контролы и весь интерфейс был крупнее. Поэтому это не проблема, если приложение сделано нормально, без привязки к пикселам,

VolCh Aug 4 2013 at 21:28

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

gildor Aug 5 2013 at 11:07

плотность пикселей на физический дюйм имеет значение, только если она принимает совсем неприличные значения

Не соглашусь, т.к. разница в плотности пикселей только для телефонов в данный момент может отличаться в 3 и более раз. Да и физический размер экрана телефона может отличается в 2 раза.
Задать например размер шрифта в пикселах — прямой путь к нечитабельным шрифтам в том или ином случае.

amarao Aug 2 2013 at 14:00

Требую такую же картинку для «фрагментации» платформы PC. Включая соотношения сторон и разрешения мониторов.

rozhik Aug 2 2013 at 15:01

Она всётаки не дотянет до картинки фрагментации пользователей. Включая уровень intelекта и размер бюста.

amarao Aug 2 2013 at 15:39

Мне кажется, что вариация размера бюста меньшая, чем разрешений. По крайней мере я с трудом себе представляю эквивалентное соотношению 640(x480) к 5120 x 1440 (соотношение 1:8, для бюста это экивалент (при минимуме в 40см) 3.2 метра).

SerDIDG Aug 3 2013 at 06:37

Можно глянь статистику Steam, но думаю будет ожидаемый перевес в сторону «играющих», и явно офисные машинки в неё не входят.
store.steampowered.com/hwsurvey?l=russian

F1oyd Aug 2 2013 at 14:03

…

gildor Aug 2 2013 at 14:51

Заметил довольно сильное расхождение в статистике версий Android по сравнению с нашей собственной статистикой и официальной статистикой — developer.android.com/about/dashboards/index.html
Наши данные близки к официальным, и расходятся с теми, что указаны в статье. Очень инетересно узнать откда данные и их структура.

MuLLtiQ Aug 2 2013 at 15:07

Надо было сделать «чекбоксовую» голосовалку — у меня Nexus на 4.3 и LG на 2.3.3.

kyberorg Aug 2 2013 at 17:53

Выше автор написал, что уже не изменишь голосовалку на чекбоксы habrahabr.ru/post/188738/#comment_6555836

StopDesign Aug 3 2013 at 05:17

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

VolCh Aug 3 2013 at 15:05

Не всегда. Некоторые вопросы прямо подразумевают один ответ. Хотя это не тот случай.

pushist1y Aug 2 2013 at 15:10

Мне непонятен график фрагментации версий ОС, точнее, принцип построения белой линии на нём (которая показывает рыночную долю топовой версии ОС). В моём понимании с выходом очередной версии андроида этот график должен резко падать в ноль, после чего постепенно расти вплоть до выхода очередной версии.

avolkov Aug 2 2013 at 15:21

Тоже непонятно.
В оригинале там «The white line shows the market share of the leading API level at any time», то есть доля рынка самой популярной(?) версии API, а не самой свежей.

zagayevskiy Aug 2 2013 at 15:33

Из этого графика в принципе можно понять, что «топовый» тут — по популярности. Например вышел 2.3.3-2.3.7, топовый в то время 2.2 начал падать, потом 2.2 и 2.3.3-2.3.7 сровнялись, затем 2.3.3-2.3.7 растет до какого-то момента, пока у него не начинает отбирать долю рынка 4.х. Как-то так.