Перейти к содержанию

Обзор архитектуры 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:

Порядок регистрации сервисов

  1. Внешние пакеты: SharedPreferences, HTTP Client, UUID
  2. Основные сервисы: Database, PyTorch, User, Classification
  3. Репозитории: Слой доступа к данным
  4. Модели представления: Слой бизнес-логики
  5. Провайдеры: Управление состоянием

Граф зависимостей

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

Паттерн потока состояния

  1. Взаимодействие пользователя: Пользователь выполняет действие в UI
  2. Обновление ViewModel: ViewModel обрабатывает действие и обновляет состояние
  3. Уведомление Provider: ViewModel уведомляет слушателей через ChangeNotifier
  4. Перестроение UI: Consumer виджеты перестраиваются с новым состоянием
  5. Взаимодействие с 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 обеспечивают организованность и тестируемость кодовой базы по мере роста сложности и функций приложения.