LeakCanary: phát hiện rò rỉ bộ nhớ dành cho dev Android

LeakCanary là gì?

LeakCanary là thư viện Android mã nguồn mở do Square duy trì, phát hiện rò rỉ bộ nhớ ngay trong lúc bạn phát triển app chứ không phải sau khi app đã ra mắt. Nó gắn vào lifecycle của Android để theo dõi các object — một Activity đã bị destroy, một Fragment đã bị clear — lẽ ra phải được garbage collector thu hồi. Khi một object còn sót lại, LeakCanary dump heap và lần theo chuỗi tham chiếu từ một GC root xuống tới object đang bị kẹt.

Tính năng chính của LeakCanary

• ✓Tự động phát hiện Activity, Fragment và View bị giữ lại trong lúc phát triển, không cần chạy profiler thủ công
• ✓Tích hợp sẵn dump heap và phân tích hprof, không cần gắn thêm công cụ phân tích riêng
• ✓In ra leak trace cho thấy chuỗi tham chiếu chính xác từ một GC root tới object bị rò rỉ
• ✓Hoạt động như nhau trên dự án Kotlin lẫn Java vì nó gắn vào lifecycle của Android, không phụ thuộc ngôn ngữ
• ✓Giấy phép Apache-2.0 nên có thể đưa vào debug build của app thương mại mà không cần bàn về pháp lý
• ✓Chỉ là một dependency Gradle — không có service riêng nào phải chạy

Khi nào nên dùng LeakCanary

• •Debug một app có mức dùng bộ nhớ cứ tăng dần qua một phiên sử dụng dài
• •Bắt một Activity hoặc Fragment bị rò rỉ ngay sau khi refactor code điều hướng hoặc lifecycle
• •Chạy liên tục trong lúc phát triển để rò rỉ lộ ra trước khi tới tay QA hoặc gây crash ngoài production
• •Kiểm tra xem một SDK bên thứ ba hay custom View có đang giữ tham chiếu quá lifecycle của Activity hay không

Thêm LeakCanary vào dự án Android

LeakCanary được thêm vào như một dependency Gradle trong module app — không cần tài khoản, không cần service, không có bước cài đặt riêng. Nguồn dữ liệu ở đây không nêu chính xác tọa độ dependency hay số phiên bản hiện tại, nên hãy lấy dòng Gradle chính xác từ tài liệu chính thức tại square.github.io/leakcanary thay vì đoán phiên bản ở đây. Sau khi có trong build, phần lớn app không cần thêm code setup nào để bắt đầu thấy leak trace.

LeakCanary hoạt động như thế nào

LeakCanary theo dõi các object lẽ ra phải được garbage collector thu hồi — một Activity hay Fragment đã bị destroy, một ViewModel đã bị clear, một View đã bị gỡ khỏi parent. Nếu một trong số đó vẫn còn tồn tại sau khoảng thời gian đáng lẽ đã bị thu hồi, LeakCanary kích hoạt dump heap và ghi ra một file hprof. Sau đó nó phân tích file dump này và tính đường đi ngắn nhất từ một GC root tới object bị giữ lại — chính là leak trace — chỉ ra tham chiếu cụ thể trong code đang giữ nó sống. Bạn thấy kết quả dưới dạng notification ngay trong lúc phát triển. Không cần chạy profiler riêng.

Lựa chọn thay thế cho phân tích bộ nhớ Android

Câu hỏi thường gặp

Vấn đề mà LeakCanary giải quyết

Rò rỉ bộ nhớ trong một app Android âm thầm cho tới khi nó không còn âm thầm nữa — một app giữ lại một Activity hay Fragment đã bị destroy sẽ ngốn dần bộ nhớ khả dụng qua một phiên sử dụng, và kiểu lỗi thường gặp là một OutOfMemoryError ngoài production với stack trace không nói rõ object nào gây ra. Bắt được điều đó ngay trong lúc phát triển, trước khi nó biến thành một crash report, chính là khoảng trống cụ thể mà LeakCanary lấp vào: nó gọi tên tham chiếu đang rò rỉ ngay khi bạn vẫn đang viết đoạn code gây ra rò rỉ đó.

Nên dùng LeakCanary khi nào — và khi nào nên bỏ qua

Một team đang phát hành app Android bằng Kotlin hoặc Java nên có LeakCanary trong debug build — chi phí setup thấp hơn nhiều so với việc lần mò một crash report OutOfMemoryError mà không có leak trace đi kèm. Bỏ qua nó, hoặc ít nhất đừng chỉ dựa vào nó, nếu bạn đang xây một library hay SDK để chạy trong app của người khác; công cụ này được thiết kế quanh vòng lặp phát triển của chính app bạn, không phải thứ bạn đóng gói gửi cho người dùng cuối. Nó cũng không phải công cụ đúng cho một vấn đề hiệu năng hay CPU diện rộng — đó là việc của một profiler, không phải của một công cụ bắt rò rỉ.

Repo liên quan