Android Strict Mode
'개발자 옵션 - 모니터링' 부분을 보면 Strict mode enabled 옵션이 있습니다.
앱이 메인 스레드에서 긴 작업을 수행하면 화면을 깜빡이게(flash) 하는 옵션입니다.
Strict mode에 대해 알아보겠습니다.
안드로이드는 기본적으로 메인 스레드(UI 스레드)에서 UI와 관련된 작업을 할 수 있습니다.
만약 메인 스레드에서 시간이 오래 걸리는 작업을 하게 된다면, 화면이 버벅거리는 프레임 드롭 현상이나 앱이 멈추는 ANR에 걸릴 수도 있습니다.
Disk나 Network 같이 시간이 오래 걸리는 작업들을 찾아내기 위해 Strict Mode라는 옵션을 이용할 수 있습니다.
Strict Mode를 활성화시키면, 시간이 오래 걸리는 작업이 발생할 때마다 화면 가장자리가 깜빡거리는 현상이 발생합니다. 이를 통해 개발자는 해당 부분에 잠재적인 문제 요소가 있다는 것을 발견할 수 있습니다.
개발자 옵션의 Strict Mode를 통해 단순히 체크만 할 뿐만 아니라, StrictMode API들을 이용하여 개발자가 직접 잠재적인 문제 요소들을 파악할 수 있습니다.
잠재적인 문제 요소들을 파악할 수 있다는 점에서 Lint와 비슷한데, 컴파일 단계에서 파악하는 Lint와 달리 StrictMode는 런타임 단계에서 파악할 수 있습니다.
아래와 같이 Activity나 Application onCreate() 메서드의 앞부분에 StrictMode의 정책(policy)을 지정할 수 있습니다.
이 정책에는 StrictMode.ThreadPolicy와 StrictMode.VmPolicy 두 가지가 있습니다.
ThreadPolicy는 Disk나 Network 같은 메인 스레드에 문제를 야기시킬 수 도 있는 부분을 찾아주고, 이를 다양한 형태로 알려줍니다.
아래와 같이 여러 API를 통해 검출(Detection) 해야 할 문제점들과, 이 문제점들을 발견했을 때 해야 할 일들(Penalty) 지정할 수 있습니다.
하나의 문제에 대해서 여러 penalty들을 지정할 수 있는데, 이 경우엔 심각한 정도에 따라 penalty가 실행되는 순서가 달라지게 됩니다.
ex) Log가 먼저 실행된 뒤에 앱이 종료되는 Death가 실행됨.
VmPolicy는 메모리 누수(Memory leak)가 발생할 수 있는 부분을 찾아주고, 이를 다양한 형태로 알려 줍니다.
메모리 누수로 인해 가용 메모리가 부족하게 되면 결국 메인 스레드에도 영향을 미치기 때문에 메모리 누수도 찾아서 고쳐야 합니다.
ThreadPolicy와 동일하게 여러 API를 통해 검출(Detection) 해야 할 문제점들과, 이 문제점들을 발견했을 때 해야 할 일들(Penalty) 지정할 수 있습니다.
참고로 StrictMode는 사용자에게 보이면 안 되기 때문에 BuildConfig.DEBUG 코드를 통해 디버그 할 때만 보이도록 해야 합니다.
아래와 같이 Log나 다른 형태로 문제점을 야기시킬 수 있는 부분을 나타냅니다.
두 번째 로그 NetworkOnMainThreadException은 메인 스레드에서 네트워크 작업을 할 때 발생하는 Exception입니다.
좀 더 자세한 설명을 보면, Honeycomb 이상의 버전에서만 발생하는데 네트워크를 체크하는 StrictMode가 Honeycomb부터 기본적으로 활성화되었기 때문입니다.
기본적으로 제공하는 StrictMode의 경우, Honeycomb 이상 버전에서 기본적으로 활성화되어 있기 때문에 쓸 만 하지만, custom 한 noteSlowCall의 경우엔 위에 나온 대로 애매한 부분이 있습니다.
그리고 구글 영상에도 나오지만 StrictMode 자체를 맹신하지 말라네요 ㅎㅎ
현재로서는 StrictMode를 직접 쓸 일 이 있을지는 모르겠지만 구글에서 계속에서 새로운 API를 만들고 있기 때문에, 새로운 OS 버전이 나올 때마다 확인할 필요는 있을 거 같습니다.