2010-11-28 3 views
24

Приложение для Android работает с использованием базы данных SQLite, созданной на ПК пользователя и переданной на устройство. Все это работает, но я не ожидал количества пользователей, у которых было бы действительно огромное количество данных. В этих случаях пользовательский интерфейс очень медленный, так как он ожидает получения данных.Производительность Android SQLite с индексами

Я пробовал несколько трюков, которые я «уверен» ускорил бы, но ничто, кажется, не имеет заметного эффекта. Мои запросы почти все очень просты, обычно это один «col = val» для предложения WHERE и данные INTEGER в столбце. Поэтому я не могу много сделать с запросами.

Последнее, и я не являюсь экспертом SQL любыми способами, заключался в том, чтобы использовать команды «CREATE INDEX» на ПК, полагая, что эти индексы используются для ускорения поиска в базе данных. Индексы значительно увеличили размер файла базы данных, поэтому я был удивлен, что он, похоже, не влияет на скорость моего приложения! Экран, который занимал 8 секунд для заполнения без индексов, по-прежнему занимает около 8 секунд даже с ними. Я надеялся довести дело до половины этого.

Что мне интересно, если реализация SQLite на Android использует индексы базы данных вообще, или если я просто теряю пространство, создавая их. Кто-нибудь может ответить на это?

Кроме того, любые другие вещи, чтобы попытаться ускорить доступ?

(Для чего на абсолютной основе пользователям не на что жаловаться. У моего наихудшего пользователя до сих пор есть данные, которые генерируют 630 000 записей (15 таблиц), поэтому возможно только так много!)

Дуг Гордон GHCS Systems

+1

Опубликовать некоторые медленные запросы, а также определения таблиц и определения индексов – Mikpa 2010-11-28 21:17:41

ответ

4

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

Painless Threading - хорошая статья по этой теме, поэтому я рекомендую вам внимательно ознакомиться с ней.

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

+1

Я уже делаю это. Проблема заключается в количестве времени, которое требуется, прежде чем запрашиваемые данные будут окончательно отображены (в onPostExecute). – gordonwd 2010-11-28 20:52:39

+0

@gordonwd: Я полагаю (поскольку вы говорите, что загружаете столько данных), что вы показываете какой-то длинный список. Если это так, вы можете попробовать решение, предложенное в этом * Android Endless List * (http://stackoverflow.com/questions/1080811/android-endless-list). И, как кто-то указал выше, вы также должны опубликовать некоторый код из своих таблиц и то, как вы извлекаете данные из нас, чтобы лучше вам помочь. – Nailuj 2010-11-28 21:55:25

10

SQLite будет использовать индекс, если он подходит для запроса. Используйте EXPLAIN

EXPLAIN QUERY PLAN ... your select statement ... 

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

11

Я, наконец, смог добиться огромного прироста производительности, просто запросив базу данных гораздо более эффективным способом. Например, при создании массива информации я ранее запрашивал базу данных для каждой строки, которая мне нужна, с селектором типа «WHERE _id = n». Но делая это таким образом, я выпускал дюжину или более запросов, по одному за раз.

Вместо этого я создаю список требуемых идентификаторов, а затем получаю их все с одним запросом формы «WHERE _id IN (n1, n2, n3, ...)» и итерации по возвращенному курсор. Выполняя эту и некоторые другие оптимизации структуры, самая большая база данных теперь почти так же быстро просматривается, как и более средний случай.

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