소개 (0:05)

저는 Gautier로 이번 Mobilization 컨퍼런스에서 2016년 안드로이드 개발자 도구에 대한 세션을 맡았습니다.

새로운 회사에 들어가서 첫날 제가 맡은 일은 기존 프로젝트를 유지하는 전쟁같은 일이었습니다. 그 전쟁터와 프로젝트 모두 마음에 들었지만 스스로 준비가 안된것을 깨달았죠. 회사에 들어가기 전에 사용하던 좋은 방어구와 작은 무기가 있긴 했지만 실제 일터에서 사용하기에는 적합하지 않았습니다. 일의 전반적인 품질을 향상하고 개발자로서의 생산성을 높이려면 적재적소에 적합한 도구를 사용해야 했습니다. 그래서 적절한 도구를 선택했고, 지금은 훨씬 더 잘 작업할 수 있게 됐습니다.

안드로이드 개발에 적합한 도구 선택하기 (0:34)

이 강연에서는 안드로이드를 개발할 때 적합한 도구를 선택하는 방법에 대해 말하겠습니다.

Gradle (1:45)

첫 번째 도구는 Gradle 입니다. Maven이나 Kobalt, Buck을 쓰지 않는 이상 거의 모든 개발자들이 사용한다 해도 과언이 아닐텐데요. Gradle 안드로이드 플러그인의 훌륭한 점은 빌드를 변형할 수 있다는 점입니다.

빌드 변형 (1:53)

빌드를 변형하면 같은 애플리케이션의 서로 다른 버전을 만들 수 있게 됩니다. 소스 코드는 거의 같고 아주 약간의 변화만 줄 수 있죠. 예를 들어 두 개의 애플리케이션을 만들고 하나는 무료 모델로, 하나는 유료 모델로 만들 수 있습니다. 소스 코드는 같지만 빌드 변형으로 두 개의 타입이 되죠.

작업 흐름을 제안하자면 두 개의 변형 타입을 만들어서 하나는 내부용으로 하나는 상용으로 사용하는 것입니다. 내부용 빌드는 회사 내의 사람들이 사용하게 하고, 상용 빌드는 고객들을 위해 Play Store에 사용합니다. 내부용 빌드 변경을 따로 사용하는 이유는 디버그에 도움이 되고 이슈를 쉽게 파악하는데 도움이 되는 여러 도구를 포함하기 위해서입니다.

영감을 얻은 곳: U+2020 (3:03)

이제부터는 내부용 버전에 넣을 수 있는 유용한 도구들에 대해 말씀드리겠습니다. 이런 아이디어는 U+2020 예제 애플리케이션에서 얻을 수 있었는데, 안드로이드 개발자에게는 정말 노다지와 같은 곳입니다. Gradle과 Dagger를 포함한 여러 라이브러리들을 통합하는 깔끔하고 고급스러운 예시를 볼 수 있습니다.

디버그 화면 (3:30)

이제 내부용 버전에서 무엇을 할 수 있는지 예제와 함께 보여드리겠습니다.

만약 앱에 menu drawer를 사용한다면 Debugger 라는 새 항목을 추가하고 개발을 돕는 여러 가지를 넣을 수 있습니다. 예를 들어 알림을 시험하고, 여러 알림을 보여주고, 다른 액티비디를 보이는 등의 작업을 할 수 있죠. 만약 menu drawer가 없다면 Android manifest에 여러 다양한 상태의 액티비티를 만들면 됩니다. 앱을 빌드할 때 manifest merger가 두 개의 상태 액티비티를 병합해줍니다. 그 결과로 두 개의 상태 액티비티를 가진 하나의 애플리케이션을 만들 수 있죠. 하나는 응용프로그램의 정상적인 액티비티를 보여주고, 하나는 내부용 액티비티를 보여줄 수 있습니다. 내부용 액티비티는 일부 빌더 장치 정보를 표시하거나 엔드포인트를 변경하거나 로그를 보여주는 등의 동작을 설정할 수 있는 액티비티입니다.

