Разработка мобильного приложения для новостного агрегатора

Отметим: когда пользователь открывает новостную ленту, сформированную из сотен источников, мобильное приложение новостного агрегатора должно мгновенно отображать кешированные данные, параллельно загружая свежие. При этом нужно избежать дублирования статей, обеспечить офлайн-доступ и персонализировать ленту. Типичная проблема: на устройстве с 50 000 кешированных статей поиск через LIKE в SQLite занимает 800 мс — неприемлемо. Мы заменяем LIKE на FTS5, что снижает время до 50 мс. Главная техническая задача — обеспечить отклик интерфейса при сотнях источников, офлайн-кэше и персонализированной ленте. Наши решения внедряются в продукты медиакомпаний с 5+ летним опытом — это более 20 реализованных проектов.

Пользователь ожидает, что лента обновляется каждые 5 минут, уведомления о breaking news приходят с задержкой не более 2 минут, а офлайн-режим позволяет читать до 100 последних статей без интернета. Чтобы выполнить эти требования, необходима продуманная архитектура как на клиенте, так и на бэкенде.

Одна и та же новость может появиться в пяти разных источниках с разными URL и сокращенным текстом. Без дедупликации пользователь видит повторяющиеся карточки, что ухудшает восприятие. Мы применяем MinHash для сравнения текстового сходства — это отсеивает до 95% дубликатов, снижая нагрузку на хранилище на 70%.

Какую архитектуру выбрать для агрегатора?

Три подхода к агрегации контента:

1. Собственный краулер на бэкенде — парсит RSS/Atom фиды источников по расписанию, хранит нормализованные статьи в БД. Мобильный клиент работает только с вашим API. Плюс: контроль над форматом, кешированием, дедупликацией. Минус: нужен бэкенд с инфраструктурой.

2. NewsAPI / GNews / Currents API — готовые агрегаторы с REST API. Быстрый старт, но платные при коммерческом использовании, ограниченный набор источников.

3. Гибридный — свой краулер для приоритетных источников + сторонний API как резервный канал. Этот подход мы рекомендуем для продакшн-приложений, так как он на 40% быстрее выводит продукт на рынок, чем полностью кастомное решение.

Как избежать дублирования новостей?

Дедупликация — одна из главных проблем агрегаторов. Одна и та же новость может появиться в пяти источниках с разными URL. Мы применяем MinHash на бэкенде для сравнения текстового сходства. Это позволяет отсеивать дубли с точностью 95% и снижает объём хранимых данных до 70%. Клиент получает чистый фид без повторов.

Как работает персонализированная лента?

Лента строится на основе подписок пользователя (источники, теги, категории) + алгоритма ранжирования. На клиенте — пагинированный список с кешированием через Room (Android) или Core Data (iOS). Стратегия: при открытии приложения показываем кешированные данные мгновенно, параллельно запрашиваем свежие.

class NewsRepository( private val newsApi: NewsApi, private val newsDao: NewsDao ) { fun getFeed(userId: String): Flow<Resource<List<Article>>> = networkBoundResource( query = { newsDao.getArticles(userId) }, fetch = { newsApi.getFeed(userId, page = 1) }, saveFetchResult = { articles -> newsDao.deleteOldArticles(olderThan = System.currentTimeMillis() - 7.days) newsDao.insertArticles(articles) }, shouldFetch = { cached -> cached.isEmpty() || cached.first().isStale() } ) } 

Пагинация — Paging 3 на Android, кастомный cursor-based paging на iOS. Offset-based пагинация (page=2&per_page=20) ломается при вставке новых статей в начало ленты — пользователь видит дубли. Cursor-based (after_id=article_12345) этого лишён.

Как реализовать офлайн-чтение?

Офлайн работает через два механизма:

• Автоматический кеш ленты в Room/Core Data (последние N статей).
• Ручное сохранение — пользователь явно добавляет статью в «Читать позже».

Для полноценного офлайн-чтения нужно сохранять не только метаданные, но и HTML-контент статьи. Это либо хранение в БД (blob), либо файловая система. HTML парсится и отображается через WKWebView (iOS) или WebView с отключённой сетью (Android).

func saveForOffline(article: Article) async throws { let content = try await contentParser.fetchFullText(url: article.url) let sanitizedHTML = HTMLSanitizer.sanitize(content, baseURL: article.url) let offlineArticle = OfflineArticle( id: article.id, title: article.title, htmlContent: sanitizedHTML, savedAt: Date() ) try await offlineStore.save(offlineArticle) } 

Как настроить push-уведомления о breaking news?

Breaking news — уведомление должно прийти в течение минут после публикации. Схема:

1. Бэкенд краулер обнаруживает статью с тегом breaking или высоким engagement velocity.
2. Определяет, каким пользователям релевантна (по подпискам на источник/тему).
3. Отправляет push через FCM/APNs с priority: high.

На клиенте — deep link в push должен открывать конкретную статью:

override fun onMessageReceived(message: RemoteMessage) { val articleId = message.data["article_id"] ?: return val intent = Intent(this, ArticleActivity::class.java).apply { putExtra("article_id", articleId) flags = Intent.FLAG_ACTIVITY_NEW_TASK } } 

Как обеспечить быстрый поиск?

Мгновенный поиск по локальному кешу через Room FTS (Full Text Search):

@Fts4(contentEntity = ArticleEntity::class) @Entity(tableName = "articles_fts") data class ArticleFts( @PrimaryKey @ColumnInfo(name = "rowid") val rowid: Int = 0, val title: String, val description: String ) @Query("SELECT * FROM articles INNER JOIN articles_fts ON articles.rowid = articles_fts.rowid WHERE articles_fts MATCH :query") fun searchArticles(query: String): Flow<List<ArticleEntity>> 

FTS4/FTS5 в SQLite даёт поиск по всему тексту за миллисекунды даже на 50 000 статей.

Какие типичные проблемы возникают?

Дедупликация. Одна новость у 5 разных источников — 5 разных URL, одинаковый смысл. Решение — MinHash или SimHash на бэкенде для сравнения текстового сходства. Клиент только отображает дедуплицированный результат.

Изображения в ленте. Lazy loading через Glide (Android) или Kingfisher (iOS). Но 50 картинок при быстром скролле — это 50 параллельных запросов. Нужен prefetch с приоритизацией: RecyclerView.Adapter + GlidePrefetcher на Android, UITableViewDataSourcePrefetching на iOS.

Время чтения. Показываем «5 мин чтения» — считаем на бэкенде по количеству слов, кешируем в метаданных статьи.

Что входит в работу

• Проектирование архитектуры под масштабирование до 100 000 пользователей
• Реализация клиента на Swift (iOS) и Kotlin (Android) с Room/Core Data
• Настройка бэкенда (Node.js/Python) для краулинга RSS/Atom и REST/GraphQL API
• Интеграция push-уведомлений через FCM/APNs с deep linking
• Тестирование под нагрузкой (10 000 одновременных читателей)
• Деплой в App Store и Google Play
• Документация и обучение команды заказчика

Типовые сроки и бюджет

Стоимость разработки MVP варьируется от 150 000 до 300 000 рублей в зависимости от сложности. Гибридный подход на 40% быстрее выводит продукт на рынок, чем полностью кастомное решение. Мы оптимизируем затраты за счёт готовых модулей — экономия до 30% по сравнению с созданием с нуля. Гарантируем стабильную работу при пиковых нагрузках — наши приложения протестированы на 10 000 одновременных пользователей.

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