В середине 2024 года, как глухой независимый разработчик, я часто размышляю о прогрессе и достижениях, достигнутых за последние шесть месяцев. В этой статье я делюсь примером сравнения модульной конструкции архитектур MVVM и MVI. Независимо от того, есть у вас опыт разработки или нет, я уверен, что эта статья будет вам очень полезна.

MVI (Model-View-Intent) и MVVM (Model-View-ViewModel) — две очень распространенные архитектуры в разработке Android. Хотя их цель — сделать код более понятным и удобным в сопровождении, у них разные идеи относительно того, как они обрабатывают поток данных, управление состоянием и взаимодействие с пользователем. Позвольте мне сравнить их простым для понимания способом.

1. Различия в архитектурном решении

MVI（Model-View-Intent）

MVI да Что-то вродеОдносторонний поток данныхархитектура,этопроходить Строго управляемый событиямии Управление статусами гарантирует, что состояние приложения предсказуемо. Другими словами, МВИ да“шаг за шагом”,Каждое действие пользователя (намерение) запускает обновление статуса.,Новый статус затем обновляется с помощью рендеринга пользовательского интерфейса.

• Model：Данные, представляющие приложениеисостояние。
• View：Отвечает за отображение пользовательского интерфейса.。
• Intent：Намерение пользователя на операцию,Например, нажимайте кнопки, вводите контент и т. д.

поток данныхнаправлениеда：Intent -> ViewModel -> Model -> View,Поток данных является однонаправленным.

MVVM（Model-View-ViewModel）

MVVM — очень распространенная архитектура Android,этопроходитьДвусторонняя привязка данныхвыполнить View и ViewModel взаимодействие. Модель просмотра Отвечает за обработку бизнес-логики, View слушая ViewModel Само обновление на основе изменений данных. и просмотреть изменения также могут быть непосредственно отражены в ViewModel середина.

• Model：и MVI Аналогично отвечает за управление данными.
• View：пользовательский интерфейс,показывать UI элемент.
• ViewModel：Как строительство моста,Отвечает за взаимодействие логики данных и логики интерфейса.

существовать MVVM середина,поток данныхдадвусторонний：View ↔ ViewModel ↔ Model,Данные могутсуществовать View и ViewModel течь между ними.

2. Сравнение потоков данных

• MVI да Односторонний поток данные: все данные, полученные в результате действий пользователя.,Потом статус изменится,Затем визуализируйте его в интерфейсе. Потому что процесс строго односторонний,Состояние приложения легко отлаживать и отслеживать.
• MVVM Это двусторонний поток данных: Просмотр и ViewModel влиять друг на друга, Посмотреть Изменения могут автоматически обновляться Модель просмотра и ViewModel Изменения также будут автоматически обновлены до View начальство. Этот метод очень гибкий,Но когда дасуществовать имеет дело со сложной логикой,Часто возникают несоответствия данных.

3. Управление статусом

• MVI：Каждая операция пользователя генерируетодинновыйизсостояние,этотсостояниеданеизменный（immutable）。Управление Статусы очень понятны, каждая операция будет иметь соответствующее обновление статуса. UI Рендеринг легче отлаживать.
• MVVM：Управление статусамиотносительно свободный,проходить LiveData или StateFlow отслеживать изменения данных. Статус может измениться в любое время, ViewModel Данные в также можно разделить на несколько View общий,Высокая гибкость,Но когда существование имеет дело со сложными состояниями,Склонен к проблемам.

4. Взаимодействие с пользователем

• MVI：Каждое взаимодействие с пользователемдаодин Intent (намерение операции), например щелчок, ввод и т. д. Все пользовательские операции будут сериализованы в события, а затем переданы ViewModel Обработка, обновление статуса и, наконец, передача View Рендеринг.
• MVVM：Непосредственное управление пользователемпроходить Механизм связывания отражаетсуществовать ViewModel середина,Например, команда View существует Введите текст во ViewModel немедленно получит изменение и обработает его. Взаимодействие простое и интуитивно понятное,Подходит для быстрой разработки и небольших приложений.

5. Применимые сценарии

