Кэширование данных android studio

Стратегия кеширования в приложении

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

Обычно люди сходу начинают предлагать готовые реализации кеша, вроде memcached или HTTP-кеша, но это лишь ответ на вопрос где кешировать.

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

Зачем нужен кеш

Кеш приближает данные к месту их использования. В современном мире, состоящим на 98% из интернета, данные обычно лежат очень далеко от пользователя. На всем пути от хранилища к пользователю есть кеши, которые служат только одной цели – чтобы пользователь как можно быстрее получил свои данные.

Если рассмотреть внимательнее, то видно, что драгоценное время тратится на обработку данных в поставщике и передачу данных от поставщика клиенту, время обработки данных на клиенте тут не учитываем.

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

Кеш нельзя просто включить

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

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

Очень важно понимать что и как вы собираетесь кешировать, чтобы не нарушать логику работы приложения. И первый вопрос, на который вам необходимо ответить – насколько устаревшие данные можно отдавать клиенту. Естественно можно сделать свой кеш для каждого клиента, это упростит решение вопроса об актуальности данных, но принесет много других проблем.

Типы кеширования

Есть три основных типа кеширования по механике работы:

• Lazy cache, он же ленивый кеш, он же тупой кеш – самый простой в реализации тип кеширования, зачастую встроен в фреймворки. Кеш просто сохраняет данные и отдает их пока не устареет.
• Synchronized cache, синхронизированный кеш – клиент вместе с данными получается метку последнего изменения и может спросить у поставщика не изменились ли данные, чтобы повторно из не запрашивать. Такой тип кеширования позволяет всегда иметь свежие данные, но очень сложен в реализации.
• Write-through cache, или кеш сквозной записи – любое изменение данных выполняется сразу в хранилище и в кеше. Этот тип кеша может никогда не устаревать, но возникают проблемы с так называемой “когерентностью”.

Наверное можно придумать и другие типы кешей, но я не встречал.

Устаревание и когерентность кеша

Объем кеша всегда ограничен. Зачастую он меньше объема данных, которые в этот кеш можно положить. Поэтому элементы, помещенные в кеш, рано или поздно будут вытеснены. Современные фреймворки для кеширования позволяют очень гибко управлять устареванием, учитывая приоритеты, время устаревания, объемы данных итд.

Если одни и те же данные попадают в разные кеши, то возникает проблема когерентности кеша. Например одни и те же данные используются для формирования разных страниц и кешируются страницы. Страницы сформированные позже будут содержать обновленные данные, а страницы, закешированные раньше, будут содержать устаревшие данные. Таким образом будет нарушена согласованность поведения.

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

Эффективность кеша

Основной параметр, который характеризует систему кеширования – это процент попаданий запросов в кеш. Этот параметр довольно легко измерить, чтобы понять насколько ваша система кеширования эффективна.

Частые сбросы кеша, кеширование редко запрашиваемых данных, недостаточный объем кеша – все это ведет к пустой трате оперативной (обычно) памяти, не повышая эффективность работы.

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

Применение разных типов кеширования

Ленивый кеш

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

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

Такой тип кеширования позволит быстрее всех дать ответ.

Синхронизированный кеш

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

Такой тип кеширования встроен в протокол HTTP. Сервер отдает метку изменения, а клиент кеширует у тебя результат и в последующем запросе передает эту метку. Сервер может дать ответ, что состояние не изменилось и можно использовать кешированный на клиенте объект. Сервер в свою очередь, получив метку может переспросить у хранилища были ли изменения или нет.

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

Кеш сквозной записи

Если есть система распределенного кеширования (memcached, Windows Sever App Fabric, Azure Cache), то можно использовать кеш сквозной записи. Рукопашная реализация синхронизации кешей между узлами сама по себе отдельный большой проект, потому не стоит заниматься ей в рамках разработки приложения.

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

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

Что еще нужно учитывать в стратегии кеширования

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

Кешируйте данные как можно позже, непосредственно перед отдачей во внешнюю систему. Кешировать данные, полученные извне, необходимо только в случае проблем с производительностью на этом этапе. Внешние хранилища, такие как СУБД и файловые системы, сами реализуют кеширование, поэтому обычно нет смысла кешировать результаты запросов.

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