Mobilization 2016 애플리케이션 (4:46)

U+2020에서 영감을 얻어 이번 컨퍼런스 동안의 일정을 관리하는 앱을 만들었습니다. 몇몇 강연을 선택해두면 강연이 시작하는 시간을 알려줍니다. 강연에 대한 사진이나 강연자, 강연 장소 등 모든 것에 대한 정보도 볼 수 있는 앱입니다. 이제부터 말씀드릴 모든 도구들이 이 프로젝트에 포함돼 있으니 클론하거나 포크하고 소스 코드를 응용해도 좋습니다.

측정 도구 (5:15)

지금부터는 측정 도구에 대해 말씀드리겠습니다.

Android Studio (5:20)

Android Studio 의 화면 아래에서 Android Monitor Tab 을 클릭하면 메모리를 측정하고 CPU 네트워크와 사용량을 확인할 수 있습니다.

메모리, CPU 네트워크와 사용량 측정 (5:24)

왼쪽 화면 중 파란색 그래프가 애플리케이션의 메모리 사용량을 나타냅니다. 네트워크를 통해 사진이나 이미지 데이터가 로드되는 것은 노란색 점선으로 볼 수 있는데 저는 이미지 캐시를 만들었기 때문에 현재는 스크롤을 해도 네트워크 통신을 나타내는 수치가 생기지 않습니다. 이런 이미지 캐시가 제대로 작동하는지와 같은 상황들을 Android Studio의 모니터 도구로 확인할 수 있죠. 파란색 크래프에서는 메모리가 살짝 증가하다가 중간에 감소한 것을 볼 수 있는데 이것으로 메모리 유출이 없고 시스템이 필요없는 메모리를 거두고 있음을 확인할 수 있어서 유용합니다.

메모리 유출 확인 (6:36)

하지만 메모리가 유출되고 있다면 어떻게 해야 할까요? 예제 앱이 메모리를 136 MB 가량 사용하고 있으면 너무 많이 사용하는 거겠죠. 이때 “Dump Java Heap” 버튼을 누르면 hprof을 만들어 줍니다. 그 다음 Analyzer 태스크를 눌러서 메모리를 유출하는 액티비티를 탐지합니다. 이제 Android Studio의 Analysis를 실행하면 몇 초 안에 애플리케이션 내의 어떤 액티비티에서 메모리가 유출되는지 알려줍니다.

많은 액티비티에서 메모리가 유출되고 있는 것을 볼 수 있습니다. 이제 첫 번째 항목을 계속 누르면 유출이 일어나는 근원지를 Android Studio가 바로 알려줍니다. 컨텍스트의 참조를 유지하는 analytics 프레임워크를 사용하고 있으므로 컨텍스트에 대한 참조를 유지할 수 있습니다.

Leak Canary (7:48)

메모리 유출을 탐지할 때 IDE를 사용하고 싶지 않다면 애플리케이션에 Leak Canary를 추가해도 됩니다. 만약 오픈 소스 프로젝트라면 이런 방법으로 매번 풀 리퀘스트를 받을 때마다 instrumentation 테스트를 시작해서 메모리를 탐지할 수 있습니다.

프레임 속도 (8:10)

프레임 속도를 측정하는데는 Takt 라이브러리를 추천합니다. ‘build.gradle’ 파일과 메인 애플리케이션에 각각 한 줄씩만 추가해서 설정할 수 있죠. 그러면 바로 프레임 속도를 볼 수 있습니다.

제 애플리케이션의 경우 60fps지만, 특정 사진을 열면 40까지 떨어집니다. 만약 애플리케이션이 초당 60프레임 이상으로 부드럽게 실행되도록 하려면 UI 스레드의 코드가 60밀리 초 이상 걸리지 않게 하세요.

Hugo (9:03)

