Какое будущее у андроид

Эпоха Android подходит к концу. Google готов к тестированию новой секретной ОС

Google собирается выпустить бета-версию Fuchsia – ОС, которая может заменить собой Android. Она создается для гигантского числа устройств, среди которых есть смартфоны и планшеты, и над ней Google работает почти пять лет. В случае с Android со дня выхода первой бета-версии и до момента релиза в последнее время проходит около полугода.

Потенциальная замена Android

Интернет-гигант Google собирается запустить тестирование своей секретной ОС Fuchsia, над которой он трудится с как минимум с августа 2016 г. По информации 9to5Google, в ближайшее время она выпустит первую бета-версию системы, доступную для разработчиков.

Данному этапу разработки Fuchsia предшествовало ее внутреннее тестирование силами специалистов самой Google – оно началось в конце 2020 г., и на тот момент было известно, что в случае его успешного завершения будет выпущена предварительная версия для разработчиков.

Видит ли Google в ОС Fuchsia полноценную замену Android, другой своей популярной мобильной платформы, в настоящее время неизвестно. Но эта система изначально разрабатывается для очень широкого спектра устройств, включая системы умного дома и носимую электронику, смартфоны, компьютеры, ноутбуки, бытовую технику, а также системы виртуальной и дополненной реальностей.

Fuchsia, в отличие от Android, базируется на собственном ядре Google, написанном с нуля и получившем название Zircon. Android же, анонс которой состоялся в 2008 г., основана на ядре Linux.

Таинственная операционка Google

Google удается в течение более 4,5 лет скрывать почти все подробности о своем новом детище и контролировать утечки. В результате в сети есть лишь минимум сведений о ней: например, Google разработала для нее графический интерфейс еще в 2017 г. CNews писал, что ее оболочка подозрительно напоминает дизайн Android. Графическая составляющая Fuchsia OS получила кодовое имя Armadillo, и она была создана с помощью кроссплатформенного инструмента разработчиков Google Flutter SDK.

К январю 2019 г. разработчики Fuchsia, среди которых числятся Трэвис Гейселбрехт (Travis Geiselbrecht), один из разработчиков NewOS, Danger и BeOS, и Брайан Свитлэнд (Brian Swetland), участник проекта BeOS, научили ее запускать Android-приложения. Они добились этого за счет интеграции в состав ОС модифицированной версии среды Android Runtime (ART).

Google лишь единожды, в мае 2019 г., поделилась подробностями о Fuchsia, и то лишь о том, поддержка каких именно мобильных устройств поддерживается. Тогда же глава направления Android и Chrome OS Хироши Локхаймер (Hiroshi Lockheimer) сообщил, что Google не рассматривает Fuchsia OS как замену этих двух платформ. С того момента прошло почти два года, и ситуация могла измениться. На возможную конкуренцию с Android указывает и наличие похожей оболочки.

Новая история Fuchsia

С мая 2019 г. и по декабрь 2020 г. Google больше не делилась никакими подробностями о Fuchsia. Лишь в первых числах декабря 2020 г. она подтвердила, что разработка проекта по-прежнему продолжается, несмотря на пандемию коронавируса. Одновременно с этим Google внесла изменения в действовавшую на тот момент модель ее разработки – если раньше к созданию Fuchsia привлекались программисты исключительно из штата Google. то теперь она не против участия и сторонних разработчиков. Другими словами, с декабря 2020 г. проект стал значительно более открытым.

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

Сроков выхода нет

На момент публикации материала степень готовности Fuchsia известна не была. Но если сравнивать с Android, то Google выпускает ее превью-версии для разработчиков в среднем за три месяца до официального анонса. Со дня премьеры, если судить по Android 10 и 11, до момента релиза проходит еще три-четыре месяца.

Сам Android разрабатывался в течение пяти лет до момента появления своей первой стабильной версии 1.0 в сентябре 2008 г. Изначально это была прошивка для цифровых фотокамер – ее создатель Энди Рубин (Andy Rubin) задумал ее в 2003 г. именно такой. Позже ее переделали в ОС для смартфонов без сенсорного экрана, а выход первого Apple iPhone в 2007 г. способствовал ее превращению в платформу, знакомую сейчас миллиардам людей.

Свой пятилетний юбилей Fuchsia отметит в конце лета 2021 г.

Новых ОС может быть две

