Продолжаем тему исследования размера приложений для Android.

Небольшое отступление. Крупные компании проводят семинары, встречи, выставки, обмен опытом и т.п. на тему того, как сделать разработку приложений для Android лучше, качественнее, ну, и конечно же рассматривают новые технологии в разработке. Меня всегда поражало то, какие Львы Толстые выступают с докладами — не в плане растительности на лице и любви к детям, конечно, а в плане подхода к выступлению. Все четко, красиво, много (и порой непонятно).

Что меня лично смущало и смущает всегда, так это то, как темы этих докладов отличаются собственно от произведенных продуктов. Взять тот же Яндекс.Диск. Он адово тормозит при запуске на любом моем устройстве, будь то старый Nexus 7, будь то прошлогодний хит Xiaomi Mi5. Нет, я пожалуй, делаю слишком громкое заявление на тему тормозов. Просто задержка между нажатием на иконку приложения и его открытием здорово отличается от других приложений (как конкурентов, так и просто отдельных).

Про старый-добрый изнасилованный в пух и прах Кинопоиск из приличия помолчим. Что добавлено в последние релизы — реклама тут, реклама там. А сохранение состояние экранов как не было, так и нет.

Другое приложение, которое попало сегодня под мою руку, это продукт того же Яндекса под названием Auto.ru. Инсталлятор сообщил мне, что весит оно аж целых 24 мегабайта!

«Что там такого напихано???» подумал я.

Для примера, пару лет назад я занимался приложением DePict, и оно весило 27 мегабайт. Я страшно переживал по этому поводу, но ничего поделать с этим не мог, потому что большую часть от этого размера занимала библиотека ffmpeg для всех архитектур. И это использование как минимум логично, а что же в Auto.ru?

Папка Resources занимает больше всего места, и что же там?

Первый файл — это рисунок в png на 1 мегабайт (PNG, мать твою, Карл, даже не оптимизированный webp) размера 1440х960 пикселей!

И так далее по списку, там целый ворох гигантских рисуноков!

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

Например, вопрос — зачем впендюривать аж три библиотеки загрузки и показа рисунков в приложении? Там есть Picasso, есть вариант получше — Glide, и постарше (он уже не поддерживается пару лет) — UniversalImageLoader. Зачем есть оба два json парсера — гугловский gson и JacksonMapper? Йоу, пацаны, у них даже биллинг для гугла — сторонняя библиотека! Как по мне, для таких ребят это позорновато.

И так далее.

 

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

Зато написано вроде как на модном и молодежном Kotlin с передовыми технологиями Dependency Injection. Молодцы, по докладам можно отчитаться!