Разработка мобильных приложений: Синхронизация с сервером

Значительная часть современных приложений для мобильных платформ (iOS, Android и т.п.) работает в паре с сервером. Приложение с устаревшими данными теряет свою полезность. Поэтому важно обеспечить постоянное обновление данных с сервера на устройство. Это касается оффлайн приложений, которые должны работать и без интернета. Для полностью онлайн приложений, которые не работают (или бесполезны) без интернета (например, Foursquare, Facebook) есть своя специфика, которая выходит за рамки текущей статьи. Я расскажу на примере одного нашего оффлайн приложения, какие подходы мы использовали для синхронизации данных. В первых версиях мы разработали простые алгоритмы и, в дальнейшем, с опытом, мы их совершенствовали. Аналогичная последовательность представлена и в статье – от простых очевидных практик к более сложных. Следует уточнить, что в статье рассматривается передача данных только в одну сторону: от сервера к устройству. Здесь сервер является источником данных.

Общие положения для всех подходов

Для примера, мы будем рассматривать передачу на устройство справочника блюд (“dishes”). Будем считать, что устройство делает запрос на url “/service/dishes/update”,  обмен идет по протоколу http в формате JSON (www.json.org). На сервере есть таблица “dishes” с полями: id (идентификатор записи), name (наименование блюда), updated (момент обновления блюда, лучше сразу делать поддержку timezone, “YYYY-MM-DDThh:mm:ssTZD”, например, “1997-07-16T19:20:30+01:00”), is_deleted (признак удаленной записи). Ремарка касаемо наличия последнего поля. По умолчанию его значение равно 0. В приложении, где сущности синхронизируются между клиентом и сервером, физически удалять данные с сервера не рекомендуется (чтобы не было ошибок). Поэтому у удаленных блюд выставляется is_deleted = 1. По приходу на устройство сущности с is_deleted = 1 она удаляется с устройства. При любом подходе, который будет рассматриваться ниже, сервер возвращает на устройства JSON массив объектов (может быть пустой):
[ {id: <id>,name: <name>,updated:<updated>,isDeleted: <isDeleted>},… ]
Пример ответа сервера:
[ {id: 5625,name: "Bread",updated: "2013-01-06 06:23:12",isDeleted: 0}, {id: 23,name: "Cooked semolina",updated: "2013-02-01 14:44:21",isDeleted: 0},{ id: 533, name: "Fish-soup", updated: "2013-08-02 07:05:19", isDeleted: 0 } ]

Принципы обновления данных на устройстве

  1. Если пришел элемент, который есть на устройстве, и isDeleted = 0, то он обновляется
  2. Если пришел элемент, которого нет на устройстве, и isDeleted = 0, то он добавляется
  3. Если пришел элемент, который есть на устройстве, и isDeleted = 1, то он удаляется
  4. Если пришел элемент, которого нет на устройстве, и isDeleted = 1, то ничего не делается

Подход 1: Синхронизируется всегда все

Это самый простой метод. Устройство запрашивает список блюд у сервера и сервер отсылает весь список целиком. Каждый раз список приходит весь. Не сортированный. Пример запроса: null, либо “{}” img35423456 Достоинства:
  • логика на сервере простая – отдаем всегда все
  • логика на устройстве простая – перезаписываем всегда все
Недостатки:
  • если запрашивать список часто (каждые 10 минут), то будет большой интернет трафик
  • если запрашивать список редко (раз в день), то будет нарушена актуальность данных
Область применения:
  • для приложений с небольшим трафиком
  • передача очень редко меняющихся данных (список городов, категорий)
  • передача настроек приложения
  • на начале проекта для самого первого прототипа мобильного приложения

Подход 2: Синхронизируется только обновленное

Устройство запрашивает список блюд, обновленный с предыдущей синхронизации. Список приходит отсортированный по “updated” в порядке возрастания (необязательно, но удобно). Устройство хранит значение “updated” у самого последнего присланного блюда и при следующем запросе шлет его серверу в параметре “lastUpdated”. Сервер присылает список блюд, которые новее “lastUpdated” (updated > lastUpdated). При первом запросе на сервер “lastUpdated” = null. Пример запроса: { lastUpdated: “2013-01-01 00:00:00” } img-1365345 На схеме: “last_updated” – значение, которое хранится на устройстве. Обычно на устройстве создается отдельная таблица для хранения этих значений “last_updated” по каждой сущности (блюда, города, организации и т.п.) Этот подход годится для синхронизации простых линейных списков, у которых правила прихода на устройство одинаковые для всех устройств. Для более избирательной синхронизации см “Подход 5: Синхронизация со знанием того, что уже есть на устройстве”. Обычно этот подход перекрывает большинство нужд. На устройство приходят только новые данные, синхронизироваться можно хоть каждую минуту – трафик будет небольшой. Однако тут возникают проблемы, связанные с ограничениями мобильных устройств. Это память и процессор.

