Android DDMS: 최고의 Android 콘솔 가이드

개발은 까다로운 비즈니스입니다. 목표물은 계속 움직이고, 새로운 기술과 영역이 주기적으로 생기며, 새로운 도구가 이따금 등장하고, 언어가 변경되면서 관리되는 혼란이 발생합니다.

그러나 이러한 모든 변경에도 불구하고 기본 규칙은 동일하게 유지됩니다. 이러한 기본 규칙 중 가장 중요한 것 중 하나는 정말 멋진 소프트웨어를 만들려면 실행 시스템에 대해 깊이 있고 지속적이며 상세한 자기 성찰 을 해야 한다는 것입니다. 진단 , 디버깅 및 프로파일링 은 이 컨텍스트에서 때때로 사용되는 용어이지만 규칙은 더 심오합니다. 최고 수준의 개발자는 말 그대로 자신의 시스템을 "느끼는" 것입니다. 그는 더 많은 메모리가 해제되기를 기다리는 청크, CPU 기아 상태로 스레드를 실행하는 작업, 광범위한 I/O 또는 네트워크 액세스가 발생하여 전체 작업이 느려지는 원인이 무엇인지 알고 있습니다.

정말 방법이 없습니다. 당신은 멋진 코드를 작성하는 매우 똑똑한 개발자가 될 수 있지만, 위의 기술, 즉 시스템의 런타임 동작에 대한 세부 사항을 모니터링하고 연구할 수 있는 기술이 없을 때까지는 정말 최고 수준의 제공에 관해서는 여전히 뒤처지게 될 것입니다. 응용 프로그램.

실제로, 약간의 경험을 얻은 후에는 내성 규칙을 무시하는 것으로 추적할 수 있는 "코드 질병"의 전체 범주를 감지할 수 있습니다. 간단히 말해서 실제 플랫폼에 미치는 영향을 지속적으로 모니터링하지 않고 코드 작성(때로는 스마트 코드) .

Android의 DDMS: 내성을 위한 내가 선택한 무기

다행스럽게도 Android 커뮤니티는 최고 수준의 내성 도구를 많이 제공했습니다. Facebook의 Stetho는 최고 중 하나이며, AT&T의 ARO("Application Resource Optimizer")는 다소 오래되었지만 여전히 최고이며 아마도 최고의 네트워크 모니터링 콘솔을 갖추고 있을 것입니다. it) 런타임 메모리 누수 감지 라이브러리에 있습니다. 간단히 말해서 Android 디버깅 도구는 부족하지 않습니다.

그럼에도 불구하고 앱의 런타임 동작과 관련하여 중요하고 정확하며 올바른 형식의 데이터를 추출해야 할 때 신뢰할 수 있는 내부 검사 도구인 왕관의 다이아몬드는 여전히 Android Studio의 좋은 오래된 DDMS(Dalvik Debug Monitor Server)입니다. Eclipse Android 플러그인 시절부터 우리와 함께했습니다(너무 많은 팀에서 잘 사용하지 않음).

Android 개발에서 DDMS는 얼마나 중요합니까? 글쎄요, 5-6년 전에는 경험이 덜한 Android 개발자로서 일반적으로 DDMS 및 모바일 앱 모니터링에 대해 지금 내가 알고 있는 것을 알고 있었다면 많은 두통과 디버깅의 밤을 절약했을 것입니다.

그리고 문제는 DDMS가 마스터하기가 매우 간단하다는 것입니다!

물론 다른 소프트웨어 도구와 마찬가지로 올바르게 사용하는 데는 경험이 필요합니다. 런타임 성능 모니터링에 능숙해질 때까지 한동안 전문 기술을 연마해야 합니다. 그러나 몇 시간 만에 이 기사를 읽은 후 내 제안을 따르고 다음 앱에 적용하면 결과가 놀랍습니다! 복잡한 시스템도 프로파일링하고 조정하는 것은 그리 어렵지 않습니다. 재미도 있을 수 있습니다!

초보 모바일 개발자와 마스터 수준 모바일 개발자의 차이점에 대한 질문을 자주 받습니다. Android에서 DDMS를 마스터하는 것(일반적으로 애플리케이션 프로파일링 및 내성 기능)은 이러한 주요 차이점 중 하나입니다.