В феврале 2020 г. CNews писал о регистрации Google торговой марки Pigweed, относящейся к категории операционных систем. Так по-английски называют амарант – однолетнее травянистое растение. В тоге Pigweed стала второй по счету после Fuchsia ОС Google с «цветочным названием» (Fuchsia переводится с английского как «фуксия»).

Спустя больше года после регистрации торговой марки Google не поделилась ни малейшей подробностью о Pigweed. На 22 марта 2021 г. Google не говорила даже о существования у нее планов по выпуску ОС с таким названием в ближайшей перспективе.

Источник

Google рассказала об Android 12. Функции, которых мы не увидим в Android 11

Что ждёт ОС в будущем

Компания Google ответила на вопросы пользователей социального новостного ресурса Reddit относительно настоящего и будущего операционной системы Android в рамках традиционной сессии AMA (Ask Me Anything).

В частности, были раскрыты функции, которые не стоит ждать в Android 11, но появятся в Android 12 в 2021 году или в следующих версиях ОС. Также некоторые из изменений уже начали внедряться в Android 11, но в будущих версиях ОС работа над ними продолжится более активно.

Во-первых, в Android 11 мы так и не дождёмся функции скриншотов длинных страниц с прокруткой. В ранних сборках бета-версий Android 11 намёки на эту функцию появлялись, однако Google разбила все надежды пользователей на её появление в стабильной версии Android 11. По словам разработчиков, над её реализацией ведётся работа, но она появится не в Android 11 R.

Во-вторых, в будущем появится усовершенствованная облачная система резервного копирования. Пользователь получит больше информации и настроек для создания бэкапов с разных устройств. Ожидается снятие ограничения в 25 МБ для данных в приложениях. Также в будущих релизах Android разработчики «убьют» функцию локального создания резервной копии информации со смартфона на компьютер через ADB.

В-третьих Google работает над проблемой с агрессивным закрытием приложений в фоновом режиме, чем грешат многие производители устройств Android. Делается это ради продления времени автономной работы и по ряду других причин. Google осознаёт проблему и планирует побудить производителей прекратить использовать экстремальные методы, приводящие к тому, что некоторые приложения становятся бесполезными.

В Android 11 накал страстей постараются снизить, требуя от производителей явно извещать пользователей о закрытии приложений в фоновом режиме, а также предоставят новый API, показывающий разработчикам причину закрытия приложений. Однако работа над этой проблемой продолжится в будущем.

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

Источник

Почему у Андроида нет будущего — отвечает технарь

Итак, попробую ответить на этот вопрос. Дело в том, что система Андроид имеет много недостатков, которые перечислены ниже.

Около 85% пользователей смартфонов используют устройства с операционной системой Android. Кажется, что при такой огромной популярности Андроид должен быть почти безупречен. К сожалению, это не так — это самые распространенные проблемы, на которые жалуются пользователи Android:

1. Фрагментация — последняя версия программного обеспечения — Android Oreo — в настоящее время доступна менее чем на 1% устройств. Предыдущие — Android 7.0 и 7.1 Nougat — присутствуют на более чем 20% смартфонов. Проблема фрагментации в основном затрагивает пользователей, которые ожидают последних обновлений программного обеспечения и покупают флагманские модели отдельных производителей. Многие модели среднего класса никогда не получат последнюю версию Android,
2. Нет обновлений старых моделей — Android, похоже, не заботится об обновлении программного обеспечения на старых моделях и не видит необходимости поддерживать своих пользователей. Даже если на данном смартфоне появляется обновление — обычно его нужно долго ждать.
3. Android — открытая система. Его пользователи могут вносить изменения в программное обеспечение. Это несет в себе высокий риск атак хакеров и киберпреступников. Исследования показывают, что около 99% всех «червей» были написаны для Android. Поэтому его пользователи с гораздо большей вероятностью заразят свой телефон или потеряют важные данные.
4. Неудобство системы — многие люди, ежедневно использующие телефоны Android, жалуются на ее ликвидность. Производители смартфонов создают собственные системные чехлы, значительно замедляющие работу телефона. Каждый оверлей снабжен дополнительными программами и функциями, которые сложно удалить и которые обычно не нужны для использования телефона. В основном проблема касается моделей среднего ценового сегмента или смартфонов менее известных производителей. Поэтому перед покупкой той или иной модели стоит почитать отзывы в интернете и немного «поиграть» с телефоном, уделив особое внимание его бесперебойной работе.

