Комментарии 12
я правильно вас понял что увеличение размера apk файла на 105 Кб вы воспринимаете как "шеф, всё пропало"? а вы могли бы пойти работать в сбербанк? их приложение пухнет безостановочно, когда доросло до 2,5 Гб и я пожаловался в СБ они просто сказали переустановить приложение ) (да, я знаю что это не apk а кеш программы, но и 2,5Гб данных для работы им не нужно это точно)
Здесь имеется в виду именно размер загружаемого из google play apk(download size), поэтому 105Кб в течении 3ч. это значимая цифра, так как apk обычно все ресурсы хранит оптимально(помимо не компилируемых ресурсов). Насчет контроля размера кэша приложения, я думаю мало кто об этом заботится, и сомневаюсь о реализуемости, даже если реализуемо, то стоит ли оно того. Зачастую это решается простой очисткой кэша.
поэтому 105Кб в течении 3ч. это значимая цифра
что значит "в течение 3ч"?
Зачастую это решается простой очисткой кэша
Вы предлагаете пользователю следить за размером кеша и чистить его самостоятельно? А разработчики софта не могут написать одну строчку if(cache.size>1M) cache.flush при старте программы?
Это же паттерн "Барахольщик": - а давай выкинем старье с балкона? - нет, вдруг там что-то ценное или пригодится! И в результате проще устроить капремонт (сбросить весь кэш), чем разбираться, что нужное, а что нет.
что значит "в течение 3ч"?
Это примерный промежуток времени(3 часа), для проверки размера, у каждого может быть свое, но суть в том, что для изменении произошедших в течении последних 3 часов - 105Кб это значительное изменение. Значение промежутка времени и значение лимита для размера можете задавать сами. В нашем случае, мы проверяем размер каждые 3 часа, с лимитом 75Кб(для примера).
Вы предлагаете пользователю следить за размером кеша и чистить его самостоятельно? А разработчики софта не могут написать одну строчку if(cache.size>1M) cache.flush при старте программы?
Думаю это не так просто будет реализовать, так как в кэше могут храниться и важная информация, которую лучше не стоит очищать. А выборочное удаление - это уже другая задача. Но я согласен, что потребление такого большого места в памяти банковских приложений, может быть неоправдано. Но опять же, тяжело сказать как они именно используют память внутри. Кэш приложения это отдельная тема и заслуживает отдельной статьи думаю.
105Кб это значительное изменение
почему?
Думаю это не так просто будет реализовать, так как в кэше могут храниться и важная информация, которую лучше не стоит очищать
учитывая что мне предлагают его очистить без опасений уверен что там нет ничего ценного, по всяком случае для СБ.
почему?
относительно значительное*
Например в играх такое значение не существенно.
если вопрос, почему у нас в приложений это так, то лимит в 75Kb мы определили на начальном этапе. Приложение доставки еды, обычно не требует колоссальных ресурсов, да и нужно постараться превысить лимит за такой короткий срок. Этот лимит не говорит, что "Тревога! Все пропало!", а лишь сигнализирует, что где-то не хватает оптимизаций, и дает знать что и как было изменено.
Пардон, но на вопрос вы не ответили. Для меня, как программиста, но далёкого от андроида, увеличение apk файла на 105 Кб не является существенным, так как это может быть проблема например самого apk (или точно-точно не может и вы в этом уверены?), так и например обновлённые рисунки и даже если код, то вероятно для этого была необходимость. Мне тут не ясно как пересборка релиза вдруг приводит к увеличению apk?
Извиняюсь, видимо я неправильно понял ваш вопрос.
как пересборка релиза вдруг приводит к увеличению apk?
Тут имеется в виду, что мы пересобираем релизный apk каждые 3 часа именно в development ветке. Зачем нам это надо? - так как все изменения, сделанные разработчиками вливается в development, впоследствии создаются релизные ветки от development, собирается релизный апк и загружается в play store. Предположим в команде 5 андроид разработчиков, за 3 часа, так или иначе, кто-то из них замержат свои PR девелопмент. И как раз наш flow будет проверять как изменения произошедшие за последние 3 часа, повлияли на размер.
например обновлённые рисунки и даже если код, то вероятно для этого была необходимость
Согласен, этим обычно занимаются feature команды, они добавляют новые фичи регулярно. И поэтому нам нужна примерная видимость, как их изменения влияют на размер, так как зачастую на code review, тяжело точно предугадать как именно изменения в коде, могут повлиять на размер. К примеру, кто-то обновил версию библиотеки(в андроиде это делается одной строчкой кода, просто цифру поменять, простой пример*), но эта новая версия библиотеки, оказывается за собой тянет новые ресурсы, которые будут добавлены в apk, и размер будет значительно увеличен. И здесь наш flow поможет понять что произошла непредвиденная регрессия размера и укажет что послужило причиной. И как только мы это видим, мы смотрим, можно ли эти изменения как-то оптимизировать, в контексте размера. В упомянутом примере, мы можем вместо простого обновления версии библиотеки - обновить версию, но при этом сделать exclude некоторых ненужных ресурсов этой версии, то есть убрать ненужные зависимости. Что позволит уменьшить регрессию.
Еще один пример: у нас был случай, когда один разработчик перед релизом, замержил PR, в котором он добавил gif анимацию, которая весила 8мб, что послучило блокером для релиза. И как только наш flow это увидел, мы посоветовали вместо gif использовать lottie animation файлы(оптимизирован в размере, при этом сохраняет качество)
увеличение apk файла на 105 Кб не является существенным
Предположим у вас уже установлена apk, который весит 20mb, вы обновляете на новую версию и теперь он весит 20.1mb(+100kb). В сравнении 2х разных версии apk, эти изменения не значительны, согласен. Обычно, компаний релизят новую версию своего приложения каждые 2 недели, или может месяца, у кого как.
Как упомянуто выше, мы проверяем размер каждые 3 часа, представьте что каждые 3 часа, размер будет увеличиваться на эти 100kb, и в конечном итоге, ко времени релиза, размер уже будет значительно увеличен не так ли? В реальности, такого не произойдет(по крайней мере, редко), но регулярное увеличение размера между релизами будет происходить и наша задача сделать видимым эти изменения и где мы можем, оптимизировать.
За исключением тех изменений, в которых мы ничего не можем оптимизировать и нам ничего не остается, как согласиться с таким увеличением.
спасибо за ответ, но я пока не увидел откуда появляется предположение (уверенность?) что если сейчас у вас увеличение на 105кб то так будет происходить каждые 3 часа? откуда появляется такая тенденция? мне кажется нет предпосылок к такому поведению. я не преуменьшаю вашу работу и выводы, просто я не в теме наверное, но я не прослеживаю зависимости в ваших предположениях.
откуда появляется предположение (уверенность?) что если сейчас у вас увеличение на 105кб то так будет происходить каждые 3 часа? откуда появляется такая тенденция?
Тенденции нет, это лишь один из худших вариантов событии, такое возможно очень редко, но возможно в большой команде.
Если вопрос в том, почему 105кб это много для андроид приложения, то можно прочитать про структуру apk в официальной документации от гугла. Но суть в том, что большинство ресурсов в андроиде оптимизируются для компоновки в apk. Код который пишется, компилируется в dex файл, есть компилируемые ресурсы(xml), некомпилируемые ресурсы(jpg, png, gif). К примеру, превысить лимит в 100кб очень легко, если добавить картинки png или jpeg, и решением для андроида является использование webp изображений, которые сохраняют качество изображения, уменьшая размер файла в 70-80%. И в основном, в андроиде, такие статические изображения используются редко, так как чаще используется динамическая загрузка изображений, который загружает и кэширует, когда надо. А в остальном, используется векторная графика, которая весит очень мало.
ps: если я правильно понял вопрос
Тенденции нет, это лишь один из худших вариантов событии, такое возможно очень редко, но возможно в большой команде.
Тогда, всё же, акцент должен быть не на размере файла, а на шагах по отслеживанию релизов. В общем тема исчерпана, основное я понял, но мне кажется в статье несколько неверное расставлены акценты и для такого как я - непосвящённого в премудрости андроида - это звучит странно.
Спасибо за материал, было интересно узнать новое.
Размер имеет значение! Часть 1