Потоковый ответ AI (Streaming Response) в мобильном приложении

Без стриминга AI-ассистент неприемлем для пользователей. Ожидание 5–10 секунд пустого экрана перед появлением ответа — это не «медленно», это «сломано». Согласно исследованию пользовательского опыта, задержка более 2 секунд снижает вовлечённость на 40% и увеличивает отток на 25%. Наши инженеры решают эту задачу с помощью Server-Sent Events (SSE) или WebSocket: первый токен приходит через 300–600 мс, пользователь видит, что модель «думает». Мы реализуем побуквенный вывод текста с учётом особенностей мобильных платформ — iOS, Android и Flutter. В этой статье разберём ключевые технические аспекты: от парсинга SSE до рендеринга Markdown без артефактов. Наша команда имеет 10+ лет опыта в мобильной разработке и реализовала 500+ проектов, что гарантирует стабильность решения.

Как реализовать потоковый ответ AI в мобильном приложении?

Проблемы потокового ответа AI в мобильном приложении

Стриминг AI-ответа — не просто открыть socket. Вот реальные сложности:

• Парсинг SSE-потока на мобильном клиенте: iOS требует AsyncBytes, Android — OkHttp + callbackFlow. Ошибка в парсинге приводит к потере данных или зависанию.
• Рендеринг незавершённого Markdown: если ответ содержит **жирный текст, а клиент рендерит его до закрывающего **, появляются артефакты. Мы используем буферизацию или отложенный рендеринг.
• Отмена запроса: пользователь нажал «Стоп» — нужно корректно прервать поток и сохранить уже полученный текст в историю диалога. На iOS Task.cancel() автоматически отменяет for await, на Android — call.cancel().
• Разрывы соединения: мобильная сеть нестабильна. При обрыве мы сохраняем частичный ответ и предлагаем «Продолжить», отправляя новый запрос с контекстом.

Как работает парсинг SSE на iOS?

Большинство LLM API отдают стриминг через SSE (определение в MDN). Каждое событие — строка data: {json}, пустая строка — разделитель. Нативный способ на iOS — URLSession + AsyncBytes (iOS 15+):

func streamCompletion(request: URLRequest) -> AsyncThrowingStream<String, Error> {
    AsyncThrowingStream { continuation in
        Task {
            let (bytes, response) = try await URLSession.shared.bytes(for: request)
            guard (response as? HTTPURLResponse)?.statusCode == 200 else {
                continuation.finish(throwing: APIError.badStatus)
                return
            }
            for try await line in bytes.lines {
                guard line.hasPrefix("data: ") else { continue }
                let payload = String(line.dropFirst(6))
                guard payload != "[DONE]" else {
                    continuation.finish()
                    return
                }
                if let data = payload.data(using: .utf8),
                   let chunk = try? JSONDecoder().decode(StreamChunk.self, from: data),
                   let delta = chunk.choices.first?.delta.content {
                    continuation.yield(delta)
                }
            }
        }
    }
}

Использование в ViewModel:

func sendMessage(_ text: String) {
    Task { @MainActor in
        currentResponse = ""
        for try await token in streamCompletion(request: buildRequest(text)) {
            currentResponse += token
        }
    }
}

@MainActor гарантирует обновление UI на главном потоке без явного DispatchQueue.main.async.

Android: OkHttp + EventSource

На Android нативного SSE-клиента нет. OkHttp — стандартный выбор:

class SSEClient(private val client: OkHttpClient) {
    fun stream(request: Request): Flow<String> = callbackFlow {
        val call = client.newCall(request)
        call.enqueue(object : Callback {
            override fun onResponse(call: Call, response: Response) {
                response.body?.source()?.let { source ->
                    while (!source.exhausted()) {
                        val line = source.readUtf8Line() ?: break
                        if (line.startsWith("data: ")) {
                            val payload = line.removePrefix("data: ")
                            if (payload == "[DONE]") {
                                close()
                                return
                            }
                            // parse JSON, extract delta
                            trySend(extractDelta(payload))
                        }
                    }
                }
                close()
            }

            override fun onFailure(call: Call, e: IOException) = close(e)
        })
        awaitClose { call.cancel() }
    }
}

callbackFlow — правильный способ превратить callback-based OkHttp в Kotlin Flow. trySend вместо send — не блокирует поток.

Для Flutter: используем dio с ResponseType.stream или dart:io HttpClient напрямую.

Почему важно буферизировать Markdown?

Если в ответе есть Markdown (жирный, код, списки), рендерить нужно аккуратно. Проблема: Markdown-парсер видит незавершённые конструкции — например, **жирный без закрывающего ** — и рендерит артефакты.

Два подхода:

1. Рендерить только завершённые блоки — буфер накапливает до закрывающего токена, потом рендерит. Даёт чистый результат, но добавляет задержку.
2. Рендерить как plain text во время стриминга, Markdown — после завершения — проще и надёжнее для большинства ассистентов.

На iOS — AttributedString с NSMarkdownParser для финального рендера, Text(currentResponse) во время стриминга. На Android — Markwon библиотека для финального рендера в TextView.

Отмена запроса и восстановление после сбоев

Пользователь нажал «Стоп» — нужно корректно отменить стриминговый запрос. На iOS: Task.cancel() автоматически отменяет URLSession.bytes — for await выбросит CancellationError. На Android: call.cancel() через OkHttp, flow.cancellation(). После отмены мы обязательно сохраняем уже полученный частичный ответ в историю диалога — пользователь видел текст, и он должен остаться.

Мобильная сеть нестабильна. Стриминговый запрос прерывается на середине ответа. Правильная реакция: показать то, что уже получено, и предложить «Продолжить». Сохранить lastTokenIndex или последний stop_reason нельзя — API не поддерживает возобновление с середины. Нужно генерировать заново, передав в контекст уже полученную часть ответа.

Сравнение протоколов: SSE vs WebSocket

Для AI-стриминга SSE достаточно. WebSocket оправдан, если нужна двусторонняя связь (например, стриминг аудио + текст).

Сравнение реализации на платформах

Этапы реализации потокового ответа под ключ

1. Аналитика: выбор протокола и архитектуры, проектирование API-запросов.
2. Реализация клиента: парсинг SSE, управление состоянием, отмена запроса.
3. Рендеринг: настройка отображения текста, поддержка Markdown.
4. Тестирование: проверка стабильности на слабых сетях (3G, Edge), edge-кейсы.
5. Деплой: интеграция в существующее приложение, публикация в App Store / Google Play.

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

• Исходный код модуля стриминга для iOS / Android / Flutter.
• Интеграция с выбранным LLM API (OpenAI, Anthropic, локальная модель).
• Документация по доработкам и поддержке.
• Настройка аналитики для отслеживания ошибок и задержек.
• Обучение команды заказчика.

Ориентировочные сроки: 4–6 рабочих дней на одну платформу, 1–1,5 недели на обе. Для Flutter — 5–7 дней. Стоимость рассчитывается индивидуально, экономия средств от внедрения достигает 30–50%.

Наша команда имеет 10+ лет опыта в мобильной разработке и реализовала 500+ проектов с аудиторией от 100 000 пользователей. Гарантируем стабильную работу даже при нестабильном соединении. Если у вас есть вопросы или вы хотите заказать реализацию, свяжитесь с нами — оценим проект. Получите консультацию уже сегодня.