Лекция 2. Классы мобильных приложений, платформы и базовые архитектурные паттерны

Введение

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

Понимание этих тем критично перед началом работы с Expo и React Native: выбор подхода к разработке и архитектуры определяет стоимость, скорость и качество будущего продукта.

1. Мобильное приложение как отдельный класс ПО

Мобильное приложение — программный артефакт, работающий в условиях ограниченных ресурсов мобильной платформы и решающий прикладные задачи пользователя «в движении».

От настольных и серверных программ его отличает совокупность характеристик.

1.1. Ограниченные и динамические ресурсы

Батарея — главный лимитирующий фактор; вычисления, сеть и экран расходуют энергию.
Память и хранилище ограничены; ОС может выгрузить приложение из памяти.
CPU/GPU слабее настольных; важна энергоэффективность, а не пиковая мощность.

1.2. Доступ к сенсорам и аппаратуре

GPS, акселерометр, гироскоп, магнитометр, барометр.
Камера, микрофон, динамики, вибромотор.
Биометрия (отпечаток, Face ID), NFC, Bluetooth.
Эти возможности недоступны (или ограничены) обычным веб‑страницам и десктоп‑программам.

1.3. Особый жизненный цикл

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

1.4. Контекстная адаптация и среда

Нестабильная сеть (Wi‑Fi/мобильная/офлайн), смена локации, прерывания (звонки, уведомления).
Персонализация под пользователя и условия использования.

1.5. Особая модель дистрибуции

Распространение через магазины (App Store, Google Play) с модерацией и правилами.
Обязательная подпись, версионирование, обновления, политика приватности.

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

2. Подходы к разработке

Существует четыре основных подхода. Выбор между ними — ключевое архитектурное решение проекта.

2.1. Нативные приложения

Код пишется на языках и с помощью SDK конкретной платформы.

iOS: Swift / Objective‑C, инструменты Xcode.
Android: Kotlin / Java, инструменты Android Studio.

Плюсы: максимальная производительность, полный доступ к API и сенсорам, лучший UX, быстрая поддержка новинок ОС. Минусы: две отдельные кодовые базы, дороже и дольше, нужны разные специалисты.

2.2. Кроссплатформенные приложения

Единый код компилируется/исполняется на нескольких платформах через общий слой.

React Native (JS/TS) — рендерит нативные компоненты.
Flutter (Dart) — собственный движок отрисовки.

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

2.3. Гибридные приложения

Веб‑приложение (HTML/CSS/JS), упакованное в нативный контейнер (WebView) с плагинами доступа к устройству.

Apache Cordova, Capacitor, Ionic.

Плюсы: переиспользование веб‑навыков и кода, очень быстрый старт, единая база для web/iOS/Android. Минусы: производительность и плавность ниже нативной, UX «не родной», доступ к железу через плагины ограничен.

2.4. PWA (Progressive Web Apps)

Веб‑приложение, которое благодаря Service Worker, манифесту и кэшу ведёт себя «как приложение»: работает офлайн, шлёт пуши, ставит иконку на домашний экран.

Плюсы: не требует установки из магазина, мгновенные обновления, единый код, низкий порог входа. Минусы: ограниченный доступ к сенсорам и системным функциям (особенно на iOS), нет полноценного присутствия в магазинах, зависимость от возможностей браузера.

2.5. Сравнение подходов

Критерий	Нативные	Кроссплатформенные	Гибридные	PWA
Языки/стек	Swift, Kotlin	JS/TS, Dart	HTML/CSS/JS	HTML/CSS/JS
Кодовых баз	2 (iOS+Android)	1	1	1
Производительность	Максимальная	Близкая к нативной	Средняя	Средняя/низкая
Доступ к железу	Полный	Широкий	Через плагины	Ограниченный
Качество UX	Эталонное	Высокое	Среднее	Зависит от браузера
Скорость разработки	Низкая	Высокая	Очень высокая	Очень высокая
Стоимость	Высокая	Средняя	Низкая	Низкая
Дистрибуция	Магазины	Магазины	Магазины	Браузер/ссылка

2.6. Когда что выбирать

Нативное — игры/графика с высокой нагрузкой, тесная работа с железом, премиальный UX, ресурсы на две команды.
Кроссплатформенное — типичный бизнес‑продукт под iOS и Android при ограниченном бюджете и сроках (наш курс — этот путь, Expo/React Native).
Гибридное — нужно быстро «обернуть» существующий веб‑продукт в приложение.
PWA — контентные сервисы, где важны охват и мгновенные обновления, а доступ к железу не критичен.

3. Классификация приложений

3.1. По назначению