Особенности системы

Любой разработчик, который хочет расширить Android для своих нужд, может загрузить Android SDK (Software Development Kit), написать приложение и опубликуйте его на Android Market. Создатели iOS, BlackBerry OS и Windows Phone ограничивают возможность распространения независимого программного обеспечения и требуют лицензионных отчислений.

В отличие от конкуренции, производство устройств на базе Android ADK (Accessories Development Kit) ограничивается затратами на покупку паяльника.

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

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

Схема системы Android

Android запускает приложения в песочнице — изолированной части системы, которая не может получить доступ к остальным системным ресурсам, если права доступа явно не указаны пользователем. Перед установкой приложения Play Store отображает все необходимые разрешения: игра может потребовать от вас включить вибрацию или сохранить данные на SD-карту, независимо от того, есть ли у нее доступ к текстовым сообщениям или контактам.

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

И еще. Android возглавляет список операционных систем с максимальным количеством уязвимостей. Всего их было обнаружено, скажем, в 2019 году аж 414. Правда, раньше их было еще больше. В 2017 году на данной платформе было найдено 843 уязвимости, в 2018 — 525. Общее количество за всю историю наблюдений за Андроид составило 2563 уязвимостей!

Источник

Андроиды уже в 2038 году? Скорее всего даже раньше

Лучшие выходные – это выходные с игрой. Особенно если это консольный эксклюзив Detroit Become a Human на PS4 про противостояние людей и «оживших» андроидов.

Я не помню как называется этот эффект, вроде сужения фокуса сознания, но смысл в том, что если ты начинаешь заниматься какой-то темой или вопросом, то всё вокруг тебя начинает намекать на присутствие этого занятия. Вот и с этой игрой примерно также. Сейчас мы внедряем программных роботов RPA в крупные российские компании, но совсем скоро это могут быть вполне «живые» андройды.

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

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

Причём желание создания андроидов исходит с обеих сторон — богатые и бизнес хотят идеальных работников, которые не болеют и работают 24/7, а многие люди отказываются выполнять какой-то тип работ из-за опасности для здоровья или «непристижности». Добавим сюда ещё нужды правительства в будущих войнах, в которых становится всё труднее оправдать необходимость людских потерь.

Что дальше? Безработица и изменение социального расслоения людей. Всё больше мега-богатых (одна каста) и мега-умных (другая каста) и всех остальных, которых со временем будут вытеснять машины. Можно сколько угодно говорить, что это не произойдёт при нашей жизни (в игре, к слову, 2038 года всего), но первые ростки андройдной роботизации мы с вами увидим.

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

Три судьбы андроидов и огромное количество сюжетных поворотов и концовок — просто рай для игромана. Где только найти столько времени? Мне срочно нужен андроид, который будет делать рутину пока я смогу заняться тем, что мне, как я думаю, важно 😉

Источник

Android Go — будущий миллиард устройств и лимит в 50 МБ. Лекция Яндекса

Новые направления развития уже знакомой платформы — это всегда интересно. С одной стороны, вы расширяете клиентскую базу, с другой — не вкладываетесь в создание софта с нуля, а используете существующие наработки. Но если направление действительно новое, со своей спецификой, то совсем малой кровью обойтись не удастся. На очередной встрече сообщества Mosdroid в нашем офисе разработчик Артур Василов Arturka рассказал об адаптации приложения «Яндекс» под систему Android Go.

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

— Меня зовут Артур, я Android-разработчик, работаю над приложением «Яндекс». Сегодня я поделюсь с вами историей о том, как мы адаптировались под Android Go. Расскажу, на какие грабли мы наткнулись, что у нас не получилось и вообще как это все работает, зачем оно надо.

Небольшое отступление о том, что это вообще такое. Android Go — специальная версия Android, которая предназначена для дешевых устройств. Они стоят 60–100 долларов, и поэтому они очень слабенькие, медленные, тормознутые. Так что Google для них решил сделать свою систему, чтобы они хоть как-то нормально работали. Ее анонсировали на Google I/O в 2017 году, то есть прошел уже год и несколько месяцев. Поэтому, когда анонсировали митап, прозвучал логичный вопрос: «Вы еще живы, что ли?». Я тогда сказал, что все хорошо, все нормально, я расскажу. А теперь я как типичный интернет-герой буду отвечать постфактум, почему так произошло.

