Làm gì nếu bạn không biết crash xảy ra ở vị trí nào trong code?

Chắc hẳn là bất cứ bạn Android dev nào cũng đã từng gặp crash khi phát triển app đúng không nào?! Nếu các bạn dùng Eclipse để phát triển app, thì Eclipse sẽ báo ngay cho các bạn biết vị trí xảy ra crash tại lúc đó. Nhưng đôi khi có những lúc Eclipse báo crash ở tầng rất thấp và bạn không thể truy ngược lại đoạn code mà mình có thể can thiệp. Cho nên khi gặp tình huống như vậy, có người sẽ đoán vị trí crash, rồi đặt breakpoint ở vài vị trí “khả nghi”. Việc này cũng gây ngốn thời gian của chúng ta cũng khá nhiều đấy! Và việc làm như vậy cũng rất là bị động…

crash unknown
Eclipse bắt crash ở tầng thấp (low-level)

CHỦ ĐỘNG tìm vị trí crash nhờ Logcat

Mình xin chia sẻ với các bạn hướng để mình có thể biết được vị trí crash ở mức độ tên hàm dù gặp bất cứ crash nào. Chắc các bạn đã biết rằng Logcat trong Eclipse, đó là một tính năng của Android cho phép bạn có thể xem những đoạn log từ app truyền ra. Mỗi dòng log của Logcat có 3 đặc tính quan trọng:

  1. Nhiều loại level như debug, verbose, info, error… với những màu sắc khác nhau.
  2. Tag’s field.
  3. Text’s field.
Logcat overview markup
3 đặc trưng của một dòng log trong Logcat

Mình sử dụng Logcat một cách chủ động bằng cách chưa có bug thì mình cũng ghi log lại ở những vị trí mà mình cho là cần thiết. Ngoài việc lấy log khi phát triển sản phẩm, đôi khi mình cũng cần lấy log khi gửi cho người dùng test thông qua các ứng dụng crash report (ví dụ như Crashlytics, HockeyApp hay Flurry…), vì thế mình wrap các hàm của Logcat lại vào một class LogManager như sau:

Vì log một cách chủ động như vậy, mỗi dòng log của mình cần có cách để xác định vị trí của nó trong code. Để biết được vị trí, thì mình cần biết tên class và tên hàm, vì thế mình sẽ đặt tên class ở Tag’s field, và tên hàm ở phần Text’s field. Vậy là với một dòng log như vậy thì mình có thể biết chính xác vị trí code ở đâu rồi đó! Việc tiếp theo mình cần biết là cách tận dụng màu sắc cũng như phân loại Logcat ra để nhìn log một cách dễ dàng nhất. Cho nên 5 loại của Logcat được mình dùng ở các vị trí như sau:

  1. LogManager.i : khi bắt đầu hàm (trừ hàm action) (màu xanh lá cây)
  2. LogManager.v : khi bắt đầu hàm thể hiện action (onClick(), onTouch()…) (màu đen)
  3. LogManager.e : trong phần catch của try catch exception nếu mình không expect lỗi này xảy ra vì có thể ảnh hưởng đến chương trình. (màu đỏ)
  4. LogManager.w : trong phần catch của try catch exception nếu lỗi này xảy ra nhưng nó không ảnh hưởng đến chương trình, mình có thể đã biết lỗi này rồi. (màu vàng)
  5. LogManager.d : dành cho những trường hợp còn lại, log bất cứ chỗ nào quan tâm. (màu xanh dương)

Và đây là ví dụ cho những chỗ cần “gài” để lấy log như đã nêu trên:

ClassName.java

Phòng bệnh > Chữa bệnh

Tuy nhìn có vẻ phiền phức và dư thừa, nhưng nó thực sự rất hữu ích khi các bạn track bug cho những device của mình và của cả những người dùng khác. Vì thiết bị Android có rất là nhiều loại và bug của nó có thể xảy ra bất cứ ở đâu, có thể ở những chỗ mình không ngờ và bạn không có đúng loại device đó để test.

Mục đích chính của bài post này là chia sẻ các bạn tư tưởng đặt log một cách chủ động và sắp xếp log sao cho hợp lý, còn về chi tiết thì các bạn có thể phát triển những cách riêng của mình sao cho phù hợp.

Những góp ý hoặc chia sẻ từ các bạn luôn được hoan nghênh!

SSS Full-stack Engineer

Love Silicon Straits and want to know more about our company culture, working environment or job vacancies?
Find out more at careers.siliconstraits.vn.

Silicon Straits
Be Challenged. Be Inspired. Be Different.


Published by Harmony Lee

Balance for efficience