Firebase Crashlytics — nó là gì, crash và chẩn đoán sự cố

Firebase Crashlytics là gì

Firebase Crashlytics là dịch vụ miễn phí của Google để giám sát độ ổn định của ứng dụng di động, được Google mua lại vào năm 2017 cùng với công ty Fabric. Crashlytics tự động thu thập thông tin về mọi sự cố ứng dụng, nhóm các crash giống nhau theo chữ ký ngăn xếp và hiển thị chúng trong bảng điều khiển Firebase với ưu tiên theo số lượng người dùng bị ảnh hưởng.

Lịch sử và phát triển

Crashlytics được ra mắt vào năm 2011 như một phần của nền tảng Fabric và nhanh chóng trở thành tiêu chuẩn thực tế cho báo cáo crash trên iOS. Sau khi được Google mua lại vào năm 2017 với giá ước tính 2 tỷ đô la (toàn bộ Fabric), Crashlytics đã được tích hợp vào SDK Firebase. Phiên bản 18.0.0 (2021) bổ sung hỗ trợ Kotlin Multiplatform, và phiên bản 19.0.0 (2024) bổ sung tính năng thu thập ANR tự động trên Android mà không cần cấu hình thêm. Theo Google (2026), Crashlytics xử lý hơn 10 tỷ crash mỗi tháng.

Giới hạn miễn phí của Crashlytics

Crashlytics được cung cấp miễn phí với giới hạn 500 nghìn phiên mỗi ngày cho mỗi dự án Firebase. Đối với hầu hết ứng dụng, điều này là đủ — theo Google (2026), 95% dự án không vượt quá giới hạn. Khi vượt quá, việc thu thập dữ liệu không dừng lại, nhưng báo cáo ngừng cập nhật cho đến ngày hôm sau. Đối với các dự án có tải cao, các gói Spark và Blaze của Firebase có sẵn — Crashlytics vẫn miễn phí trên cả hai gói, và giới hạn phiên được tính riêng.

Cách Crashlytics phát hiện và thu thập sự cố

Cơ chế thu thập của Crashlytics dựa trên việc chặn ngoại lệ ở cấp độ nền tảng và runtime. Trên Android, SDK triển khai UncaughtExceptionHandler, chặn tất cả các ngoại lệ chưa được bắt của Kotlin và Java. Trên iOS, Crashlytics sử dụng NSSetUncaughtExceptionHandler cho Objective-C/Swift và trình xử lý ngoại lệ Mach riêng cho crash mã native.

Các loại sự cố bị chặn

Crashlytics phân biệt năm loại sự cố: fatal (crash gây chết), non-fatal (ngoại lệ không gây chết được truyền thủ công), ANR (Android — ứng dụng không phản hồi), signal (tín hiệu hệ điều hành — SIGSEGV, SIGABRT) và OOM (hết bộ nhớ trên iOS). Mỗi loại được xử lý bởi một cơ chế riêng và hiển thị trong bảng điều khiển với nhãn tương ứng.

Định dạng báo cáo sự cố

Mỗi báo cáo Crashlytics chứa thông tin đầy đủ: dấu vết ngăn xếp hoàn chỉnh với tên lớp và số dòng, phiên bản ứng dụng (versionName + versionCode), model thiết bị, phiên bản hệ điều hành, dung lượng bộ nhớ trống, hướng màn hình và thời gian kể từ khi khởi động. Nếu Firebase Analytics được kết nối, báo cáo cũng bao gồm đường dẫn từ 50 sự kiện người dùng cuối cùng trước khi xảy ra crash — điều này rất quan trọng để tái tạo crash.

class CrashlyticsHelper {
    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .log("Non-fatal: user action = payment_failed")
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }

    fun setUserContext(userId: String) {
        FirebaseCrashlytics.getInstance()
            .setUserId(userId)
        FirebaseCrashlytics.getInstance()
            .setCustomKey("subscription", "premium")
    }
}

Tích hợp Crashlytics vào dự án Android

