Trang này cung cấp trợ giúp khắc phục sự cố và câu trả lời cho các câu hỏi thường gặp về việc sử dụng Crashlytics. Nếu bạn không thể tìm thấy những gì mình đang tìm kiếm hoặc cần trợ giúp thêm, hãy liên hệ với bộ phận hỗ trợ của Firebase .
Khắc phục sự cố chung / Câu hỏi thường gặp
Nếu bạn không thấy người dùng không gặp sự cố, nhật ký đường dẫn và / hoặc cảnh báo tốc độ, chúng tôi khuyên bạn nên kiểm tra cấu hình ứng dụng của mình cho Google Analytics.
Đảm bảo rằng bạn đã bật Google Analytics trong dự án Firebase của mình.
Đảm bảo rằng Chia sẻ dữ liệu được bật cho Google Analytics trong trang Tích hợp > Google Analytics của bảng điều khiển Firebase. Lưu ý rằng cài đặt Chia sẻ dữ liệu được hiển thị trong bảng điều khiển Firebase nhưng được quản lý trong bảng điều khiển Google Analytics.
Ngoài SDK Firebase Crashlytics, hãy đảm bảo rằng bạn đã thêm SDK Firebase cho Google Analytics vào ứng dụng của mình ( iOS + | Android ).
Đảm bảo rằng bạn đang sử dụng các phiên bản mới nhất cho tất cả các SDK Firebase của mình ( iOS + | Android ).
Đặc biệt hãy kiểm tra để đảm bảo rằng bạn đang sử dụng tối thiểu các phiên bản sau của SDK Firebase cho Google Analytics: iOS + - v6.3.1 + (v8.9.0 + cho macOS và tvOS) | Android - v17.2.3 +(BoM v24.7.1 +) .
Giá trị không có sự cố thể hiện phần trăm người dùng đã tương tác với ứng dụng của bạn nhưng không gặp sự cố trong một khoảng thời gian cụ thể.
Đây là công thức tính tỷ lệ phần trăm người dùng không gặp sự cố. Giá trị đầu vào của nó được cung cấp bởi Google Analytics.
1 - ( CRASHED_USERS / ALL_USERS )
Khi sự cố xảy ra, Google Analytics sẽ gửi một loại sự kiện
app_exceptionvà CRASHED_USERS đại diện cho số lượng người dùng được liên kết với loại sự kiện đó.ALL_USERS đại diện cho tổng số người dùng đã tương tác với ứng dụng của bạn trong khoảng thời gian mà bạn đã chọn từ menu thả xuống ở phía trên bên phải của trang tổng quan Crashlytics.
Bạn có thể xem số lượng sự kiện app_exception cho ứng dụng của mình trong trang tổng quan Analytics. Lưu ý rằng do sự khác biệt nhỏ về cách xử lý sự cố, số app_exception hiển thị trong trang tổng quan Analytics đôi khi có thể khác với số được sử dụng trong phép tính người dùng không gặp sự cố.
Tỷ lệ phần trăm người dùng không gặp sự cố là tổng hợp theo thời gian , không phải là mức trung bình.
Ví dụ: hãy tưởng tượng ứng dụng của bạn có ba người dùng; chúng tôi sẽ gọi họ là Người dùng A, Người dùng B và Người dùng C. Bảng sau đây cho biết người dùng nào tương tác với ứng dụng của bạn mỗi ngày và người dùng nào gặp sự cố vào ngày hôm đó:
| Thứ hai | Thứ ba | Thứ Tư | |
|---|---|---|---|
| Người dùng đã tương tác với ứng dụng của bạn | A, B, C | A, B, C | A, B |
| Người dùng gặp sự cố | C | B | Một |
Vào thứ Tư, tỷ lệ phần trăm người dùng không gặp sự cố của bạn là 50% (1 trong số 2 người dùng không gặp sự cố).
Hai trong số người dùng của bạn đã tương tác với ứng dụng của bạn vào thứ Tư, nhưng chỉ một trong số họ (Người dùng B) không gặp sự cố.Trong 2 ngày qua, tỷ lệ phần trăm người dùng không gặp sự cố của bạn là 33,3% (cứ 3 người dùng thì có 1 người dùng không gặp sự cố).
Ba trong số người dùng của bạn đã tương tác với ứng dụng của bạn trong hai ngày qua, nhưng chỉ một trong số họ (Người dùng C) không gặp sự cố.Trong 3 ngày qua, tỷ lệ phần trăm người dùng không gặp sự cố của bạn là 0% (0 trong số 3 người dùng không gặp sự cố).
Ba trong số người dùng của bạn đã tương tác với ứng dụng của bạn trong ba ngày qua, nhưng không có ai trong số họ không gặp sự cố.
Ghi chú cho phép các thành viên dự án bình luận về các vấn đề cụ thể với các câu hỏi, cập nhật trạng thái, v.v.
Khi một thành viên của dự án đăng một ghi chú, ghi chú đó được gắn nhãn với email trong tài khoản Google của họ. Địa chỉ email này được hiển thị cùng với ghi chú, cho tất cả các thành viên dự án có quyền truy cập để xem ghi chú.
Phần sau mô tả quyền truy cập cần thiết để xem, viết và xóa ghi chú:
Các thành viên dự án có bất kỳ vai trò nào sau đây có thể xem và xóa các ghi chú hiện có cũng như viết ghi chú mới về một vấn đề.
- Chủ sở hữu hoặc người chỉnh sửa dự án, Quản trị viên Firebase, Quản trị viên chất lượng hoặc Quản trị viên Crashlytics
Các thành viên dự án có bất kỳ vai trò nào sau đây có thể xem các ghi chú được đăng trên một vấn đề, nhưng họ không thể xóa hoặc viết ghi chú.
Tích hợp
Nếu dự án của bạn sử dụng Crashlytics cùng với SDK quảng cáo trên thiết bị di động của Google, thì có khả năng các báo cáo sự cố đang can thiệp khi đăng ký các trình xử lý ngoại lệ. Để khắc phục sự cố, hãy tắt báo cáo sự cố trong SDK quảng cáo trên thiết bị di động bằng cách gọi disableSDKCrashReporting .
Sau khi bạn liên kết Crashlytics với BigQuery, các tập dữ liệu mới mà bạn tạo sẽ tự động được đặt ở Hoa Kỳ, bất kể vị trí của dự án Firebase của bạn là gì.
Hỗ trợ nền tảng
Các vấn đề đã khắc phục
Sự cố đã có hồi quy khi trước đó bạn đã đóng sự cố nhưng Crashlytics nhận được một báo cáo mới rằng sự cố đã xảy ra lại. Crashlytics tự động mở lại các sự cố đã khắc phục này để bạn có thể giải quyết chúng nếu phù hợp với ứng dụng của mình.
Dưới đây là một tình huống ví dụ giải thích cách Crashlytics phân loại vấn đề dưới dạng hồi quy:
- Lần đầu tiên, Crashlytics nhận được báo cáo sự cố về Crash "A". Crashlytics mở ra một vấn đề tương ứng cho sự cố đó (Vấn đề "A").
- Bạn nhanh chóng khắc phục lỗi này, đóng Sự cố "A", sau đó phát hành phiên bản mới của ứng dụng.
- Crashlytics nhận được một báo cáo khác về Vấn đề "A" sau khi bạn đã đóng vấn đề.
- Nếu báo cáo là từ một phiên bản ứng dụng mà Crashlytics đã biết khi bạn xử lý sự cố (nghĩa là phiên bản đó đã gửi báo cáo sự cố cho bất kỳ sự cố nào), thì Crashlytics sẽ không coi sự cố là đã được giải quyết. Vấn đề sẽ vẫn đóng.
- Nếu báo cáo là từ một phiên bản ứng dụng mà Crashlytics không biết về thời điểm bạn đóng sự cố (có nghĩa là phiên bản đó chưa bao giờ gửi bất kỳ báo cáo sự cố nào cho bất kỳ sự cố nào), thì Crashlytics sẽ coi sự cố đã được giải quyết và sẽ mở lại sự cố .
Khi sự cố xảy ra, chúng tôi sẽ gửi một cảnh báo phát hiện hồi quy và thêm tín hiệu hồi quy cho sự cố để cho bạn biết rằng Crashlytics đã giải quyết lại sự cố. Nếu bạn không muốn sự cố mở lại do thuật toán hồi quy của chúng tôi, hãy "tắt tiếng" sự cố thay vì đóng nó.
Nếu một báo cáo là từ phiên bản ứng dụng cũ chưa từng gửi bất kỳ báo cáo sự cố nào khi bạn đóng sự cố, thì Crashlytics sẽ coi sự cố đã được giải quyết và sẽ mở lại sự cố.
Tình huống này có thể xảy ra trong trường hợp sau: Bạn đã sửa lỗi và phát hành phiên bản mới của ứng dụng, nhưng bạn vẫn có người dùng trên các phiên bản cũ hơn mà không có bản sửa lỗi. Nếu tình cờ, một trong những phiên bản cũ hơn đó chưa bao giờ gửi bất kỳ báo cáo sự cố nào khi bạn đóng vấn đề và những người dùng đó bắt đầu gặp phải lỗi, thì các báo cáo sự cố đó sẽ kích hoạt sự cố được hồi quy.
Nếu bạn không muốn sự cố mở lại do thuật toán hồi quy của chúng tôi, hãy "tắt tiếng" sự cố thay vì đóng nó.