Что именно произошло? Google сказал: «Мы делаем такую систему». Потом он сказал: «Окей, нам нужно время на доработку» и все такое. После этого у вендоров всегда бывает какая-то задержка в адаптации этой версии под себя. А новая версия у нас и так выходит не раньше, чем через год, поэтому здесь ничего удивительного нет. К тому же им требовалось решить, надо ли вообще делать такую штуку: речь идет про дешевые устройства и непонятно, будет от них профит или нет. К тому же этот девайс должен быть новым, его надо сделать, научиться продавать, понять, как он будет работать.

Первый смартфон с Android Go появился не так давно. Где-то в апреле, наверное, начались продажи, а может, в мае. Это Nokia 1, он продается везде. У меня он тут валяется. Сейчас, по-моему, на рынке есть всего штук девять таких смартфонов, но к концу года их обещают больше сотни. И в принципе, еще никто из крупных игроков типа Huawei, Samsung и прочих не сказали свое слово, поэтому они еще что-то добавят, не смогут остаться в стороне от такого большого рынка.

Я перед докладом зашел на страничку Android Go и увидел, что они сделали Android Pie Go Edition. Но они там ничего не сделали, просто заранее уменьшили количество установленных приложений и их вес. Сказали: — «У вас теперь в два раза больше свободного места». И стандартные отмазки: bug fix, улучшение производительности, все дела. Но хоть назвали, а значит, не забыли.

Какие ограничения этих устройств, если говорить конкретно? Во-первых, у них 512 мегабайт или 1 гигабайт оперативной памяти, 8 или 16 гигабайт storage. Понятно, что при таких условиях они крайне тормознутые и все нормальные приложения на них будут работать примерно так же тормознуто. Чтобы на них приложения работали с минимальной адекватностью, Google сказал: «Давайте введем следующие требования». Они вполне логичны, вытекают из того, что было на предыдущем слайде.

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

Дальше уже конкретные числа, которым надо соответствовать. Занимаемое место после распаковки и установки APK — не больше 40 мегабайт. Иногда это проблема, потому что у кого-то и APK весит все 80 мегабайт. Будет больно. Более того, это нельзя адекватным образом взять и померить. То есть вы не можете сказать: «Я знаю, что у меня APK весит столько-то, поэтому после установки приложение будет занимать столько-то». Все это очень сильно зависит от вендора, версии устройства, Android и т. д. Но если у вас APK занимает 10 мегабайт, то, в принципе, все нормально и вы никогда не превысите это число.

И теперь самое веселое и классное требование: потребляемая оперативная память во время работы с приложением не должна превышать 50 мегабайт.

Кто знает, сколько оперативной памяти его приложение в среднем занимает во время работы? Кто когда-нибудь интересовался этим вопросом? Есть те, у кого меньше 100 мегабайт? Красавчик. Но, возможно, вы врете. В общем, в среднем, если вы не пишете калькулятор, будильник и прочее, то либо вы очень классный, большой молодец и все сделали хорошо, либо ваше приложение занимает 150–170 мегабайт. Засунуть это в 50 мегабайт очень сложно. Поэтому все остальное время мы будем говорить об этом, будем обсуждать, как засунуть глобус в сову, и т. д.

Что включает наш разговор по памяти? Непосредственно нужно понять, что именно мы меряем, дальше как лучше всего это померить. Также для Android Go устройств есть своя специфика, которую нужно учитывать, и мы о ней тоже поговорим. И я также расскажу какие-то общие вещи, общие советы, о которых вы, возможно, не догадывались, но они реально могут отожрать у вас кучу памяти.

В 2018 году после того, как прошел Google I/O, начинать рассказ про память нужно обязательно с отсылки к этому докладу. Кто его смотрел?

Отлично. Все остальные 180 человек знают, чем заняться в ближайшее время. На мой взгляд, это один из лучших докладов на Google I/O. Чувак рассказал нереально крутые вещи. Он рассказал все по полочкам, хорошо, и со многими глубокими деталями. Те, кто смотрел его и хорошо помнит, наверняка заметят, что я оттуда скопипастил некоторые вещи, потому что иначе нельзя, он рассказал все, поэтому я буду повторять.

Что мы меряем? Там была такая штука, которая называлась PSS (Proportional Set Size). То есть оперативная память в Android представлена некоторыми блоками по 40 килобайт, и эти блоки могут как полностью принадлежать приложению, так и шариться между процессами и приложениями.