Подход 3: Синхронизация порциями

У мобильных устройств мало оперативной памяти. Если в справочнике 3000 блюд, то парсинг большой json строки от сервера в объекты на устройстве может вызвать нехватку памяти. В этом случае приложение либо аварийно завершится, либо не сохранит эти 3000 блюд. Но даже если устройство смогло переварить такую строку, то производительность приложения в моменты синхронизации в фоне будет низкая (лаги интерфейса, не плавная прокрутка и т.п.) Поэтому необходимо запрашивать список более мелкими порциями. Для этого устройство передает еще один параметр (“amount”), который определяет размер порции. Список присылается обязательно отсортированный по полю “updated” по возрастанию. Устройство, аналогично предыдущему подходу, запоминает значение “updated” у последней присланной сущности и передает его в поле “lastUpdated”. Если сервер прислал ровно это же количество сущностей, то устройство продолжает синхронизацию и снова делает запрос, но уже с обновленным “lastUpdated”. Если сервер прислал меньше сущностей, это значит, больше новых данных у него нет, и синхронизация завершается. img-25675768 На схеме: “last_updated” и “amount” – значения, которые хранятся в мобильном приложении. “last_item” – последняя присланная с сервера сущность (блюдо). Именно новее этого значения будет запрошен следующий список. Пример запроса: { lastUpdated: “2013-01-01 00:00:00”, amount: 100 } Достоинства:
  • На устройство приходит столько данных, сколько оно в состоянии обработать за один раз. Размер порции определяется практическими тестами. Простые сущности можно синхронизировать по 1000 штук за раз. Но бывает и такое, что сущности с большим количеством полей и сложной логикой обработки сохранения синхронизируются нормально не более 5 штук.
Недостатки:
  • Если будет 250 блюд с одинаковым updated, то при amount = 100 последние 150 не придут на устройства. Такая ситуация вполне реальна и описана в следующем подходе.

Подход 4: Корректная синхронизация порциями

В предыдущем подходе возможна ситуация, что если в таблице есть 250 блюд с одинаковым “updated” (например, “2013-01-10 12:34:56”) и размер порции равен 100, то придут только первые 100 записей. Остальные 150 будут отсечены жестким условием (updated > lastUpdated). Почему так произойдет? При запросе первых 100 записей lastUpdated установится в “2013-01-10 12:34:56”, и следующий запрос будет иметь условие (updated > “2013-01-10 12:34:56”). Не поможет даже смягчение условия (updated >= “2013-01-10 12:34:56”), потому что устройство тогда будет бесконечно запрашивать первые 100 записей. Ситуация с одинаковым “updated” не настолько редкая. Например, при импорте данных из текстового файла поле “updated” было выставлено в NOW(). Импорт файла с тысячами строк может занять меньше секунды. Может случиться и так, что весь справочник будет иметь одинаковый “updated”. Чтобы это исправить надо использовать какое-то поле блюда, которое было бы уникальным хотя бы в пределах одного момента (“updated”). Поле “id” уникально вообще по всей таблице, так что следует дополнительно в синхронизации использовать именно его. Итого, реализация этого подхода выглядит так. Сервер отдает список отсортированный по “updated” и “id”, а устройства запрашивают данные с помощью “lastUpdated” и нового параметра “lastId“. У сервера условие выборки усложняется: ((updated > lastUpdated) OR (updated = lastUpdated and id > lastId)). img-35786867867 На схеме: “last_updated”, “last_id” и “amount” – значения, которые хранятся в мобильном приложении. “last_item” – последняя присланная с сервера сущность (блюдо). Именно новее этого значения будет запрошен следующий список.

Подход 5: Синхронизация со знанием того, что уже есть на устройстве

