Снижение производительности при использовании большого количества liveata в модели представления

Question

Мне нужно использовать несколько обзоров переработчиков.В приведенном ниже сценарии мне потребуются как минимум 6 обзоров.6 = 1 для горизонтального просмотра переработчика + 3 для каждого фрагмента в окне просмотра + 1 для повторного просмотра + 1 для разметки сетки.

Поскольку сложность данных огромнаи данные каждого адаптера зависят от изменений от других адаптеров, я решил пойти с компонентами архитектуры, представленными в Android Jetpack.Поэтому сначала я интегрирую модель представления и живые данные.позже включите базу данных комнаты (существующая БД находится в SQLite)

Поскольку я буду использовать несколько живых данных для мониторинга изменений данных адаптера.Я хочу прояснить мои сомнения в аспектах производительности модели представления и оперативных данных.

Избыточные затраты при использовании большого количества активных данных :

1. Iпотребуется 6-7 реальных данных для наблюдения за изменениями данных каждого адаптера.Чтобы получить представление о производительности, предположим, что должно использоваться около 50 ~ 60 данных в реальном времени.

2. Является ли это наилучшей практикой или рекомендуется использовать живые данные только с комнатой ?.

   можем ли мы использовать его для данных адаптера или простых примитивных типов, таких как логические, int и т. Д. (Например: isLoading: MutableLiveData, inputText: MutableLiveData textField string для мониторинга изменений.)

Скажем, кто-то может потребовать, чтобы это было в форме, которая может иметь несколько чисел, редактировать текст, выпадающий список, множественный выбор и т. Д., К каждому из которых прикреплены действительные данные.

Как внутренние данные работают внутренне, использует ли он дорогой ресурс для отслеживания изменений в переменной

Answer 1

Живые данные Используйте реактивное программирование (на основе шаблона наблюдателя). Мои наблюдения:

• Правильное использование живых данных зависит от вашего жизненного цикла данных, дляНапример, если вам просто нужен запрос для подтверждения пользователя и пароля (запрос живет только один раз в жизненном цикле вашей программы), неправильно использовать Observer, лучше только обратный вызов (интерфейс).Если ваши данные обновляются в течение всего жизненного цикла программы, живые данные - хорошая идея.

• С другой стороны, ViewModel обрабатывает ваш жизненный цикл живых данных, это означает, что ваши живые данные активны толькокогда ваша деятельность или фрагмент (владелец жизненного цикла) находится в активном состоянии жизненного цикла, это предотвращает утечки памяти.

• Комната работает аналогично SQLite (говоря о производительности), есть
  некоторыеразличия, например, синтаксис, запросы и т. д., самое важное отличие состоит в том, что Room может работать с шаблоном Observer (вы можете поместить свои данные в оболочку LiveData), это означает, что Room использует Observers для уведомления об изменениях данных (это необходимо?),

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

Заключение

• Правильно использовать ViewModel

• Жизненный цикл зависит от случая

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

Надеюсь, это поможет вам, привет.