Исходя из моего опыта работы с мобильными устройствами, переосмысление синхронизации в большинстве случаев является излишним.Это, очевидно, зависит от оборудования, программного обеспечения и количества данных, с которыми вы работаете.Но в большинстве случаев длительное время выполнения операций на мобильных устройствах вызвано неправильным дизайном, небрежным кодированием или особенностями встроенных систем, которые не принимаются во внимание.
К сожалению, я могу дать вам только некоторые советы, которые вы можете рассмотреть,учитывая довольно расплывчатое описание проблем, с которыми вы сталкиваетесь.Я имею в виду, что «LOT» не имеет большого значения для меня - я видел мобильные приложения с БД, содержащими миллионы записей, которые работают довольно гладко, и те, у которых около 1 КБ записей работали ужасно медленно и вызывали зависание пользовательского интерфейса.Вы также не упомянули, какую версию ОС и устройство (или, по крайней мере, его возможности) вы используете.Какая конфигурация сервера, какое программное обеспечение установлено, какие библиотеки / фреймворки используются и в каких режимах.Все это имеет значение, когда вы хотите действительно ускорить процесс.
Помимо кодирования, являющегося gzip (которое, я считаю, вы оставили по умолчанию, то есть on), вы должны попробовать эту идею:
- Потоковое!- убедитесь, что и клиент и сервер используют потоковую версию JSON API и используют буферизованные потоки.Если ни один не делает - замените это библиотекой, которая делает.У Джексона один из самых быстрых потоковых API.Конечно, писать (де) сериализатор труднее, но это окупается.Если все сделано правильно, ни одна из сторон не должна создавать достаточно большой буфер для (де) сериализации всех данных, заполнять их содержимым, а затем анализировать / записывать его.Вместо этого намного меньший буфер выделяется и заполняется постепенно, когда последовательные поля сериализуютсяКогда этот буфер заполняется, его содержимое немедленно отправляется на другой конец канала данных.Там его можно сразу десериализовать.Процесс продолжается до тех пор, пока все данные не будут переданы небольшими порциями.Это делает обмен данными намного более плавным и менее ресурсоемким.
- Для больших пакетных вставок или обновлений используйте подготовленные операторы.Иногда это также помогает вставить ваши данные без ограничений и затем создать их - таким образом, например, индекс можно вычислить за один прогон, а не для каждой вставки.Не используйте транзакции (они требуют ведения дополнительных журналов базы данных) и не фиксируйте каждые 300 строк, чтобы минимизировать накладные расходы.Если вы обновляете существующую базу данных и необходимы атомарные модификации - загрузите новые данные во временную базу данных и, если все в порядке, замените старую базу данных новой на лету.
- Почти всегда некоторые данные можно предварительно вычислитьи хранится на SD-карте, например.Или его можно загрузить непосредственно на sd-карту в виде подготовленной базы данных SQLite в компании.Если для задачи требуются данные настолько большого размера, что импорт занимает более 10 минут, вам, вероятно, не следует выполнять эту задачу на мобильных устройствах.