2012-04-29 2 views
9

Я работаю над проектом, который требует хранения растровых изображений на столе. Эти растровые изображения используются в адаптерах данных для отображения в списках. Эта таблица может содержать более 1000 изображений. Причина, по которой я сейчас не сохраняю файл, связана с тем, насколько быстро я могу читать и записывать изображения в db.Как курсор SQLite работает внутри?

В основном я ищу, чтобы понять ограничения курсора SQLite. Как курсор загружается в память? Поместит ли он результаты запроса в память или создает ли какой-либо тип файла чтения/записи temp? Я не хочу сталкиваться с проблемами, когда запрос больших наборов данных приводит к тому, что у устройства заканчивается память.

+0

Существует [CursorWindow] (http://developer.android.com/reference/android/database/CursorWindow.html), и он, кажется, используется для загрузки только частей запроса всякий раз, когда вы перемещаетеToXyz'. Данные должны поступать непосредственно из базы данных. – zapl

+0

«Я работаю над проектом, который требует хранения растровых изображений на столе». - ick. «Эта таблица может содержать более 1000 изображений». - больше. «Причина, по которой я в настоящее время не сохраняю файл, связана с тем, насколько быстро я могу читать и писать изображения в db». - по определению файл будет таким же быстрым или быстрым, поскольку SQLite должен хранить свои файлы в файле. – CommonsWare

+0

zapl спасибо за информацию. @CommonsWare Не уверен, что означает ick: P Я думаю, что кажется, что он должен быть быстрым или быстрым читать из файла, чем db. Я мало знаю о курсорах, кроме как их использовать ... но SQLite не оптимизирует, как вы читаете данные? Я имею в виду, что чтение данных изображения из файла несколько раз кажется намного медленнее, чем чтение их из курсора. – Jona

ответ

0

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

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

1

Если я помню, он сохранит, однако, много результатов, которые могут быть сохранены в памяти в памяти. Он должен оставаться ниже soft heap limit, как правило. Это консультативный лимит, поэтому он предпочтет преодолеть лимит, чем вернуть SQL_NOMEM.

Я не верю, что он записывает на диск какие-либо механизмы кэширования. Пока каждое изображение может поместиться в память, а они не в индексах, это не должно быть проблемой.

Я не программист для Android, для чего это стоит. Некоторые из этих вещей могли быть настроены.

В качестве фона sqlite_step является курсором в библиотеке по умолчанию. Я не знаю, если андроид реализовал свои собственные механизмы. Вы можете найти общую информацию на своей странице о dynamic memory allocation.

Смежные вопросы