Предыдущие подходы не учитывают факта, что сервер в реальности не знает насколько успешно данные сохранились на устройстве. Устройство могло просто не сохранить часть данных из-за невыясненных ошибок. Поэтому неплохо было бы получать от устройства подтверждение, что все (или не все) блюда сохранились. Кроме этого, пользователь приложения может так настроить приложение, что ему нужна будет только часть данных. Например, пользователь хочет синхронизировать блюда только из 2 городов из 10. Описанными выше синхронизациями этого не добиться. Идея подхода следующая. Сервер хранит у себя (в отдельной таблице “stored_item_list”) информацию о том, какие блюда есть на устройстве. Это может быть просто список пар “id – updated”. В этой таблице хранятся все списки пар “id – updated” блюд для всех устройств. Информацию об имеющихся на устройстве блюдах (список пар “id – updated“) устройство отсылает серверу вместе с запросом на синхронизацию. При запросе сервер проверяет то, какие блюда должны быть на устройстве и какие есть сейчас. После этого на устройство отсылается разница. Как сервер определяет, какие блюда должны быть на устройстве? В простейшем случае сервер делает запрос, который возвратит ему список пар “id – updated” всех блюд (например, SELECT id, updated FROM dishes). На схеме это делает “WhatShouldBeOnDeviceMethod()” метод. В этом недостаток подхода – серверу приходится вычислять (порой делая тяжелые sql-запросы), что должно быть на устройстве. Как сервер определяет какие блюда есть на устройстве? Он делает запрос в таблицу “stored_item_list” по этому устройству и получает список пар “id – updated”. Анализируя эти два списка, сервер решает, что следует послать на устройство, а что – удалить. На схеме это “delta_item_list”. Поэтому в запросе нет “lastUpdated” и “lastId”, их задачу выполняют пары “id – updated”. Как сервер узнает об имеющихся на устройстве блюдах? В запросе к серверу добавляется новый параметр “items”, который содержит список id блюд, которые были присланы на устройство в прошлой синхронизации (“device_last_stored_item_list”). Конечно, можно отсылать список id всех блюд, которые есть на устройстве, и не усложнять алгоритм. Но если на устройстве 3000 блюд и они будут каждый раз все отсылаться, то расходы трафика будут очень велики. В подавляющем количестве синхронизаций параметр “items” будет пустой. Сервер должен постоянно обновлять у себя “stored_item_list” данными, которые пришли с устройства в параметре “items”. img-47897897897 Следует реализовать механизм очистки серверных данных в stored_item_list. Например, после переустановки приложения на устройстве сервер будет считать, что на устройстве все еще актуальные данные. Поэтому при установке приложения устройство должно как-то проинформировать сервер чтобы он очистил stored_item_list по этому устройству. В нашем приложении мы посылаем дополнительный параметр “clearCache” = 1 в этом случае.

Заключение

Сводная таблица по характеристикам этих подходов:
Подход Объем трафика(5 – большой) Трудоемкость разработки(5 – высокая) Использование памяти устройства(5 – высокое) Корректность данных на устройстве(5 – высокая) Можно выделить конкретное устройство
1 Синхронизируется всегда все 5 1 5 5 нет
2 Синхронизируется только обновленное 1 2 5 3 нет
3 Синхронизация порциями 1 3 1 3 нет
4 Корректная синхронизация порциями 1 3 1 3 нет
5 Синхронизация со знанием того, что уже есть на устройстве 2 5 2 5 да
“Корректность данных на устройстве” – это вероятность того, что на устройстве есть все данные, которые отсылались сервером. В случае подходов №1 и №5 есть 100% уверенность, что устройство имеет все данные, которые нужны. В остальных случаях такой гарантии нет. Это не говорит о том, что остальные подходы использовать нельзя. Просто если на устройстве часть данных пропадет, то исправить это с сервера (а тем более узнать про это на стороне сервера) не получится. Возможно, при наличии безлимитых тарифов на интернет и бесплатного wifi проблема ограничения трафика, генерируемого мобильным приложением, станет менее актуальна. Но пока приходится идти на всякие ухищрения, придумывать более “умные” подходы, которые позволяют снизить сетевые расходы и увеличить производительность приложений. Не всегда это работает. Порой бывает “чем проще – тем лучше”, зависит от ситуации. Надеюсь, из этой статьи можно подобрать подход, который пригодится. В интернете на удивление мало описаний синхронизации сервера и мобильных устройств. Притом, что приложений, работающих по такой схеме, много. Для интересующихся пара ссылок: