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