• MVI Больше подходит для тех, кому нужно сложное Управление Применение статусами,Например, чат в реальном времени, сложная обработка форм и т. д. Потому что его поток состояний односторонний,Чтобы облегчить отладку и управление.
• MVVM Больше подходит для ежедневного развитияисерединанебольшой проект,Механизм привязки данных делает их разработку более эффективной.,Подходит для менее сложных приложений.

Краткое описание различий

• MVI：сила Односторонний поток данных,Неизменяемое состояние,Отладка ясна. Подходит для приложений со сложными состояниями и строгим управлением событиями.,Но объем кода, который нужно реализовать, относительно велик.
• MVVM：Двусторонняя привязка данных,Больше гибкости,Подходит для небольших приложений,Но когда существование имеет дело со сложными состояниямисклонен к путанице。

Интуитивное сравнение

6. Технические трудности и проблемы

Используете ли вы MVI все еще MVVM Архитектура,Возникнут некоторые технические трудности. Следующий,Я совмещаю свой личный опыт,Поговорите о проблемах, возникающих при использовании этих архитектур.,И идеи, полученные в процессе обучения середина.

Техническая трудность первая: сложность управления статусами

MVI Самая большая особенность неизменяемого состояния и одностороннего. поток данных。Хотя эта конструкция делаетсостояние Изменения очень очевидны,Однако при его реализации мы часто сталкиваемся с ситуациями, когда объект состояния слишком сложен. Каждая пользовательская операция генерирует новое состояние,И этот статус будет содержать всю актуальную информацию. Комплексное управление всеми состояниями приложения,Объем кода станет очень большим,Для поддержания этих состояний необходимо написать много логики.

существовать Я использую MVI Процесс середина часто требует времени, чтобы подумать о том, как правильно спроектировать эти состояния. Специальное дасуществовать большое приложение середина, Управление Статусы легко могут стать очень утомительными. Как избежать «раздувания» государственных объектов и сделать их ясными и краткими, даисуществовать MVI Самая большая техническая сложность в разработке.

MVVM Очень гибкий, поскольку использует изменяемое состояние. (LiveData или Стейт Флоу). Однако эта гибкость также имеет некоторые недостатки, такие как противоречивое состояние. Поскольку состояние является переменным, при совместном использовании несколькими представлениями данные могут быть несинхронизированы или противоречивы. Хотя его реализация относительно MVI Простой,Но дасуществовать сложные сценарии бизнес-логикисередина,Отладка и поддержка потока данных становится затруднительной.

мой опыт：существоватьвыбирать Архитектурачас,Взвесить Управление Сложность статусами. Если ваше приложение имеет сложную бизнес-логику, MVI из Односторонний поток данные помогут вам лучше управлять состоянием, но если логика приложения относительно проста, MVVM; Более подходит для обеспечения более высокой эффективности разработки.

Техническая трудность вторая: обработка взаимодействия с пользователем.

MVI проходить Intent управлятьвзаимодействие с Подход пользователя очень строгий, но он также требует большого количества логики обработки событий. существовать MVI ,каждая пользовательская операция будет преобразована в Intent,а потом еще разпроходить ViewModel Обновите статус. По мере увеличения логики взаимодействия в приложении управление событиями может стать очень сложным. Кроме того, для каждого действия пользователя напишите Intent Код значительно увеличит объем кода всего проекта.

Например, я существую, использую MVI , каждый раз, когда пользователь нажимает кнопку, вводит текст или выполняет другие действия, мне нужно создать Намерьтесь и убедитесь, что эти Intent можно правильно обработать. Хотя это может сделать логику кода понятной и управляемой, это также приведет к избыточности кода и увеличению затрат на разработку.

В сравнении,MVVM существоватьиметь дело свзаимодействие с пользователемчас Это даже больше Простой。проходить Двусторонняя привязка данных, операции пользователя могут напрямую отражать существование ViewModel Поднимитесь, сэкономьте много Intent Этапы обработки. Преимуществом этого метода является высокая эффективность разработки, однако недостатком является то, что по мере роста масштаба проекта Двусторонняя привязка логика данных может стать неуправляемой, особенно дасуществовать несколько View с тем же самым ViewModel Во время взаимодействия могут возникнуть проблемы с синхронизацией данных.

