Khắc phục sự cố và câu hỏi thường gặp về Crashlytics
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 tìm thấy nội dung mình cần hoặc cần được trợ giúp thêm, hãy liên hệ với Nhóm hỗ trợ Firebase.
Khắc phục sự cố chung/Câu hỏi thường gặp
Thấy các định dạng khác nhau (và đôi khi là "biến thể") cho một số vấn đề trong bảng Vấn đề
Bạn có thể nhận thấy hai định dạng khác nhau cho các vấn đề được liệt kê trong bảng Vấn đề trong bảng điều khiển Firebase. Ngoài ra, bạn cũng có thể nhận thấy một tính năng có tên là "biến thể" trong một số vấn đề. Sau đây là lý do!
Vào đầu năm 2023, chúng tôi đã ra mắt một công cụ phân tích cải tiến để phân nhóm các sự kiện, cũng như thiết kế mới và một số tính năng nâng cao cho các vấn đề mới (chẳng hạn như biến thể!). Hãy xem bài đăng gần đây trên blog của chúng tôi để biết toàn bộ thông tin chi tiết. Bạn cũng có thể đọc phần dưới đây để biết thông tin nổi bật.
Crashlytics phân tích tất cả sự kiện từ ứng dụng của bạn (chẳng hạn như sự cố, sự cố không nghiêm trọng và lỗi ANR) và tạo các nhóm sự kiện được gọi là vấn đề – tất cả sự kiện trong một vấn đề đều có điểm lỗi chung.
Để nhóm các sự kiện thành những vấn đề này, công cụ phân tích cải tiến hiện xem xét nhiều khía cạnh của sự kiện, bao gồm các khung trong dấu vết ngăn xếp, thông báo ngoại lệ, mã lỗi và các đặc điểm khác của nền tảng hoặc loại lỗi.
Tuy nhiên, trong nhóm sự kiện này, dấu vết ngăn xếp dẫn đến lỗi có thể khác nhau. Dấu vết ngăn xếp khác nhau có thể có nghĩa là nguyên nhân gốc rễ khác nhau.
Để thể hiện sự khác biệt có thể có này trong một vấn đề, giờ đây, chúng ta tạo các biến thể trong các vấn đề – mỗi biến thể là một nhóm con của các sự kiện trong một vấn đề có cùng một điểm lỗi và một dấu vết ngăn xếp tương tự. Với các biến thể, bạn có thể gỡ lỗi các dấu vết ngăn xếp phổ biến nhất trong một vấn đề và xác định xem có nhiều nguyên nhân gốc rễ dẫn đến lỗi hay không.
Dưới đây là những điểm cải tiến mà bạn sẽ thấy:
Siêu dữ liệu được cải tiến hiển thị trong hàng vấn đề Giờ đây, bạn có thể dễ dàng hiểu và phân loại các vấn đề trong ứng dụng.
Ít vấn đề trùng lặp hơn Việc thay đổi số dòng không dẫn đến vấn đề mới.
Dễ dàng gỡ lỗi các vấn đề phức tạp với nhiều nguyên nhân gốc Sử dụng biến thể để gỡ lỗi các dấu vết ngăn xếp phổ biến nhất trong một vấn đề.
Các cảnh báo và tín hiệu có ý nghĩa hơn Một vấn đề mới thực sự đại diện cho một lỗi mới.
Tìm kiếm hiệu quả hơn Mỗi vấn đề chứa nhiều siêu dữ liệu có thể tìm kiếm hơn,
chẳng hạn như loại ngoại lệ và tên gói.
Sau đây là cách triển khai các điểm cải tiến này:
Khi nhận được sự kiện mới từ ứng dụng của bạn, chúng tôi sẽ kiểm tra xem các sự kiện đó có khớp với vấn đề hiện có hay không.
Nếu không có sự trùng khớp, chúng tôi sẽ tự động áp dụng thuật toán nhóm sự kiện thông minh hơn cho sự kiện đó và tạo một vấn đề mới với thiết kế siêu dữ liệu được cải tiến.
Đây là lần cập nhật lớn đầu tiên mà chúng tôi thực hiện đối với tính năng nhóm sự kiện. Nếu bạn có ý kiến phản hồi hoặc gặp vấn đề, vui lòng cho chúng tôi biết bằng cách
gửi báo cáo
.
Không thấy các chỉ số không gặp sự cố và/hoặc cảnh báo về tốc độ
Nếu bạn không thấy các chỉ số không gặp sự cố (chẳng hạn như số người dùng và số phiên không gặp sự cố) và/hoặc cảnh báo về tốc độ, hãy đảm bảo rằng bạn đang sử dụngSDK Crashlytics 11.7.0 trở lên.
Không thấy nhật ký liên kết phân cấp
Nếu không thấy nhật ký đường dẫn, bạn nên kiểm tra cấu hình của ứng dụng cho Google Analytics.
Hãy đảm bảo rằng bạn đáp ứng các yêu cầu sau:
Xem dấu vết ngăn xếp chưa được biểu tượng hoá cho ứng dụng Android trong trang tổng quan Crashlytics
Nếu bạn đang sử dụng Unity IL2CPP và thấy các dấu vết ngăn xếp chưa được biểu tượng hoá, hãy thử làm như sau:
Đảm bảo rằng bạn đang sử dụng phiên bản 8.6.1 trở lên của SDK Unity Crashlytics.
Đảm bảo rằng bạn đã thiết lập và chạy lệnh Firebase CLI
crashlytics:symbols:upload để tạo và tải tệp biểu tượng lên.
Bạn cần chạy lệnh dòng lệnh này mỗi khi tạo bản phát hành hoặc bất kỳ bản dựng nào mà bạn muốn xem dấu vết ngăn xếp tượng trưng trong bảng điều khiển Firebase. Tìm hiểu thêm trong trang Nhận báo cáo sự cố có thể đọc được.
Có thể sử dụng Crashlytics với các ứng dụng sử dụng IL2CPP không?
Có, Crashlytics có thể hiển thị dấu vết ngăn xếp được biểu tượng hoá cho các ứng dụng sử dụng IL2CPP. Khả năng này có sẵn cho các ứng dụng phát hành trên nền tảng Android hoặc Apple. Dưới đây là những việc bạn cần làm:
Đảm bảo rằng bạn đang sử dụng phiên bản 8.6.0 trở lên của SDK Unity Crashlytics.
Hoàn thành các nhiệm vụ cần thiết cho nền tảng của bạn:
Đối với ứng dụng trên nền tảng Apple: Bạn không cần thực hiện hành động đặc biệt nào. Đối với các ứng dụng trên nền tảng Apple, trình bổ trợ Trình chỉnh sửa Unity của Firebase sẽ tự động định cấu hình dự án Xcode để tải các biểu tượng lên.
Đối với ứng dụng Android: Đảm bảo rằng bạn đã thiết lập và chạy lệnh crashlytics:symbols:upload CLI Firebase để tạo và tải tệp biểu tượng lên.
Bạn cần chạy lệnh dòng lệnh này mỗi khi tạo bản phát hành hoặc bất kỳ bản dựng nào mà bạn muốn xem dấu vết ngăn xếp được biểu tượng hoá trong bảng điều khiển Firebase. Tìm hiểu thêm trong trang Nhận báo cáo sự cố có thể đọc được.
Tỷ lệ người dùng không gặp sự cố được tính như thế nào?
Giá trị không gặp sự cố thể hiện tỷ lệ 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ể.
Dưới đâ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 hàm này do Google Analytics cung cấp.
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100
Khi xảy ra sự cố, Google Analytics sẽ gửi một loại sự kiện app_exception và 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 thể hiện 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 trong trình đơn thả xuống ở phía trên bên phải của trang tổng quan Crashlytics.
Tỷ lệ phần trăm người dùng không gặp sự cố là thông tin tổng hợp theo thời gian, chứ không phải là giá trị trung bình.
Ví dụ: giả sử ứng dụng của bạn có 3 người dùng; chúng ta 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 những người dùng đã tương tác với ứng dụng của bạn mỗi ngày và những người dùng nào trong số đó gặp sự cố vào ngày đó:
Thứ Hai
Thứ Ba
Thứ Tư
Những 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
A
Vào thứ Tư, tỷ lệ phần trăm người dùng không gặp sự cố là 50% (1/2 người dùng không gặp sự cố). Hai người dùng đã 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ố là 33,3% (1/3 người dùng không gặp sự cố). Ba người dùng đã tương tác với ứng dụng của bạn trong hai ngày qua, nhưng chỉ có một người dùng (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ố là 0% (0 trong số 3 người dùng không gặp sự cố). Ba người dùng đã tương tác với ứng dụng của bạn trong ba ngày qua, nhưng
không có người dùng nào gặp sự cố.
Bạn không nên so sánh giá trị người dùng không gặp sự cố trong nhiều khoảng thời gian.
Xác suất một người dùng gặp sự cố sẽ tăng lên khi họ sử dụng ứng dụng của bạn nhiều lần hơn, vì vậy, giá trị người dùng không gặp sự cố có thể nhỏ hơn trong khoảng thời gian dài hơn.
Ai có thể xem, viết và xoá ghi chú về một vấn đề?
Ghi chú cho phép các thành viên trong dự án bình luận về các vấn đề cụ thể bằng câu hỏi, thông tin cập nhật về trạng thái, v.v.
Khi một thành viên trong dự án đăng ghi chú, ghi chú đó sẽ được gắn nhãn bằng email của Tài khoản Google của họ. Địa chỉ email này cùng với ghi chú sẽ hiển thị cho tất cả thành viên dự án có quyền xem ghi chú.
Phần sau đây mô tả quyền truy cập cần thiết để xem, ghi và xoá ghi chú:
Thành viên dự án có bất kỳ vai trò nào sau đây đều có thể xem và xoá ghi chú hiện có cũng như viết ghi chú mới về một vấn đề.
Ghi chú cho phép các thành viên trong dự án bình luận về các vấn đề cụ thể bằng câu hỏi, thông tin cập nhật về trạng thái, v.v.
Khi một thành viên trong dự án đăng ghi chú, ghi chú đó sẽ được gắn nhãn bằng email của Tài khoản Google của họ. Địa chỉ email này cùng với ghi chú sẽ hiển thị cho tất cả thành viên dự án có quyền xem ghi chú.
Phần sau đây mô tả quyền truy cập cần thiết để xem, ghi và xoá ghi chú:
Thành viên dự án có bất kỳ vai trò nào sau đây đều có thể xem và xoá ghi chú hiện có cũng như viết ghi chú mới về một vấn đề.
Ứng dụng cũng sử dụng SDK Google Mobile Ads nhưng không gặp sự cố
Nếu dự án của bạn sử dụng Crashlytics cùng với SDK Google Mobile Ads, thì có thể trình báo cáo sự cố đang can thiệp khi đăng ký trình xử lý ngoại lệ. Để khắc phục vấn đề này, hãy tắt tính năng báo cáo sự cố trong SDK Mobile Ads bằng cách gọi disableSDKCrashReporting.
Tập dữ liệu BigQuery của tôi nằm ở đâu?
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 nằm ở Hoa Kỳ, bất kể vị trí của dự án Firebase.
Vấn đề hồi quy
Vấn đề hồi quy là gì?
Một vấn đề đã hồi quy khi bạn đã đóng vấn đề trước đó nhưng Crashlytics nhận được một báo cáo mới cho biết vấn đề đã tái diễn.
Crashlytics sẽ tự động mở lại các vấn đề hồi quy này để bạn có thể giải quyết các vấn đề đó cho phù hợp với ứng dụng của mình.
Dưới đây là một tình huống mẫu giải thích cách Crashlytics phân loại một vấn đề là hồi quy:
Lần đầu tiên, Crashlytics nhận được báo cáo sự cố về Sự cố "A". Crashlytics sẽ mở 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 Vấn đề "A" rồi 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à của một phiên bản ứng dụng mà Crashlyticsbiết khi bạn đóng vấn đề (nghĩa là phiên bản đã gửi báo cáo sự cố cho mọi sự cố), thì Crashlytics sẽ không coi vấn đề là hồi quy. Vấn đề này sẽ vẫn được đóng.
Nếu báo cáo đến từ một phiên bản ứng dụng mà Crashlyticskhông biết khi bạn đóng vấn đề (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ẽ xem xét vấn đề đã hồi quy và sẽ mở lại vấn đề.
Khi một vấn đề hồi quy, chúng tôi sẽ gửi một cảnh báo phát hiện hồi quy và thêm một tín hiệu hồi quy vào vấn đề đó để cho bạn biết rằng Crashlytics đã mở lại vấn đề. Nếu bạn không muốn một vấn đề mở lại do thuật toán hồi quy của chúng tôi, hãy "tắt tiếng" vấn đề đó thay vì đóng vấn đề.
Tại sao tôi thấy các vấn đề hồi quy đối với các phiên bản ứng dụng cũ?
Nếu một báo cáo đến từ một phiên bản ứng dụng cũ chưa bao giờ gửi báo cáo sự cố nào khi bạn đóng vấn đề, thì Crashlytics sẽ coi vấn đề đó là hồi quy và sẽ mở lại vấn đề.
Trường hợp này có thể xảy ra trong trường hợp sau: Bạn đã khắc phục lỗi và phát hành phiên bản mới của ứng dụng, nhưng vẫn có người dùng sử dụng 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ũ đó chưa bao giờ gửi báo cáo sự cố nào khi bạn đóng vấn đề và người dùng bắt đầu gặp lỗi, thì các báo cáo sự cố đó sẽ kích hoạt vấn đề hồi quy.
Nếu bạn không muốn một vấn đề mở lại do thuật toán hồi quy của chúng tôi, hãy "tắt tiếng" vấn đề đó thay vì đóng vấn đề.
Báo cáo các ngoại lệ chưa phát hiện là ngoại lệ nghiêm trọng
Crashlytics có thể báo cáo các ngoại lệ chưa phát hiện là ngoại lệ nghiêm trọng (kể từ phiên bản 10.4.0 của SDK Unity). Các câu hỏi thường gặp sau đây giúp giải thích lý do và các phương pháp hay nhất để sử dụng tính năng này.
Tại sao ứng dụng phải báo cáo các ngoại lệ chưa phát hiện là ngoại lệ nghiêm trọng?
Bằng cách báo cáo các ngoại lệ chưa phát hiện là ngoại lệ nghiêm trọng, bạn sẽ nhận được thông tin thực tế hơn về những ngoại lệ có thể khiến trò chơi không chơi được – ngay cả khi ứng dụng tiếp tục chạy.
Xin lưu ý rằng nếu bạn bắt đầu báo cáo lỗi nghiêm trọng, tỷ lệ phần trăm người dùng không gặp sự cố (CFU) có thể sẽ giảm, nhưng chỉ số CFU sẽ phản ánh chính xác hơn trải nghiệm của người dùng cuối với ứng dụng của bạn.
Những ngoại lệ nào sẽ được báo cáo là nghiêm trọng?
Để Crashlytics báo cáo một ngoại lệ chưa phát hiện là nghiêm trọng, bạn phải đáp ứng cả hai điều kiện sau:
Ứng dụng (hoặc thư viện đi kèm) gửi một ngoại lệ không được phát hiện. Một ngoại lệ được tạo, nhưng không được gửi, không được coi là ngoại lệ không được phát hiện.
Sau khi bật tính năng báo cáo các ngoại lệ chưa phát hiện dưới dạng lỗi nghiêm trọng, tôi hiện có nhiều lỗi nghiêm trọng mới. Làm cách nào để xử lý đúng cách các trường hợp ngoại lệ này?
Khi bạn bắt đầu nhận được báo cáo về các ngoại lệ chưa phát hiện dưới dạng ngoại lệ nghiêm trọng, sau đây là một số tuỳ chọn để xử lý các ngoại lệ chưa phát hiện này:
Các ngoại lệ được tạo và gửi để phản ánh các trạng thái bất ngờ hoặc ngoại lệ.
Việc giải quyết các vấn đề được phản ánh bằng một ngoại lệ được gửi đi sẽ liên quan đến việc trả về chương trình về một trạng thái đã biết (một quy trình được gọi là xử lý ngoại lệ).
Tốt nhất là bạn nên phát hiện và xử lý tất cả ngoại lệ dự kiến, trừ phi không thể trả về chương trình về trạng thái đã biết.
Để kiểm soát loại ngoại lệ nào được phát hiện và xử lý bằng mã nào, hãy gói mã có thể tạo ngoại lệ trong khối try-catch.
Đảm bảo rằng các điều kiện trong câu lệnh catch càng hẹp càng tốt để xử lý các ngoại lệ cụ thể một cách thích hợp.
Ghi lại các ngoại lệ trong Unity hoặc Crashlytics
Có nhiều cách để ghi lại các trường hợp ngoại lệ trong Unity hoặc Crashlytics để giúp gỡ lỗi vấn đề.
Khi sử dụng Crashlytics, sau đây là hai tuỳ chọn phổ biến nhất và được đề xuất:
Cách 1: In trong bảng điều khiển Unity nhưng không báo cáo cho Crashlytics trong quá trình phát triển hoặc khắc phục sự cố
In vào bảng điều khiển Unity bằng Debug.Log(exception), Debug.LogWarning(exception) và Debug.LogError(exception). Các hàm này sẽ in nội dung của ngoại lệ vào bảng điều khiển Unity và không gửi lại ngoại lệ.
Cách 2: Tải lên Crashlytics để báo cáo tổng hợp trong trang tổng quan Crashlytics trong các trường hợp sau:
Nếu một trường hợp ngoại lệ đáng được ghi lại để gỡ lỗi một sự kiện Crashlytics có thể xảy ra sau đó, hãy sử dụng Crashlytics.Log(exception.ToString()).
Nếu ngoại lệ vẫn được báo cáo cho Crashlytics mặc dù đã được phát hiện và xử lý, hãy sử dụng Crashlytics.LogException(exception) để ghi lại ngoại lệ đó dưới dạng một sự kiện không nghiêm trọng.
Tuy nhiên, nếu muốn báo cáo sự kiện nghiêm trọng cho Unity Cloud Diagnostic theo cách thủ công, bạn có thể sử dụng Debug.LogException. Tuỳ chọn này in ngoại lệ lên bảng điều khiển Unity như Tuỳ chọn 1, nhưng cũng gửi ngoại lệ (cho dù ngoại lệ đã được gửi hay chưa). Lỗi này sẽ được gửi ra ngoài. Điều này có nghĩa là ngay cả Debug.LogException(exception) xung quanh với các khối try-catch vẫn dẫn đến một ngoại lệ không được phát hiện.
Do đó, hãy gọi Debug.LogException nếu và chỉ khi bạn muốn thực hiện tất cả những thao tác sau:
Để in trường hợp ngoại lệ vào bảng điều khiển Unity.
Để tải ngoại lệ lên Crashlytics dưới dạng một sự kiện nghiêm trọng.
Để gửi ngoại lệ, hãy coi ngoại lệ đó là ngoại lệ chưa nắm bắt được và báo cáo ngoại lệ đó cho Unity Cloud Diagnostics.
Xin lưu ý rằng nếu bạn muốn in một ngoại lệ đã phát hiện được vào bảng điều khiển Unity và tải lên Crashlytics dưới dạng một sự kiện không nghiêm trọng, hãy làm như sau:
try
{
methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
// Print the exception to the Unity console at the error level.
Debug.LogError(exception);
// Upload the exception to Crashlytics as a non-fatal event.
Crashlytics.LogException(exception); // not Debug.LogException
//
// Code that handles the exception
//
}