메서드의 실행 시간을 얻으려면, 예를 들어 60밀리 초 이하로만 실행되는 것을 확인하려면, Hugo 라는 gradle 플러그인을 추가하세요. ‘@debugLog’ 어노테이션을 클래스나 메서드에 추가하는 것만으로도 로그에서 실행 시간을 확인할 수 있습니다. 예를 들어 예제 앱에서는 초기화 그래프 메서드가 30밀리 초간, ‘onCreate’ 메서드는 73밀리 초간 실행됐습니다. ‘onCreate’ 메서드의 실행 시간을 줄일 필요가 있겠죠?

혹은 ‘system.nanotime’을 사용해서 수동으로 확인할 수도 있습니다. 메서드를 시작할 때와 끝낼 때 ‘system.nanotime’를 사용해서 시차를 확인해보세요.

Pidcat (9:52)

애플리케이션 로그에 색을 입혀서 검색하고 싶다면 Pidcat을 강력히 추천합니다. 패키지 이름이나 옵션 태그를 필터링하는 데 도움을 주는 커맨드 라인 logcat입니다.

데모에서는 pidcat mobilization이라고 써서 애플리케이션의 로그가 색상이 입혀지고 필터링되는 것을 볼 수 있습니다. 설치도 간단한데, Mac에서는 brew install pidcat으로, Linux나 다른 패키지 매니저로는 apt-get install pidcat 등으로 설치할 수 있습니다. 개인적으로는 앱을 개발할 때 항상 Pidcat이 실행되는 터미널을 열어두고 쉽게 로그를 확인하는 것을 좋아합니다.

Android DevMetrics (10:38)

Dagger를 사용한다면 가끔 종속 그래프에 객체를 제공하기 위해 초기화하는데 시간이 조금 걸리는 것을 인지하셨을 겁니다. 그 시간을 파악하는데 Android DevMetrics 를 사용할 수 있습니다. 애플리케이션의 build.gradle 파일에 한 줄만 추가하면 됩니다.

데모에서는 Picasso가 14밀리 초 걸리고 Retrofit 같은 경우 47밀리 초가 걸리는 것을 확인할 수 있습니다.

정적 코드 분석 도구(11:10)

이제부터는 질적 향상을 위한 도구에 대해 말씀드리겠습니다. 먼저 정적 코드 분석 툴입니다. 개발 경력이 오래됐다면 PMD, Checkstyle, FindBugs에 대해 알고 계시겠지만, 요즘 트랜드는 Lint, Error Prone, Infer죠.

Lint 를 사용해서 문제를 찾을 수 있습니다. 예를 들어 어떤 메서드를 호출했는데 이것이 낮은 API 버전에서는 실행되지 않을 수 있습니다. 이 경우 애플리케이션이 멈출 수 있다고 안드로이드를 위한 Lint가 경고해줍니다. 매번 코드를 작성할 때마다 문제가 있는 경우 IDE가 바로 알려줍니다. 정적 코드 분석 도구는 개발 중에 개발자를 도와주는 역할이죠.

Sonar Lint (12:00)

SonarLint 도 추천합니다. Android Lint와 유사한 Android Studio를 위한 플러그인으로 보다 Java에 집중돼 있습니다. 매 코드 줄을 검사해서 잘못된 것이 있으면 경고해줍니다.

Sonar Lint 예제 (12:20)

많은 잘못된 점이 있는 예제 코드입니다. 사용하지 않는 import도 있고 public 필드 안에 private final도 사용했습니다. 수식어 순서도 잘못됐고 쓸모없는 괄호도 있죠. 컴파일은 되겠지만, 가독성이 나쁩니다. Lint와 SonarLint는 이렇게 뭔가 잘못된 경우 친절하게 조언을 줍니다. 하지만 이런 정적 코드 분석 도구를 전적으로 믿었다가 오류를 놓치는 경우도 있으니 주의하세요.

SonarQube (14:05)

더 많은 측정 항목을 원한다면 SonarQube 가 있습니다. IDE 플러그인이 아닌 웹 애플리케이션이므로 Dockerfile을 통하거나 Docuweb에 설치해야 합니다.

