В 2022 году многим российским компаниям пришлось адаптировать мобильные приложения и решать проблемы, вызванные международными санкциями.
Когда мобильное приложение ВТБ было удалено из Google Play, сразу встал вопрос — как пользователи смогут получать обновления? В нашем случае это вопрос доступа миллионов клиентов, которые уже установили Android-приложение «ВТБ Онлайн», к банковским услугам. При поиске решения заодно удалось сократить размер приложения в 2 раза — до 220 Мб.
Где публиковать заблокированное в GooglePlay приложение
Самый очевидный ответ — на сайте банка ВТБ Онлайн. Потом появились отечественные аналоги Google Play: Наш Store, Ru Store и RuMarket. Кроме того, опубликовали приложение, Get Apps (Xiaomi), Galaxy Store (Samsung). Эти площадки не поддерживают разделения на архитектуры.
Как происходила публикация приложения в Google Play.
Нужен аккаунт разработчика
Нужно само приложение
Нужно текстовое описание и картинки
Нужно сделать сборку и отправить её на ревью
После ревью новый релиз приложения появлялся в магазине
Сложностей с публикацией в другие магазины не было: везде процесс был похожим. При этом не везде нужна отправка на ревью — несколько файлов под разную архитектуру публикуется непосредственно на сайте банка.
Для пользователей тоже сложностей с обновлениями не возникло, т. к. для всех сборок передавались одни и те же файлы, подписанные одной подписью. В итоге если первая установка приложения была с Google Play, то её можно спокойно обновить с любого другого магазина.
Так мы решили основной вопрос — с обновлением и установкой приложения.
Осталось решить второй вопрос — с его размером.
Почему тяжёлому приложению нужно худеть
Можно выделить четыре проблемы больших приложений:
Долгая загрузка обновления или приложения. Пользователи не готовы ждать и часто прерывают процесс, отменяя загрузку.
Мобильные операторы отказываются от безлимитных подписок, а с пакетом интернета, скажем, в 5Гб — регулярно обновлять приложение дорого.
У многих пользователей на телефонах мало свободной памяти, и большое приложение может банально не поместиться на телефоне.
В некоторых сторах есть ограничение на скачивание слишком больших приложений и предлагается скачивать такие файлы только по Wi-Fi.
Так что в любом случае сокращать размер приложения нужно.
Как мы затягивали пояса и избавлялись от лишнего
Сборки и архитектуры
Для ВТБ Онлайн мы использовали сборку-бандл, которая состояла из установочных пакетов под разные архитектуры. Она грамотно упакована с учётом общих данных для разных архитектур, и бандл весил немного по сравнению с тем же APK. Когда пользователь начинал скачивать приложение с Google Play, было понятно, какая у него архитектура, и скачивалось уже оптимизированное под его устройство. Именно поэтому на Google Play не было проблем с размерами приложений. Например, если бандл весил 200 Мб (под разные архитектуры), пользователь скачивал с Google Play приложение весом 80 Мб, уже оптимизированное под конкретное устройство.
Кроме создания бандла, можно собрать универсальный APK, который будет работать на любой архитектуре, но это приводит к увеличению веса приложения. В случае с ВТБ Онлайн универсальный APK до оптимизаций весил около 400 Мб. Сразу забегу вперёд: нам удалось сократить размер универсального APK до 220 Мб. Сейчас поддерживаются 4 архитектуры:
armeabi-v7a — более бюджетные и старые модели ARM;
arm64-v8a — более новые и дорогие модели ARM;
x86 — более старые 32-битные модели x86;
x86_64 — более новые 64-битные модели x86.
Библиотеки и ресурсы
Вес сторонних SDK обычно не является существенным, но в совокупности они составляют большую часть веса финального APK. Поэтому 13 нативных (.so) библиотек мы удалили сразу, сократив размер финального APK на 252,063 Мб:
Долго думали, что делать с оставшимися библиотеками. Может, переписать их своими силами? В итоге пока убрали в них некоторые неиспользуемые функции, а также отказались от нескольких фич.
Часть кода написана на Java, часть — на Kotlin (Kotlin — целевой язык для новых проектов). Была кодогенерация в Dagger и Synthetic, а также байтового кода. Поэтому поставили задачи по оптимизации этих процессов, что также сократило размер APK. Кстати, при оптимизации Dagger были сложности при выделении и разделении графа даггера (их тоже удалось решить).
Флаги minifyEnabled (запускающий анализатор ProGuard и удаляющий неиспользуемый код) и shrinkResources (удаляющий ресурсы, которые ProGuard пометил как «неиспользуемые») в приложении были изначально включены — так что тут уже не оптимизируешь. Зато удалось оптимизировать Lint на уровне CI, что упростило код-ревью и избавило от проблемы увеличения веса приложения.
Много места занимали и ресурсы. Провели в команде анализ, что с ними можно сделать. Оказалось, что у многих .png- и .webp-ресурсы не были включены в оптимизацию и частенько попадались картинки с метаданными. У больших картинок сократили размер. Какие-то картинки уменьшились автоматически, над некоторыми пришлось поработать вручную, подбирая степень оптимизации. Некоторые картинки сжались очень сильно. Рекорд — картинка стала в 100 раз меньше. В итоге сократили 30 Мб по всем плотностям ресурсов за счёт их оптимизации. Если говорить о сборках под конкретный DPI — там выигрыш поменьше.
При анализе ресурсов было найдено множество старых ресурсов, которые были оставлены как техдолг и благополучно забыты. Но эти ресурсы могли неявно использоваться, и поиск мест для них делался проблематичным. Так что решили пока «стариков» не трогать.
В итоге получилось следующее соотношение библиотек, ресурсов и кода:
Риски оптимизации приложения
При оптимизации под разные архитектуры стоит проверить корректность работы на телефонах от разных производителей. Потому что то, что не используется у одного производителя, может оказаться обязательным для другого. И тогда оптимизация может привести к критичным проблемам на некоторых устройствах. Поэтому желательно после подобных оптимизаций тестировать на большом количестве устройств.
При оптимизации библиотек есть вероятность удалить и сами библиотеки, и их функции, которые используются не напрямую, а подключаются динамически (например, через lazy в Kotlin). А это станет заметно только на этапе Runtime. Так что по каждой функции библиотеки, которая планируется к удалению, стоит запустить глобальный поиск и убедиться, что её удаление не нарушит работу приложения.
При удалении ресурсов — если воспользоваться возможностями Android Studio — можно удалить динамически подключаемые ресурсы. Многие ресурсы, подключаемые в классе, статический анализатор может посчитать неиспользуемым. Поэтому надо по каждому «подозрительному» проводить отдельное исследование.
При использовании флагов minifyEnabled=true и shrinkResources=true есть вероятность, что анализатор ошибочно посчитает динамически подключаемый код и ресурсы неиспользуемыми. А это приведёт к ошибкам и даже падению приложения. Поэтому нужно внимательно настраивать правила в ProGuard.
В целом, если приложение имеет высокий процент покрытия unit-тестами, большинства рисков при оптимизации можно избежать.
Вместо заключения
Собственно, мы вернули пользователям возможность скачивать обновления и устанавливать приложение «ВТБ Онлайн». Попутно уменьшили размер приложения вдвое и решили множество технических задач.
Дальше по оптимизации планируем:
переписать сторонние библиотеки своими силами — это упростит их обновление, сократит размер и тоже повысит безопасность;
наше приложение не использует технологию BFF (backend for frontend), и в планах не было делать dynamic module.
Итого рассчитываем, что скоро приложение «ВТБ Онлайн» станет ещё легче.
А как вы оптимизировали размер своих приложений? Пишите в комментариях.
Комментарии (44)
Elmot
01.09.2022 10:40+28А есть чем гордиться-то?
Банальное банковское приложение занимает после оптимизаций "всего" 220 мБ.
Зачем такой бешеный объем нативных библиотек?
Что там происходит внутри? Там видеоклипарт внутри?AlexanderY
01.09.2022 13:43Присоединяюсь к вопросу. Причем, без сарказма, хотел бы узнать подробный разбор. И это касается не только ВТБ. Сбер, Тинькофф, Альфа - у всех 250+ мб.
Я просто от мобильной разработки далёк. Занимаюсь вебом, у нас веб-приложение занимает пару мегабайт (и то мне кажется, что это много). Но это plaintext. Я всегда думал, что нативные приложения за счет компиляции будут выигрывать.
Конечно, я не учитываю медиа-ресурсы, но неужели их там ТАК много?
AllexIn
01.09.2022 13:46-2Да. Их так много. Вы на разрешение устройств посмотрите. Просто одна фоновая картинка в разрешении современного устройства (без сжатия) это 8 мегабайт. Понятно что там сжатие используется. Но там же не одна картинка.
hogstaberg
01.09.2022 14:54+3Я вот лично в банковские приложения залезаю не для того, чтобы на картинки пялиться. Мне бы и заливка фона зашла более чем.
AllexIn
01.09.2022 14:59Лично про вас ничего не могу сказать, но в целом - на простые интерфейсы пользователь реагирует плохо.
MechanicusJr
01.09.2022 20:14+2но в целом - на простые интерфейсы пользователь реагирует плохо.
Выборка какая-то была или просто так решили?
Popadanec
01.09.2022 21:40Тоже поддержу. От приложения в первую очередь требуется очевидность действий, во втором уже свистелки — перделки.
Касательно приложения банка, я пользовался/наблюдал как пользуются родственники и ВТБ и Сбером, второй интуитивно понятнее. И вызывает меньше вопросов.
AllexIn
02.09.2022 13:40Выборка есть, но вам я её не покажу. Потому что не имею желания попасть под нарушением NDA ради рандомного обсуждения в инете.
hbn3
01.09.2022 19:46+2А векторные картинки почему бы не использовать? Или алгоритмические.
Вполне можно красивые фоны генерировать с идеальным качеством одной векторной картинкой для всех устройств с малой долей от размеров обычных форматов.
Может быть конечно дизайнер так «видит» что требуются сотни мегабайтов. Попросить чтобы видел подругому.
saboteur_kiev
01.09.2022 15:20Да никому не интересно, что в пакет включены какие-то стандартные библиотеки, которые приложение даже не использует.
У меня был опыт, когда дистрибутива, состоящий из десятка микросервисов, в каждом из них лежал почти стандартный пакет библиотек. И если вынести эти библиотеки отдельно, чтобы убрать дублирование, размер дистрибутива уменьшился бы процентов на 80-90.
И когда я привел в экселе красивую табличку сколько мы сэкономим места (а это сотни версий дистрибутива на разных енвайрнментах, плюс CI, плюс бэкапы, а каждый дистрибутив почти под гигабайт... мне сказали что на это нет времени.
VTB Автор
01.09.2022 17:15Все верно, отказаться от многих нативных библиотек - наш приоритет. Возможно, в будущем расскажем и об этом.
avmaksimov
01.09.2022 17:22+4Как что? Анализ и передача ваших контактов, звонков, местоположения и всей другой конфиденциальной информации, без доступа к которой приложение отказывается работать.. Я думал, только Сбер хочет "БигДату" нахаляву, но нет...
Лично я свой выбор против этого Банка сделал, который не уважаем моё privacy... Иногда захожу через веб и всё.
isden
02.09.2022 11:49без доступа к которой приложение отказывается работать
К слову, именно сабжевому приложению требуется только доступ к звонкам.
Приложеньки других банков, которыми недавно пользовался (росбанк, тиньков), не требуют даже этого.avmaksimov
02.09.2022 13:09Я являюсь клиентами нескольких банков и "нормальные" банки позволяют работать без этого. Не хочу делать рекламу никому, чтобы не обвинили, но там всё только добровольно - без принуждения.
nick-for-habr
01.09.2022 10:47+10Про «похудение» приложения — ну тут особо хвалиться нечем, это надо было сразу делать. А то понапишут bloatware с кучей рекламы, а потом героически борются: смотрите, мы тут расчистили уголок от мусора, что сами и навалили.
Я честно говоряприфигелудивился, когда ВТБ в марте предложил мне обновиться и закачать пакет на 450 ГБ.
Но может кому-то полезно будет, минимум натолкнёт на эту же мысль.
И сделайте уже в настройках опцию «Показывать собственные средства без учёта кредитного лимита». Несколько карт ваших, навязали ещё когда их везде пихали, а дебетовые не хотели давать — теперь приходится вычитать кредитный лимит что бы понять, сколько там денег. И он ещё разный везде…
flx0
01.09.2022 11:17+7Охренеть. Что такого можно напихать в банковское приложение на 220 МБ? Да еще выдавать это за достижение, мол раньше вообще полгига было...
mrsantak
01.09.2022 11:37+2Там же написано, что 220 Мб - это бандл для 4 архитектур. Под конкретную архитектуру будет сильно меньше. А что такого понапихали? Ну вот эта страничка хабра у меня закачала почти 7 Мб ресурсов. И ВТБ тут не особо-то и выделяются.
Пользователи хотят пыщ-пыщ картинок и анимаций, без них wow-эффекта нет. Разрабы хотят использовать как можно больше фреймворков, без этого им не интересно. Манагеры хотят выкатить продукт побыстрее. Вот и получается, что в маленьком размере приложения и эффективном использовании ресурсов никто не заинтересован.
nerudo
01.09.2022 12:05+1Это пользователи сказали, что они хотят пыщ-пыщ?
Pokolo
01.09.2022 12:12+2за пользователей говорят маркетологи)
пыщ-пыщ и прочие кешбеки это здорово, но главное в банке это сохранность, пока же весь колосс держится на пинкоде 0000 вашей симки и девичей фамилии матери.
почему нет доп опций в безопасности для меня загадка.
mrsantak
03.09.2022 00:31Ну типа того, посмотрите какая доля пользователей какого-нибудь телеграм вкорячивает всякие стикеры по которым подчас вообще хрен поймешь чего они означают. Или зайдите на что-нибудь типа пикабу и увидите, что 2/3 постов вставляют текст картинкой. Откройте хабр и увидите гребаные кдпв, которые в большинстве постов вообще никакого отношения к теме поста не имеют. Запускаешь такой minikube и наслаждается разноцветными смайликами в консоли. Эта срань везде. И если ты ей не соответствуешь, то выглядишь в лучшем случае устаревшим.
atd
01.09.2022 11:21+6Требую продолжения этой статьи, пожалуйста не останавливайтесь!
Можно ещё раза в 4 уменьшить
VTB Автор
01.09.2022 17:16Можно, конечно) Как раз продолжаем работать над этим, и уже в ближайших версиях размер приложения будет значительно меньше, чем сейчас.
avmaksimov
02.09.2022 11:35+1может сделаете версию для тех, кому дорога их приватность и приложение не будет требовать доступа к звонкам, контактам и т.д.? Мне не нужна ваша борьба с мошенниками или удобство перевода.. Кому надо переводить я сам скопирую из адресной книги. И уважение к клиентам проявите, и приложение будет ещё меньше размером ;)
AlanDrakes
01.09.2022 11:26+10А знаете, я скучаю по временам Windows CE / Win Mobile 5.
Приложения были лаконичными. Мессенджер? QIP Mobile - 1.3МБ. ICQ? 1МБ. Текстовый редактор? 200-300кБ. Пара утилит-виджетов? 16кБ.
Всё было легковесным и летало на медленных процах. Не жрало батарею и адекватно вело себя в фоне.А сейчас что?
Телефон с 4ГБ оперативной памяти не может удержать в этой памяти три приложения (и рабочий стол). VK + Telegram ещё как-никак работают, но стоит запустить что-то дополнительно - мессенджеры выдавливает из памяти. Почему? "Потому что ты лох, вот почему" (с)Popadanec
01.09.2022 15:16Одна из проблем, мультипроцессорность и мультиверсионность.
Одно приложение для устройства с практически любым процессором и любой версией андроида.
Гугл плей вроде бы собирался или уже начал разделять приложения, для разных устройств, с разными ЦП/разрешением экрана/версиями ОС.
Вторая, подтягивание целой библиотеки, ради пары функций.
Вот в результате весят современные монстры много и требуют много ресурсов.AlanDrakes
01.09.2022 15:47Чёт у них там вроди бы своя витруальнма машина, кэш которой при некоторых действиях, приходится чистить (угу, Davik). И подозреваю, что ВСЕ приложения изначально подразумевалось писать именно под него.
Так зачем тонны библиотек? Ах да... нельзя просто так взять и сделать на базе обычных библиотек.
Почему-то в WM всё работало нормально. Интересно, да?werwolflg
02.09.2022 14:20>Почему-то в WM всё работало нормально. Интересно, да?
Далеко не всё, кривых приложений тоже хватало, особенно написанных на .NET CF. Но в целом работало всё быстрее, да.
atd
02.09.2022 14:25да и без netcf были свои приколы.
Например, когда после использования какой-то модной библиотеки на куче темплейтов бинарник распухает, и гуй начинает свопиться )) но это уже совсем другая история.
prishol
01.09.2022 11:35+1Никогда не понимал большие размеры обновлений. В моём понимании: первая установка требует больший размер, но потом все обновления идут маленькими патчами. И только когда приложения обновляет всю свою логику, платформу, то скачивается снова большой файл.
atd
01.09.2022 11:37+1У гугла был (есть?) интересный проект по обновлению хрома: высчитывался минимальный дифф (даже для бинарных файлов), он и скачивался.
Проблема в том, что это сложно. Намного проще заставить юзера скачать всё заново. Из этого же и растут все эти приложения на сотни мегабайт, просто потому что «так проще».
freedbrt
01.09.2022 11:52Особенно если версии выходит часто, нужно держать диффы между каждыми из них.
SGordon123
01.09.2022 12:24А точно с датами платежей в приложухе проблем нет? Когда 20 число суббота?
NekitGeek
01.09.2022 13:20Хорошая тенденция, вы наверно единственные кто этим вопросом задался)
VTB Автор
01.09.2022 17:15Спасибо!) Наверное, это вечный вопрос, которым задается абсолютное большинство сервисов, в том числе и мы. Тенденция продиктована развитием и доступностью определенных технологий - стараемся использовать их ради удобства клиентов.
AstorS1
01.09.2022 22:37Было бы здОрово оставить ландшафтный режим отображения во всех экранах и операциях. Очень удобно для планшетов.
virtusha
02.09.2022 00:33-2Ваше приложение как было паршивым, так оно и осталось паршивым. Я не знаю, что у вас за программисты сидят там, но такое ощущение, что вы в команду понабрали одних бездарей. Да и в целом банк отстойный.
nerudo
Мораль: пока нагрузка была на инфраструктуру гугла, нам было глубоко положить на ресурсы и траты пользователей.