Привет! Я Алёна, пишу про мобильные проекты со стороны Системного аналитика.
Сегодня хочу поговорить про кэши. Статья ориентирована на новичков системных аналитиков и написана в легкой форме
Что такое кэширование?
Кэширование - это сохранение данных в локальном хранилище (кэше) для быстрого их использования. Конкретно в статье рассмотрим кэширование ответов методов на мобильных устройствах.
Чем кэши помогут тебе?
Кэши помогут быстрее отображать пользователю информацию. Данные загружаются заранее и отображаются из кэша, что позволяет избежать загрузочных экранов, шиммеров и ошибок.
Также кэширование помогает посылать запросы к бэку только тогда, когда это действительно необходимо. А значит снизить нагрузку и чуть сэкономить мобильный интернет клиента.
Чем опасные неправильные кэши?
При неправильно настроенном кэшировании приложение будет показывать пользователю неактуальную информацию. В лучшем случае пользователь будет ругаться и перезагружать приложение, в случае хуже - волноваться, писать в поддержку и оставлять гневные отзывы.
Также при отсутствии кэширования можно отправить слишком много запросов к серверу, что увеличит нагрузку на него и время ответа.
Как подружиться с кэшами?
1) Помни про них
Перед отдачей тз в разработку обязательно проверяй, описал ли ты кэширование для всех методов. Если кэшировать не нужно, тоже укажи это.
~ Полезное:
Изучи, какие правила кэширования есть на текущем проекте. Приложение должно грузится быстро, или важнее получать актуальную информацию? Должно ли приложение работать оффлайн?
Если у вас есть шаблон требований, добавь туда пункт о кэшировании методов
При ревью задачек своих и коллег обращай внимание на кэширование: описано ли оно? Не противоречит ли кэширование бизнес требованиям? Указаны ли ситуации, когда надо обновить кэш?
Пример: пусть у тебя есть экран с информацией о тарифе клиента, и ты кэшируешь информацию до следующего захода в приложение. Но если пользователь купил новый тариф, тебе нужно:
Провести покупку
Вызвать метод с информацией о тарифе заново
Обновить кэш с информацией о тарифе
Иначе ты покажешь пользователю старую информацию, он будет волноваться и пойдет в КЦ - а это нам не надо :)
2) Изучи бизнес требования
Кэши не живут в вакууме, они привязаны к бизнес требованиям. Узнай у продакта:
Как часто будет обновляться информация?
Что влияет на изменение информации? Можем ли мы это отследить?
Какие риски, если мы покажем старую информацию?
Пример: пусть у тебя есть метод, который возвращает рейтинг клиента. Коллеги с бэка говорят, что расчет рейтинга происходит раз в день. Бизнесу ок, что рейтинг будет максимально обновляться раз в 2 дня. Тогда ты можешь кэшировать ответ метода на 24 часа.
И напротив - пусть у тебя есть метод, который возвращает информацию о тратах клиента. Для бизнеса важно, чтобы клиент сразу видел свои траты. Тут стоит вызывать метод при каждом открытии экрана, а не брать из кэша.
3) Изучи требования бэка
В идеальном мире мы хотим отображать клиенту самую свежую информацию. Но не всегда это рационально - иногда лучше потратить ресурсы на другое
Поэтому узнай у бэка, какую нагрузку они готовы выдержать. Как часто ты можешь вызывать метод? Есть ли способы получить ответ быстрее, не проводя расчетов на бэк (например, etag, если информация не менялась)?
~ Полезное:
Если ты хочешь использовать метод, который был реализован раннее, узнай о его кэшировании. Как часто оно происходит, в каких местах, на какой срок? Как часто происходят вызовы?
Если ты хочешь использовать метод, который был реализован раннее, зайди к бэку и уточни, ок ли им новые вызовы. Чтобы коллеги знали о твоей задаче и были готовы к возрастающей нагрузке (плюс коллеги могут посоветовать другой метод, который лучше закроет твою потребность).
Если требования к кэшированию не удается определить (новый функционал, новый бэк, не понятно, потребуются ли частные изменения), то можно сделать изменяемый кэш. Например, положить кол-во минут для кэша в конфиг. Когда потребуется кэшировать на большее/меньшее время, ты изменишь значение в конфиге и получишь требуемое.
4) Проверь дизайны на возможное использование кэша
Если для отображения элемента нужна информация с бэка, посоветуйся с дизайнерами. Либо тебе нужно состояние загрузки этого элемента (лоадеры, скелетоны), либо тебе нужно получать информацию заранее и брать из кэша.
Пример: пусть у тебя есть экран с подробным описанием отеля. Он открывается с экрана отеля. Тогда ты можешь подгрузить информацию для подробного описания на экране отеля, чтобы потом отобразить ее без лоадеров.
~ Полезное:
Если на экране несколько элементов, и какие-то можно взять из кэш, а для других нужно вызывать метод, то можно сделать шиммер для каждого такого элемента. И сразу показывать пользователю имеющуюся информацию, пока остальная загружается.
5) Что насчет Fallback cache?
Если необходимо вызывать метод каждый раз, кэширование все равно может быть полезным. Пусть запрос ответил ошибкой. Тогда без кэша тебе придется оставить клиента без информации. А с кэшом ты сможешь показать данные из последнего успешного ответа метода.
Иногда лучше показать старые данные, чем оставить клиента с "Упс, что-то пошло не так, попробуйте позже".
Пример: пусть есть мобильное приложение, где можно забронировать отель. Описание номеров меняется редко, поэтому можно закэшировать его и показать из кэша. А вот цены на номера меняются часто, плюс клиенты будут недовольны, если не смогут забронировать по указанной цене. Поэтому цены мы не кэшируем
Заключение
Правильная работа с кэшами позволяет сделать быстрое и красивое приложение, сэкономить ресурсы и порадовать разработчиков и QA :) Надеюсь, в статье ты найдешь полезные фишки и применишь их в работе.