Парсинг XML в объекты Room
При работе на одном из проектов возникло несколько проблем.
Сервер - 1С система; Интерфейс обмена - SOAP.
Сервер - 1С система; Интерфейс обмена - SOAP.
Первая проблема: в целом SOAP это тот же XML, но с некоторыми надстройками. Эти надстройки потребовалось убрать, чтобы работать с чистым XML.
<!-- до очистки -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<m:Response xmlns:m="tp.mobile">
<m:return xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<m:name>Название объекта</m:name>
<m:error>Кол-во ошибок</m:error>
<m:objects_qty>Кол-во объектов в ответе</m:objects_qty>
<m:information version="3"
is_deleted="false"
hide="false">
<m:id>object_id</m:id>
<!-- остальные поля объекта -->
</m:information>
<!-- остальные объекты information -->
</m:return>
</m:Response>
</soap:Body>
</soap:Envelope>
<!-- после очистки -->
<return>
<name>Название объекта</name>
<error>Кол-во ошибок</error>
<objects_qty>Кол-во объектов в ответе</objects_qty>
<information version="3" is_deleted="false" hide="false">
<id>object_id</id>
<!-- остальные поля объекта -->
</information>
<!-- остальные объекты information -->
</return>Вторая проблема - тяжелые объекты. Помимо примитивных данных (строки, числа, даты, булевые значения и т. п.) приходили огромные картинки в формате base64. Вообще парсинг чего-либо - это сама по себе тяжелая задача для мобильного процессора. А с увеличением количества данных растет количество используемой оперативной памяти и увеличивается время выполнения операции. Если приходил очень большой объект, то приложение падало из-за OutOfMemoryError, а если не падало, то заметно долго выполняло операцию.
Третья проблема - в удобстве использования моделей данных. Приложение должно было хранить данные оффлайн. Для хранения использовали базу данных SQLite. В качестве обертки над SQLite - библиотеку Room. Работа с базой происходит в основном через модели. А т. к. парсер XML тоже работает с моделями, возникла идея не плодить по две модели на объект, а объединить эти модели в одну.
Третья проблема - в удобстве использования моделей данных. Приложение должно было хранить данные оффлайн. Для хранения использовали базу данных SQLite. В качестве обертки над SQLite - библиотеку Room. Работа с базой происходит в основном через модели. А т. к. парсер XML тоже работает с моделями, возникла идея не плодить по две модели на объект, а объединить эти модели в одну.
Решение проблемы
Для работы с XML использовали библиотеку SimpleXML. У SimpleXML есть DOM-парсер (ручной) и Pull-парсер (автоматизированный).
Преимущество Pull в том, что на вход он принимает xml и модель данных, которую необходимо получить. На выходе получается готовый объект. Недостаток Pull в том, что пока парсер будет искать требуемое поле в XML, он несколько раз пройдется по тем полям, которые он уже использовал. Это существенно замедляет производительность.
Преимущество DOM-парсера перекрывает недостаток Pull: движение по XML полностью контролируется разработчиком, и парсер не проходит несколько раз по уже использованным полям, но поля в модель приходится присваивать вручную. Этот парсер работает быстрее в несколько раз.
Далее будут изображены примерные алгоритмы обоих парсеров. Пожалуйста, не нужно воспринимать их как обучающее пособие. Главное - передать принцип. На практике под отдельную задачу придется писать свой код.
Преимущество Pull в том, что на вход он принимает xml и модель данных, которую необходимо получить. На выходе получается готовый объект. Недостаток Pull в том, что пока парсер будет искать требуемое поле в XML, он несколько раз пройдется по тем полям, которые он уже использовал. Это существенно замедляет производительность.
Преимущество DOM-парсера перекрывает недостаток Pull: движение по XML полностью контролируется разработчиком, и парсер не проходит несколько раз по уже использованным полям, но поля в модель приходится присваивать вручную. Этот парсер работает быстрее в несколько раз.
Далее будут изображены примерные алгоритмы обоих парсеров. Пожалуйста, не нужно воспринимать их как обучающее пособие. Главное - передать принцип. На практике под отдельную задачу придется писать свой код.
Алгоритм работы pull-парсера
Алгоритм работы DOM-парсера
Как можно заметить из алгоритмов, в DOM-парсере присутствует лишний вложенный цикл в отличие от Pull-парсера. Именно он замедляет процесс парсинга. Но, как я уже говорил, DOM-парсер быстрее настраивается, поэтому если объекты небольшие, то его можно использовать.
Исходя из информации, приведенной ниже, я принял решение использовать оба парсера. Легкие объекты парсил автоматически, а тяжелые - вручную. Это существенно ускорило время парсинга объектов в целом.
Для наглядности в приложении я посчитал разницу между временем начала парсинга и временем получения готовых объектов, тем самым получил время парсинга в миллисекундах для обоих парсеров. Результат приведен на скриншотах.
Исходя из информации, приведенной ниже, я принял решение использовать оба парсера. Легкие объекты парсил автоматически, а тяжелые - вручную. Это существенно ускорило время парсинга объектов в целом.
Для наглядности в приложении я посчитал разницу между временем начала парсинга и временем получения готовых объектов, тем самым получил время парсинга в миллисекундах для обоих парсеров. Результат приведен на скриншотах.
Главный экран приложения с выбором типа парсера
Время обработки данных через Pull-парсер
Время обработки данных через DOM-парсер
Для уменьшения количества моделей в 2 раза и для удобства разработки я объединил модели XML и Room. На рисунках ниже показаны модели отдельно и объединенная модель.
Преимущество объединенной модели не только в меньшем количестве классов. Самое главное преимущество в том, что не нужно конвертировать XML-модель в Room, чтобы сохранить объект в БД. То, что пришло с парсера, можно сразу же вставить в БД. А если возникнет потребность получить XML из объекта, то с объединенной моделью это можно сделать быстро и легко.
Преимущество объединенной модели не только в меньшем количестве классов. Самое главное преимущество в том, что не нужно конвертировать XML-модель в Room, чтобы сохранить объект в БД. То, что пришло с парсера, можно сразу же вставить в БД. А если возникнет потребность получить XML из объекта, то с объединенной моделью это можно сделать быстро и легко.
Room-модель объекта User
XML-модель объекта User
Объединенная модель объекта User
Вывод
В результате я получил большой опыт работы с библиотеками SimpleXML и Room. Проверил на практике два типа парсинга XML, изучил их преимущества и недостатки. Также я проверил идею с объединением моделей, она отлично себя показала. В любом случае, это отличный опыт. Если однажды мне придется работать с подобными проектами, то на парсер я потрачу гораздо меньше времени.
Спасибо за внимание!