SonarQube Dockerfile 예제 (14:09)

Dockerfile을 만들고 실행하면 웹 서버가 생성됩니다. SonarQube 서버를 시작한 후 ‘build.gradle’ 파일에 위 코드와 설정을 추가합니다.

SonarQube를 위한 Docker를 사용하는 것이 좋은데 컴퓨터의 설정에 영향을 주지 않기 때문입니다.

Docker를 사용하면 왜 컴퓨터 설정 측면에서 좋을까요?

만약 두 대의 컴퓨터가 있는데 하나는 업무용이고 하나는 개인용이라고 생각해 보겠습니다. 물론 개인용에 위에 말한 도구들같이 많은 것을 설치하고 싶진 않겠지만, 가끔은 개인용에서 업무 목적, 즉 개발을 위해서 이런 것들을 사용해야 할 때도 있습니다. 이럴 때 직접 설치하는 대신 Docker 컨테이너를 실행해서 이 모든 것들을 개인 컴퓨터에서 사용할 수 있습니다. 다른 사례는 소스에서 Android를 빌드하는 것입니다. 처음에 Android를 컴퓨터에 설치하는 것은 꽤 까다로운 데다 많은 종속성을 설치해야 하므로 개인용에는 다시 설치하고 싶지 않을 수 있습니다. 이럴 때 필요한 모든 종속성을 포함하는 Docker 컨테이너를 사용해서 초기 컴퓨터의 구성에 영향을 미치지 않고도 소스로부터 안드로이드를 빌드할 수 있습니다.

SonarQube 예제 코드 (15:29)

첫 번째 블록은 프로젝트의 이름이고, 두 번째 블록은 SonarQube 서버가 위치하는 곳입니다. 세 번째 블록은 테스트 보고서가 위치할 곳에 대한 정보입니다.

  FROM java:8
  MAINTAINER Nilhcem
  
  RUN DEBIAN_FRONTEND=noninteractive apt update
  RUN DEBIAN_FRONTEND=noninteractive apt install -y wget unzip
  RUN wget -q https://sonarsource.bintray.com/Distribution/sonarqube/sonarqube-6.1.zip
  RUN unzip -qq sonarqube-6.1.zip -d /opt/
  RUN rm sonarqube-6.1.zip
  
  EXPOSE 9000
  CMD ["/opt/sonarqube-6.1/bin/linux-x86-64/sonar.sh", "console"]

SonarQube 결과 보고서 (15:52)

SonarQube로 결과 정보를 얻으려면 분석을 시작하면 됩니다. SonarQube 서버를 실행해서 애플리케이션의 복잡도에 대한 개요를 보여줍니다. 예제의 경우 3개의 버그가 있고, 16일의 기술적인 부채가 있는데 이는 유용성, 가독성 및 유지 보수 측면에서 완벽한 애플리케이션으로 개선하려면 16일 정도가 더 걸릴 것이라는 예측입니다. 더 많은 기능을 추가하는 대신 SonarLint가 알려준 문제를 먼저 해결하는 것이 좋겠죠.

테스팅 도구 (17:16)

대부분의 앱은 서버와 통신하는데, 이런 앱을 테스트하기는 좀 까다롭습니다. 받은 것과 이후의 결과를 비교해야만 하죠.

모의 서버 (18:18)

항상 동일한 데이터를 반환하는 모의 서버 를 만드는 도구를 사용해서 테스트할 수도 있습니다. 다양한 방식으로 만들 수 있는데 특히 NodeJS와 Express를 활용하면 몇 줄의 코드만으로 모의 서버를 만들 수 있습니다. 이는 상용이 아니라 개발 테스트를 위해 사용하는 것입니다.

NodeJS + Express 서버 예제 (18:42)