Игры — от казуальных до AAA, часто с высокой нагрузкой на GPU.
Бизнес/корпоративные — CRM, ERP, банковские клиенты, документооборот.
Социальные сети и коммуникации — мессенджеры, соцсети, почта, видеозвонки.
Утилиты/инструментальные — калькуляторы, заметки, файловые менеджеры, фонарик.
Образовательные — курсы, словари, электронные учебники, тренажёры.
Развлекательные/медиа — стриминг видео и музыки, новости, подкасты.
Здоровье и фитнес — трекеры активности, шагомеры, медицинские дневники.

3.2. По зависимости от сети

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

Тип по сети	Сеть	Примеры	Особенности проектирования
Онлайн	Обязательна	Стриминг, онлайн‑игры	Обработка задержек и обрывов связи
Офлайн	Не нужна	Калькулятор, заметки	Всё хранится и считается локально
Гибридный	Желательна	Карты, почта, заметки с облаком	Локальный кэш + синхронизация

Классификации не взаимоисключающие: одно приложение можно описывать одновременно по способу реализации, назначению и сетевой зависимости (например, «кроссплатформенный гибридный по сети мессенджер»).

4. Базовые презентационные паттерны

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

Общий элемент всех трёх паттернов — Model: данные и бизнес‑логика предметной области, не зависящие от способа отображения.

4.1. MVC (Model–View–Controller)

Model — данные и логика.
View — отображение, пользовательский интерфейс.
Controller — принимает ввод от View, обновляет Model, выбирает View.

Поток данных: пользователь → View → Controller → Model → (обновление) → View.

Особенность: классический паттерн, но на практике Controller часто разрастается и берёт слишком много (проблема «Massive View Controller» в iOS). View и Model могут быть связаны напрямую.

4.2. MVP (Model–View–Presenter)

Model — данные и логика.
View — пассивна, только отображает и передаёт события.
Presenter — вся логика представления; обращается к Model и обновляет View через интерфейс.

Поток данных: пользователь → View → Presenter → Model → Presenter → View.

Особенность: View и Presenter связаны через абстракцию (интерфейс), что упрощает модульное тестирование. View максимально «глупая».

4.3. MVVM (Model–View–ViewModel)

Model — данные и логика.
View — декларативный UI, подписан на ViewModel.
ViewModel — состояние и команды для View; не знает о конкретной View.

Поток данных: View ↔ ViewModel (двусторонняя привязка данных, data binding); ViewModel → Model.

Особенность: связь View и ViewModel через привязку данных — изменения состояния автоматически отражаются в UI. Естественен для декларативных фреймворков (SwiftUI, Jetpack Compose, а также React/React Native с управлением состоянием).

4.4. Сравнение паттернов

Критерий	MVC	MVP	MVVM
Третий компонент	Controller	Presenter	ViewModel
Связь View ↔ логика	Прямая	Через интерфейс	Через привязку данных
Роль View	Активная	Пассивная	Реактивная
Знает ли логика о View	Да	Да (через интерфейс)	Нет
Тестируемость	Низкая/средняя	Высокая	Высокая
Привязка данных	Нет	Нет	Да
Типичная среда	Ранний iOS, веб	Android (классический)	SwiftUI, Compose, React

Помимо этих базовых паттернов существуют производные и более строгие подходы (MVVM‑C, VIPER, Clean Architecture), цель которых — ещё сильнее разделить ответственность и сделать домен независимым от платформы. Их мы затронем в следующих разделах курса.

Краткие итоги

Мобильное приложение — отдельный класс ПО из‑за ограниченных ресурсов, доступа к сенсорам, особого жизненного цикла и магазинной модели дистрибуции.
Четыре подхода к разработке: нативный (производительность и UX ценой двух баз), кроссплатформенный (баланс цены и качества), гибридный (быстрое «оборачивание» веба), PWA (охват и мгновенные обновления без магазина).
Приложения классифицируют по способу реализации, по назначению (игры, бизнес, соцсети, утилиты и др.) и по зависимости от сети (онлайн, офлайн, гибрид).
Презентационные паттерны MVC, MVP и MVVM по‑разному распределяют ответственность между Model, View и третьим компонентом; ключевое отличие — способ связи View с логикой и наличие привязки данных.
Для нашего курса выбран кроссплатформенный путь (Expo/React Native) с реактивным подходом к состоянию, близким к идее MVVM.

Вопросы для самопроверки

В чём отличие нативных, кроссплатформенных, гибридных приложений и PWA? Когда какой подход выбрать?
Как классифицируются мобильные приложения по назначению?
Как классифицируются приложения по зависимости от сети и как это влияет на проектирование?
Какие характеристики выделяют мобильное приложение в отдельный класс ПО?
В чём суть и отличия паттернов MVC, MVP и MVVM? Как в каждом организован поток данных?