Tôi có nên nhận xét các cuộc gọi đăng nhập khi tạo gói cuối cùng của mình không?

Question

Tôi có một ứng dụng sử dụng nhiều lệnh Log.d() hoặc Log.e() để gỡ lỗi. Bây giờ tôi muốn tạo gói cuối cùng để phát hành. Tính năng Xuất của Android từ Eclipse đề cập đến việc xóa cờ "Debuggable" trong tệp kê khai mà tôi đã thực hiện. Tôi có nên bình luận tất cả các cuộc gọi Log để cải thiện hiệu suất của ứng dụng của tôi hoặc các cuộc gọi này sẽ không làm gì trong gói phiên bản cuối cùng không thể gỡ lỗi?

Answer 1

Tôi đã phân lớp lớp Log thành một lớp có tên Trace, phản ánh các phương thức trên Nhật ký. Vì vậy, tôi làm Trace.d (TAG, "blah") và sau đó trong phương thức Trace.d mã chỉ thực thi dựa trên biến lớp cuối cùng tĩnh gọi là LOGGING_LEVEL, có mức 1-5 (không, chỉ lỗi, lỗi & cảnh báo , lỗi & cảnh báo & thông tin và mọi thứ bao gồm gỡ lỗi). Khi sản xuất APK sản xuất, Proguard sẽ xóa tất cả mã không được sử dụng trong ứng dụng, vì vậy nó sẽ làm cho tôi.

Đối với tôi, việc ghi nhật ký quá quan trọng để xóa khỏi nguồn, nhưng nó phải bị xóa khỏi ứng dụng sản xuất, vì lý do hiệu suất, an toàn và sở hữu trí tuệ.

Cấu trúc này cho phép tôi để thêm ghi THÊM rất nhiều đến các ứng dụng, mà làm cho vấn đề gỡ lỗi dễ dàng hơn nhiều, nhưng không có tác động nào đến việc sản xuất APK

public class Trace 
{ 
    public static final int NONE       = 0; 
    public static final int ERRORS_ONLY     = 1; 
    public static final int ERRORS_WARNINGS    = 2; 
    public static final int ERRORS_WARNINGS_INFO   = 3; 
    public static final int ERRORS_WARNINGS_INFO_DEBUG = 4; 

    private static final int   LOGGING_LEVEL = ERRORS_ONLY;  // Errors + warnings + info + debug (default) 

    public static void e(String tag, String msg) 
    { 
     if (LOGGING_LEVEL >=1) Log.e(tag,msg); 
    } 

    public static void e(String tag, String msg, Exception e) 
    { 
     if (LOGGING_LEVEL >=1) Log.e(tag,msg,e); 
    } 

    public static void w(String tag, String msg) 
    { 
     if (LOGGING_LEVEL >=2) Log.w(tag, msg); 
    } 

    public static void i(String tag, String msg) 
    { 
     if (LOGGING_LEVEL >=3) Log.i(tag,msg); 
    } 

    public static void d(String tag, String msg) 
    { 
     if (LOGGING_LEVEL >=4) Log.d(tag, msg); 
    } 

} 

Answer 2

Từ developer.android.com:

Tắt khai thác gỗ và gỡ lỗi và dọn dẹp dữ liệu/file Đối với phát hành, bạn nên chắc chắn rằng cơ sở vật chất debug được tắt và sửa lỗi đó và khác không cần thiết dữ liệu/tệp được xóa khỏi dự án ứng dụng của bạn.

Xóa thuộc tính android: debuggable = "true" từ yếu tố của tệp kê khai. Xóa nhật ký tệp, tệp sao lưu và các tệp không cần thiết khác từ ứng dụng . Kiểm tra riêng tư hoặc dữ liệu độc quyền và xóa dữ liệu đó là cần thiết. Tắt mọi cuộc gọi tới các phương thức Log trong mã nguồn.

Source

Answer 3

Điều này làm tôi kiểm tra giả thuyết của tôi rằng log.d dòng trong mã sẽ bằng cách nào đó không xuất hiện trên một gói ứng dụng phát hành ký kết mà không có cờ debuggable đặt trong manifest, tôi đã sai, họ vẫn xuất hiện.

Một tìm kiếm nhanh trên SO dẫn tôi đến câu trả lời chấp nhận cho câu hỏi này: Remove all debug logging calls before publishing: are there tools to do this?

Nó hoạt động rất tốt và bạn không cần phải thay đổi bất kỳ mã.

Answer 4

tôi sẽ loại bỏ các mã đăng nhập như sau:

-assumenosideeffects class android.util.Log { 
    public static boolean isLoggable(java.lang.String, int); 
    public static int v(...); 
    public static int i(...); 
    public static int w(...); 
    public static int d(...); 
    public static int e(...); 
    public static java.lang.String getStackTraceString(java.lang.Throwable); 
} 

-assumenosideeffects class java.lang.Exception { 
    public void printStackTrace(); 
} 

-assumenosideeffects class * implements org.slf4j.Logger { 
    public void trace(...); 
    public void debug(...); 
    public void info(...); 
    public void warn(...); 
    public void error(...); 
    public boolean isTraceEnabled(...); 
    public boolean isDebugEnabled(...); 
    public boolean isInfoEnabled(...); 
    public boolean isWarnEnabled(...); 
    public boolean isErrorEnabled(...); 
} 

Nếu được yêu cầu, lỗi và danh mục cảnh báo có thể được giữ lại.Nhưng hãy chắc chắn rằng tối ưu hóa và thu hẹp được kích hoạt cho việc xây dựng chỉ sau đó việc loại bỏ mã có hiệu lực