참고: 최고 수준의 개발자가 되는 주요 부분은 도메인에서 사용할 수 있는 최고의 라이브러리를 사용하는 것입니다. 이전 Toptal 기사에서 Android에서 사용할 수 있는 최고의 개발자 라이브러리를 나열했습니다. 어떤 의미에서 이 기사는 "라이브러리" 기사의 속편이며 많은 Android 도구 중 하나를 다룹니다. 말할 필요도 없이 Android 개발자 기술 향상을 목표로 하는 경우 지금 읽으십시오!

Android Studio의 DDMS에 대한 빠른 가이드

이제 더 이상 고민하지 않고 최고의 Android 개발자 도구 중 하나인 DDMS에 대한 설명을 살펴보겠습니다.

노력과 이점을 비교할 때 앱의 품질을 개선하고 앱에 포함될 수 있는 정말 지저분하고 파악하기 어려운 버그를 찾는 데 도움이 되는 다른 도구는 없을 것입니다. 그러나 여전히 어떤 이유로(게으름, 누군가?), 많은 팀이 DDMS를 사용하지 않습니다.

DDMS의 단기 집중 과정부터 시작하겠습니다.

DDMS는 Studio > 도구 > Android > Android Device Monitor 메뉴에서 DDMS 버튼을 클릭하여 액세스할 수 있습니다. 당신은 또한 당신의 상단 패널에 바로 가기 아이콘 (나는)으로 배치 할 수 있습니다.

열면 다음과 같습니다.

왼쪽 패널은 장치/앱 선택을 허용하고 오른쪽 콘솔은 각각 고유한 탭에서 앱의 특정 보기를 표시하는 여러 보기를 제공합니다.

Dalvik 디버그 모니터 서버에서 제공하는 주요 서비스는 다음과 같습니다.

• 앱 메모리 사용량 통계(총 힙 및 개체 할당 통계)
• 앱 스레드 통계
• 기기 화면 캡처
• 장치 파일 탐색기
• 수신 전화 및 SMS 스푸핑
• 위치 데이터 스푸핑
• 로그캣

앱에서 사용하는 현재 힙 메모리 값을 얻으려면 다음과 같이 하십시오.

• 앱이 실행되는 기기 연결
• 힙 통계 수집을 활성화하려면 힙 업데이트 버튼을 클릭하세요.
• 힙 탭 열기
• GC 실행을 강제 실행하려면 "GC 원인"을 클릭합니다. 이러한 실행 후에만 힙 데이터 수집이 시작됩니다.
• 탭을 열어 두고 앱 작업을 계속하고 주기적으로 "GC 원인"을 다시 클릭하여 힙 통계 데이터를 새로 고칩니다.

이 마지막 줄에는 추가 설명이 필요할 수 있습니다. 메모리 사용량은 초기 값보다 역학 이 훨씬 더 중요한 분석 값 중 하나입니다. 대부분의 앱에서 초기 힙 사용량 값에 대해서는 크게 신경 쓰지 않습니다. 모바일 개발자를 기다리고 있는 진정한 악몽 중 하나인 Android 메모리 누수에 대한 명확한 표시를 제공하므로 이 값의 진행 상황에 대해 많은 관심을 기울일 것입니다.

heap stat 모듈의 사용법은 간단합니다. 앱 개발 수명 주기의 일부로 힙 사용에 영향을 미치는 변경 사항을 도입한 후 "Cause GC" 모듈을 활성화하여 통계 수집을 초기화하고 앱의 힙 집약적 위치를 활성화(보통 두 번 이상)할 것입니다. 주기적으로 "GC 유발"을 새로 고칩니다. 힙 사용량이 계속 늘어나면 손에 메모리 누수가 발생하고 해결해야 합니다(자세한 방법은 아래 참조). 그렇지 않으면 실제 힙 크기에 관계없이 좋습니다.

메모리 누수가 감지되면 다음으로 사용할 도구는 Object Allocation Tracker입니다. Android에서 메모리 관리를 위해 무엇을 할 수 있는지 봅시다.

개체 할당 추적기

간단히 말해서 할당 추적기는 현재 힙 크기에 대해 "책임을 지는" 당사자를 파악하는 데 필요한 정보를 제공합니다. 이 모듈은 할당 명령이 어떤 스레드와 메서드에서 왔는지 실시간으로 알려주므로 Android의 메모리 분석에 매우 유용합니다.

추적을 시작하려면 다음과 같이 하십시오.

