Firebase Performance Monitoring е безплатен инструмент на Google за проследяване на производителността на мобилни приложения в реално време. Услугата автоматично събира метрики за време за стартиране, скорост на изобразяване на екрани и продължителност на HTTP заявки, без да изисква писане на код за основни сценарии. Според данни на Google Firebase, 2025, SDK автоматично проследява до 90% от мрежовите заявки без допълнителна конфигурация. Инструментът е достъпен за Android, iOS и уеб приложения в рамките на екосистемата Firebase.
Основни точки
Firebase Performance Monitoring е облачна услуга на Google, която събира и показва метрики за производителността на мобилни приложения. Услугата е част от набора инструменти Firebase и не изисква отделно заплащане — мониторингът е достъпен в рамките на безплатния тариф Spark (ограничение от 500 000 събития на ден) и платения Blaze. Firebase Performance автоматично генерира трасета за стандартни сценарии: cold start на екран, warm start, фонови HTTP заявки.
Архитектурата на услугата е изградена върху два типа данни: traces (трасета) и metrics (метрики). Трасето е времеви интервал с начало и край, в рамките на който се измерва продължителността на изпълнение. Метриката е числова стойност: размер на отговор, честота на грешки, скорост в байтове/сек. Всяко трасе може да съдържа множество метрики. SDK събира данни на устройството, буферира ги и ги изпраща към Firebase във фонов режим с нисък приоритет на латентност, за да не влияе на потребителското изживяване.
Според доклада на Google I/O 2024, Firebase Performance се използва в над 2 милиона приложения по целия свят. Средното време за откриване на проблем с производителността чрез Firebase Performance е 15 минути след пускане, ако са настроени аларми. Без мониторинг подобен проблем се открива средно след 2-3 дни на база жалби на потребители към поддръжката.
Crashlytics проследява сривове и фатални грешки — ситуации, при които приложението неочаквано спира. Firebase Performance следи производителността на работещото приложение: бавни екрани, дълги мрежови заявки, закъснения в отговора на UI. Crashlytics отговаря на въпроса „защо приложението се срина?„, а Performance на въпроса „защо приложението работи бавно?„. И двете услуги се интегрират чрез един SDK (Firebase Core) и данните се показват в свързани раздели на Firebase конзолата.
Firebase Performance не показва средни стойности — само персентили: P50, P75, P90, P95, P99. Това е критично за производителността: средното време скрива отклоненията. Ако 99 потребители отворят екрана за 200 ms, а един за 20 секунди, средното ще бъде ~400 ms, което изглежда приемливо. P99 ще покаже 20 секунди — реалния проблем. Firebase показва персентилите на времева скала, което позволява проследяване на регресии с точност до час.
Firebase Performance SDK се интегрира в приложението чрез стандартна интеграция: добавяне на зависимост в Gradle (Android) или чрез CocoaPods (iOS). След инициализиране на Firebase в кода, SDK автоматично започва да събира метрики без допълнителна конфигурация. Важен принцип на работа — lazy collection: SDK не изпраща данните веднага, а ги натрупва и ги предава на партиди, когато мрежовите условия са благоприятни.
За iOS SDK използва NSURLProtocol за прихващане на HTTP заявки, за Android — OkHttp Interceptor. Ако приложението не използва OkHttp, SDK автоматично обвива HttpURLConnection. Прихванатите заявки се обогатяват с метаданни: Content-Type, статус на отговор, размер в байтове, продължителност. Всички данни се предават по HTTPS към сървъра на Firebase с TLS 1.3 криптиране.
Едно от ключовите изисквания на Firebase Performance — да бъде последният plugin в списъка с Gradle plugin-ове. Ако редът е нарушен, SDK може да не прихваща всички заявки или да измерва неправилно времето за стартиране. Firebase препоръчва поставяне на plugin-а в края на plugins блока, след Crashlytics и други Google Services plugin-ове.
// build.gradle (Module: app) — правилен ред на plugin-овете
plugins {
id "com.android.application"
id "org.jetbrains.kotlin.android"
id "com.google.gms.google-services"
id "com.google.firebase.crashlytics"
id "com.google.firebase.firebase-perf" // последен!
}
dependencies {
implementation platform("com.google.firebase:firebase-bom:33.0.0")
implementation "com.google.firebase:firebase-perf"
}
Firebase Performance създава три типа автоматични трасета: screen trace (време за изобразяване на екран), app start trace (време за стартиране на приложението) и network request trace (HTTP заявки). Screen trace за Android измерва времето между извикването на Activity.onCreate и завършването на изобразяването на първия кадър. За iOS се измерва времето между viewDidLoad и viewDidAppear. Firebase автоматично създава трасе за всеки екран, използвайки името на класа Activity или ViewController.
App start trace се разделя на два типа: cold start (приложението стартира от нулата, процесът не е съществувал) и warm start (приложението се възстановява от фоново състояние). Cold start е най-критичният показател, тъй като включва инициализация на всички SDK, зареждане на DEX файлове и създаване на първото Activity. Firebase измерва cold start от момента на стартиране на процеса до пълното изобразяване на първия екран. Според препоръките на Google, cold start не трябва да надвишава 500 ms за P50 и 2 секунди за P99.
Network request trace автоматично записва всяка HTTP заявка с метаданни: URL, метод, код на отговор, размер на отговор, скорост на предаване. В конзолата на Firebase Performance заявките могат да се филтрират по URL модел — например да се покажат всички заявки към /api/v2/orders. За всеки модел се показват персентилите на времето за отговор и честотата на грешки 4xx/5xx. Това позволява бързо откриване на деградация на конкретен API без настройване на отделни аларми.
За екраните Firebase Performance допълнително изчислява метриката „frozen frames„ — кадри, които са се изобразявали повече от 700 ms. Такива замръзвания на UI се възприемат от потребителя като „приложението замръзна„. Ако на даден екран има повече от 1% frozen frames, Firebase маркира метриката като проблемна. За Android SDK допълнително събира метриката slow renders — кадри по-дълги от 16 ms (пропускане на 60 FPS). Комбинацията от screen trace и frozen frames дава пълна картина както за времето за зареждане, така и за плавността на анимациите.
Персонализирани трасета позволяват измерване на продължителността на всеки потребителски сценарий: поръчка, качване на изображение в облака, синхронизиране на данни. Разработчикът изрично посочва началото и края на трасето в кода и дава име на сценария. За разлика от автоматичните трасета, персонализираните трасета предоставят пълен контрол върху това какво се измерва и позволяват добавяне на атрибути за филтриране.
Всяко персонализирано трасе може да съдържа атрибути — двойки ключ-стойност, които се добавят като метаданни. Атрибутите помагат за сегментиране на данните: например времето за поръчка може да се проследява отделно за „promo_user„ и „regular_user„. Firebase Performance поддържа до 5 атрибута на трасе и до 100 уникални стойности на атрибут. Атрибутите са индексирани и достъпни за филтриране в конзолата на Firebase.
Според доклада на Google I/O 2024, екипът на Spotify използва персонализирани Firebase трасета за проследяване на времето за превключване между песни. Това позволи намаляване на медианното време за превключване от 400 ms на 120 ms чрез идентифициране на тясно място в кеша на аудио буфера. Ключовото прозрение беше филтрирането по атрибут „device_model„ — проблемът се проявяваше само на Samsung устройства с Android 13.
import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace
class CheckoutTracker {
private val firebasePerf = FirebasePerformance.getInstance()
fun trackCheckoutFlow(userId: String, promoApplied: Boolean) {
val trace: Trace = firebasePerf.newTrace("checkout_flow")
trace.putAttribute("promo_user", promoApplied.toString())
trace.putAttribute("user_tier", "premium")
trace.start()
// Изпълнение на сценарий за поръчка
validateCart()
processPayment()
confirmOrder()
trace.stop()
}
}
Интеграцията на Firebase Performance в Android изисква три стъпки: добавяне на google-services plugin, свързване на Firebase BOM (Bill of Materials) и добавяне на firebase-perf зависимост. Firebase Performance работи автоматично на всички Activity и фрагменти, ако използват AppCompatActivity. За Compose екрани Firebase препоръчва използване на персонализирани трасета, тъй като автоматичното screen trace не поддържа Compose директно.
Важен нюанс: Firebase Performance Gradle plugin модифицира байткода на приложението по време на компилация. Plugin-ът добавя инструментиращ код към всяко Activity и OkHttp клиент. Това може да увеличи времето за компилиране с 5-10% и размера на APK с 200-400 KB. В debug компилации Firebase Performance автоматично се изключва — това предпазва от изкривяване на метриките по време на локално разработване. За принудително включване в debug режим се използва флагът firebasePerformanceInstrumentationEnabled в манифеста.
Firebase Performance също поддържа MetricKit за iOS и Perfetto за Android — нискостепенни системни трасьори. MetricKit предоставя данни за честота на кадрите, потребление на CPU и памет на ниво операционна система. Firebase агрегира тези данни и ги показва в същата конзола, където се показват HTTP трасета и screen traces, комбинирайки системна и приложна телеметрия в един интерфейс.
import okhttp3.OkHttpClient
import com.google.firebase.perf.network.FirebasePerfOkHttpClient
val client = OkHttpClient.Builder()
.addInterceptor FirebasePerfOkHttpClient
.build()
val request = Request.Builder()
.url("https://api.example.com/orders")
.build()
client.newCall(request).enqueue(object : Callback {
override fun onFailure(call: Call, e: IOException) { /* handle */ }
override fun onResponse(call: Call, response: Response) { /* handle */ }
})
За iOS интеграцията на Firebase Performance се извършва чрез CocoaPods или Swift Package Manager. След инсталиране на pod-овете FirebasePerformance и FirebaseCore, SDK автоматично започва да събира метрики. За прихващане на HTTP заявки Firebase Performance iOS използва NSURLProtocol — системен механизъм, който позволява прихващане на всички URL зареждания в приложението. SDK регистрира свой собствен NSURLProtocol подклас при стартиране и всички заявки чрез URLSession автоматично попадат под мониторинг.
Ограничение за iOS: Firebase Performance не поддържа автоматично screen trace за SwiftUI. За SwiftUI приложения е необходимо ръчно да се създават персонализирани трасета, като тялото на View се обвие в start/stop блок. Firebase работи върху естествена поддръжка за SwiftUI, но в момента SDK автоматично проследява само UIView контролери. За хибридни приложения на UIKit + SwiftUI се препоръчва създаване на екрани в UIKit и вграждане на SwiftUI чрез UIHostingController.
Firebase Performance iOS също предоставя интеграция с MetricKit — рамката на Apple, която събира диагностични данни на ниво операционна система. MetricKit изпраща ежедневни отчети с метрики за CPU, GPU, памет и честота на кадрите. Firebase Performance агрегира тези отчети и ги показва в конзолата до персонализираните трасета, което дава пълна картина на производителността както на ниво приложение, така и на ниво система.
import FirebasePerformance
final class ImageUploadService {
func uploadImage(_ data: Data, to url: URL) async throws {
guard let trace = Performance.startTrace(name: "image_upload") else { return }
trace?.setValue("image/jpeg", forAttribute: "content_type")
trace?.setValue("\(data.count)", forAttribute: "file_size")
var request = URLRequest(url: url)
request.httpMethod = "POST"
request.httpBody = data
let (_, response) = try await URLSession.shared.data(for: request)
guard let httpResponse = response as? HTTPURLResponse else { return }
trace?.setValue("\(httpResponse.statusCode)",
forAttribute: "status_code")
trace?.stop()
}
}
Често задавани въпроси
Да, Firebase Performance е достъпен на безплатния Spark тариф с лимит от 500 000 събития на ден. За проекти с по-голям обем данни се използва Blaze тариф с плащане според потреблението: 0,0003 долара за 1000 събития над лимита. За повечето стартиращи и средни проекти 500 000 събития на ден са напълно достатъчни.
Firebase Performance SDK е оптимизиран за минимално влияние. Изпращането на данни се извършва във фонова нишка с нисък приоритет. Според тестовете на Google, влиянието на SDK върху времето за стартиране е под 1%. Размерът на SDK е около 300 KB за Android и 250 KB за iOS.
Автоматично се събират app start (cold/warm), screen rendering (време за изобразяване на всеки екран), HTTP заявки (време, размер, статус) и frozen frames. За Android допълнително се събира честотата на slow renders (>16 ms) и ANR.
Firebase Performance автоматично се изключва в debug режим. За принудителен контрол се използва флаг в Android манифеста: firebasePerformanceInstrumentationEnabled. За iOS изключването се извършва чрез флаг -FIRPerformanceEnabled NO в аргументите на схемата за стартиране.
Да, Firebase Performance поддържа експорт към BigQuery. След свързване на проекта с BigQuery, всички метрики автоматично се дублират в BigQuery таблици, достъпни за SQL заявки и създаване на табла за управление в Looker Studio. Експортът се конфигурира в секцията Integrations на Firebase конзолата.
Резюме
Ще разработим мобилно приложение под ключ
IT Sectr създава iOS и Android приложения за стартъпи и бизнеси от 2017 г. Ще ви консултираме и ще предложим най-доброто решение.
Прочетете също