Источник

How to Cache Fragments in Android

Andy Trevorah

How to Cache Fragments in Android

If you have an Android app with multiple fragments that are unable save state (e.g they have a WebView), it can be a real drag to your users when state is lost when navigating around your app.

To fix this, we can cache the fragments that your user has visited by using some features of the FragmentManager.

0: Creating a Master-Detail app

For this, we can use a the built-in Master-Detail template. We’ll be using the app on a tablet device but only because the app template doesn’t use fragments on mobile. We’ll also have to make a few modifications to swap the default TextView with a WebView:

• The item_detail.xml layout needs to have a WebView:

• The ItemDetailFragment.java needs to load a long page into the WebView and to store the root view as a field:

• The AndroidManifest.xml needs to request permission to load our wikipedia page:

1. Enabling the fragment back-stack

You may notice that after navigating around, the back button just quits the app. This is because the back stack only deals with activities and not their inner fragments. But we can enable the fragment manager’s own fragment back-stack.

First we need to find where our fragments are being created (this is a little bit simplified):

. then get add the fragment to the back-stack with .addToBackStack(null) .

. before finally overriding our back button to pop off the fragment back-stack if it has any entries.

2. Using the back-stack as a cache

Here is where we take advantage of our fragment back-stack. Android already has all of our fragments cached in the stack, its just that they are only being reused when hitting the back button.

What we can do is when a user selects an item in our list, we can check if that fragment already exists in our back-stack (with FragmentManager.findFragmentByTag(tag) ) and reuse it. This requires us to add a unique tag when the fragment is about to be committed in our .replace() call:

The beauty of this technique is that we are using Android’s fragments api in a straightforward way, and so we don’t have to second-guess any memory management in the background.

Источник

Русские Блоги

Механизм кэширования Android — общая реализация хранилища

Один, механизм кеширования Android

Кэш Android разделен на кеш памяти и файловый кеш (дисковый кеш). В первые дни, до того, как стали популярными основные фреймворки кэширования изображений, наиболее часто используемыми методами кэширования памяти были SoftReference и WeakReference.Например, большинство методов использования: HashMap > imageCache; форма. Начиная с Android 2.3 (уровень 9), сборщик мусора более склонен к повторному использованию объектов SoftReference или WeakReference, что делает SoftReference и WeakReference менее практичными и эффективными. В то же время после Android 3.0 (уровень 11) Bitmap данных изображения помещается в область кучи памяти, а память в области кучи управляется сборщиком мусора, и разработчику не нужно освобождать ресурсы изображения, но это также делает Выпуск данных изображения непредсказуем, что увеличивает вероятность OOM. Поэтому после Android 3.1 в Android появился класс кэша памяти LruCache, и на объекты в LruCache имеются сильные ссылки.

Во-вторых, рабочий механизм вторичного кеша

Так называемый кеш второго уровня на самом деле не сложен.Когда стороне Android требуется получить данные, например получить изображения из сети, мы сначала ищем в памяти (поиск по ключу), а затем ищем файл на диске или sqlite, если в памяти ничего нет. Он недоступен на диске, пока не будет получен через сеть; когда данные из сети получены, они сначала кэшируются в памяти (кеш первого уровня) в виде пар ключ-значение, и в то же время кешируются в файле или sqlite (кеш второго уровня). Примечание. Кэш памяти вызовет утечку памяти в виде кучи. Все кеши уровня 1 обычно должны строго контролировать размер кеша, обычно контролируемый на 1/4 системной памяти.

Три, автономный кеш

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

Наши приложения обычно генерируют следующие типы данных:

файл — обычное файловое хранилище
файл базы данных (файл .db)
sharedPreference- данные конфигурации (файл .xml)
файл кэша изображений

Все пути к данным в приложении:

/data/data/com.xxx.xxx/cache-in-app cache (Примечание: соответствующий метод getCacheDir ())
/data/data/com.xxx.xxx/databases-in-app база данных
/data/data/com.xxx.xxx/shared_prefs-in-app файл конфигурации
/data/data/com.xxx.xxx/files-In-app files (Примечание: соответствующий метод getFilesDir ())
Файл SD-карты (разработан индивидуально)