예제와 같이 15줄의 코드를 작성했습니다. 첫 번째 블록은 서버를 초기화하고, 두 번째 블록은 HTTP get /speaker를 사용해서 JSON 파일을 통해 데이터의 내용을 얻습니다. 10분 만에 작성한 이 코드를 바로 실행할 수 있죠. JavaScript이므로 원하는 대로 바꿔보세요.

느린 네트워크 호출을 시뮬레이션하는 예제 (19:35)

느린 네트워크 호출을 시뮬레이션하려면 아무것도 하지 않는 루프를 오랜 시간 동안 돌리면 됩니다. Netflix는 Chaos Monkey라는 것을 사용하는데, 서버를 매번 다운시키는 애플리케이션입니다. 가끔은 필요에 의해 쿼리를 없애버릴 수 있습니다. 그 후 이를 테스트하고 필요한 에러를 발생시킬 수 있습니다.

예제 앱에서 모의 서버 사용하기 (20:40)

Mobilization 애플리케이션을 만들 때는 아직 스케줄과 같은 데이터가 없었기 때문에 가짜 모의 서버를 만들었습니다. 모의 데이터를 마련하자 쉽게 개발을 시작할 수 있었습니다. 즉, 서버가 마련되는 마지막 순간까지 개발을 미룰 필요가 없었죠. 물론 테스트 서버와 상용 서버는 다를 수 있지만, 서버 위치를 알려주는 gradle 설정을 통해 필요한 대로 수정할 수 있습니다.

Host Editor (21:50)

만약 소스 코드를 수정하고 싶지 않다면 Hosts Editor를 사용해도 됩니다. 기본적으로 /etc/hosts 파일에 대한 엔트리를 생성한 다음, 필요한 IP를 호스트 이름 변수에 연결해줍니다.

HTTP 디버깅 (22:34)

다음으로 추천할 앱은 mitmproxy 라는 HTTP 디버깅 프락시 소프트웨어 로 GNU/Linux를 위해 만들어진 커맨드 라인 도구입니다. Mac에서는 무료인 Fiddler 를 사용하거나 유료인 Charles proxy 를 사용할 수 있습니다. 저는 Linux와 Mac에서 Charles Proxy를 사용하고 있습니다. 네트워크가 필요한 애플리케이션을 만들 때 다음과 같은 상황을 만들 필요가 있는데요.

1. 느린 네트워크 연결
2. 몇몇 쿼리 반복
3. 응답 확인
4. 코드 통합이나 요청/응답 수정을 위해 네트워크 코드에 브레이크포인트 추가

앞서 소개한 도구로 이런 상황을 해결할 수 있습니다.

Charles Proxy (23:07)

서버를 수정하고 브레이크포인트를 만들었습니다. 그 다음 느린 네트워크 호출을 시뮬레이션하기 위해 tortoise를 클릭하고 쿼리를 실행했습니다. 응답을 “Hello World by Keynote Larry Page”로 수정하면 앱이 로드된 다음 해당 문구를 보여줄 겁니다. 이런 작업이 왜 필요할까요? 가끔은 서버 팀이 이전에 만든 필드를 JSON 응답에서 제거하거나 null로 설정하면 여러분이 개발 중인 애플리케이션에 문제가 생기진 않는지 물어볼 수도 있습니다. 이런 경우 HTTP 디버깅 프락시 소프트웨어를 사용해서 앱이 중단되는지 확인하면 됩니다.

Android 상태 복원 (앱 상태 복원 테스트) (24:53)

Android 시스템은 앱이 보이지 않는 상태라면 언제든지 중단시킬 수 있으므로 이런 경우를 제대로 테스트할 필요가 있습니다.

액티비티 유지 안함(Do not Keep Activities) (25:06)

이런 경우를 테스트하는 방법으로 개발자 옵션의 액티비티 유지 안함 옵션을 사용해서 홈 화면으로 갈 때마다 액티비티를 유지하지 않도록 할 수 있습니다. 하지만 액티비티를 유지하지는 않지만 애플리케이션 객체의 참조를 유지하기 때문에 이것만으로는 충분하지 않습니다.

