Crash ứng dụng: nó là gì, nguyên nhân đóng đột ngột và phương pháp phát hiện

Crash ứng dụng là gì

Crash — sự kết thúc bất ngờ của chương trình do một tình huống ngoại lệ mà mã không xử lý được. Trong hệ điều hành di động, crash dẫn đến việc đóng ứng dụng ngay lập tức và hiển thị màn hình “Ứng dụng đã dừng” hoặc quay lại màn hình chính.

Crash được chia thành hai lớp lớn. Lỗi đã xử lý — khối try/catch bắt ngoại lệ, ứng dụng tiếp tục chạy, có thể mất một số chức năng. Crash chưa xử lý — ngoại lệ lan lên đến cấp độ hệ điều hành và hệ thống kết thúc tiến trình. Loại thứ hai đặc biệt nguy hiểm vì người dùng không thể lưu dữ liệu.

Một hệ thống với hai triệu người dùng và tỷ lệ crash 0,1% mất 2.000 người dùng ở mỗi bản phát hành. Theo Google Play Console (2024), các ứng dụng có tỷ lệ crash trên 1,5% bị loại khỏi đề xuất và mất tới 30% lưu lượng truy cập tự nhiên.

Nguyên nhân chính gây crash trong ứng dụng di động

NullPointerException (NPE) — vua của các crash trong Java/Kotlin. Cố gắng gọi phương thức trên một đối tượng null. Trong Kotlin, NPE ít phổ biến hơn nhờ tính năng null safety, nhưng vẫn có thể xảy ra khi sử dụng toán tử !! hoặc tương tác với mã Java. Google (2024) ước tính NPE chiếm 25% tổng số crash ứng dụng Android.

IndexOutOfBoundsException — truy cập phần tử danh sách với chỉ mục không tồn tại. Nguyên nhân phổ biến: dữ liệu đến từ máy chủ ở định dạng không mong đợi và giao diện cố gắng hiển thị vị trí không tồn tại. Giải pháp — luôn kiểm tra kích thước bộ sưu tập trước khi truy cập theo chỉ mục.

ANR (Application Not Responding) — vấn đề đặc thù của Android. Luồng giao diện người dùng bị chặn hơn 5 giây. Nguyên nhân chính: yêu cầu mạng trên luồng chính, tính toán nặng, đồng bộ cơ sở dữ liệu. StrictMode trong Android giúp phát hiện chặn luồng giao diện trong quá trình phát triển.

OutOfMemoryError (OOM) — ứng dụng vượt quá giới hạn bộ nhớ. Trên thiết bị di động có 2–4 GB RAM, OOM là vấn đề phổ biến khi làm việc với hình ảnh lớn hoặc danh sách vô hạn không phân trang. Giải pháp — Glide/Coil để tải hình ảnh, LruCache để lưu cache, ViewHolder trong RecyclerView.

Ngoại lệ runtime và lỗi nghiêm trọng

Ngoại lệ runtime — lỗi mà trình biên dịch không kiểm tra tại thời điểm xây dựng. Chúng chỉ xuất hiện khi mã chạy trên một thiết bị cụ thể với dữ liệu cụ thể. Trong Java, đây là RuntimeException và các lớp con của nó: NullPointerException, IllegalArgumentException, ArithmeticException.

Lỗi nghiêm trọng (FATAL) — không phải runtime, mà là lỗi hệ thống. Signal 11 (SIGSEGV) — vi phạm phân đoạn bộ nhớ trong mã native. Signal 6 (SIGABRT) — kết thúc bất thường do chính ứng dụng gây ra qua abort(). Những crash này khó chẩn đoán vì stack trace thường không hiển thị ngữ cảnh rõ ràng.

Trong iOS, nguyên nhân chính là NSInvalidArgumentException (nil bất ngờ trong tham số) và EXC_BAD_ACCESS (truy cập bộ nhớ đã giải phóng). Swift đã giảm số lượng crash so với Objective-C, nhưng lỗi trong runtime ObjC và thư viện C vẫn gây ra crash.

Giám sát và thu thập nhật ký crash

Firebase Crashlytics — tiêu chuẩn cho ứng dụng di động. Tự động thu thập stack trace, thêm nhật ký, ID người dùng và siêu dữ liệu thiết bị. Phân nhóm crash theo chữ ký (lớp lỗi + dòng). Cảnh báo thời gian thực — thông báo khi tỷ lệ crash vượt quá ngưỡng đã đặt (ví dụ: >0,1% mỗi giờ).

