Эта страница переведена с помощью Cloud Translation API.

Руководство по архитектуре приложения

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

Пользовательский опыт мобильного приложения

Типичное приложение Android содержит несколько компонентов приложения , включая действия , фрагменты , службы , поставщиков контента и приемники широковещательных сообщений . Большинство этих компонентов приложения вы объявляете в манифесте приложения . Затем ОС Android использует этот файл, чтобы решить, как интегрировать ваше приложение в общий пользовательский интерфейс устройства. Учитывая, что типичное приложение Android может содержать несколько компонентов и что пользователи часто взаимодействуют с несколькими приложениями за короткий период времени, приложениям необходимо адаптироваться к различным видам рабочих процессов и задач, управляемых пользователем.

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

Учитывая условия этой среды, компоненты вашего приложения могут запускаться индивидуально и не по порядку, и операционная система или пользователь могут уничтожить их в любой момент. Поскольку эти события не находятся под вашим контролем, вам не следует хранить или хранить в памяти какие-либо данные приложения или состояние в компонентах вашего приложения, а компоненты вашего приложения не должны зависеть друг от друга.

Общие архитектурные принципы

Если вам не следует использовать компоненты приложения для хранения данных и состояния приложения, как вместо этого вам следует спроектировать свое приложение?

Поскольку приложения Android растут в размерах, важно определить архитектуру, которая позволит приложению масштабироваться, повысит его надежность и упростит его тестирование.

Архитектура приложения определяет границы между частями приложения и обязанности, которые должна иметь каждая часть. Чтобы удовлетворить упомянутые выше потребности, вам следует спроектировать архитектуру своего приложения так, чтобы она следовала нескольким конкретным принципам.

Разделение интересов

Самый важный принцип, которому следует следовать, – это разделение задач . Распространенной ошибкой является запись всего кода в Activity или Fragment . Эти классы на основе пользовательского интерфейса должны содержать только логику, которая обрабатывает взаимодействие пользовательского интерфейса и операционной системы. Сохраняя эти классы как можно более компактными, вы можете избежать многих проблем, связанных с жизненным циклом компонентов, и улучшить тестируемость этих классов.

Имейте в виду, что у вас нет реализаций Activity и Fragment ; скорее, это просто связующие классы, которые представляют собой контракт между ОС Android и вашим приложением. ОС может уничтожить их в любой момент в зависимости от взаимодействия с пользователем или из-за системных условий, таких как нехватка памяти. Чтобы обеспечить удовлетворительное взаимодействие с пользователем и более управляемое обслуживание приложений, лучше всего свести к минимуму вашу зависимость от них.

Управляйте пользовательским интерфейсом на основе моделей данных

Еще один важный принцип заключается в том, что вы должны создавать свой пользовательский интерфейс на основе моделей данных, предпочтительно постоянных моделей. Модели данных представляют данные приложения. Они независимы от элементов пользовательского интерфейса и других компонентов вашего приложения. Это означает, что они не привязаны к жизненному циклу пользовательского интерфейса и компонентов приложения, но все равно будут уничтожены, когда ОС решит удалить процесс приложения из памяти.

Постоянные модели идеальны по следующим причинам:

Ваши пользователи не потеряют данные, если ОС Android уничтожит ваше приложение, чтобы освободить ресурсы.
Ваше приложение продолжает работать в случаях, когда сетевое соединение нестабильно или недоступно.

Если вы основываете архитектуру своего приложения на классах модели данных, вы делаете свое приложение более тестируемым и надежным.

Единый источник истины

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

Этот шаблон дает несколько преимуществ:

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

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

Однонаправленный поток данных

Принцип единого источника истины часто используется в наших руководствах с шаблоном однонаправленного потока данных (UDF). В UDF состояние течет только в одном направлении. События , которые изменяют поток данных в противоположном направлении.

В Android состояние или данные обычно передаются из типов иерархии с более высокой областью действия в типы с более низкой областью действия. События обычно запускаются из типов с более низкой областью действия, пока не достигнут SSOT для соответствующего типа данных. Например, данные приложения обычно передаются из источников данных в пользовательский интерфейс. Пользовательские события, такие как нажатия кнопок, передаются из пользовательского интерфейса в SSOT, где данные приложения изменяются и предоставляются в неизменяемом типе.

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