И вопрос: как именно понять, к какому приложению относить эту расшаренную память? Есть несколько подходов, они вполне логичные. PSS говорит, что если память шарится между N процессами, значит, мы будем считать, что вашему приложению принадлежит 1/N этой памяти. И абсолютно аналогично есть Residential Set Size и Unique Set Size, который говорит, что «Ничего из shared-памяти не принадлежит мне» и «Все принадлежит». В принципе, PSS здесь самый логичный.

Как именно можно померить потребляемую память? Здесь все просто. Либо это профайлер в Android Studio, либо это dumpsys. Есть, конечно, другие тулзы. Они могут вам дать более детальные результаты, что-то более сложное, но проблема в том, что для понимания их результатов, для их использования все это очень-очень сложно. Часто вам нужен либо root, либо кастомная сборка Android. И они вам по большому счету не нужны, достаточно первых двух инструментов.

_{Ссылка со слайда}

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

_{Ссылка со слайда}

Dumpsys — простая консольная штука, которая не требует от вас ничего, только подключенного телефона и adb. И можно выполнить такую команду: вызвать dumpsys meminfo, передать ему пакет, и он вам вернет примерно такую картинку. И если у нас интересует, сколько именно потребляет наше приложение, то мы можем посмотреть конкретно на TOTAL, которая говорит, что «Ваше приложение жрет около 168 мегабайт». Много, но что поделать?

_{Ссылка со слайда}

Также он показывает вам разбивку, что именно в этой потребляемой памяти сколько места занимает. Здесь есть различные участки, они сложные, мы поговорим о них дальше, но пока можем заметить основное — это Java Heap, наши джавовые объекты, а все, что дальше — это сложнее.

Что еще важного? Память — это очень чувствительная вещь ко всяким тестам и всяким внешним условиям. То есть все тесты вы должны выполнять как можно более в одинаковых условиях. Понятно, что это должен быть в идеале один девайс, потому что память зависит от версии Android. Здесь достаточно вспомнить различия между четверками и пятерками. Зависит от размера или разрешения экрана, потому что чем больше размер экрана, тем больше контента влезает, тем больше памяти нужно, чтобы все это отрисовать. Разрешение чем больше, тем больше пикселей занимают ваши bitmap, и тем больше памяти требуется на их хранение.

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

Еще одна важная вещь — загруженность устройства. То есть у вас может быть все одинаково, но при этом в одном случае у вас ваше приложение единственное работающее, а в другом случае у вас куча приложений, которые еще что-то в фоне делают, что-то качают, удаляют, работают на foreground, и при этом у вашего приложения просто отжимают память, потому что надо отдать другим приложениям. Поэтому в идеале лучше взять и сначала убить все другие приложения, которые работают, не ваши. Все, до чего можете дотянуться, то убейте. Просто в таком случае и PSS в точности скажет вам спасибо, потому что не надо будет шарить память между процессами.

Можно, например, взять и посмотреть текущую информацию по свободной памяти, по занятой памяти. Он вам выведет примерно такую табличку, которая говорит, что «Вот у меня свободной памяти столько, кэшированной памяти столько, занятой памяти столько». И если у вас там есть 200–250 мегабайт свободной памяти для себя любимого, то это хорошо, скорее всего, тогда ничто не повлияет на ваши тесты.

Возможно, у кого-то сейчас возник вопрос «Зачем мне все это надо?». Это такой перерывчик, в котором я дополнительно скажу мотивацию для всего этого.

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

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

Если говорить про специфику Android Go — третий наш пункт в борьбе с памятью, — то там есть несколько приятных новостей. Во-первых, никто на самом деле для вас не требует следовать этим ограничениям. То есть вы можете использовать приложение, как оно у вас есть, поставить его на девайс с Android Go, и все нормально. Проблема в том, что пользователь, весьма вероятно, вас удалит, потому что вы занимаете кучу места. Также ваше приложение может медленно работать и есть кучу памяти, да. Но пока никто это не запрещает, потому что иначе не было бы ни одного приложения, кроме гугловских на Android Go. Но если дальше эта штука будет развиваться, многие будут адаптироваться к таким условиям, то, в конце концов, ваше приложение могут просто понизить в выдаче Android Go, или сказать, как бы пользователь будет устанавливать приложение на свой Android Go смартфон, ему могут показать Alert: «Чувак, приложение плохо работает с Android Go. Может, не будешь его ставить?».