Kết nối Crashlytics với ứng dụng Android yêu cầu thêm hai phụ thuộc vào build.gradle và cấu hình plugin Google Services. SDK tự động kết nối báo cáo crash khi khởi tạo Firebase mà không cần mã bổ sung. Để hoạt động chính xác, cũng cần plugin google-services và tệp google-services.json từ bảng điều khiển Firebase.

// build.gradle (cấp dự án)
plugins {
    id "com.google.gms.google-services" version "4.4.0"
}

// build.gradle (cấp ứng dụng)
plugins {
    id "com.google.firebase.crashlytics"
}

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-crashlytics-ktx")
    implementation("com.google.firebase:firebase-analytics-ktx")
}

Cấu hình plugin Crashlytics

Plugin com.google.firebase.crashlytics thực hiện hai nhiệm vụ: tạo mã định danh bản dựng duy nhất (build ID) để ánh xạ các ngăn xếp bị làm rối và tự động tạo tài nguyên cho SDK Crashlytics. Nếu không có plugin, các crash sẽ được đánh dấu là "chưa được ánh xạ" — bạn sẽ chỉ thấy tên lớp bị làm rối (a.b.c) mà không thể tìm mã nguồn. Plugin được thêm vào build.gradle gốc và build.gradle của mô-đun ứng dụng.

Kiểm tra tích hợp

Để kiểm tra tích hợp Crashlytics, sử dụng phương thức đặc biệt forceCrash() để tạo ra ngoại lệ thử nghiệm. Trong các bản dựng production, phương thức này không khả dụng. Sau khi chạy crash thử nghiệm, báo cáo xuất hiện trong bảng điều khiển Firebase trong vòng 1-5 phút. Nếu báo cáo không hiển thị, hãy kiểm tra rằng google-services.json khớp với gói ứng dụng và AndroidManifest không có cờ vô hiệu hóa việc thu thập dữ liệu.

Phân tích crash và nhóm báo cáo

Bảng điều khiển Crashlytics cung cấp hai cấp độ xem: danh sách tất cả crash (Issues) được nhóm theo loại sự cố và báo cáo chi tiết cho từng Issue với dấu vết, thống kê và dữ liệu tùy chỉnh. Mỗi Issue tổng hợp tất cả các crash có cùng chữ ký — cùng loại ngoại lệ và dấu vết ngăn xếp khớp nhau.

Issues và phân nhóm

Nhóm crash là tính năng chính của Crashlytics. Thay vì hiển thị hàng nghìn crash riêng lẻ, dịch vụ nhóm chúng thành Issues dựa trên dấu vân tay (fingerprint) — tổng kiểm tra của dấu vết ngăn xếp. Một Issue có thể chứa từ 1 đến vài triệu crash. Mỗi Issue hiển thị: số trường hợp gây chết, số người dùng duy nhất, phiên bản ứng dụng nơi crash xuất hiện và tỷ lệ phần trăm người dùng gặp sự cố.

Theo Google (2026), trung bình 20% Issues chiếm 80% tổng số crash gây chết của ứng dụng (nguyên lý Pareto). Crashlytics tự động sắp xếp Issues theo mức độ nghiêm trọng — càng nhiều người dùng bị ảnh hưởng, mức ưu tiên càng cao. Điều này cho phép nhà phát triển ưu tiên sửa các vấn đề phổ biến nhất trước.

Thống kê theo phiên bản

Crashlytics theo dõi độ ổn định của từng phiên bản ứng dụng riêng biệt. Biểu đồ crash-free users hiển thị tỷ lệ phần trăm người dùng không gặp crash gây chết trong mỗi phiên bản. Nếu khi cập nhật tỷ lệ này giảm xuống dưới ngưỡng (mặc định 99%), Crashlytics gửi thông báo qua email và trong Firebase Console. Điều này cho phép nhanh chóng quay lại phiên bản ổn định hoặc phát hành bản sửa lỗi nóng.

Khóa tùy chỉnh, nhật ký và Breadcrumbs

Crashlytics cung cấp ba cơ chế để làm phong phú báo cáo với ngữ cảnh: khóa tùy chỉnh (keys) cho dữ liệu có cấu trúc, nhật ký (logs) cho dấu vết văn bản và Breadcrumbs từ Analytics cho đường dẫn người dùng. Cả ba loại dữ liệu được gắn với báo cáo crash và hiển thị trong thẻ chi tiết của nó.