Sentry — một giải pháp thay thế với khả năng linh hoạt hơn. Cho phép tạo ngữ cảnh tùy chỉnh, thêm breadcrumb (sự kiện trước đó), cấu hình bộ lọc trong ứng dụng để loại trừ các lỗi không quan trọng. Source maps cho Kotlin và Swift cho phép xem mã nguồn thay vì tên bị làm rối.

Các phương pháp hay nhất cho nhật ký: gửi siêu dữ liệu chính trước khi thực hiện thao tác nguy hiểm — nhờ đó nhật ký sẽ hiển thị người dùng đang làm gì trước khi crash. Thêm khóa tùy chỉnh (số phiên bản API, màn hình cuối cùng, kích thước dữ liệu đầu vào). Điều này biến stack trace vô dụng thành thông tin có thể hành động.

Ví dụ: thiết lập Crashlytics trong Android

class PaymentViewModel : ViewModel() {
    fun processPayment(amount: Double) {
        crashlytics.setCustomKey("last_screen", "payment")
        crashlytics.setCustomKey("amount", amount)
        try {
            api.charge(amount)
        } catch (e: Exception) {
            crashlytics.recordException(e)
        }
    }
}

Chiến lược phòng ngừa crash

Ràng buộc tùy chọn và null safety — trong Kotlin sử dụng `?` cho kiểu nullable, `let` và `?:` để xử lý null an toàn. Trong Swift — optionals và guard let. Kotlin hiện đại (2024) đã thêm chú thích Contract: `@ContractsDsl` cho phép khai báo rằng một hàm không trả về null và trình biên dịch kiểm tra điều đó.

Xử lý lỗi mạng — mỗi yêu cầu mạng phải xử lý timeout, lỗi phân tích và lỗi máy chủ. Retrofit với kiểu Result — một lớp sealed đảm bảo lỗi sẽ được xử lý. Phong cách không ngoại lệ: thay vì try/catch, sử dụng Result sealed để xử lý rõ ràng thành công và lỗi.

Cờ tính năng — tắt chức năng có vấn đề từ xa mà không cần phát hành phiên bản mới. Nếu một thao tác máy chủ gây crash trên thiết bị cũ, cờ sẽ tắt nó cho nhóm đó. Firebase Remote Config cho phép thay đổi hành vi ứng dụng mà không cần xuất bản lên cửa hàng.

Triển khai dần dần — phát hành phiên bản mới cho 5% người dùng và theo dõi tỷ lệ crash. Nếu tỷ lệ duy trì dưới mục tiêu (thường <0,1%), mở rộng lên 25%, sau đó 50%, sau đó 100%. Google Play Console và App Store Connect hỗ trợ triển khai theo giai đoạn để tự động dừng khi vượt ngưỡng.

Kế hoạch hành động khi phát hiện lỗi

Bước 1: Phân loại — xác định mức độ nghiêm trọng: Nghiêm trọng (crash ở >1% người dùng), Cao (0,1–1%), Trung bình (<0,1%). Với crash nghiêm trọng — phản hồi ngay lập tức. Với các trường hợp khác — quy trình sửa lỗi tiêu chuẩn trong sprint hiện tại. Google Play Console tự động phân loại crash theo số lượng người dùng bị ảnh hưởng.

Bước 2: Phân tích stack trace — mở nhật ký trong Crashlytics, xem vị trí crash chính xác. Kiểm tra khóa tùy chỉnh: màn hình nào, dữ liệu nào, phiên bản hệ điều hành. Liên hệ với bản triển khai gần nhất — thường crash do thay đổi mã gần đây ảnh hưởng đến kịch bản sử dụng không mong đợi.

Bước 3: Tái tạo — thử tái tạo crash trên thiết bị hoặc trình giả lập với tham số tương tự. Nếu không thành công, kiểm tra nhật ký crash theo mẫu: model cụ thể (Samsung A10), phiên bản Android (API < 26), ngôn ngữ. Giải pháp — thêm điều kiện phòng vệ bao phủ kịch bản.

Bước 4: Sửa lỗi và giám sát — phát hành bản vá ưu tiên. Sau khi phát hành, đảm bảo tỷ lệ crash cho loại này giảm xuống không. Viết kiểm thử hồi quy bao phủ kịch bản crash. Nếu không có kiểm thử, cùng một lỗi có thể quay lại trong lần tái cấu trúc tiếp theo.