Есть еще один момент — вы можете руками из Google Play исключить Android Go девайсы, то есть сказать, что приложение нельзя ставить на Android Go девайсы. Это появилось не так давно.

И Google еще тоже достаточно умный, и 50 мегабайт, которые звучали в названии доклада — это не фиксированная цифра, она зависит от разрешения устройства, от размера экрана, и, к тому же, от типа приложения. Например, играм выделено больше, по-моему, 115 мегабайт. В принципе, это вполне понятно.

_{Ссылка со слайда}

Что если говорить непосредственно про этот тест? Есть еще один момент, который в частности очень сильно касается нас — работа с предустановками. Когда вендоры делают новый телефон, они часто ставят туда какой-то набор предустановленных приложений. В частности, мы очень сильно этим занимаются, и проблема в том, что там они прогоняют такие штуки как Compatibility Test Suite. Это гугловые тесты, они их прогоняют. И там, если ваше приложение не соответствует этим 50 мегабайтам, то все плохо, и ваше приложение не может быть предустановлено на такое устройство.

К сожалению, тесты, которые делает Google, не из open source, я не могу их рассказать, они под NDA, но хорошие разработчики из Google написали такую статью про Android Go, и там, в принципе, есть рекомендации, которые достаточно хорошие

То есть все банально. Запускаем приложение. Ждем 5 секунд, пока все загрузится. Делаем dumpsys, записываем значение TOTAL, выполняем кучу раз, получаем результат. Все очень просто и банально.

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

Кто считает, что это хорошо для Android Go? А кто считает, что это плохо? Смело.

Проблема в том, что, да, это плохо, потому что в итоге ваша потребляемая память приложения считается по всем процессам. Если мы сделаем такой пустой процесс без ничего и возьмем dumpsys именно этого процесса, то увидим, что он занимает 7 мегабайт. 5-8 мегабайт — это такой оверхед от создания процесса. Поэтому, когда мы боремся за каждый мегабайт, чтобы втиснуть это все в 50, то такая штука дается нам очень плохо. В частности, допустим, у «Яндекс» самая популярная библиотека «Яндекс.Метрика», она тоже работает в другом процессе, и это тоже может давать нам боли.

Поэтому, если вам приходят, допустим, какие-то external-библиотеки, вы можете просто сказать: «Чувак, работай, пожалуйста, в главном процессе. Я согласен, что это может быть медленнее, но зато оно не будет жрать лишнюю память». Так что это тоже тонкий момент.

Если говорить по потреблению памяти, то давайте перейдем к этой табличке, что там есть. Берем пустой проект, и запускаем этот dumpsys, натравливаем на это дело, и видим, что 23 мегабайта из 50 уже занято. Пустой “Hello, world!” без ничего, просто активити с текстом. Становится довольно грустно. Еще более грустно становится от осознания того факта, что непосредственно влиять мы можем на такой параметр как Java Heap, то есть это непосредственно наши джавовые объекты, которые можем отслеживать явно, которые можем удалять, уменьшать и хоть как-то взаимодействовать.

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

Что такое Java Heap — понятно. Что такое Native Heap — тоже достаточно логично предположить. Это те же самые аллокации, только плюсовые. Они приходят из фреймворка и из ваших нативных библиотек, файлов .so и прочего.

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

Stack — это стек Java/C++ потоков. То есть у каждого потока есть свой стек вызовов, поэтому каждому потоку создается такая определенная область памяти для хранения всего этого дела.

Graphics — это отрисовка UI. Там частично хранятся и битмапы, которые отрисовываются, и то, что с этим связано.

Private other, System — это что-то, на что мы совсем влиять не можем, и, по сути, все остальное, что не очень сильно поддается категоризации.

Если говорить про нативные библиотеки, то, допустим, взять можно пустое приложение… можно взять обычное приложение, которое есть у нас, и взять из него dumpsys, увидеть, что он занимает 146 мегабайт. А если пойти и выпилить кое-что… в частности я взял и выпилил две самые большие нативные библиотеки, которые у нас есть в сумме на 15 мегабайт, и взять dumpsys после этого, можно легко увидеть, что у нас пропало потребление из Native Heap и из кода. То есть таким простым жестом мы сэкономили себе порядка 35 мегабайт. Достаточно неплохо.

