Разработка под Android
Комментарии 23
+1
Спасибо за статью, а использование ресурсов по типу:
android:theme="@style/android:Theme.DeviceDefault.NoActionBar"

не может вызвать ResNotFound на каких-нибудь китайских устройствах?
0
Если в файле res/values/styles.xml зажать Ctrl и кликнуть мышью в строке по «Theme.AppCompat.Light», то Вы попадёте в другой файл, в котором будет указан стиль, от которого идет наследование «AppTheme» если операцию повторить несколько раз, то можно дойти до «android:Theme.DeviceDefault.NoActionBar», или, например, до «android:Theme.Holo.Light».
На счёт китайский устройств не могу быть уверен, но скорее всего не вызовет ошибку.
+5

Ок, а смысл? За исключением вот этого:


shrinkResources true
minifyEnabled true

Все остальное – не очень понятно, что автор предлагает с этим делать. С практической точки зрения разрабатывать реальное приложение без support library – это надо быть очень изощренным мазохистом. С академической – ну вроде и так понятно, что если убрать зависимости, то приложение должно весить меньше.

+1
Смысл в том, что размер приложения должен зависить от его функциональности.
И если функциональность ограничивается простым кликером, то приложение не должно весить более 50 КБ, иначе его размер повлияет на количество скачиваний. Вот ссылка, в которой показано влияние размера приложения на количество загрузок.
Да, Вы правы, для приложения размером 50 МБ или 51 МБ прирост не велик ценой потери support library, и здесь лучше оставить библиотеки поддержки ради удобства разработки. Но для очень простых приложений, может быть эффективен отказ от support library ради уменьшения размера.
+6

Ну вообще приложение с функциональностью Hello World может весить хоть 100Кб, хоть 100Мб – оно все равно нафиг никому не нужно, и скачивать его никто не будет.


В 99.99% случаев стартовый размер в 1Мб – это нормально, если у вас в приложение будет хоть что-то полезное. Уменьшать дальше – ну разве что для хаба "Ненормальное программирование".

0
А потом телефоны с 2 Гб оперативной памяти становятся «бюджетными».
+1

Да я обеими руками за уменьшение размера приложений. Но только работающими на практике способами, вон ниже товарищ все правильно написал, а не экономией на иконке или support library (которая сейчас вполне себе модульная).

0
Вот у меня в телефоне есть приложение PowerTorch, которое включает вспышку (то есть фонарик). Весит оно 124 Кб. Я не знаю, какими способами автор его уменьшал, но свои функции оно выполняет, и мегабайт памяти (а телефон действительно бюджетный, а не «бюджетный») экономит.
+1

К сожалению, это единственное подобное приложение во всей экосистеме Android. Все остальные приложения имеют запредельные размеры. Какое-нибудь приложение магазина или кафе, нужное только для того, чтобы получить скидку, и имеющую всего одну функциональность: показать штрихкод и размер скидки, будет весить мегабайт 80-160. Каждый раз когда смотрю на размер устанавливаемых приложений, в голове не укладывается.


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


И таки да, покупать Android телефон с размером ОЗУ менее 3Гб и размером флешки менее 32 Гб — стрелять себе в ногу, потому что все эти приложения выжрут все место на флешке и в ОЗУ моментально. После опыта использования двух бюджетых андроидофонов, я окончательно усвоил истину, что покупать что-то с худшими характеристиками, чем у флагманов — обрекать себя на невыносимые страдания (такие как невозможность обновления приложений).

+1
> К сожалению, это единственное подобное приложение во всей экосистеме Android.

Полно таких приложений. Root Explorer — ≈500 кб, Nesoid (эмулятор NES) — 300 кб, SQLite Editor — 200 кб…

> Все остальные приложения имеют запредельные размеры. Какое-нибудь приложение магазина или кафе, нужное только для того, чтобы получить скидку, и имеющую всего одну функциональность: показать штрихкод и размер скидки, будет весить мегабайт 80-160.

Ну а подобные приложения всегда писались даже не задней ногой, а хвостом.
0
Ну а подобные приложения всегда писались даже не задней ногой, а хвостом.

Скажите спасибо таким кроссплатформенным фреймворкам как ReactNative, Xamarin, Qt, Flutter. Бизнес выбирает где дешевле, их размер бинарника не сильно волнует.


Я общаюсь с людьми которые пишут кроссплатформенные приложения, они считают что приложения с минимальным функционалом размером в 10-20 мб это нормально.

0
ну вот я, лично, критично смотрю на вес приложений… было приложение у меня с клавой, в какой-то момент (точных причин не знаю, я на кастоме и после обновления) перестало работать. привлекало тем, что делает что нужно, лишних прав не требует и весило мало. тогда я написал своё, но размер меня не устроил и тут вышла прошлая статья… уменьшил и то что надо вышло.
+1
Также заменим идентификаторы на однобуквенные

А это то чем поможет? Сейчас запретили сжатие и эти биты дают какой-то выигрыш по сравнению с читабельным кодом?
0
Верно, читабельность кода уменьшается, ради 30-100 байт. Если вес приложения исчисляется в единицах килобайт, то небольшой выигрыш может быть.
+2
Если уж хотите поизвращаться, то ничего переименовывать не нужно.
После компиляции, в dex и xml файлах все пользовательские атрибуты и ссылки заменяются на resId (например, 0x7f0b0004) и пакуется в файл resources.arsc, где и хранятся все строки, включая пути к файлам, все типы (drawable, string, etc) и все ключи (например, ic_launcher_round). Можно взять, разобрать этот нехитрый файл, удалить все ключи, переименовать любые файлы из ресурсов, переместив их из res/ хоть в корень архива, провести некоторые оптимизации, заново запаковать файл ресурсов и подписать архив.
Так вы не потеряете читабельный код и сможете оптимизировать и даже обфусцировать ссылки на ресурсы, атрибуты и даже «поломать» этим великий и могучий apktool. Только выигрыш в плане уменьшения байт с этого всё равно минимальный.
0
А можно ли при перепаковке APK внедрить туда какой-то вредоносный код? Давно вызывают подозрение приложения выложенные на 4PDA и подобных местах.
+1

Можно, конечно, просто подписано оно будет не подписью оригинального разработчика.

0
Можно. Но при установке же можно проверить подпись. Да и уже установленных тоже.
+3
Гугл для уменьшения веса предлагает App bundle и dynamic features. Это есть смысл использовать в реальных приложениях. А вырезать support library? Зачем?
+4
Для меня смысл данной статьи сводится к «Удаляем зависимости которые не используем и это сокращает обьем APK» — что собственно и так крайне очевидно. Пример со сферическим конем в вакууме. Как часто вы создаете приложение с одной кнопкой? Вот знаете, когда у вас будет стоять настоящая задача минификации (допустим с 4х dex файлов до какого то минимума), переименовыванием ресурсов тут явно не обойтись.

Я надеялся увидеть хотя бы кастомные настройки для proguard или что то в этом духе.

Установка минификации в gradle конфигурации является чем то обыденным для релиза.

Обработка нажатия через OnTouchListener? Серьезно?

Только полноправные пользователи могут оставлять комментарии. , пожалуйста.