• 이전과 같이 해당 장치/프로세스를 선택합니다.
• 할당 추적기 탭으로 전환하고 추적 시작을 클릭하여 시작합니다.
• 여기에서 모든 새 할당이 추적됩니다.
• 모든 최신 할당의 목록 보기를 얻으려면 "할당 가져오기"를 클릭하십시오(마지막 "시작" 이후 최신).
• 할당 권한이 누구인지 확인하려면 목록에서 특정 라인을 클릭하십시오.

이제 내 경험에 따르면 앱에서 할당 집약적인 작업을 수행한 다음 할당 카운터를 보기 위해 "할당 가져오기"를 클릭하면 일반적으로 간단한 방식으로 누출로 안내해야 합니다. 때때로 누출이 비선형인 경우(즉, 때때로 발생) 또는 앱에 작동하지 않을 수 있는 여러 누출이 포함된 경우. 이러한 경우에는 이러한 경우가 많이 발생하지 않았으므로 수동으로 덤프 HPROF 파일을 만들고 분석해야 합니다. 메모리 분석 및 Android 메모리 관리는 이 문서에서 자세히 다루지 않습니다. 몇 가지 리드를 보려면 여기를 참조하십시오.

스레드 정보 콘솔: Android CPU 사용이 쉬워졌습니다.

모든 개발자에게 잘 알려진 논리 실행의 동기 경로는 스레드로 그룹화되며 각각은 앱 내에서 하나의 직렬 실행 흐름을 구성합니다. 말 그대로 모든 앱은 단일 실행 스레드 이상을 사용합니다. 그들 중 일부는 수십 가지를 사용합니다.

스레드를 사용할 때 잠재적인 문제에 대한 전반적인 조사는 이 기사의 범위를 벗어납니다. 그런 다음 스레드 정보 콘솔을 방문하는 주요 문제인 스레드 기아라는 단일 문제에 집중하겠습니다.

모든 모바일 애플리케이션에서 서로 다른 스레드가 CPU 시간을 놓고 경쟁합니다. 단순히 둘러보기에 충분하지 않습니다. 어떤 이유로든 이러한 스레드가 필요한 실행 시간을 얻지 못하면 어떻게 됩니까? 보통 나쁜 것들. 시스템은 계획한 대로 작동하지 않을 것이며, 이는 항상 나쁜 생각입니다. 이 문제의 잠재적인 이유는 낮은 우선 순위를 설정하거나 다른 스레드가 동시에 지나치게 높은 우선 순위로 설정을 실행하거나 동기화 모니터에서 오랜 시간을 보내는 등일 수 있습니다. 코드 리뷰만으로는 모두 감지하기 어렵 기로 악명 이 높습니다.

Android DDMS 스레드 콘솔을 구출합니다!

스레드 보기에 들어가면 스레드 이름과 ID가 포함된 스레드 레코드와 utime 및 stime이라는 두 개의 추가 카운터로 구성된 목록이 표시됩니다. Utime은 스레드가 사용자 코드를 실행하는 데 소비한 총 시간(함수 및 타사 라이브러리 생각)을 측정하는 반면 stime은 시스템 코드(잠자기, 동기화, 시스템 호출 등)에 소비한 총 시간을 측정합니다. pfirst 것인 utime은 일반적으로 우리에게 더 흥미로울 것이지만, 대부분 stime 카운터에 의해 나타날 문제를 생각할 수 있습니다.

좋습니다. 여러 스레드를 포함하여 코드가 실행 중이며 모든 스레드가 CPU 시간을 공유하도록 하고 싶습니다. 이를 위해 먼저 시스템을 잠시 실행한 다음 스레드 탭을 열고 "특이한" utime 값을 찾기 시작합니다. 0은 확실히 문제를 나타낼 수 있습니다. 스레드는 말 그대로 CPU 시간과 CPU 사용률이 없습니다. 그러나 지나치게 높은 값은 동일한 문제의 다른 측면을 나타낼 수 있습니다. 즉, 우선 순위가 너무 높아 다른 사람을 굶게 만드는 스레드입니다.

한 가지 유형의 스레드에서 0 또는 0에 가까운 utime 값은 실제 문제를 나타내지 않습니다. 이들은 I/O 바운드 스레드, 주로 네트워킹 또는 디스크(또는 데이터베이스) 액세스를 수행하는 스레드입니다. 이러한 스레드 는 데이터가 도착하기를 기다리거나 보류 중인 시스템 호출을 차단하는 데 대부분의 시간을 소비해야 합니다. 이러한 작업 중 어느 것도 utime 카운터를 증가시키지 않습니다. 당신의 스레드를 알고!

