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