Независимо от того, внутренняя это или внешняя SD-карта, способ получения пути один и тот же:

Получите корневой каталог SD-карты: Environment.getExternalStorageDirectory (). GetAbsolutePath ();
Путь к внешнему кэшу: /mnt/sdcard/android/data/com.xxx.xxx/cache Общее хранилище данных кеша (Примечание: получено с помощью getExternalCacheDir ())
Путь к внешнему файлу: /mnt/sdcard/android/data/com.xxx.xxx/files Хранить долгоживущие данные (Примечание: полученные с помощью getExternalFilesDir (тип String), тип специфичен Тип, может быть любым из следующих
Environment.DIRECTORY_MUSIC, Environment.DIRECTORY_PODCASTS, Environment.DIRECTORY_RINGTONES, Environment.DIRECTORY_ALARMS, Environment.DIRECTORY_NOTIFICATIONS, Environment.DIRECTORY_PICTURES, or Environment.DIRECTORY_MOVIES. ）

В-четвертых, обычно используемое хранилище Android:

Пять основных методов хранения данных на платформе Android:

1 Используйте SharedPreferences для хранения данных

2 Данные для хранения файлов

3 База данных SQLite для хранения данных

4 Используйте ContentProvider для хранения данных

5 Данные сетевого хранилища

Следующее знакомит с использованием первых двух, база данных может использовать библиотеку более удобно, например: greenDao; другие, но не слишком много введения. В основном ввести кеш.

(1) Подробное объяснение SharedPreferences

Шаги по использованию SharedPreferences для сохранения пар ключ-значение обычно следующие:
Используйте метод getSharedPreferences класса Activity, чтобы получить объект SharedPreferences, укажите имя файла и права доступа
Получите объект SharedPreferences.Editor и используйте метод putXxx объекта для сохранения пары «ключ-значение».
Сохранение (отправка) пар «ключ-значение» с помощью метода фиксации SharedPreferences.Editor.

(1) Два способа получить SharedPreferences:

1 Вызовите метод getSharedPreferences () объекта Context
2 Вызовите метод getPreferences () объекта Activity.

(2) Разница между двумя методами:

Объект SharedPreferences, полученный путем вызова метода getSharedPreferences () объекта Context, может использоваться другими приложениями в том же приложении.Компонентыобщий.

Объект SharedPreferences, полученный путем вызова метода getPreferences () объекта Activity, может использоваться только в Activity.

(3) Четыре режима работы SharedPreferences:

Context.MODE_PRIVATE: это режим работы по умолчанию, что означает, что файл является личными данными и может быть доступен только самому приложению. В этом режиме записанное содержимое будет перезаписывать содержимое исходного файла.

Context.MODE_APPEND: режим проверит, существует ли файл, добавит содержимое в файл, если он существует, или создаст новый файл.

Context.MODE_WORLD_READABLE и Context.MODE_WORLD_WRITEABLE используются, чтобы контролировать, есть ли у других приложений разрешение на чтение и запись файла.

MODE_WORLD_READABLE: указывает, что текущий файл может быть прочитан другими приложениями.

MODE_WORLD_WRITEABLE: указывает, что текущий файл может быть записан другими приложениями.

(4) Сохраните данные в SharedPreferences:

Или следующее письмо также может быть

(5) Получите данные из SharedPreferences:

(2) Подробное описание хранилища файлов (Файл)

Файловое хранилище — это самый простой способ хранения данных в Android. Он не форматирует сохраненный контент, и все данные сохраняются в файле без изменений. Он больше подходит для хранения простых текстовых или двоичных данных. Если вы хотите использовать метод хранения файлов для сохранения некоторых более сложных текстовых данных, вам необходимо определить набор собственных спецификаций формата, чтобы облегчить повторный анализ файла позже.

(1) Методы хранения файлов, предоставляемые Context (openFileOutput, openFileInput)

• Предоставляется в классе ContextopenFileOutput()Метод, который можно использовать для хранения данных в указанном файле.
• Этот метод принимает два параметра. Первый параметр — это имя, используемое при создании файла. Обратите внимание, что указанное здесь имя файла не может включать путь, поскольку все файлы по умолчанию хранятся в / data / data / / files /. Под каталогом.
• Второй параметр — это режим работы файла.Есть два основных режима на выбор: MODE_PRIVATE (перезапись исходного текста) и MODE_APPEND (дополнительный контент).
• Метод openFileOutput () возвращает объект FileOutputStream.После получения этого объекта вы можете записывать данные в файл в потоке Java.

(I) Сохраните фрагмент текстового содержимого в файл:

Примечание. По умолчанию файл будет храниться в / data / data / package / files;

Подобно хранению данных в файле, класс Context также предоставляетopenFileInput()Метод чтения данных из файла.

Метод openFileInput () получает только один параметр, то есть имя файла для чтения, и система автоматически перейдет в каталог / data / data /

/ files /, чтобы загрузить этот файл и вернуть объект FileInputStream.

(II) Покажите, как читать текстовые данные из файла:

(III) Четыре режима сохранения файлов.

Context.MODE_PRIVATE — это режим работы по умолчанию, что означает, что файл является личными данными и может быть доступен только самому приложению. Содержимое, записанное в этом режиме, перезапишет содержимое исходного файла.
Context.MODE_APPEND Проверьте, существует ли файл, и добавьте содержимое в файл, если он существует, в противном случае создайте новый файл.
MODE_WORLD_READABLE означает, что текущий файл может быть прочитан другими приложениями.
MODE_WORLD_WRITEABLE означает, что текущий файл может быть записан другими приложениями.

(2) Внутренняя память: файл общих операций потока ввода-вывода

Обратите внимание, что внутренняя память — это не память. Внутреннее хранилище находится в очень особенном месте в системе. Если вы хотите хранить файлы во внутреннем хранилище, по умолчанию файлы доступны только вашему приложению, и все файлы, созданные приложением, имеют то же имя, что и пакет приложения. Под содержимым. Другими словами, файлы, созданные приложением во внутренней памяти, связаны с этим приложением. При удалении приложения эти файлы во внутренней памяти также удаляются. С технической точки зрения, если вы устанавливаете атрибут файла для чтения при создании файла внутреннего хранилища, другие приложения могут получить доступ к данным вашего собственного приложения при условии, что он знает имя пакета вашего приложения, если атрибут файла является частным (частным ), то другие приложения не смогут получить к нему доступ, даже если вы знаете имя пакета. Внутреннее пространство для хранения очень ограничено, поэтому оно очень ценно. Кроме того, оно также является основным местом хранения данных для самой системы и системных приложений. Когда внутреннее пространство для хранения исчерпано, телефоном нельзя пользоваться. Таким образом, мы должны стараться избегать использования внутренней памяти. Общие настройки и базы данных SQLite хранятся во внутренней памяти. Внутреннее хранилище обычно использует контекст для получения и работы.

getFilesDir()Получите внутреннее хранилище вашего приложения, которое эквивалентно корневому каталогу вашего приложения во внутреннем хранилище.

После установки приложения / data / data / packagename будет сгенерирован в корневом каталоге Android, и текущему приложению не требуются разрешения на чтение и запись для чтения.

нота:
Некоторые разработчики, возможно, видели корневой каталог приложения / data / user / 0 / packagename, вот объяснение, версия Android 4.2 добавляет функцию входа в систему для разных пользователей на одном устройстве. (По причинам, связанным с патентом, эта функция ограничена планшетами, мобильные телефоны не поддерживают эту функцию), поэтому, чтобы различать настройки и сохраненные данные разных пользователей в одном приложении, добавляется путь этой серии, который указывает на / data / data / packagename

• Метод getFileDir () получает объект File папки с файлами в каталоге.
• Метод getChacheDir () получает объект File из папки кеша в этом каталоге.
• Вызов метода openFileOutput (String name, int mode) ContextWrapper напрямую также создаст соответствующий файл в папке файлов в этом каталоге, и он будет частным. Его можно изменить, чтобы он был доступен другим приложениям, с помощью параметра режима метода openFileOutput для завершения

нота:

Этот каталог можно просмотреть только с правами root и будет удален при удалении приложения.

Очистка данных в деталях приложения приведет к удалению всех данных под именем пакета и всего каталога / Android / data / packagename во внутреннем хранилище и на внешней SD-карте.

Очистка кеша в деталях приложения приведет к удалению всех данных в каталоге packagename / cache и всего каталога / Android / data / packagename / cache во внутренней памяти и на внешней памяти SD-карты.

Если вы хотите создать файл, выполните следующие действия.

Android также предоставляет нам простой способopenFileOutput()`Для чтения и записи файлов во внутренней памяти ниже приведен пример записи текста в файл: (см. Выше)

Некоторые другие операции с внутренней памятью:

A. Перечислите все созданные файлы, это может быть непросто, Context Есть такой способ.

Б. Чтобы удалить файл, если вы можете его создать, вы должны иметь возможность удалить его. Конечно, он также предоставляет интерфейс для удаления файлов. Это также очень просто. Вам нужно только указать имя файла.

C. Чтобы создать каталог, вам необходимо передать имя каталога, и он возвращает файловый объект, используя путь к операции

Обобщая файловые операции, мы можем получить следующие три характеристики:

1. Файловым операциям нужно только предоставить функции имя файла, поэтому самой программе нужно только поддерживать имя файла;
2. Вам не нужно самостоятельно создавать файловые объекты и потоки ввода и вывода. Вы можете возвращать объекты File или потоки ввода и вывода, указав имя файла.
3. Все операции с путями возвращают файловые объекты.

(3) Внешнее хранилище: ввод-вывод (чтение и запись файлов на SD-карте)

Путь хранения собственного ПЗУ телефона

1. Метод getExternalCacheDir () для получения пути к каталогу / Android / data / packagename / cache на встроенной карте памяти, разрешения на чтение и запись не требуются после версии 4.4 и будут удалены по мере удаления приложения.
2. Метод getExternalFilesDir () получает путь к каталогу / Android / data / packagename / files на встроенной карте памяти. После версии 4.4 разрешения на чтение и запись не требуются и будут удалены по мере удаления приложения. Если параметр метода имеет значение «null», вложенная папка не указана. Если указано, создается вложенная папка для сохранения файла. Созданный файл может быть прочитан другими приложениями, если у него есть разрешения на чтение и запись. Если вы хотите сохранить его частным, используйте внутреннее хранилище.
3. Метод Environment.getExternalStorageDirectory () получает корневой каталог каталога встроенного хранилища. Требуются разрешения на чтение и запись, которые не будут удалены при удалении приложения.
4. Метод Environment.getExternalStoragePublicDirectory () получает общедоступный каталог с файлом определенного типа по корневому пути каталога встроенного хранилища. Требуются разрешения на чтение и запись, которые не будут удалены при удалении приложения.
5. Обратите внимание, что разрешения на чтение и запись для пути / Android / data / packagenaem / во встроенном хранилище различаются и требуют разных разрешений, поэтому при разработке всегда следует объявлять разрешения на чтение и запись.

Этапы чтения и записи выполняются следующим образом:

1. Вызовите метод getExternalStorageState () среды Environment, чтобы определить, вставлена ​​ли SD-карта в телефон и есть ли у приложения разрешение на чтение и запись на SD-карту. Следующий код вернет истину.

2. Вызовите метод Environment.getExternalStorageDirectory (), чтобы получить внешнее хранилище, которое является каталогом SD-карты, или используйте каталог «/ mnt / sdcard /».

3. Используйте поток ввода-вывода для работы с файлами на SD-карте.

Примечание. В мобильный телефон должна быть вставлена ​​SD-карта. Для симулятора вы можете создать виртуальную карту памяти с помощью команды mksdcard.
Разрешение на чтение и запись SD-карты должно быть настроено в AndroidManifest.xml.

(I) Функция операции записи файла

II) Функция чтения файла

Пять, обобщены некоторые коды использования:

Общее хранилище:
Небольшое тело данных, параметр, значение (хранится в shared_prefs)
сетевые данные json (данные такого типа обычно не большие, хранятся в файле (.txt и т. д.))
картинки, музыка, видео (рекомендуется хранить большие данные на SD-карте, изображения (кадры с кадрами))

Источник