Обзор архитектуры CulicidaeLab¶
Введение¶
CulicidaeLab — это мобильное приложение Flutter, предназначенное для идентификации видов комаров и распространения информации о заболеваниях. Приложение использует классификацию изображений на основе ИИ с использованием моделей PyTorch Lite для идентификации видов комаров по фотографиям, сделанным пользователями, и предоставляет комплексную информацию о заболеваниях, переносимых комарами.
Высокоуровневая архитектура¶
Приложение следует паттерну слоистой архитектуры с четким разделением ответственности:
graph TB
subgraph "Слой представления"
UI[Экраны и виджеты]
VM[Модели представления]
P[Провайдеры]
end
subgraph "Слой бизнес-логики"
S[Сервисы]
R[Репозитории]
end
subgraph "Слой данных"
DB[(База данных SQLite)]
API[Внешние API]
ML[Модели PyTorch]
SP[Общие настройки]
end
subgraph "Внешние зависимости"
CAM[Камера]
GPS[Службы геолокации]
NET[Сеть]
FS[Файловая система]
end
UI --> VM
VM --> P
VM --> R
R --> S
S --> DB
S --> API
S --> ML
S --> SP
S --> CAM
S --> GPS
S --> NET
S --> FS
Реализация паттерна MVVM¶
CulicidaeLab реализует архитектурный паттерн Model-View-ViewModel (MVVM) с Provider для управления состоянием:
Слой представления¶
- Экраны: Основные компоненты UI, представляющие различные страницы приложения
- Виджеты: Переиспользуемые компоненты UI и пользовательские виджеты
- Навигация: Управление маршрутами и переходами между экранами
Слой модели представления¶
- ClassificationViewModel: Управляет рабочим процессом классификации комаров
- DiseaseInfoViewModel: Обрабатывает отображение информации о заболеваниях
- MosquitoGalleryViewModel: Контролирует функциональность просмотра галереи
Слой модели¶
- Модели данных: Представляют основные сущности (Mosquito, Disease, Observation)
- Репозитории: Абстрагируют доступ к данным и бизнес-логику
- Сервисы: Обрабатывают специфическую функциональность (ИИ, База данных, Сеть)
Отношения компонентов¶
Основные компоненты¶
graph LR
subgraph "Компоненты UI"
HS[HomeScreen]
CS[ClassificationScreen]
GS[GalleryScreen]
DS[DiseaseScreen]
end
subgraph "Модели представления"
CVM[ClassificationViewModel]
DVM[DiseaseInfoViewModel]
GVM[GalleryViewModel]
end
subgraph "Репозитории"
CR[ClassificationRepository]
MR[MosquitoRepository]
end
subgraph "Сервисы"
CLS[ClassificationService]
DBS[DatabaseService]
US[UserService]
end
HS --> CVM
CS --> CVM
GS --> GVM
DS --> DVM
CVM --> CR
GVM --> MR
DVM --> MR
CR --> CLS
CR --> MR
MR --> DBS
CVM --> US
Архитектура потока данных¶
Рабочий процесс классификации¶
sequenceDiagram
participant User as Пользователь
participant UI as ClassificationScreen
participant VM as ClassificationViewModel
participant Repo as ClassificationRepository
participant CS as ClassificationService
participant ML as PyTorchWrapper
participant DB as DatabaseService
User->>UI: Сделать/Выбрать изображение
UI->>VM: processImage(image)
VM->>Repo: classifyImage(image)
Repo->>CS: classifyMosquito(image)
CS->>ML: predict(imageBytes)
ML-->>CS: PredictionResult
CS-->>Repo: ClassificationResult
Repo->>DB: saveObservation(result)
Repo-->>VM: ClassificationResult
VM-->>UI: Обновить состояние UI
UI-->>User: Показать результаты
Поток сохранения данных¶
graph TD
A[Действие пользователя] --> B[ViewModel]
B --> C[Repository]
C --> D{Источник данных}
D -->|Локальные данные| E[DatabaseService]
D -->|Удаленные данные| F[HTTP Client]
D -->|Настройки пользователя| G[SharedPreferences]
E --> H[(SQLite)]
F --> I[Внешний API]
G --> J[Локальное хранилище]
Внедрение зависимостей¶
Приложение использует GetIt для внедрения зависимостей, настроенного в lib/locator.dart:
Порядок регистрации сервисов¶
- Внешние пакеты: SharedPreferences, HTTP Client, UUID
- Основные сервисы: Database, PyTorch, User, Classification
- Репозитории: Слой доступа к данным
- Модели представления: Слой бизнес-логики
- Провайдеры: Управление состоянием
Граф зависимостей¶
graph TD
SP[SharedPreferences] --> US[UserService]
SP --> LP[LocaleProvider]
UUID[Uuid] --> US
HTTP[HTTP Client] --> CR[ClassificationRepository]
DBS[DatabaseService] --> MR[MosquitoRepository]
PW[PytorchWrapper] --> CS[ClassificationService]
CS --> CR
MR --> CR
MR --> DVM[DiseaseInfoViewModel]
MR --> GVM[GalleryViewModel]
CR --> CVM[ClassificationViewModel]
US --> CVM
Управление состоянием с Provider¶
Архитектура Provider¶
graph TB
subgraph "Дерево Provider"
LP[LocaleProvider]
CVM[ClassificationViewModel]
DVM[DiseaseInfoViewModel]
GVM[GalleryViewModel]
end
subgraph "Дерево виджетов"
MA[MaterialApp]
HP[HomePage]
CS[ClassificationScreen]
GS[GalleryScreen]
DS[DiseaseScreen]
end
LP --> MA
CVM --> CS
GVM --> GS
DVM --> DS
Паттерн потока состояния¶
- Взаимодействие пользователя: Пользователь выполняет действие в UI
- Обновление ViewModel: ViewModel обрабатывает действие и обновляет состояние
- Уведомление Provider: ViewModel уведомляет слушателей через ChangeNotifier
- Перестроение UI: Consumer виджеты перестраиваются с новым состоянием
- Взаимодействие с Repository: ViewModel вызывает методы репозитория для операций с данными
Интеграция модели ИИ¶
Интеграция PyTorch Lite¶
graph LR
subgraph "Конвейер ИИ"
IMG[Входное изображение] --> PREP[Предобработка изображения]
PREP --> MODEL[Модель PyTorch Lite]
MODEL --> POST[Постобработка]
POST --> RESULT[Результат классификации]
end
subgraph "Управление моделью"
ASSETS[Ресурсы модели] --> LOADER[Загрузчик модели]
LOADER --> CACHE[Кэш модели]
CACHE --> MODEL
end
Архитектура сервиса классификации¶
- Предобработка изображений: Изменение размера, нормализация и форматирование изображений для входа модели
- Вывод модели: Выполнение предсказания модели PyTorch Lite
- Обработка результатов: Парсинг выхода модели и сопоставление с видами комаров
- Оценка достоверности: Оценка достоверности предсказания и обработка результатов с низкой достоверностью
Архитектура базы данных¶
Схема SQLite¶
erDiagram
MOSQUITO {
int id PK
string species_name
string common_name
string description
string habitat
string distribution
string image_path
datetime created_at
datetime updated_at
}
DISEASE {
int id PK
string name
string description
string symptoms
string prevention
string treatment
string image_path
datetime created_at
datetime updated_at
}
OBSERVATION {
int id PK
string user_id
int mosquito_id FK
string image_path
float confidence_score
double latitude
double longitude
datetime observed_at
datetime created_at
}
MOSQUITO_DISEASE {
int mosquito_id FK
int disease_id FK
}
MOSQUITO ||--o{ OBSERVATION : "identified_as"
MOSQUITO ||--o{ MOSQUITO_DISEASE : "carries"
DISEASE ||--o{ MOSQUITO_DISEASE : "carried_by"
Паттерн доступа к данным¶
- Паттерн Repository: Абстрагирование доступа к данным через интерфейсы репозиториев
- Сервисный слой: Бизнес-логика отделена от доступа к данным
- Классы моделей: Строго типизированные модели данных с валидацией
- Поддержка миграций: Версионирование схемы базы данных и обработка миграций
Архитектура безопасности¶
Защита данных¶
- Локальное хранилище: База данных SQLite с шифрованием чувствительных данных
- Конфиденциальность пользователя: Анонимная идентификация пользователя с UUID
- Безопасность изображений: Локальное хранение изображений с безопасными путями к файлам
- Сетевая безопасность: HTTPS для всех внешних API коммуникаций
Управление разрешениями¶
- Доступ к камере: Требуется для функциональности захвата изображений
- Службы геолокации: Опционально для геотегирования наблюдений
- Доступ к хранилищу: Требуется для обработки и кэширования изображений
- Доступ к сети: Требуется для интеграции внешних API
Соображения производительности¶
Управление памятью¶
- Обработка изображений: Эффективная загрузка и освобождение изображений
- Кэширование модели: Модель PyTorch загружается один раз и кэшируется
- Соединения с базой данных: Пулинг соединений и правильное освобождение
- Жизненный цикл виджетов: Правильное освобождение контроллеров и слушателей
Стратегии оптимизации¶
- Ленивая загрузка: Сервисы и модели загружаются по требованию
- Кэширование изображений: Кэшированные сетевые изображения для офлайн доступа
- Индексирование базы данных: Оптимизированные запросы с правильным индексированием
- Фоновая обработка: Тяжелые операции перенесены в фоновые потоки
Архитектура тестирования¶
Слои тестирования¶
graph TB
subgraph "Пирамида тестирования"
UT[Модульные тесты]
IT[Интеграционные тесты]
WT[Тесты виджетов]
E2E[Сквозные тесты]
end
subgraph "Цели тестирования"
M[Модели]
S[Сервисы]
R[Репозитории]
VM[Модели представления]
W[Виджеты]
F[Полный поток приложения]
end
UT --> M
UT --> S
IT --> R
IT --> VM
WT --> W
E2E --> F
Стратегия тестирования¶
- Модульные тесты: Тестирование отдельных компонентов в изоляции
- Интеграционные тесты: Тестирование взаимодействий компонентов и потока данных
- Тесты виджетов: Тестирование компонентов UI и взаимодействий пользователя
- Сквозные тесты: Тестирование полных пользовательских рабочих процессов
Архитектура развертывания¶
Конфигурация сборки¶
- Разработка: Отладочные сборки с инструментами разработки
- Промежуточная: Релизные сборки с промежуточными API эндпоинтами
- Продакшн: Оптимизированные релизные сборки с продакшн конфигурацией
Платформо-специфические соображения¶
- Android: Конфигурация сборки Gradle и разрешения
- iOS: Настройки проекта Xcode и конфигурация Info.plist
- Управление ресурсами: Платформо-специфическая оптимизация ресурсов
Точки расширения¶
Области кастомизации¶
- Новые модели классификации: Архитектура плагинов для дополнительных моделей ИИ
- Источники данных: Расширяемый паттерн репозитория для новых источников данных
- Темы UI: Настраиваемая система тем
- Локализация: Поддержка дополнительных языков и регионов
Возможности интеграции¶
- Внешние API: Фреймворк интеграции RESTful API
- Сторонние сервисы: Система плагинов для интеграции внешних сервисов
- Экспорт данных: Настраиваемые форматы экспорта данных и назначения
- Аналитика: Подключаемые системы аналитики и мониторинга
Заключение¶
Архитектура CulicidaeLab обеспечивает прочную основу для масштабируемого, поддерживаемого и расширяемого мобильного приложения. Четкое разделение ответственности, внедрение зависимостей и паттерн MVVM обеспечивают организованность и тестируемость кодовой базы по мере роста сложности и функций приложения.