Поскольку это моя первая публикация на Хабр, давайте для начала представлюсь: меня зовут Федор, я из Нижнего Новгорода и работаю в компании Orion Innovation техническим менеджером/СТО. На практике это означает, что я отвечаю за направление Android Platform – написание прошивок для разных устройств под Android. Если вы, вдруг, меня знаете, то, скорее всего, по моим выступлениям на Mobius и других конференциях. А данная статья – это обобщение пары моих докладов, сдобренное разными деталями, ссылками и отступлениями от темы, на которые в рамках доклада обычно не хватает времени. С представлением закончили, дальше статья.
Для создания конфликта в каждом повествовании должен быть свой злодей. В моей истории злодей – Фрагментация Android. Как благородный рыцарь, Google сражается с нашим злодеем в ожесточенной схватке с самого начала существования операционной системы. В этой борьбе были победы и поражения, менялись тактики и приемы, но счастливый финал по-прежнему остается вне досягаемости.
Проблема фрагментации
Пожалуй, начать стоит со статистики, знакомой каждому Android-разработчику:
Из этой картинки видно, как много людей все еще используют телефоны со старыми версиями Android – почти все. Значит и разработчикам приходится ориентироваться на эти старые версии в своих приложениях. И порою это означает отказ от многих преимуществ последней версии Android.
Google, конечно же, в курсе данной проблемы. Разработчикам Google самим вряд ли нравится то, что большинство пользователей Android не могут оценить все новинки операционной системы. Но недовольство разработчиков – это лишь верхушка айсберга.
Что хуже, многие телефоны не получают последних обновлений безопасности из-за данной проблемы. А значит, они уязвимы, что позволяет единственному конкуренту Google на мобильном рынке напирать на безопасность личных данных пользователей в своих рекламных кампаниях. Да, у iOS нет проблемы фрагментации – большинство пользователей iPhone регулярно обновляются на последнюю версию. Для Google это, вероятно, обиднее всего.
Обновления операционной системы
Так почему у Apple все отлично, а Google бьется годами и не может победить фрагментацию? Ответ в том, как работают обновления. Все-таки большинство людей не меняют телефон на новый каждый год. И с обновлениями у iOS все намного лучше. Причина тому в самом фундаментальном отличии двух систем: Apple делает и софт, и железо, а Google – только софт. Давайте объясню, как оно работает.
Что нужно сделать Apple, чтобы обновить прошивку на iPhone? Создать обновление и прислать его на устройства. Пользователю лишь остается принять эти обновления и наслаждаться последним iOS на телефоне.
Что если Google хочет обновить Android? Вот картинка от Google, описывающая данный процесс:
Разницу заметить не сложно: процесс обновления прошивки Android-устройства гораздо сложнее, так как в него вовлечено больше сторон. iOS – это закрытая система, которая полностью контролируется одной компанией и сфокусирована на поддержке одной аппаратной платформы – iPhone. С Android все иначе. Это проект с открытым кодом и поддержкой железа от многих производителей. В результате, производители чипов и телефонов так или иначе вовлечены и в процесс обновления прошивки.
Такая открытость – одна из сильных сторон Android. Она создает конкуренцию, способствует инновациям, позволяет Android эволюционировать намного быстрее. Но увы, за это разнообразие приходится платить, и усложнение процесса обновлений – часть этой цены.
Первые попытки
Google понимал, что проблема обновлений в необходимости кооперации между разными компаниями. В первую очередь, они решили наладить эту кооперацию административным путем. Первая попытка случилась в 2011 году и называлась «Android Update Alliance». По сути, это было торжественное обещание основных производителей Android-смартфонов и сотовых операторов выпускать своевременные обновления.
Увы, оказалось, что производителям телефонов интереснее выпускать и продавать новые устройства, а не обновлять старые. В результате Android Update Alliance умер не прожив и года. Мораль данной истории: в большом бизнесе соображения выгоды всегда возобладают над торжественными обещаниями.
Несмотря на смерть «Альянса», Google продолжал оказывать административное давление на производителей смартфонов. В 2016 году эта борьба достигла пика, и Google начал угрожать составить рейтинг по частоте выпуска обновлений производителями. Идея, видимо, была в том, чтобы поддержать «хороших» производителей и пристыдить «плохих». Однако дальше угроз дело не зашло. Возможно потому, что примерно в это время Google начал смотреть на данную проблему под другим углом.
Новая идея заключалась в том, что проблема может быть решена не административным, а инженерным путем. Сделать процесс обновлений и кооперации гораздо проще технически. Первый шаг был сделан в 2017 году. Он назывался Project Treble.
Project Treble
Project Treble вышел вместе с восьмым Android. И, на мой взгляд, он вполне может бороться за звание самого масштабного рефакторинга в истории. Google сумел полностью переписать половину основных компонент операционной системы и поменять архитектуру, сделав её более модульной. Самое удивительное – никто даже не заметил изменений. Все, что работало до этого, продолжило работать как раньше.
В рамках данной статьи мы не будем вдаваться в детали Project Treble. Эта тема заслуживает отдельной публикации или даже книги. Если вам интересно, на YouTube есть запись моего выступления на Mobius по данной теме.
Вкратце: цель Project Treble в том, чтобы убрать производителей чипов из процесса обновлений. И хотя это звучит не так страшно, усилия Google были огромными. В разных интервью сотрудники Google говорили о том, что 300 человек были вовлечены в проект в течение года, чтобы воплотить в жизнь необходимые перемены:
«Vendor» здесь – это производитель чипов (например, Qualcomm). И хотя иллюстрация выше излишне все упрощает, из нее можно понять основную идею: Project Treble поделил код Android на Framework (верхнеуровневые сервисы и приложения) и Vendor Part (нижний уровень драйверов и HALов). Производитель чипов в новой модели отвечал за нижнюю часть, в то время как Google и производители устройств могли сконцентрироваться на верхней.
Две части системы были разделены Vendor интерфейсом. Он был стандартизирован Google, имел четкую систему версий и был обратно совместим. Все это позволяло выпускать обновления для обеих частей почти независимо друг от друга, а значит делало процесс обновлений проще и быстрее.
С технической точки зрения проект внушал только уважение. Но решил ли он свою бизнес задачу? Стали ли обновления проще и быстрее? В качестве ответа на этот вопрос Google опубликовал график скорости обновлений через 2 года после выхода Project Treble:
Из него видно, что обновления на Android 9 шли вдвое быстрее обновлений на Android 8. Во многом это заслуга Treble. Также видно, что Treble начал работать только с 9-ки, хотя и вышел с Android 8. Дело в том, что Treble упростил процесс обновления с 8-ки, но процесс обновления на 8-ку проще не стал. Вот такая же статистика перехода на Android 10:
Как видите, с Android 10 все даже лучше: 400 миллионов пользователей на 10-й версии меньше чем за год. Так что же, проблема решена, злодей повержен? Увы, даже из этих графиков можно понять, что проблема далека от решения. Достаточно лишь посмотреть на них внимательнее:
1. Графики показывают глобальные объемы, но не показывают проценты. И они включают в себя как старые телефоны, получившие Android 10 через обновления, так и новые устройства, изначально выпущенные с Android 10. То есть бОльшие цифры могут отражать большое количество новых телефонов. И это на самом деле так – сегодня в мире 2,5 миллиарда активных пользователей Android. И это число увеличивается на 1,5 миллиона ежедневно.
2. Рост на всех графиках начинается где-то спустя 100 дней после релиза новой версии Android. И даже спустя год, рост не замедляется. Это означает, что большинство людей еще не получили обновление прошивки.
3. iOS на километр впереди: если построить подобный график для последней версии iOS, заменить общие объемы на проценты, то мы увидим, что скорость обновления iOS раз в 10 выше.
В целом, можно сказать, что Project Treble сделал обновления лучше, но не решил проблему полностью. Но это был явно шаг в верном направлении, и Google решил шагать дальше. В 2019 вышел Android 10, а вместе с ним – Project Mainline.
Project Mainline
Суть Project Treble была в разбивке монолитной системы на несколько частей. Это позволило разделить код Android на области ответственности между производителями чипов и производителями устройств. Project Mainline стал продолжением и углублением данного подхода – модульность 2.0. Если Treble делил систему на две части, Mainline выделил уже с десяток модулей. Новая архитектура выглядела примерно так:
Теперь в Android появилось новое понятие – «модульный системный компонент» или просто «модуль». Им может стать любой компонент системы: приложение, сервис, библиотека. Главная изюминка модулей в том, что Google может обновлять их напрямую через Google Play. Ни производители чипов, ни вендоры устройств не участвуют в этом процессе – Google присылает обновления пользователям напрямую.
Какие же компоненты системы Google решил обновлять таким образом? В Android 10 все модули поделили на 3 категории по той роли, которую они должны были играть. Вот еще одна картинка от Google, описывающая эти три корзины:
Security – самая понятная категория. Любую уязвимость, связанную с безопасностью, Google хочет закрыть ASAP. Поэтому они выбрали несколько мест в системе, наиболее тесно связанных с безопасностью, и превратили их в модули.
Privacy – категория, которая не так сильно отличается от Security по смыслу. Она должна помочь с защитой пользовательских данных и приватностью, а это в некотором роде часть Security. Возможно, свою роль тут сыграли уже соображения маркетинга и желание подчеркнуть слово Privacy в пресс-релизах. По сути, можно сказать, что Privacy модули это те же Security, но напрямую связанные с permissions.
Consistency – самая интересная категория, на мой взгляд. Во-первых, не сразу понятно, как именно «стабильность, совместимость и последовательность» связаны с модульными обновлениями. Это безусловно достойные цели, но скорость обновлений системы не всегда с этим связана. Во-вторых, большинство модулей попадают именно в эту, наименее очевидную категорию. Включая самый большой и интересный модуль – Android Runtime.
Что такое Consistency
Android Runtime заслуживает отдельного упоминания. Для начала, в Android 11 он обновляется только вместе со всей системой (по слухам, в Android 12 Runtime может стать независимо обновляемым). То есть это как бы независимый модуль, но при этом он не получает независимых обновлений. Логичный вопрос: зачем же он тогда нужен? Однозначного ответа у меня нет, но я могу предложить несколько версий.
Первая версия: Google, возможно, хотел бы обновлять Runtime отдельно, но он несет в себе львиную долю самого «ядерного» функционала Android. Этот модуль включает ART – виртуальную машину, внутри которой существует любое Android-приложение. И это лишь один из примеров того, что внутри Runtime модуля много других вещей, сравнимых по важности. Можно сказать, что без Runtime модуля ничего в Android работать не будет. И, видимо, отделить Runtime от «немодульного» Android оказалось пока невозможно.
Вторая версия: перемещение некоторого функционала в модуль может быть полезным, даже если этот модуль невозможно обновлять отдельно. И польза эта как раз в Developer Consistency. Если производители устройств не могут менять код внутри модуля, это означает, что на всех устройствах он будет работать одинаково. Для разработчиков приложений это хорошая новость. Большинство новых модулей в Android 11, следуют этой логике, добавляя новые API через модули, чтобы они работали одинаково на всех устройствах и прошивках.
На данный вопрос можно посмотреть и под иным углом. Модули могут быть использованы Google как довольно сильный инструмент контроля производителей телефонов. Все-таки у новой модельной архитектуры можно выделить два ключевых последствия:
-
Google может обновлять модули напрямую, не спрашивая согласия вендоров;
-
вендоры не имеют права трогать код внутри модулей.
И если первое следствие наверняка является основной причиной появления Project Mainline, второе тоже не стоит сбрасывать со счетов. И Runtime, вполне вероятно, существует именно для достижения второй цели. Помещая «ядерный» функционал в отдельный модуль, Google гарантирует единообразие работы этого функционала на всех телефонах. На мой взгляд, именно так и стоит перевести «consistency» – единообразие.
Как косвенное подтверждение такого мотива Google, можно привести следующий факт: хотя Mainline и позволяет Google быстро обновлять модули, общие обновления системы быстрее от этого почти не стали, так как они все еще приходят от вендоров телефонов.
То есть Project Mainline не был задуман для того, чтобы сделать обновления системы быстрее. И он не поможет уменьшить фрагментацию. Его задача – снизить негативные эффекты фрагментации, вынеся часть системы «за скобки». И пусть обновления не станут при этом быстрее, но это будет уже не так критично.
В этом суть Project Mainline – это технический вариант решения текущей проблемы. Google наконец-то понял, что не сможет заставить производителей телефонов обновлять их чаще и поддерживать дольше. Вместо этого Google просто лишил их контроля над самыми важными и критичными кусками Android и теперь будет обновлять их напрямую. И есть у меня подозрение, что конечные пользователи от этого только выиграют.
Выводы
На этом моя статья подходит к концу, но борьба Google с фрагментацией, вероятно, продолжится. Уже сейчас можно сказать, что Android претерпел на этом пути кардинальные изменения, которые не ограничиваются одними лишь обновлениями. Google перекроил всю архитектуру системы, сделал ее модульной, установив границы и зоны ответственности. Да, в результате обновления стали быстрее, а фрагментация менее критичной, но в целом это выглядит как лишь один из эффектов лучшей архитектуры.
На сегодняшний день Android так и не удалось полностью справиться с проблемой фрагментации и сравняться со своим основным конкурентом. Это связно с тем, что Android, в отличие от iOS, – продукт совместной работы многих компаний, и за это придется платить. А значит борьба продолжится, и мы можем ждать дальнейших решений Google по оптимизации архитектуры своей ОС.
Несмотря на это, на решение проблемы было брошено много усилий, и можно ожидать, что проблема фрагментации будет становиться все менее критичной. Project Mainline должен с этим помочь. В конце концов, так ли важно будет пользователям, какая версия Android крутится на их телефонах, если их личные данные в безопасности и все приложения работают должным образом?
Комментариев нет:
Отправить комментарий