3

Есть новостной агрегатор. Статьи грузятся из сети, и хранятся в локальной SQLite. UI организован стандартно: RecyclerView, элементами которого являются превью статей.

Вопрос следующий: как оптимально организовать подгрузку данных в RecyclerView из SQLite, если на экране помещается ≈ 3 элемента?

Поясню: в данном вопросе временем загрузки статей из сети, их размещением в БД и временем преобразования статей в превью пренебрегаем. Интересует механизм подгрузки элементов в RecyclerView за один запрос и организация этой подгрузки. Стандартный механизм (загружаем сколько-то элементов -> пользователь прокручивает список до конца -> загружаем новую порцию элементов) не подходит.

Например, возможно стоит ловить скроллинг на середине списка и уже тогда начинать подгрузку новых данных? Кроме того, возможно у уважаемого сообщества есть опыт о том, какое количество элементов из SQLite оптимально забирать за один запрос? Т.к. есть подозрение, что загрузка 3 элементов из SQLite будет примерно равна по времени загрузке 30 элементов, т.к. большая часть времени тратится на саму транзакцию, но уже скажем запрашивать 300 элементов за запрос будет неоптимально.

Aliaksei
  • 483
  • 3
    за один запрос нужно "забирать" все нужные данные, нет никакого смысла делить их на маленькие части. Такое применимо к сетевым запросам, но никак не к локальным БД. Cursor сам подгрузит что надо, в нужном ему количестве, насколько мне помниться. В любом случае не стоит делать из этого проблему – pavlofff Dec 14 '17 at 21:22
  • вы как-то сильно заморачиваетесь. последний пиксель или самсунг вам за секунду загрузит с базы овер9000 элементов. дешевенький мейзу начнет пыхтеть уже на пяти – Sviat Volkov Dec 14 '17 at 21:22
  • 3
    все эти "подгрузить еще" были придуманы ради экономии трафика сети. локально грузите сразу всё – Sviat Volkov Dec 14 '17 at 21:24
  • @SviatVolkov и @pavloff в целом согласен с вами, действительно немного заморачиваюсь и именно для оптимизации на маломощных устройствах. С тем, чтобы грузить "все нужные данные", а не порциями, не согласен. Т.к. даже если устройство мощное, то как минимум нужно смотреть размер этих данных. У SQLiteCursor есть буфер CursorWindow, размером около 2 MB. И если ваш запрос вытаскивает > 2 MB, уже будут относительно большие накладные расходы по времени со стороны SQLiteCursor. – Aliaksei Dec 15 '17 at 10:35
  • О проблемах производительности с SQLiteCursor при больших запросах см. в этой статье – Aliaksei Dec 15 '17 at 10:43

2 Answers2

4

@pavloff, конечно все верно расписал:

за один запрос нужно "забирать" все нужные данные, нет никакого смысла делить их на маленькие части. Такое применимо к сетевым запросам, но никак не к локальным БД. Cursor сам подгрузит что надо, в нужном ему количестве, насколько мне помниться. В любом случае не стоит делать из этого проблем

Но проблема в том, что RecyclerView из коробки не умеет поддерживать адаптер с курсором, то есть надо самому заморачиваться с изобретением адаптера, который будет читать из БД или же придумывать адаптер, который работает поверх Cursor, по аналогии с CursorAdapter, который имеется в комплекте ListView.

К счастью умные люди уже все написали все. Возьмите RecyclerViewCursorAdapter - подайте ему на вход заранее подготовленный Cursor и будет вам счастье

Barmaley
  • 81,300
1

Разобрался в проблеме. Представлю свой ответ.

Во-первых, почему для достаточно больших списков не стоит загружать сразу все данные для RecyclerView из SQLite:

  1. Нет смысла грузить данные, которые пользователь, возможно, не увидит.
  2. Если при той же отзывчивости интерфейса (без тормозов), мы можем обеспечить плавную подгрузку данных и, при этом, наше приложение будет кушать меньше памяти, то почему бы не сделать так?
  3. Использование SQLiteCursor имеет ту особенность, что при выборке данных размером больше 2 MB появляются дополнительные расходы по времени на выборку каждых следующих 2 MB данных. Речь о том, что размер используемого SQLiteCursor буфера строк (CursorWindow) около 2 MB. Более подробно об этой проблеме см. в этой статье: оригинал (en) и перевод на русский.

Существуют решения по плавной подгрузке данных в RecyclerView из SQLite: см., например, этот цикл статей (en).

Есть данные, что оптимально загружать за один раз не менее чем в 10 раз больше элементов RecyclerView, чем помещается на экране. Т.е., если на экране 3 элемента, подгружаем за один раз около 30. Подгрузку следующей порции данных, следует начинать на половине или 2/3 скроллинга до конца списка. Это общие советы, т.к. стоит учитывать размер данных, возможное их преобразование в POJO-объекты для списка, особенности реализации RecyclerView.

Наконец, есть библиотека от Google Paging Library (еще не вышла в релиз 1.0), которая призвана в том числе решать проблему, затронутую в вопросе.

Еще один пример, реализация подгрузки c использованием RxJava (1 часть, 2 часть).

Aliaksei
  • 483
  • 1
    я понял то, что хотя CursorWindow и имеет некоторые недостатки в алгоритме, все же он справится с задачей подгрузки данных лучше, чем вы будете писать свой алгоритм подгрузки "порциями" (не говоря уже о том, что и вам не удастся избежать 90% проблем CursorWindow, перечисленных в статье или предется писать очень сложный буфер, который будет давать очень малое преимущество в скорости, так как подавляющее большинство современных устройств достаточно мощные для таких задач). В общем, я по прежнему уверен, что "заморачиваться" подгрузкой данных при работе SQLite нет никакого практического смысла. – pavlofff Dec 18 '17 at 00:20
  • 1
    про PagingLibrary как то упустил, посмотрю на досуге. Так же стоит заметить, что большинство проблем из статьи решается использованием CursorLoader (фоновая подгрузка и менеджмент курсора). Поставлю плюс, за проделанную работу, которая содержит много полезной информации, хотя с выводами я не согласен – pavlofff Dec 18 '17 at 00:48
  • 1
    Если говрить о связке SQLite и POJO, то есть все резоны отказаться от этой связки и использовать nosql БД Realm или ObjectBox (для более простых задач) или тот же ORM Room, который сейчас активно двигает Google (хотя он и сущестаенно проигрывает nosql решениям в скорости) , хотя учитывая ваше стремление к "экономии на спичках" они могут вас и не устроить (по факту преобразования реляционной структуры в POJO "в ручную" отнимут брльше ресурса, чем низкоуровневые реализации в nosql БД). – pavlofff Dec 18 '17 at 00:51
  • За советы благодарю. Переписывать SQLiteCursor, конечно, не собираюсь. Вы правы, по поводу Realm, как раз рассматриваю эту ORM, как замену SQLite на будущее. По поводу CursorLoader, видел в связке с ContentProvider - действительно удобно, но по скорости не выигрывает. Paging Library Google как раз совместно с Room и продвигает в массы. – Aliaksei Dec 20 '17 at 13:04