Потоки. Сделаем самый простой тест. Есть пустое приложение, и есть то же самое пустое приложение, где мы возьмем и сделаем цикл, который будет делать new Thread(), в нем sleep на пять секунд, и запускать этот поток. Можно увидеть, что в таком случае у нас сильно пополняется стек. То есть на все это дело мы можем влиять, но опосредовано, уменьшая количество потоков в Java-коде. То есть через Java-объекты в том числе влиять на все эти локации, которые есть в других элементах.

Если продолжать говорить про потоки, то можно легко посмотреть, что у вас есть за потоки, что они делают в приложении. Есть разные инструменты. Можно тем же systrace, можно просто консолькой найти id вашего процесса, и грепнуть ps по тому, какие потоки есть вообще в системе.

Если вы хорошо делаете и используете всякие ThreadFactory, чтобы именовать ваши потоки, то вы можете понять, что у вас должно быть, что не должно быть, и таким образом уменьшить все это дело, потому что 100 потоков в приложении иметь особо бессмысленно.

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

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

Уменьшение памяти невероятно плохо сочетается с оптимизацией. Допустим, мы хотим сделать самый простой кейс, когда пользователь скроллит ленту картинок, картинки подгружаются из сети. Что мы делаем в таком случае, чтобы пользователь видел картинки быстрее? Мы заранее — пока он еще не доскроллил до этих картинок — начинаем подгружать нужные картинки, чтобы он не видел серые квадраты. В таком случае, если мы говорим про память, то мы будем просто занимать память этими картинками. Поэтому память и оптимизация крайне плохо сочетаются. В смысле — оптимизации такого типа.

Если посмотреть на dumpsys, то он хороший, он выводит вам много чего интересного, кроме непосредственно потребления памяти. Например, количество ваших объектов, типа количество View, количество WebView, количество Assets, информацию по базам данных.

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

Также, например, очень приятно посмотреть на выделенные Assets. В частности, самое популярное, что можно увидеть –это шрифты. И эти шрифты занимают 1,5 мегабайта. Опять-таки, когда мы боремся за каждый мегабайт, то нежные дизайнерские чувства посылаются далеко в первую очередь. Да простят меня коллеги.

Неожиданно отвратительная вещь — это WebView. Если создать пустую активити, запустить WebView, загрузить страницу Яндекса, взять dumpsys, будет 100 мегабайт, просто сразу. Если открыть, допустим, какие-нибудь картинки, проскроллить пару раз, то 300 мегабайт — легко. Даже несмотря на то, что WebView хромовское, а процесс считается ваш. Так-то.

Google об этом знает. Они сделали небольшой хак. То есть у них есть WebView, у них есть приложение Google, в котором можно что-то искать. Поисковая выдача открывается в WebView. Нормально.

И есть приложение Google Go, которое предназначено для Android Go-устройств. И здесь они открывают выдачу уже нативно, то есть они создают какой-то layout для отображения этой выдачи, они отображают все это нативными компонентами. А все, что нужно открыть непосредственно в браузере, открывают не в своем внутреннем браузере, а в Chrome Tabs, чтобы Chrome разбирался с этим делом. Такие вот хитрости.

Если говорить про приложение непосредственно под Android Go, то что тут интересного? Тут есть определенные специфики, как именно разрабатывать приложение под Android Go, и давайте немножко поговорим об этом.

Есть несколько способов. Во-первых, у вас все может быть классно, приложение может работать хорошо, и вы можете его отдавать для Android Go без всяких доработок. То же самое в случае, если вы пишете будильник, калькулятор. Но чаще всего у вас с этим все сложно, поэтому вам нужно, допустим, сделать какие-то build флаги, отключить какие-то модули, фичи на этапе компиляции, еще что-то сделать. И таким образом у вас будет две APK, и вы можете загрузить одну как обычную, вторую — использовать uses-feature «low-memory», и это будет как две APK.

Либо же вы можете сделать два приложения, то есть одно приложение обычное, другое приложение специально заточено под Android Go. Так делает Google. Они, в частности, выпустили Go-версии многих своих приложений.