팁: 스레드의 기본 이름을 사용하지 마십시오. 아무 의미가 없으며 일반적으로 DDMS 보기에서 이를 감지하지 못합니다. 대신 스레드를 생성하거나 스레드 풀에서 가져올 때마다 설명이 필요 없는 이름을 할당하여 상호 작용을 시작하십시오. 이렇게 하면 시스템을 디버깅/프로파일링하는 것보다 훨씬 쉽게 생활할 수 있습니다. Android에서 생성한 스레드와 내 코드에 의해 생성된 스레드를 구별하기 위해 일반적으로 앱 이름 앞에 추가합니다(예: MyApp-server-connector, MyApp-db-interactor 등).

팁: 스레드의 우선 순위는 스케줄러가 부여할 CPU 시간의 양을 나타냅니다. 작업자 스레드에 할당된 우선 순위는 앱의 전체 성능과 "부드러움"에 매우 중요하며 많은 경우 매끄럽게 빠른 동작과 울퉁불퉁한 느린 동작의 차이가 될 수 있습니다. 규칙은 간단합니다. Android에서 할당한 기본 우선 순위(NORMAL=5)는 거의 항상 사용하려는 우선 순위가 아닙니다. 대신, 대부분의 작업자 스레드의 경우 전체 CPU 사용량에 미치는 영향을 줄이는 방법을 원합니다. 이렇게 하려면 스레드가 시작될 때 우선 순위를 더 낮은 값으로 설정합니다. 일반적으로 우선 순위=3을 사용합니다.

네트워크 통계 콘솔

네트워크 통계는 합리적으로 사람이 읽을 수 있는 방식으로 앱에 대한 수신 및 발신 통신 채널을 모두 모니터링할 수 있도록 하는 것입니다.

네트워크 차트의 y축은 KB/초로 측정된 전송 속도를 나타내고 x축은 경과 시간(초)을 나타냅니다. 따라서 전송 크기를 빠르게 추정하려면 관련 스파이크 영역을 추정해 보십시오. 잠시 후 이것은 오히려 쉬워집니다.

이 콘솔에 들어간 후 네트워크 측정이 나타나기 시작하려면 상단의 "활성화" 버튼을 클릭해야 합니다.

네트워크 콘솔이 현재 수준으로 성숙하기 전에 개발자는 일반적으로 유사한 정보를 얻기 위해 스니퍼 앱(일부는 여전히 사용)을 사용해야 했습니다.

이 콘솔의 가장 큰 장점은 주요 배터리 소모 동작 중 하나인 지속적인 작은 패킷 크기 통신을 시각화하는 방식입니다. 많은 분들이 아시다시피 앱을 배터리 소모로 만드는 것은 5분 동안의 집중적인 네트워킹이 아니라, 예를 들어 연결 유지, 진단 또는 상태 업데이트를 위한 짧고 반복적인 네트워킹입니다.

이러한 패턴이 감지되고 네트워크 콘솔의 시각적 패킷 표시로 매우 쉽게 처리되므로 즉시 일괄 처리를 생각하십시오. 여러 개의 작은 전송을 하나의 큰 전송으로 일괄 처리할 수 있습니까? 이 변경 사항의 배터리 영향은 앱을 배터리 소모에서 잘 작동하는 범주로 이동시킬 것입니다!

팁: 이미지를 있는 그대로 메모리에 로드하지 마십시오. 이것은 메모리 부족 충돌이 일어나기를 기다리고 있습니다. 대신, 축소 로드를 수행하거나 더 나은 방법으로 타사 라이브러리를 사용하여 확장을 관리하십시오.

이 정보를 거의 사용하지 않을 것이지만 DDMS는 Android 디버그 브리지(ADB) 스택에 의존하여 기기에서 데이터를 되돌려 주고 받습니다. DDMS가 앱을 표시하지 못하거나 DDMS 세션 도중 멈춘 경우 가장 좋은 방법은 콘솔을 열고 다음을 입력하는 것입니다.

 adb devices

귀하의 장치가 ADB로 액세스 가능하고 승인되었는지 확인하십시오. 그렇지 않은 경우 많은 경우 로컬 ADB 서버를 다시 시작하면 문제가 해결됩니다.

 adb kill-server adb devices # restarts the adb server and displays all detected devices

여전히 문제가 있고 앱이 물리적 장치에 설치된 경우 모든 에뮬레이터 인스턴스의 연결을 끊으십시오. 왜요? DDMS는 물리적 장치 장치와 에뮬레이터 인스턴스 모두에 연결되기 때문에 기본값은 후자입니다.