Khóa tùy chỉnh

Custom Keys là các cặp "khóa-giá trị" được truyền cùng với mỗi crash. Tối đa 64 khóa cho mỗi ứng dụng, mỗi khóa là chuỗi dài tối đa 1024 ký tự. Khóa rất hữu ích để đánh dấu trạng thái ứng dụng: cấp độ đăng ký, trạng thái xác thực, màn hình cuối cùng, có bật VPN hay không. Giá trị bị ghi đè — khóa mới có cùng tên thay thế khóa cũ.

Ghi nhật ký sự kiện

Custom Logs là các thông điệp văn bản mà Crashlytics lưu giữ trong bộ đệm vòng 64 KB. Nhật ký tự động được đính kèm vào crash tiếp theo. Nếu không có crash xảy ra, nhật ký không được truyền đến máy chủ (không tốn băng thông). Ghi nhật ký được sử dụng để ghi lại các bước của người dùng trước khi xảy ra sự cố: "payment_processing_started", "api_call_initiated", "response_received_200".

class PaymentViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance().log("Payment started: amount=$amount")

        FirebaseCrashlytics.getInstance().setCustomKey("last_screen", "payment_screen")
        FirebaseCrashlytics.getInstance().setCustomKey("subscription_tier", "basic")

        try {
            paymentGateway.charge(amount)
        } catch (e: NetworkException) {
            FirebaseCrashlytics.getInstance().recordException(e)
        }
    }
}

Breadcrumbs từ Analytics

Nếu Firebase Analytics được kết nối trong dự án, Crashlytics tự động nhận Breadcrumbs — 50 sự kiện phân tích cuối cùng trước khi xảy ra crash. Mỗi breadcrumb chứa tên sự kiện và tham số của nó. Điều này cho phép khôi phục chính xác chuỗi hành động dẫn đến sự cố: người dùng mở màn hình → thêm sản phẩm → chuyển đến thanh toán → xảy ra crash. Breadcrumbs được hiển thị trong thẻ Issue trên tab "Logs" riêng.

Thực hành tốt nhất khi làm việc với sự cố

Crashlytics hiệu quả nhất khi cấu hình ngữ cảnh và quy trình xử lý Issues đúng cách. Thực tế cho thấy, các đội đã triển khai quy trình làm việc với crash giúp giảm thời gian sửa lỗi nghiêm trọng đến 60% (dữ liệu Google, 2026).

Ưu tiên Issues

Không phải tất cả crash đều quan trọng như nhau. Ưu tiên theo số lượng người dùng và tần suất giúp tập trung vào các vấn đề nghiêm trọng nhất. Quy tắc: sửa các Issues ảnh hưởng đến hơn 0,1% người dùng trong vòng 24 giờ. Các Issues có tần suất đơn lẻ (< 0,01%) có thể hoãn đến bản phát hành theo kế hoạch tiếp theo. Crashlytics tự động đánh dấu các hồi quy — Issues đã được sửa nhưng xuất hiện lại trong phiên bản mới.

Tích hợp với CI/CD

API Crashlytics cho phép tích hợp báo cáo crash vào quy trình CI/CD thông qua REST API hoặc Firebase CLI. Ở mỗi bản phát hành mới, bạn có thể tự động kiểm tra xem tỷ lệ người dùng không gặp crash có vượt quá ngưỡng hay không. Nếu vượt quá ngưỡng, CI/CD sẽ chặn việc triển khai và gửi thông báo cho nhóm. Firebase CLI hỗ trợ lệnh firebase crashlytics:builds:upload để tải lên tệp ánh xạ ProGuard/R8 — nếu không có chúng, các ngăn xếp sẽ không đọc được.

Theo Google (2026), các ứng dụng sử dụng kiểm tra tự động ngưỡng crash-free trong CI/CD phát hành ít hơn 40% hồi quy trong production. Ngưỡng khuyến nghị: crash-free users >= 99,5% cho các bản phát hành quan trọng và >= 99,0% cho các bản phát hành thông thường.