Các LogCatphương pháp khác nhau là:
Log.v(); // Verbose
Log.d(); // Debug
Log.i(); // Info
Log.w(); // Warning
Log.e(); // ErrorCác tình huống thích hợp để sử dụng từng loại Đăng nhập là gì? Tôi biết rằng có lẽ đó chỉ là một chút ngữ nghĩa và có lẽ nó không thực sự quan trọng, nhưng để LogCatlọc trong Android Studio và Eclipse, thật tuyệt khi biết tôi đang sử dụng các phương thức thích hợp vào những thời điểm thích hợp.
Câu trả lời:
Hãy đi theo thứ tự ngược lại:
Log.e : Đây là khi những thứ xấu xảy ra. Sử dụng thẻ này ở những nơi như bên trong một tuyên bố bắt. Bạn biết rằngđã xảy ra lỗi và do đó bạn đang đăng nhập một lỗi.
Log.w : Sử dụng điều này khi bạn nghi ngờ điều gì đó mờ ám đang diễn ra. Bạn có thể không hoàn toàn ở chế độ lỗi, nhưng có thể bạn đã phục hồi từ một số hành vi không mong muốn. Về cơ bản, sử dụng điều này để ghi nhật ký những thứ bạn không mong muốn xảy ra nhưng không nhất thiết là một lỗi. Kiểu như một "hey, điều này đã xảy ra, và thật kỳ lạ , chúng ta nên xem xét nó."
Log.i : Sử dụng điều này để đăng thông tin hữu íchvào nhật ký. Ví dụ: bạn đã kết nối thành công với máy chủ. Về cơ bản sử dụng nó để báo cáo thành công.
Log.d : Sử dụng cái này chomục đích gỡ lỗi . Nếu bạn muốn in ra một loạt các tin nhắn để bạn có thể ghi lại chính xác luồng chương trình của mình, hãy sử dụng cái này. Nếu bạn muốn giữ một bản ghi các giá trị biến, hãy sử dụng cái này.
Log.v : Sử dụng cái này khi bạn muốn thực hiện các thao tác hoàn toàn với việc ghi nhật ký của bạn. Nếu vì một lý do nào đó, bạn đã quyết định đăng nhập từng thứ nhỏ trong một phần cụ thể của ứng dụng, hãy sử dụng thẻ Log.v.
Và như một phần thưởng ...
Log.wtfmình thậm chí đã kiểm tra vài lần và cười rất to .. Theo tôi, tất cả các API nên có một cái gì đó như thế này trong
Các phương pháp khác nhau là chỉ dẫn ưu tiên. Như bạn đã liệt kê chúng, chúng sẽ đi từ ít nhất đến quan trọng nhất. Tôi nghĩ cách bạn ánh xạ cụ thể chúng để gỡ lỗi nhật ký trong mã của bạn tùy thuộc vào thành phần hoặc ứng dụng bạn đang làm việc, cũng như cách Android xử lý chúng trên các hương vị xây dựng khác nhau (eng, userdebug và user). Tôi đã thực hiện một số lượng công việc khá lớn trong các trình tiện ích gốc trong Android và đây là cách tôi thực hiện. Nó có thể không áp dụng trực tiếp cho ứng dụng của bạn, nhưng có thể có một số điểm chung. Nếu lời giải thích của tôi nghe có vẻ mơ hồ, thì đó là vì một số điều này là một nghệ thuật hơn là một khoa học. Quy tắc cơ bản của tôi là hiệu quả nhất có thể, đảm bảo bạn có thể gỡ lỗi hợp lý thành phần của mình mà không làm giảm hiệu suất của hệ thống và luôn kiểm tra lỗi và ghi nhật ký.
V - Bản in trạng thái tại các khoảng thời gian khác nhau hoặc theo bất kỳ sự kiện nào xảy ra mà thành phần của tôi xử lý. Cũng có thể bản in rất chi tiết về tải trọng của tin nhắn / sự kiện mà thành phần của tôi nhận hoặc gửi.
D - Chi tiết về các sự kiện nhỏ xảy ra trong thành phần của tôi, cũng như tải trọng của tin nhắn / sự kiện mà thành phần của tôi nhận hoặc gửi.
I - Tiêu đề của bất kỳ tin nhắn / sự kiện nào mà thành phần của tôi nhận hoặc gửi, cũng như bất kỳ phần quan trọng nào của tải trọng quan trọng đối với hoạt động của thành phần của tôi.
W - Bất cứ điều gì xảy ra bất thường hoặc đáng ngờ, nhưng không nhất thiết là một lỗi.
E - Lỗi, nghĩa là những điều không nên xảy ra khi mọi thứ đang hoạt động như bình thường.
Sai lầm lớn nhất tôi thấy mọi người mắc phải là họ lạm dụng những thứ như V, D và tôi, nhưng không bao giờ sử dụng W hoặc E. Nếu theo một định nghĩa, lỗi không được phép xảy ra hoặc chỉ xảy ra rất hiếm khi xảy ra, thì nó cực kỳ hiếm giá rẻ cho bạn để đăng nhập một tin nhắn khi nó xảy ra. Mặt khác, nếu mỗi lần ai đó nhấn phím bạn thực hiện Log.i (), bạn đang lạm dụng tài nguyên ghi nhật ký được chia sẻ. Tất nhiên, sử dụng thông thường và cẩn thận với nhật ký lỗi cho những thứ nằm ngoài tầm kiểm soát của bạn (như lỗi mạng) hoặc những lỗi chứa trong các vòng lặp chặt chẽ.
Có lẽ xấu
Log.i("I am here");Tốt
Log.e("I shouldn't be here");Với tất cả những điều này, mã của bạn càng gần "sẵn sàng sản xuất", bạn càng có thể hạn chế mức ghi nhật ký cơ sở cho mã của mình (bạn cần V in alpha, D trong beta, I trong sản xuất hoặc thậm chí là W trong sản xuất ). Bạn nên chạy qua một số trường hợp sử dụng đơn giản và xem nhật ký để đảm bảo rằng bạn vẫn có thể hiểu được những gì đang xảy ra khi bạn áp dụng bộ lọc hạn chế hơn. Nếu bạn chạy với bộ lọc bên dưới, bạn vẫn có thể biết ứng dụng của mình đang làm gì, nhưng có thể không nhận được tất cả các chi tiết.
logcat -v threadtime MyApp:I *:SMã nguồn cung cấp một số hướng dẫn cơ bản:
Thứ tự về mức độ chi tiết, từ ít nhất đến nhiều nhất là LRI, WARN, INFO, DEBUG, ĐỘNG TỪ. Verbose không bao giờ nên được biên dịch thành một ứng dụng trừ khi phát triển. Nhật ký gỡ lỗi được biên dịch trong nhưng bị tước khi chạy. Nhật ký lỗi, cảnh báo và thông tin luôn được lưu giữ.
Để biết thêm chi tiết, câu trả lời của Kurtis đã chết. Tôi chỉ cần thêm: Không đăng nhập bất kỳ thông tin cá nhân hoặc thông tin cá nhân nào tại INFOhoặc trên ( WARN/ ERROR). Mặt khác, báo cáo lỗi hoặc bất cứ điều gì khác bao gồm đăng nhập có thể bị ô nhiễm.
Bạn có thể sử dụng LOG như:
Log.e(String, String) (error)
Log.w(String, String) (warning)
Log.i(String, String) (information)
Log.d(String, String) (debug)
Log.v(String, String) (verbose)mã ví dụ:
private static final String TAG = "MyActivity";
...
Log.i(TAG, "MyClass.getView() — get item number " + position);Tôi nghĩ rằng điểm của các loại ghi nhật ký khác nhau đó là nếu bạn muốn ứng dụng của mình tự lọc các bản ghi của chính nó. Vì vậy, Verbose có thể ghi nhật ký hoàn toàn mọi thứ quan trọng trong ứng dụng của bạn, sau đó mức gỡ lỗi sẽ ghi lại một tập hợp con của nhật ký verbose và sau đó cấp Thông tin sẽ ghi nhật ký một tập hợp con của nhật ký gỡ lỗi. Khi bạn truy cập vào Nhật ký lỗi, thì bạn chỉ muốn ghi lại bất kỳ loại lỗi nào có thể xảy ra. Ngoài ra còn có một mức gỡ lỗi được gọi là Fatal khi một cái gì đó thực sự chạm vào người hâm mộ trong ứng dụng của bạn.
Nói chung, bạn đúng, về cơ bản là tùy ý và tùy thuộc vào bạn để xác định những gì được coi là nhật ký gỡ lỗi so với thông tin, so với và lỗi, v.v.
Mặc dù câu hỏi này đã được trả lời, tôi cảm thấy rằng có những ví dụ còn thiếu trong câu trả lời đã được trả lời.
Vì vậy, tôi sẽ mang đến đây những gì tôi đã viết trong một bài đăng trên blog "Cấp độ nhật ký Android"
Dài dòng
Là mức thấp nhất của đăng nhập. Nếu bạn muốn đi các hạt với đăng nhập thì bạn đi với cấp độ này. Tôi không bao giờ hiểu khi nào nên sử dụng Verbose và khi nào nên sử dụng Debug. Sự khác biệt nghe có vẻ rất tùy tiện. Cuối cùng tôi cũng hiểu nó một khi tôi được chỉ vào mã nguồn của Android¹ Kiếm Verbose không bao giờ nên được biên dịch thành một ứng dụng ngoại trừ trong quá trình phát triển. Bây giờ tôi đã rõ, bất cứ khi nào bạn đang phát triển và muốn thêm các nhật ký có thể xóa giúp bạn trong quá trình phát triển, sẽ rất hữu ích khi có mức độ dài dòng, điều này sẽ giúp bạn xóa tất cả các nhật ký này trước khi bạn đi vào sản xuất.
Gỡ lỗi
Dành cho mục đích gỡ lỗi. Đây là mức thấp nhất nên có trong sản xuất. Thông tin ở đây là để giúp đỡ trong quá trình phát triển. Hầu hết các lần bạn sẽ vô hiệu hóa nhật ký này trong sản xuất để gửi ít thông tin hơn và chỉ bật nhật ký này nếu bạn gặp sự cố. Tôi muốn đăng nhập gỡ lỗi tất cả thông tin mà ứng dụng gửi / nhận từ máy chủ (chú ý không đăng nhập mật khẩu !!!). Điều này rất hữu ích để hiểu nếu lỗi nằm ở máy chủ hoặc ứng dụng. Tôi cũng tạo nhật ký nhập và thoát các chức năng quan trọng.
Thông tin
Đối với các thông báo thông tin làm nổi bật tiến trình của ứng dụng. Ví dụ, khi khởi tạo ứng dụng kết thúc. Thêm thông tin khi người dùng di chuyển giữa các hoạt động và các mảnh. Ghi nhật ký từng lệnh gọi API nhưng chỉ cần một ít thông tin như URL, trạng thái và thời gian phản hồi.
Cảnh báo
Khi có một tình huống có thể gây hại.
Nhật ký này là trong kinh nghiệm của tôi một mức độ khó khăn. Khi nào bạn có một tình huống có hại tiềm tàng? Nói chung hoặc nó là OK hoặc đó là một lỗi. Cá nhân tôi không sử dụng cấp độ này nhiều. Ví dụ về khi tôi sử dụng nó thường là khi công cụ xảy ra nhiều lần. Ví dụ: một người dùng có mật khẩu sai hơn 3 lần. Điều này có thể là do anh ta nhập sai mật khẩu 3 lần, cũng có thể là do có vấn đề với một nhân vật không được chấp nhận trong hệ thống của chúng tôi. Tương tự với các vấn đề kết nối mạng.
lỗi
Sự kiện lỗi. Ứng dụng vẫn có thể tiếp tục chạy sau lỗi. Đây có thể là ví dụ khi tôi nhận được một con trỏ null trong đó tôi không cần phải lấy một con trỏ. Có lỗi khi phân tích phản hồi của máy chủ. Có một lỗi từ máy chủ.
WTF (Thật là một thất bại khủng khiếp)
Fatal dành cho các sự kiện lỗi nghiêm trọng sẽ khiến ứng dụng thoát ra. Trong Android, mức độ nghiêm trọng trong thực tế là mức Lỗi, sự khác biệt là nó cũng thêm fullstack.
Các trang web Android Studio có thời gian gần đây (tôi nghĩ) cung cấp một số lời khuyên những loại thông điệp mong đợi từ mức log khác nhau mà có thể hữu ích cùng với Kurtis' câu trả lời:
Verboseđăng nhập. Đó là những gì bạn sử dụng khi bạn muốn xuất ra mọi hoạt động logic có thể.