스플래시 화면이 있는 경우 네트워크로부터 데이터를로딩해서 애플리케이션 객체나 의존성 주입 등의 단일 통로에 저장합니다. 이 경우 단일 통로가 삭제되지 않기 때문에 액티비티 유지 안함 옵션을 켜더라도 애플리케이션이 계속 살아 있습니다.

Fill Ram (26:07)

이런 경우를 제대로 테스트하기 위해 Fill RAM을 사용합니다. 휴대폰에 메모리가 없을 때까지 많은 프로세스를 생성하거나 fork하는 도구입니다. 이렇게 되면 Android 시스템이 모든 액티비티 참조를 삭제하게 됩니다. QA에도 유용하게 사용할 수 있죠.

Android Device Monitor + Stop Process (26:58)

가장 빠른 방법은 Android Device Monitor 를 사용하는 겁니다. 액티비티를 시작하고 홈 화면으로 간 다음 프로세스를 중단시키고 Android가 모든 것을 다시 생성하기를 기다립니다. Android Device Monitor에서 애플리케이션을 중단한 다음 앱 아이콘을 눌러서 앱을 재시작하면 먼저 하얀 화면이 보이게 됩니다. Android가 액티비티를 재생성하기 때문인데요. 이런 행동을 Android Device Monitor로 테스트할 수 있습니다.

분석 도구 (27:49)

개발자 옵션 (27:54)

개발자 옵션 에는 여러 유용한 도구가 있습니다.

레이아웃 범위 표시(Show Layout Bounds) (27:58)

레이아웃 범위 표시(Show Layout Bounds) 는 레이아웃의 마진과 범위를 보여줍니다.

GPU 오버드로 디버깅(Debug GPU Overdraw) (28:07)

GPU 오버드로 디버깅(Debug GPU Overdraw) 은 앱의 어떤 부분이 다시 그려지는지 확인하는 데 도움을 줍니다. 앱이 단일 프레임에서 같은 픽셀을 한 번 이상 그리는 것을 오버드로라고 하는데, 이 옵션을 개발자 옵션에서 켜면 여러 다른 색깔이 화면에 표시됩니다. 예를 들어 빨간 색은 4번 이상 오버드로된 것을 알려줍니다.

또한 개발자 옵션은 중첩 레이아웃이 너무 많지는 않은지 확인하는 등 레이아웃을 최적화하는 데 활용할 수도 있습니다.

UIAutomatorViewer (28:48)

레이아웃을 분석하기 위해 Android SDK에 포함된 ‘UIAutomatorViewer’ 를 사용할 수도 있습니다.

1. 휴대폰을 USB로 연결
2. UIAutomatorViewer 버튼 클릭 (애플리케이션 스냅샷 생성)
3. 앱의뷰 계층구조 확인 후 필요에 맞게 수정 (예: 강연자 이름을 두껍게 수정하기)

뷰의 영역을 클릭해서 직접 뷰의 ID를 확인할 수 있고, 코드에서 확인해서 뷰가 만들어진 위치와 시점을 확인할 수 있습니다. 자신의 앱이 아니라도 검사할 수 있습니다. 예를 들어 Twitter의 뷰 계층구조가 얼마나 잘 되어 있는지, 접근성을 확보했는지도 확인할 수 있죠. ‘UIAutomatorViewer’는 다양한 앱의 여러 레이아웃을 검사하는 데 유용한 도구입니다.

애니메이션 테스트 (29:45)

애니메이션에 결함이 있지만, 뭐가 잘못됐는지 파악하기 힘든 경우도 많습니다. 이런 경우를 디버그하려면 개발자 옵션에서 애니메이션 길이 배율(animation scale) 를 늘려서 애니메이션의 속도를 늦출 수 있습니다.

다른 방식의 애니메이션 테스트 (30:03)

다른 방법은 애니메이션의 스크린샷을 만드는 것입니다. adb shell screencast를 하고 VLC를 사용해서 열 수 있습니다. E를 눌러서 프레임 단위로 확인하면 되죠.

