|
Читайте также: |
У мобільних пристроїв мало оперативної пам'яті. Якщо за один запит пристрій отримає відповідь від сервера розміром у 3000 рядків з БД, то парсинг такого розміру json -файл в об'єкти на пристрої може викликати недостачу пам'яті. У цьому випадку додаток або аварійно завершиться, або не збереже отриману відповідь. Але навіть якщо пристрій зможе обробити таку кількість даних за один раз, то продуктивність програми в моменти синхронізації буде низька (лаги інтерфейсу, не плавна прокрутка і т.п.) Тому необхідно запитувати список більш дрібними порціями.
На схемі: "last_updated" і "amount" - значення, які зберігаються в мобільному додатку. "Last_item" - остання надіслана з сервера сутність. Саме новіше цього значення буде запитаний наступний список.
Приклад запиту: {lastUpdated: "2013-01-01 00:00:00", amount: 100}
При використання такого типу запиту можлива ситуація, що якщо в таблиці є 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" використовувалась функція NOW(), що повертає час. Імпорт файлу з тисячами рядків може зайняти менше секунди. Може статися й так, що весь довідник буде мати однаковий "updated". Щоб виправити таку ситуацію необхідно використовувати унікальне поле у межах одного моменту ("updated"). Поле "id" унікально взагалі по всій таблиці, тому слід додатково в синхронізації використовувати саме його.
Реалізація цього методу є такою. Сервер віддає список відсортований по "updated" і "id", а пристрої запитують дані за допомогою "lastUpdated" і нового параметра "lastId". Умова, що виконується на сервері під час генерування відповіді: ((updated> lastUpdated) || (updated == lastUpdated and id> lastId)).
Рис. 3.9. МС даних за третім методом
Оскільки швидкість передачі через мобільний інтернет є незначною(середня швидкість передачі ~18000 байт/с), то необхідно зробити так, щоб за один запит дані передавались ½ часу проміжку між повторною синхронізацією, тобто 10/2 = 5 секунд. Кількість даних, що може бути передана за 5 секунд дорівнює 18000 * 5 = 90000 байт. Це зумовлене тим, що якість покриття на різних місцевостях може відрізнятись і необхідно для забезпечення надійної роботи додатку.
Таблиця 3.9
Тестування третього методу
| Запит, № | Кількість переданого трафіку(байт) | Час виконання операції на сервері(мс) | Час виконання операції на пристрої(мс) | Загальний час виконання операції(мс) |
| 252 374 | ||||
| 27 473 | ||||
| 26 300 | ||||
| 27 310 | ||||
| 27 014 |
Рис. 3.10. Кількість переданих байт інформації при кожному запиті
Рис. 3.11. Часова діаграма початку і завершення синхронізації
Загальна кількість переданих байт за 5 запитів дорівнює 360 471.
Дані передаються майже однаковими малими порціями, що виключає можливої ситуації коли до завершення синхронізації n починається синхронізація n+1.
Переваги:
- низьке навантаження на пам’ять та процесор пристрою
Недоліки:
- для пристроїв різних характеристик, обмеження для одного пристрою не підходить для іншого пристрою(якщо обмеження низькі – синхронізація відбуватиметься довше ніж є можливість, якщо обмеження вищі – нестабільність роботи додатку)
Область застосування:
- для пристроїв однакової характеристики
Дата добавления: 2015-12-07; просмотров: 99 | Нарушение авторских прав