мои мысли：MVI Он подчеркивает строгое управление событиями и подходит для сценариев приложений, требующих сложных взаимодействий и MVVM Очень прямой и гибкий, подходит для быстрой разработки и относительно простых приложений.

Техническая трудность третья: повторное использование кода и сложность.

MVI дизайн Чтобы сохранить за каждым модулем единую ответственность, эта существующая модульная разработка середина работает очень хорошо. Однако, поскольку Односторонний поток данныхизхарактеристика,При работе со сложной бизнес-логикой будет генерироваться много повторяющейся логики. Например,то же действие пользователя,Возможно, потребуется выполнить аналогичную обработку в разных состояниях.,Это приводит к уменьшению возможности повторного использования кода.

существоватьреальный проектсередина,Я часто нахожу,При использовании МВИ,Количество дублированного кода будет постепенно увеличиваться.,существуют, когда разным модулям необходимо обрабатывать схожую бизнес-логику.

MVVM Гибкость упрощает повторное использование кода. действовать LiveData и ViewModel Взаимосвязь между ними упрощает управление данными, совместно используемыми различными представлениями. Эта архитектура позволяет View и ViewModel Логическое разделение труда между ними очень четкое, что облегчает повторное использование кода.

мой опыт：существоватьвыбирать MVI все еще MVVM При этом это зависит от сложности проекта и необходимости повторного использования кода. МВИ Модульность и удобство сопровождения очень сильны, но возможность повторного использования кода пока низкая; MVVM Хотя гибкость вносит определенную степень неопределенности, она упрощает повторное использование кода.

7. Учебные заметки

1. Дизайн намерения в MVI：Intent да MVI Ключевая часть середина. Каждая операция пользователя будет отслеживаться Intent сериализуется и отправляется в ViewModel иметь дело с. существуют фактическое развитие середина, разработка разумного Intent Структурада очень важна. Старайтесь избегать чрезмерного проектирования сложных Цель: сохранение простой и понятной модели событий помогает улучшить читаемость кода.
2. MVVM середина Двусторонняя привязка данныхизловушка：Хотя MVVM привязка данных середины очень удобна, но этот двусторонний поток данные могут легко вызвать проблемы с несогласованным статусом. Специальное дасуществовать совместное использование одного и того же изображения в нескольких представлениях ViewModel час,Может возникнуть ошибка синхронизации статуса. Поэтому вам нужно быть особенно осторожными с этими невидимыми изменениями статуса при разработке.,Минимизируйте сценарии чрезмерной привязки.
3. Управление статусамиизвыбирать：MVI Уделите особое внимание управлению неизменяемым состоянием, сделав каждое обновление состояния понятным и простым для отладки. и MVVM проходить LiveData или StateFlow Управление статусом, хотя и очень гибкое, непросто отслеживать изменения статуса. существующей практики середина, я обнаружил, что если статус заявки меняется очень часто, MVI из Односторонний поток Данные кажутся очень надежными.
4. Обработка сложной логики взаимодействия：Если применяетсясередина Есть многоиз Сложная логика взаимодействия,MVI Может обеспечить лучшее управление событиями. Каждое взаимодействие порождает Намерение запускает обновления статуса, и разработчики могут точно контролировать влияние каждой операции. и MVVM Когда существуют обрабатывают сложные взаимодействия, необходимо ввести другую логику для обеспечения согласованности данных.

8. Резюме

Будь то MVI все еще MVVM,У всех есть свои преимущества и недостатки. Ранние этапы существования проекта,Я предпочитаю использовать MVVM Архитектура, потому что она гибкая, быстрая и подходит для быстрых обновлений. А когда проект становится все более сложным, к нему нужно быть строгим. статусами, я бы рассмотрел возможность перехода на MVI Архитектура, обеспечивающая управляемость и возможность отладки состояния приложения.

выбирать Архитектураизключсуществоватьпо проектамизсложностьикомандная пара Архитектураиззнакомство。MVI Больше подходит для сложных приложений, требующих точного управления, в то время как MVVM Он подходит для относительно простых сценариев, в которых эффективность разработки имеет приоритет.

Не стесняйтесь задавать любые вопросы, спасибо всем, кто дочитал)