Что здесь хорошего, что здесь плохого? Хорошо то, что вы изначально делаете новое приложение, и если вы изначально будете что-то в нем писать и превышать потребление памяти, то вы скажите: «Ага, делал что-то не то. Пошел делать нормально». И вам не нужно сразу уменьшать эту память в четыре раза. К тому же, это хорошо и это легко, а плохо в том, что вам нужно сделать новое приложение, к тому же, оно должно быть как-то поддерживаемо, одинаково с фичами с основным приложением, и как-то вместе оно должно сочетаться. Это требует огромную кучу ресурсов, и, в принципе, делать это не надо, если вы не Google, потому что если Google не будет делать такие приложения, то никто их не будет делать. А сейчас вам делать такое приложение не надо, потому что это требует кучу ресурсов, и непонятно, действительно ли Android Go хорошо выстрелит, и будет действительно очень много таких устройств, или же это будет довольно нишевая доля.

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

_{Ссылка со слайда}

Еще один довольно важный момент из доклада, который был на Google I/O: ребята правильно говорят, что не надо бояться для таких слабых устройств отключать какие-то свои фичи в рантайме. Возможно, у вас есть очень клевый фоторедактор, который может делать все, что угодно, накладывать любые фильтры, но он требует кучу-кучу памяти, и на слабом устройстве он будет работать плохо. Поэтому не бойтесь сказать, что «Давайте не будем на вашем устройстве запускать фоторедактор, потому что у вас слабое устройство. Купите нормальное». Так что это график хороший. Это график зависимости количества фич от потребляемой памяти, и наоборот. И этому можно следовать, в принципе.

Что еще стоит учесть? Понятно, что здесь вопрос не только памяти. Память — самое сложное, самое интересное и то, с чем мы возились 98% времени. Но понятно, что надо думать в том числе о скорости работы, запуске, потреблении батарейки и т. д. К тому же вы можете сделать какие-то дополнительные фичи для Android Go-приложений. В частности, в YouTube Go есть возможность скачать приложение для просмотра офлайн. В основном приложении YouTube такого не было, и, может быть, нет и сейчас. Не знаю. Дело в том, что девайсы с Android Go будут использоваться в странах, где, возможно, не очень хороший интернет — поэтому давайте скачивать заранее. Есть другие хорошие примеры — Facebook Lite, Twitter Lite, а также Яндекс.Браузер Lite, потому что не всем нужны какие-то полностью функциональные фичи. Кому-то, может быть, нужна только переписка или только посты. Незачем скачивать огромный Facebook, когда можно поставить маленький. И все это должно быть для пользователей, вы должны подумать и сделать так, чтобы им было хорошо. Вообще, это классный челлендж — сделать такое приложение, чтобы оно работало под Android Go.

Что еще по ссылочкам? Есть классный ответ на Stack Overflow, который набрал почти 1000 лайков. Вы можете помочь ему набрать еще. Ответ разъясняет, что вообще с памятью, что за что отвечает, что чем является в памяти. И, в принципе, весь этот ответ — по dumpsys.

Знают ли это многие или нет, но Android может работать с устройствами, у которых 512 мегабайт оперативной памяти, только начиная с Android 4.4. Там как раз таки появился специальный API для взаимодействия с такими устройствами, и это вам может помочь.

Здесь можно было бы закончить, это было бы красиво. А теперь о том, как это было у нас на самом деле. Если коротко — не так красиво, совсем не так красиво.

Пришли ко мне в мае, сказали: «Надо сделать». Я сказал: «Хорошо». Пошли разбираться. Почитали — все хорошо, кроме памяти. Память где-то 170 мегабайт. Отличный старт. Надо каким-то образом уменьшить. Что проще всего сделать? Взять и отключить все отключаемые модули, посмотреть, что происходит, потому что надо сделать так, чтобы оно хоть как-то работало. Если там не будет каких-то фич — ну и ладно. Осталось 105 мегабайт. Было больно.

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

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

После недельки осталось где-то 64 мегабайта. Я думаю: «Хорошо, надо сегодня закончить». Прошло 14 часов, время 4 утра, памяти 60 мегабайт. И я уже не знаю, что делать дальше. Все бесит. Более того, это стало уже необратимым рефакторингом. Поэтому на следующее утро было принято волевое решение — все это не то, жизнь отвратительна, ненавижу все, и делаем специальную новую ветку, начинаем все с нуля. Берем и удаляем весь код, которого, скорее всего, не должно быть в Android Go, и чиним ошибки компиляции. 10 часов, APK с оставшейся основной функциональностью готова, тесты проходят, прекрасно. Проблема в том, что эта штука неподдерживаемая, она у нас есть и все.

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

Источник