Android-приложение без Firebase — миф или реальность?

Привет! Я Илья Илемков. С 2017 года успел поработать в Directum, EPAM Systems и Huawei. Попробовал почти всё в мобильной разработке: от написания обычных клиентских приложений до разработки системного ПО под Android. Теперь я старший программист-разработчик в инфраструктурной команде ВКонтакте — занимаюсь основным приложением и не только.

В этой статье на основе опыта работы с Firebase расскажу о плюсах, минусах и альтернативах использования этой платформы. Текст будет полезен тем, кто разрабатывает или планирует разрабатывать мобильные приложения.

В основе статьи — онлайн BoF-сессия на IT-конференции Mobius 2024, во время которой я обсуждал Firebase с коллегой Сергеем Мясниковым из ВКонтакте, Кириллом Поповым из ОК, Артёмом Ковардиным из RuStore и Алексеем Гладковым — мобильным разработчиком, автором проекта Mobile Developer.

Что такое Firebase?

Платформа Firebase популярна как набор решений для упрощения разработки мобильных приложений. С помощью её инструментов можно развернуть бэкенд со своей серверной логикой, подключить push-сообщения и аналитику, получать отчёты об ошибках, проводить A/B-тестирование. Платформа облачная: все ресурсы приложений, в том числе базы данных и клиентская аналитика, хранятся на серверах Google.

Самые востребованные инструменты Firebase:

• Firebase Cloud Messaging (FCM) — позволяет отправлять push-сообщения на устройства пользователей;
• облачная служба Firebase Remote Config — позволяет вносить изменения в конфигурацию приложения в режиме реального времени;
• сервис Firebase Crashlytics — помогает находить в приложениях причины зависаний, сбоев и медленной работы, собирать ошибки с продакшена, систематизировать их и фильтровать;
• сервис Firebase Performance Monitoring — инструмент для аналитики, позволяет отслеживать ключевые метрики: использование памяти, CPU, сетевого трафика;
• сервис Google Analytics — инструмент для продуктовой аналитики, позволяет получать информацию об использовании приложений и вовлечённости пользователей.
  

Именно с этих инструментов независимые разработчики и стартаперы обычно начинают знакомство с Firebase.

Альтернативы Firebase: почему они важны?

У Firebase действительно много полезных инструментов для мобильной разработки. Однако некоторые из них несовершенны и могут замедлить развитие проекта. Именно поэтому важны альтернативы, с которыми можно более точечно работать над продуктом.

Firebase — хороший выбор для старта приложения, в нём есть всё необходимое для запуска. Можно без лишних затрат опробовать технологии, поиграться с ними. Но сейчас мы находимся на этапе, когда Firebase постепенно теряет свою монополию. Альтернативные механики начинают давать не просто аналоги инструментам платформы, они открывают много новых опций. Поэтому вы даже выиграете, если будете использовать в том числе и альтернативные решения

Кирилл Поповруководитель направления Android-разработки ОК, основатель и руководитель сервиса Tracer

Есть ещё одна причина, почему важны альтернативы Firebase: разработчикам необходимо поддерживать свои продукты на версиях Android без сервисов Google, например на ОС, собранных на базе AOSP. Но вне зависимости от операционной системы и её версии лучше держать в голове (а желательно в инструментарии) запасные варианты на случай, если что-то пойдёт не так.

Чем можно заменить FCM?

Push-сообщения — один из самых востребованных инструментов Firebase. Часто именно из-за него разработчики начинают использовать эту платформу в своих проектах; у них просто нет вариантов — push-сообщения используют Google-сервисы, которые, в свою очередь, имеют «системные привилегии».

Однако если вы собираетесь делать приложение для рынка России, то крайне желательно рассмотреть и другие инструменты и подумать над запасными решениями. Часть рынка РФ занимают, например, смартфоны Huawei, в которых нет сервисов из Google Play.

• RuStore Push — фактически альтернативный вариант для доставки push-сообщений, причём со своим транспортом. Чтобы упростить интеграцию, есть и омниканальное решение — Universal Push. Благодаря ему в рамках одного SDK можно обеспечить отправку в HMS, FCM и RuStore. Использование универсального API позволит подготовить некоторый fallback-механизм и поможет несколько повысить доставляемость уведомлений.
• Отдельные вендоры смартфонов разрабатывают свои решения для своих устройств. Например есть облачная служба Push Kit для рассылки уведомлений. С помощью неё можно отправлять push-сообщения на устройства Android и iOS, а также в веб-приложения.
• Если вы работаете в сфере B2B, то на рынке есть много MDM-решений — некоторые из них базируются на AOSP со своим транспортом для push-сообщений и со своим сервисом, который интегрируется в инфраструктуру заказчика. Этот вариант обычно используют компании, чтобы управлять устройствами сотрудников.

Когда проект только стартует, в нём обычно используется лишь Firebase. В дальнейшем желательно сразу заложить в проект несколько вариантов: например, RuStore Push, HMS Core, Firebase и один из омниканальных сервисов, — это позволит обезопасить себя и повысить доставляемость