실제 DDMS 사용의 예: 앱이 중지됩니다(충돌이 아니라 그냥 중지됨). 사용자는 즉시 가까운 워크스테이션으로 달려가 USB에 연결하고 스레드 보기에서 DDMS를 열어 스레드 스택 » 실패한 스레드 » 스택 추적을 찾습니다. 제 경우에는 동기화 교착 상태가 발생하여 일단 감지되면 전환으로 쉽게 해결되었습니다.

팁: 미디어 집약적인 앱과 같이 Android에서 앱에 할당한 표준 RAM 메모리가 충분하지 않은 경우 _ largeHeap 매니페스트 플래그를 올려 대부분의 기기에서 약 15-20%의 추가 메모리를 얻을 수 있습니다. : https://developer.android.com/guide/topics/manifest/application-element.html_

Android DDMS의 기기 상태 에뮬레이션

일반적으로 모바일 앱은 선형 구조가 아닙니다. 대신 장치 상태의 변경 사항을 모니터링하고 대응할 수 있는 인식 전략을 배포합니다. 예를 들어 앱은 수신 전화나 문자 메시지를 듣고 네트워크 상태에 따라 상태를 재정렬하고 장치 위치의 변경 사항을 추적하고 이에 대응할 수 있습니다.

후자의 간단한 예는 GPS 앱입니다. 우리 대부분은 그러한 앱을 개발하지 않지만(아아, 시장이 충분히 크지 않습니다...) 그러나 여전히 많은 경우에 사용자의 현재 위치에 대한 간단한 지도 보기인지, 경로 추적인지 여부에 관계없이 위치 종속적인 논리를 배포합니다. , 또는 위치에 민감한 데이터 표시.

이러한 상태에 민감한 조건에 대한 테스트는 악명 높으며 때로는 실제 코드를 작성하는 것보다 더 복잡합니다. SIM이 있는 물리적 장치가 있다면 물론 전화와 SMS를 주고받을 수 있습니다. 장치의 전화 상태를 변경하는 것은 훨씬 어렵지만 여전히 할 수 있습니다. 테스트 위치 변경은 더 까다로울 수 있지만 랩톱으로 시내를 산책하는 것은 옵션입니다…

하지만 여전히 에뮬레이터 인스턴스를 어떻게 처리할까요? 이러한 변경 사항에 대해 어떻게 테스트할 수 있습니까?

DDMS가 다시 한 번 구출합니다. DDMS의 강력하지만 종종 간과되는 기능 중 하나는 실행 중인 에뮬레이터 인스턴스에 모의 이벤트를 발행("스푸핑")하는 기능입니다. DDMS는 특정 번호에서 에뮬레이터로 전화를 걸고, SMS를 보내고, 전화 상태 데이터를 변경하는 등의 작업을 수행할 수 있습니다.

에뮬레이터에 도착하면 이러한 모든 스푸핑된 이벤트는 더 이상 "실제" 이벤트와 구별할 수 없습니다. 즉, 기본 하드웨어 센서에서 수신한 것처럼 보입니다. 특히 관련 앱의 모든 수신자는 실제 전화/SMS 메시지를 수신했을 때와 동일한 방식으로 활성화됩니다.

전화 통신 상태 및 작업을 활성화하는 것은 다소 간단합니다.

네트워크 연결이 낮은 경우(모든 네트워크 중심 앱에서 수행해야 함)에 대해 앱을 테스트하려면 전화 통신 상태 섹션으로 이동하여 속도 및 대기 시간 값을 원하는 값으로 설정합니다. 나는 일반적으로 낮은 연결성을 에뮬레이트하는 효과적인 방법으로 두 가지 모두에 대한 GPRS 값을 사용하지만 자유롭게 자신의 값을 설정할 수 있습니다.

전화 통화 또는 SMS를 시뮬레이션하려면 Telephony Action 섹션으로 이동하여 발신 전화 번호를 설정하고 필요한 경우 문자 메시지를 추가하고 실행합니다. 이 도구는 해외 전화 전용 코드 경로를 설정하고 예산에 맞게 테스트하려는 경우에 특히 효과적입니다.

새로운 위치를 조롱할 때 상황이 더욱 흥미로워집니다.

에뮬레이터 인스턴스의 새 위치를 설정하는 것이 목표라면 수동을 선택하고 원하는 위도/경도 값을 설정한 다음 보내기를 누르십시오.

