티스토리 뷰

반응형

 개발을 하다보면 android.util 패키지의 Log 클래스를 사용하여 로그를 분석하는 경우가 많습니다. 저도 대부분의 메소드와 데이터를 보고 싶은 중간중간에 참 많이 사용합니다. 그런데 골치거리중에 하나가 테스트시에는 보이는 것이 맞는데 배포시에 사용자에게는 불필요한 메시지이기도하고, 중요한 데이터를 숨겨야 하는 등의 이유로 Log를 주석처리하거나, 제거해야 하죠..


 안드로이드 개발툴이 발전하면서 이러한 부분에도 신경쓴 부분이 있는데요. 안드로이드 프로그램 프로젝트에 보시면 다음과 같은 클래스가 자동으로 생성된 것을 본적이 있을 겁니다.



 프로젝트구조에 자동생성되는 gen 폴더가 있습니다. 여기에 프로젝트 생성시 작성했던 기본패키지와 동일한 패키지내에 BuildConfig.java 와 R.java 가 자동생성되어 있습니다. R.java는 익히 아시듯이 res(리소스) 폴더의 각 파일과 xml 레이아웃등의 파일의 리스소를 자동으로 빌드해서 생성된 파일이지요.


 우리가 관심을 가질 파일은 BuildConfig.java 입니다. 열어보시면 내용은 별개 없습니다.


/** Automatically generated file. DO NOT MODIFY */
package com.dante2k.test;

public final class BuildConfig {
    public final static boolean DEBUG = true;
}


 주석에 자동으로 생성되는 파일이니 수정하지 말라고 되었습니다. 내용을 건드리지는 마시구요.. 그리고 클래스내에 public fianl static 으로 선언된 상수가 하나 있습니다. DEBUG지요..


 이것이 테스트 빌드시에는 true로 되어있다가, apk 배포시에는 false로 자동으로 변경되어 apk를 생성합니다. 고로 우리는 저것을 사용하면 테스트에는 로그를 볼 수 있게, 배포시에는 로그가 나오지 않도록 할 수 있다는 것이지요..


 필요에 따라서는 테스트시 접근가능한 테스트 메뉴나 엑티비티를 만들고 위 상수를 이용하여 배포시 접근하지 못하게 할 수도 있다는 이야기입니다. 뭐 이건 개발자 소간이니까요..


 자 그럼 로그를 위한 별도의 클래스를 하나 만들어봤습니다.


package com.dante2k.test.common;

import com.dante2k.test.BuildConfig;

import android.content.Context;
import android.util.Log;

/**
 * Log 와 같은 기능을 지원하는 클래스
 * 
 * 

* 테스트시에는 BuildConfig.DEBUG가 true 상태여서 logcat으로 로그를 분석할 수 있고, apk 생성하여 배포시에는 * 자동으로 false로 변경되어 로그가 출력되지 않는다. *

* * @author dante2k * */ public class DLog { /** Log Level Error **/ public static final void e(Context context, String message) { if (BuildConfig.DEBUG) Log.e(context.getClass().getSimpleName(), message); } /** Log Level Warning **/ public static final void w(Context context, String message) { if (BuildConfig.DEBUG) Log.w(context.getClass().getSimpleName(), message); } /** Log Level Information **/ public static final void i(Context context, String message) { if (BuildConfig.DEBUG) Log.i(context.getClass().getSimpleName(), message); } /** Log Level Debug **/ public static final void d(Context context, String message) { if (BuildConfig.DEBUG) Log.d(context.getClass().getSimpleName(), message); } /** Log Level Verbose **/ public static final void v(Context context, String message) { if (BuildConfig.DEBUG) Log.v(context.getClass().getSimpleName(), message); } /** Log Level Error **/ public static final void e(String TAG, String message) { if (BuildConfig.DEBUG) Log.e(TAG, message); } /** Log Level Warning **/ public static final void w(String TAG, String message) { if (BuildConfig.DEBUG) Log.w(TAG, message); } /** Log Level Information **/ public static final void i(String TAG, String message) { if (BuildConfig.DEBUG) Log.i(TAG, message); } /** Log Level Debug **/ public static final void d(String TAG, String message) { if (BuildConfig.DEBUG) Log.d(TAG, message); } /** Log Level Verbose **/ public static final void v(String TAG, String message) { if (BuildConfig.DEBUG) Log.v(TAG, message); } }

 별개 없습니다. 기존에 Log.d("TAG", "error message"); 등으로 활용하던 것을 단순히 DLog.d("TAG", "error message"); 로 변경하여 사용하시면 됩니다. 클래스명은 원하시는대로 변경하셔서 사용하시면 되고요.


 속도면에서는 주석처리보다 느리지 않느냐 하실지 모르겠습니다만.. 일단 if 문에서 항상 false인 경우 내부코드는 데드코드가 되어서 컴파일타임에서 처리됩니다. 오버로드라고 하면 빈 함수를 호출하는 정도의 추가적인 로드가 발생하기는 하겠지만, 그것이 귀차니즘을 이길 수는 없습니다.


 이렇게해서 테스트, 배포에 따른 로그를 처리하는 방법을 알아보았습니다.


끝.

반응형
댓글
댓글쓰기 폼