откуда появляется предположение (уверенность?) что если сейчас у вас увеличение на 105кб то так будет происходить каждые 3 часа? откуда появляется такая тенденция?
Тенденции нет, это лишь один из худших вариантов событии, такое возможно очень редко, но возможно в большой команде.
Если вопрос в том, почему 105кб это много для андроид приложения, то можно прочитать про структуру apk в официальной документации от гугла. Но суть в том, что большинство ресурсов в андроиде оптимизируются для компоновки в apk. Код который пишется, компилируется в dex файл, есть компилируемые ресурсы(xml), некомпилируемые ресурсы(jpg, png, gif). К примеру, превысить лимит в 100кб очень легко, если добавить картинки png или jpeg, и решением для андроида является использование webp изображений, которые сохраняют качество изображения, уменьшая размер файла в 70-80%. И в основном, в андроиде, такие статические изображения используются редко, так как чаще используется динамическая загрузка изображений, который загружает и кэширует, когда надо. А в остальном, используется векторная графика, которая весит очень мало.
как пересборка релиза вдруг приводит к увеличению 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, и в конечном итоге, ко времени релиза, размер уже будет значительно увеличен не так ли? В реальности, такого не произойдет(по крайней мере, редко), но регулярное увеличение размера между релизами будет происходить и наша задача сделать видимым эти изменения и где мы можем, оптимизировать. За исключением тех изменений, в которых мы ничего не можем оптимизировать и нам ничего не остается, как согласиться с таким увеличением.
относительно значительное* Например в играх такое значение не существенно. если вопрос, почему у нас в приложений это так, то лимит в 75Kb мы определили на начальном этапе. Приложение доставки еды, обычно не требует колоссальных ресурсов, да и нужно постараться превысить лимит за такой короткий срок. Этот лимит не говорит, что "Тревога! Все пропало!", а лишь сигнализирует, что где-то не хватает оптимизаций, и дает знать что и как было изменено.
Это примерный промежуток времени(3 часа), для проверки размера, у каждого может быть свое, но суть в том, что для изменении произошедших в течении последних 3 часов - 105Кб это значительное изменение. Значение промежутка времени и значение лимита для размера можете задавать сами. В нашем случае, мы проверяем размер каждые 3 часа, с лимитом 75Кб(для примера).
Вы предлагаете пользователю следить за размером кеша и чистить его самостоятельно? А разработчики софта не могут написать одну строчку if(cache.size>1M) cache.flush при старте программы?
Думаю это не так просто будет реализовать, так как в кэше могут храниться и важная информация, которую лучше не стоит очищать. А выборочное удаление - это уже другая задача. Но я согласен, что потребление такого большого места в памяти банковских приложений, может быть неоправдано. Но опять же, тяжело сказать как они именно используют память внутри. Кэш приложения это отдельная тема и заслуживает отдельной статьи думаю.
Здесь имеется в виду именно размер загружаемого из google play apk(download size), поэтому 105Кб в течении 3ч. это значимая цифра, так как apk обычно все ресурсы хранит оптимально(помимо не компилируемых ресурсов). Насчет контроля размера кэша приложения, я думаю мало кто об этом заботится, и сомневаюсь о реализуемости, даже если реализуемо, то стоит ли оно того. Зачастую это решается простой очисткой кэша.
Информация
В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность
Специализация
Mobile Application Developer, Application Developer
Тенденции нет, это лишь один из худших вариантов событии, такое возможно очень редко, но возможно в большой команде.
Если вопрос в том, почему 105кб это много для андроид приложения, то можно прочитать про структуру apk в официальной документации от гугла. Но суть в том, что большинство ресурсов в андроиде оптимизируются для компоновки в apk. Код который пишется, компилируется в dex файл, есть компилируемые ресурсы(xml), некомпилируемые ресурсы(jpg, png, gif). К примеру, превысить лимит в 100кб очень легко, если добавить картинки png или jpeg, и решением для андроида является использование webp изображений, которые сохраняют качество изображения, уменьшая размер файла в 70-80%. И в основном, в андроиде, такие статические изображения используются редко, так как чаще используется динамическая загрузка изображений, который загружает и кэширует, когда надо. А в остальном, используется векторная графика, которая весит очень мало.
ps: если я правильно понял вопрос
Извиняюсь, видимо я неправильно понял ваш вопрос.
Тут имеется в виду, что мы пересобираем релизный 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, который весит 20mb, вы обновляете на новую версию и теперь он весит 20.1mb(+100kb). В сравнении 2х разных версии apk, эти изменения не значительны, согласен. Обычно, компаний релизят новую версию своего приложения каждые 2 недели, или может месяца, у кого как.
Как упомянуто выше, мы проверяем размер каждые 3 часа, представьте что каждые 3 часа, размер будет увеличиваться на эти 100kb, и в конечном итоге, ко времени релиза, размер уже будет значительно увеличен не так ли? В реальности, такого не произойдет(по крайней мере, редко), но регулярное увеличение размера между релизами будет происходить и наша задача сделать видимым эти изменения и где мы можем, оптимизировать.
За исключением тех изменений, в которых мы ничего не можем оптимизировать и нам ничего не остается, как согласиться с таким увеличением.
относительно значительное*
Например в играх такое значение не существенно.
если вопрос, почему у нас в приложений это так, то лимит в 75Kb мы определили на начальном этапе. Приложение доставки еды, обычно не требует колоссальных ресурсов, да и нужно постараться превысить лимит за такой короткий срок. Этот лимит не говорит, что "Тревога! Все пропало!", а лишь сигнализирует, что где-то не хватает оптимизаций, и дает знать что и как было изменено.
Это примерный промежуток времени(3 часа), для проверки размера, у каждого может быть свое, но суть в том, что для изменении произошедших в течении последних 3 часов - 105Кб это значительное изменение. Значение промежутка времени и значение лимита для размера можете задавать сами. В нашем случае, мы проверяем размер каждые 3 часа, с лимитом 75Кб(для примера).
Думаю это не так просто будет реализовать, так как в кэше могут храниться и важная информация, которую лучше не стоит очищать. А выборочное удаление - это уже другая задача. Но я согласен, что потребление такого большого места в памяти банковских приложений, может быть неоправдано. Но опять же, тяжело сказать как они именно используют память внутри. Кэш приложения это отдельная тема и заслуживает отдельной статьи думаю.
Здесь имеется в виду именно размер загружаемого из google play apk(download size), поэтому 105Кб в течении 3ч. это значимая цифра, так как apk обычно все ресурсы хранит оптимально(помимо не компилируемых ресурсов). Насчет контроля размера кэша приложения, я думаю мало кто об этом заботится, и сомневаюсь о реализуемости, даже если реализуемо, то стоит ли оно того. Зачастую это решается простой очисткой кэша.