그러나 하나의 고정된 위치를 설정하는 대신 앱이 미리 설정된 경로를 거치도록 하려면, 예를 들어 사용자가 한 도시에서 다른 도시로 이동할 때 앱의 동작을 검사하려면 어떻게 해야 할까요? 이러한 테스트는 지도 지원 앱뿐만 아니라 사용자 위치별로 데이터 창을 설정하는 기타 위치에 민감한 앱에 큰 가치가 있습니다. 여기에서 다른 속도로 이동하는 위치가 표시된 데이터 창을 최신 상태로 유지하는 것을 보고 싶을 것입니다.

이를 위해 Google 어스와 함께 사용하도록 특별히 개발된 KML이라는 특수 형식을 사용합니다. 이 형식은 GPS 지원 장치에서 사용할 수 있는 공간의 연결된 지점 집합으로 경로 또는 경로를 나타냅니다.

GPX는 DDMS에서 지원하는 대체 경로 형식입니다. 모든 실제적인 목적을 위해 이 두 가지는 모바일 위치 스푸핑에 사용될 때 상호 교환 가능한 것으로 간주되어야 합니다.

이제 모의 경로를 에뮬레이터로 설정하는 단계를 살펴보겠습니다.

1. 경로를 생성합니다. 지금까지 가장 간단한 방법은 적절한 출발지와 목적지를 설정하는 Google 지도 방향 옵션을 사용하는 것입니다.

1. 경로가 지도에 표시되면 주소 표시줄로 이동하여 URL을 복사합니다.

2. 클립보드에 있는 URL을 사용하여 GPS Visualizer로 이동하여 "URL 제공" 텍스트 상자에 붙여넣고 변환 버튼을 클릭합니다.

클릭하여 결과 GPX 파일을 다운로드합니다(약간 지저분한 이름, 예: 20170520030103-22192-data.gpx)

1. DDMS 위치 제어로 돌아가서 GPX 탭을 열고 GPX 로드를 클릭하고 새로 다운로드한 파일을 선택합니다.

1. 우리는 끝났어! 이제 뒤로 및 앞으로 버튼을 클릭하거나 재생 버튼을 클릭하여 설정된 속도로 경로를 통해 자동으로 다른 경로 위치 사이를 탐색할 수 있습니다.

고유한 경로를 만들 필요가 없습니다. OpenStreetMap과 같은 사이트에서 다운로드할 수 있는 많은 경로('GPS 추적' 섹션 참조).

마지막으로 라우트 파일 로드가 간편했던 이전 DDMS 버전과 달리 최신 버전은 특정 라우트를 로드할 때 시행착오가 필요할 수 있습니다.

예를 들어 GPX 1.1만 DDMS에서 지원되는 것으로 나타납니다. 새 GPX 버전은 수동 조정이 필요할 수 있습니다.

또한 GPX 웨이포인트 형식은 더 이상 지원되지 않습니다. 대신 GPX 트랙 형식을 사용하십시오.

 <trk> <name /> <cmt /> <trkseg> <trkpt lat="27.0512" lon="-80.4324"> <ele>0</ele> <time>2017-02-02T08:01:41Z</time> </trkpt> </trkseg> </trk>

Android 디버깅: 일주일에 한 시간이 차이를 만듭니다!

충분한 이론! 이제 연습을 할 시간입니다. Android 개발자라고 가정하고 다음 프로젝트부터 DDMS를 통해 앱 성능에 대한 내성을 얻기 위해 일주일에 한 시간만 투자할 것을 제안합니다.

이것이 제공하는 양질의 정보 (즉, 앱 상태를 즉시 개선하는 데 사용할 수 있는 정보)의 양에 놀라게 될 것입니다!

Android DDMS는 내가 초보 개발자들과 함께 몇 번이고 목격했듯이, 숙달되고 적절하게 사용된다면 개발자의 능력을 크게 향상시킬 수 있는 도구입니다. 최고 수준의 시스템을 제공하는 Android 개발자의 능력은 일단 Android 개발에서 DDMS의 잠재력을 최대한 활용하면 말 그대로 한두 단계 올라갈 것입니다. 따라서 DDMS를 잘 활용하기 위해 몇 시간을 할애하는 것은 Android 성능과 효율성을 크게 향상시킬 수 있으므로 현명한 투자처럼 들립니다.

똑똑한 사람이 되십시오. 그걸 써.