Алексей Гладковмобильный разработчик, автор проекта Mobile Developer

Remote Config: какие есть аналоги?

Второй по популярности инструмент Firebase — Remote Config. Из названия понятно, что сервис позволяет добавлять в приложение параметры, которые можно изменять удалённо с бэкенда. Он достаточно легко интегрируется в мобильные приложения — как на Android, так и на iOS.

Одно из главных достоинств Remote Config — аналитика. Благодаря этому инструменту можно проводить A/B-тесты и изучать аудиторию приложения на основе таких критериев, как возраст или увлечения.

В качестве альтернативы FRC можно назвать RuStore Remote Config, который также позволяет конфигурировать приложения и проводить A/B-тесты. Это решение доступно для приложений на устройствах c Android и iOS и позволяет заменить Firebase.

Возможность конфигурировать свои приложения и проводить А/В-тесты — важная часть любого проекта, которая помогает делать его лучше для пользователей. Я советую диверсифицировать риски и использовать разные инструменты, чтобы не зависеть от одного сервиса

Артём Ковардинруководитель команды разработки инструментов RuStore

Анализ ошибок: Firebase vs Tracer

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

Сервис Firebase Crashlytics предоставляет подобную функциональность поиска ошибок. Он пользуется популярностью среди разработчиков, однако возможности сервиса сравнительно ограничены: в нём неудобный поиск, неточная группировка событий (ошибок, ANR) по типу, нет инструментов для работы с non-fatal ошибками, из-за чего они могут создавать свалку. И это только небольшой список проблем — на деле их гораздо больше.

В вопросе анализа ошибок у Firebase есть крепкая альтернатива — сервис Tracer от ОК. Если сравнивать эти два инструмента, то Tracer не только предлагает похожую функциональность по анализу, но и расширяет инструментарий разработчика. В нём есть:

• полнотекстовый поиск по стектрейсу;
• полноценный поиск по User ID — не только крешей, но и любых событий;
• возможность самому на клиенте решать, как группировать ошибки. Например, отдельно отслеживать все баги, связанные с авторизацией;
• поиск и фильтрация по любым полям и атрибутам;
• поддержка A/B-тестов;
• возможность профилирования и анализа утечек памяти в продакшене с загрузкой дампов памяти.

Мы начали создавать Tracer, когда разработчики Crashlytics, по ощущениям, совсем его забросили. Главная страница долго грузилась, сервис не умел сортировать ошибки по количеству задетых пользователей, не было полноценного поиска. В какой-то момент мы с коллегами решили делать свой продукт, в котором не было бы этих проблем

Кирилл Поповруководитель направления Android-разработки ОК, основатель и руководитель сервиса Tracer

Ещё одна альтернатива Crashlytics — сервис Sentry. Это open-source проект, главная особенность которого — возможность развёртки внутри собственной инфраструктуры. Это позволяет минимизировать риски, связанные с утечкой чувствительных данных: например, словарей обфускации или логов с пользовательскими данными. Однако в России легально приобрести и развернуть self-hosted решение от Sentry не выйдет. К тому же на больших объёмах данных оно работает не идеально. И при всём этом требует затрат на поддержку и инфраструктуру.

Аналитика от Firebase: альтернативы есть

Аналитика, прежде всего, помогает разработчикам зарабатывать на их продуктах. Без неё не получится закупить трафик и будет непонятно, как много времени пользователь проводит в приложении и сколько удалось заработать с каждого источника.

Сервис для аналитики от Firebase — Google Analytics — позволяет увидеть общую картину того, что происходит в приложении. Однако для глубокого погружения он не очень подходит — для этого лучше использовать более локальные решения. Кстати, их довольно много: Google Analytics можно назвать самым легко заменяемым продуктом от Firebase.

Например, сервис MyTracker от VK. Он ориентирован на российский рынок, менее загружен, чем Performance Monitoring. Соответственно, позволяет более точно анализировать ключевые показатели мобильных приложений, эффективность источников трафика и монетизации. С помощью него можно сегментировать аудиторию и строить прогнозы LTV, оттока. Сервис интегрирован с RuStore и другими альтернативными сторами. На данных и сегментах MyTracker работают Remote Config и могут работать push-уведомления RuStore.

Ещё один вариант — написать свой движок для аналитики.

Аналитика от Google позволяет только примерно представить, что происходит с приложением. Если вам необходимо детальное понимание, то лучше всегда держать „второе мнение“. Обычно мы используем внешние системы аналитики и самописные вещи. В этом есть значительный плюс: не надо отдавать важные и персонализированные данные о пользователях сторонней компании

Сергей Мясниковстарший разработчик в инфраструктурной команде Android-приложения ВКонтакте

Архитектурная гибкость

Запуститься совсем без Firebase невозможно, однако у инструментов этой платформы есть альтернативы. Те решения, о которых я рассказал, дополнят необходимую функциональность. Я не призываю навсегда отказаться от Firebase — просто рекомендую проектировать архитектуру так, чтобы была возможность переключиться на другой инструмент. Благодаря этому вы сможете закрыть свои потребности, работать быстрее либо с бо́льшим удобством.