Управление зависимостями между компонентами

Классы в вашем приложении зависят от других классов для правильной работы. Для сбора зависимостей определенного класса можно использовать любой из следующих шаблонов проектирования:

Внедрение зависимостей (DI) . Внедрение зависимостей позволяет классам определять свои зависимости, не создавая их. Во время выполнения за предоставление этих зависимостей отвечает другой класс.
Локатор сервисов : шаблон локатора сервисов предоставляет реестр, в котором классы могут получать свои зависимости, а не создавать их.

Эти шаблоны позволяют масштабировать ваш код, поскольку они предоставляют четкие шаблоны для управления зависимостями без дублирования кода и усложнения. Более того, эти шаблоны позволяют быстро переключаться между тестовой и производственной реализациями.

Мы рекомендуем следовать шаблонам внедрения зависимостей и использовать библиотеку Hilt в приложениях Android. Hilt автоматически конструирует объекты, проходя по дереву зависимостей, предоставляет гарантии времени компиляции для зависимостей и создает контейнеры зависимостей для классов платформы Android.

Общие рекомендации

Программирование — творческая область, и создание приложений для Android — не исключение. Есть много способов решить проблему; вы можете передавать данные между несколькими действиями или фрагментами, получать удаленные данные и сохранять их локально для автономного режима или обрабатывать любое количество других распространенных сценариев, с которыми сталкиваются нетривиальные приложения.

Хотя следующие рекомендации не являются обязательными, в большинстве случаев их следование делает вашу кодовую базу более надежной, тестируемой и поддерживаемой в долгосрочной перспективе:

Не храните данные в компонентах приложения.

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

Уменьшите зависимости от классов Android.

Компоненты вашего приложения должны быть единственными классами, которые полагаются на API-интерфейсы SDK платформы Android, такие как Context или Toast . Отделение от них других классов в вашем приложении помогает улучшить тестируемость и уменьшает связанность внутри вашего приложения.

Создайте четко определенные границы ответственности между различными модулями вашего приложения.

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

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

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

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

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

Подумайте, как сделать каждую часть вашего приложения тестируемой по отдельности.

Например, наличие четко определенного API для получения данных из сети упрощает тестирование модуля, который сохраняет эти данные в локальной базе данных. Если вместо этого вы смешаете логику этих двух модулей в одном месте или распределите сетевой код по всей базе кода, эффективное тестирование станет гораздо сложнее, если вообще возможно.

Типы отвечают за свою политику параллелизма.

Если тип выполняет длительную блокирующую работу, он должен нести ответственность за перемещение этих вычислений в правильный поток. Этот конкретный тип знает тип вычислений, которые он выполняет, и в каком потоке они должны выполняться. Типы должны быть безопасными для основного потока, то есть их можно безопасно вызывать из основного потока, не блокируя его.

Сохраняйте как можно больше актуальных и свежих данных.

Таким образом, пользователи смогут пользоваться функциями вашего приложения, даже если их устройство находится в автономном режиме. Помните, что не всем вашим пользователям нравится постоянное высокоскоростное соединение, а даже если и они это делают, они могут получить плохой сигнал в людных местах.

Преимущества архитектуры

Наличие хорошей архитектуры в вашем приложении приносит много преимуществ проектным и инженерным группам:

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

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

Образцы

Следующие примеры Google демонстрируют хорошую архитектуру приложения. Изучите их, чтобы увидеть это руководство на практике:

{% дословно %} {% дословно %}

Пользовательский опыт мобильного приложения

Типичное приложение Android содержит несколько компонентов приложения , включая действия , фрагменты , службы , поставщиков контента и приемники широковещательных сообщений . Большинство этих компонентов приложения вы объявляете в манифесте приложения . Затем ОС Android использует этот файл, чтобы решить, как интегрировать ваше приложение в общий пользовательский интерфейс устройства. Учитывая, что типичное приложение Android может содержать несколько компонентов и что пользователи часто взаимодействуют с несколькими приложениями за короткий период времени, приложениям необходимо адаптироваться к различным типам рабочих процессов и задач, управляемых пользователем.