Хабрахабр

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

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

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

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

Android Go — специальная версия Android, которая предназначена для дешевых устройств. Небольшое отступление о том, что это вообще такое. Так что Google для них решил сделать свою систему, чтобы они хоть как-то нормально работали. Они стоят 60–100 долларов, и поэтому они очень слабенькие, медленные, тормознутые. Поэтому, когда анонсировали митап, прозвучал логичный вопрос: «Вы еще живы, что ли?». Ее анонсировали на 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 килобайт, и эти блоки могут как полностью принадлежать приложению, так и шариться между процессами и приложениями.

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

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

Ссылка со слайда

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

Ссылка со слайда

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

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

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

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

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

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

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

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть