F1oyd2 авг 2013 в 08:33

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

4 мин

44K

Android *

Перевод

+18

Комментарии 48

kAIST 2 авг 2013 в 08:36

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

F1oyd 2 авг 2013 в 08:38

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

ElleSolomina 2 авг 2013 в 11:13

del

mekegi 2 авг 2013 в 08:43

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

Indexator 2 авг 2013 в 08:51

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

F1oyd 2 авг 2013 в 08:53

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

NoEscape 2 авг 2013 в 09:18

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

gildor 2 авг 2013 в 09: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 и т; п;) этот момент далеко не так важен, как пару лет назад и большинство возможных проблем обратной совместимости легко решается.

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

F1oyd 2 авг 2013 в 10:03

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

gildor 2 авг 2013 в 10:34

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

silentnuke 4 авг 2013 в 10:02

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

VolCh 4 авг 2013 в 17:32

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

Divers 2 авг 2013 в 11:14

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

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

gildor 2 авг 2013 в 12:37

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

Jihar 2 авг 2013 в 17:10

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

gildor 5 авг 2013 в 06:11

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

Jihar 5 авг 2013 в 08:12

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

Jihar 2 авг 2013 в 17:10

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

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

MrShoor 2 авг 2013 в 23:56

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

Jihar 5 авг 2013 в 09:00

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

VolCh 2 авг 2013 в 23:35

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

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

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

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

gildor 4 авг 2013 в 16:14

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

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

VolCh 4 авг 2013 в 17:28

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

gildor 5 авг 2013 в 07:07

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

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

amarao 2 авг 2013 в 10:00

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

rozhik 2 авг 2013 в 11:01

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

amarao 2 авг 2013 в 11:39

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

SerDIDG 3 авг 2013 в 02:37

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

F1oyd 2 авг 2013 в 10:03

…

gildor 2 авг 2013 в 10:51

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

MuLLtiQ 2 авг 2013 в 11:07

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

kyberorg 2 авг 2013 в 13:53

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

StopDesign 3 авг 2013 в 01:17

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

VolCh 3 авг 2013 в 11:05

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

pushist1y 2 авг 2013 в 11:10

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

avolkov 2 авг 2013 в 11:21

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

zagayevskiy 2 авг 2013 в 11:33

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