컴파일 도구 (30:38)

다음으로는 컴파일 도구 를 소개하겠습니다.

고객에게 Google Play Store으로나 APK로 애플리케이션을 제공하면 ProGuard를 적용하더라도 소스 코드에 접근할 수 있습니다. 제가 컨설턴트로 일할 때 한 고객이 FTP 위치와 URL, 비밀번호를 소스 코드에 넣은 적이 있습니다. 이런 경우 FTP에 누구나 접근할 수 있고 코드를 수정할 수 있으므로 정말 위험합니다. 그러므로 배포하기 이전에 소스 코드에 무엇이 들어가는지 주의해야 합니다.

다른 사람들이 애플리케이션에서 어떤 것을 볼 수 있는지 직접 확인하려면 APKTOOL, DEX2JAR, Java decompiler 를 사용하세요. APKTOOL은 APK를 DEX 파일로 디컴파일해서 JAR로 바꿀 수 있도록 합니다. 그다음 Java decompiler를 사용해서 애플리케이션의 소스 코드를 볼 수 있죠.

JADX (31:50)

더 쉽게 확인하려면 JADX를 사용하세요. 애플리케이션 내의 모든 것을 시각화해주는 GUI가 있는 도구입니다. 단 일 분만에 여러분의 소스코드를 읽을 수 있으니 미리 확인해두는 것이 좋겠죠?

혹은 외부 도구를 사용할 필요 없이 Android Studio 내에서 분석 APK를 빌드해서 APK의 컨텐츠를 시각화할 수도 있습니다.

추가 도구

Stetho (32:25)

Facebook이 제공하는 Stetho 는 애플리케이션과 상호작용하는 동안 검사할 수 있도록 합니다. Chrome 브라우저에서 실시간 결과를 볼 수 있습니다.

Stetho + UI (32:36)

예를 들어 앱의 계층구조를 보고 싶다면 휴대폰을 USB로 컴퓨터에 연결한 후 Google Chrome을 켠 다음 뷰의 계층구조를 바로 볼 수 있습니다.

Stetho + Network (33:20)

또 Stetho를 사용하면 네트워크 코드로 분석할 수 있습니다.

리소스 탭에는 더 많은 기능이 있습니다. 실시간으로 애플리케이션에 전달되는 데이터를 수정할 수 있습니다. Realm이나 SQLite 데이터베이스 등 어느 데이터베이스라도 수정할 수 있습니다.

Stetho DumpApp (35:22)

Stetho에는 DumpApp 이라는 더 강력한 기능도 있습니다. 안드로이드 개발자로서 애플리케이션 디버깅에 웹 브라우저를 사용하는 것이 내키지 않을 수 있습니다. DumpApp는 터미널을 사용하기 때문에 웹 브라이저가 아닌 터미널이나 셸을 통해 애플리케이션과 상호작용할 수 있습니다.

Stetho + 커스텀 플러그인 (40:10)

쉽게 직접 DumpApp 플러그인을 만들 수도 있습니다.

Stetho의 마지막 장점은 애플리케이션을 열어서 실시간으로 로그를 볼 수 있다는 겁니다. Rhino 라는 플러그인을 추가할 수도 있는데 이는 Mozilla가 제공하는 Java 상의 JavaScript 구현입니다.

결론 (42:16)

필요와 취향에 따라 도구를 선택하세요. 도구를 탐색하고 자신만의 도구 상자를 만들어 보세요. 필요한 도구를 찾지 못했다면 직접 만들어서 커뮤니티에 공유하세요.

트위터 @Nilhcem에서 저와 소통할 수 있고, 프로젝트는 GitHub에서 다운받을 수 있습니다. 앞서 말한 모든 도구를 포함하니 자유롭게 탐색해보세요!

다음: Realm Java를 사용하면 안드로이드 앱 모델 레이어를 효과적으로 작성할 수 있습니다.