안드로이드 ANR 전체 분석 및 화웨이 AGC 성능 관리로 ANR 케이스 세트 해결

1. ANR 소개

1.1 ANR이란?

ANR, 전체 이름은 Application Not Responding입니다. 즉, 애플리케이션이 응답하지 않습니다. Android 애플리케이션의 인터페이스 스레드가 너무 오랫동안 차단되면 "응답하지 않는 애플리케이션"(ANR) 오류가 트리거됩니다.

이 시점에서 시스템은 사용자에게 대화 상자를 표시하고 ANR 대화 상자는 사용자에게 응용 프로그램을 강제로 종료 할 수있는 옵션을 제공합니다.

1.2 4 가지 유형의 ANR

  Android 시스템에서 애플리케이션의 응답은 Activity Manager와 Window Manager의 두 시스템 서비스에 의해 모니터링됩니다. 정상적인 상황에서 시스템은 애플리케이션에서 다음 네 가지 상황이 발생할 때 ANR을보고합니다.

• KeyDispatchTimeout (가장 일반적인 유형)-입력 이벤트는 5 초 내에 처리되지 않으므로 주로 키 및 터치 이벤트와 같은 ANR이 발생합니다.

로그 키워드 : InputDispatching 제한 시간

• BroadcastTimeout : -BroadcastReceiver가 특정 시간 내에 처리를 완료하지 않아 ANR이 발생합니다 (제한 : 전경 브로드 캐스트 10 초, 백그라운드 브로드 캐스트 60 초).

로그 키워드 : 브로드 캐스트 BroadcastRecord 시간 초과

• ServiceTimeout —— 서비스가 일정 시간 내에 처리되지 않아 ANR이 발생합니다. (제한 : 포 그라운드 서비스의 경우 20 초, 백그라운드 서비스의 경우 200 초)

로그 키워드 : 서비스 실행 시간 초과

• ContentProviderTimeout —— 컨텐츠 제공자, ANR이 10 초 이내에 완료되지 않습니다.

로그 키워드 : 콘텐츠 공급자 게시 시간 초과

1.3 ANR의 원인

많은 수의 ANR 사례를 분석 한 후 ANR 문제의 다음 세 가지 일반적인 시나리오가 요약됩니다.

• 메인 스레드가 다른 스레드에 의해 잠겨 있음 (57 %) : sleep (), wait () 및 기타 스레드 메서드가 호출되어 메인 스레드가 시간 초과를 기다립니다.

• 점유 된 시스템 자원 (14 %) : 다른 프로세스의 시스템 자원 (CPU / RAM / IO)의 높은 점유율로 인해 프로세스가 충분한 시스템 자원을 선점 할 수 없습니다.

• 주 스레드의 시간 소모적 인 작업으로 인해 스레드가 정지됩니다 (예 : 많은 데이터베이스 읽기 및 쓰기, 시간 소모적 인 네트워크 조건 및 고강도 하드웨어 계산).

2. ANR 문제 해결 방법론

2.1 일반적인 아이디어

1. ANR 로그 정보를 내보내고 로그 정보를 기반으로 패키지 이름, 클래스 이름, 프로세스 번호, 발생 시간 및 ANR 원인 유형을 결정합니다.

2. ANR 발생 전후의 CPU, 메모리, IO 및 기타 시스템 리소스 사용량을 포함한 시스템 리소스 정보에주의하십시오.

3. 메인 스레드의 상태를 확인하고 메인 스레드에 시간 소모, 교착 상태 및 기타 잠금과 같은 문제가 있는지 확인하고 ANR이 앱 또는 시스템에 의해 발생하는지 확인합니다.

4. 애플리케이션 로그, 코드 또는 소스 코드 등을 결합하여 ANR 문제가 발생하기 전에 애플리케이션의 비정상 여부를 분석하고 특정 문제를 자세히 분석합니다.

2.2 ANR 로그 내보내기

ANR 문제가 발생하면 시스템은 ANR 관련 로그 정보, CPU 사용량, 추적 로그, 즉 각 스레드의 실행과 같은 정보를 수집하고 traces.txt 파일을 생성하여 / data / anr / 경로에 배치합니다.

참고 : 새로운 ANR 문제가 발생할 때마다 이전 ANR 정보를 덮어 씁니다.

adb 명령을 통해 추적 파일을 로컬로 내보낼 수 있습니다.

    adb root     
    adb shell ls /data/anr     
    adb pull /data/anr/<filename>

2.3 키 로그 정보 읽기

1) 로그에서 ANR 발생 정보 찾기 :
Traces 파일의 키워드, 예 :

09-24 15:20:20.211 1001 1543 1570 XXXXXXX： ANR in xxxxxx 
09-24 15:20:20.211 1001 1543 1570 XXXXXXX： PID: xxxxx 
09-24 15:20:20.211 1001 1543 1570 XXXXXXX： Reason: xxxxxx

그들 중 :

• ANR 입력에는 ANR을 유발 한 패키지 이름과 클래스 이름이 포함됩니다.

• PID에서 ANR이 발생한 프로세스의 PID

• Reason에서 keyDispatchingTimedOut과 같은 ANR의 원인

2) CPU 사용량 정보 찾기

09-24 15:20:20.211 1001 1543 1570 XXXXXX： CPUusage from xxx to xxx ago xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx 
09-24 15:20:20.211 1001 1543 1570 XXXXXX： CPUusage from xxx to xxx later xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx

그들 중

• ago는 ANR이 발생하기 전의 CPU 사용량을 나타냅니다.

• 나중에는 ANR 발생 후 CPU 사용량을 나타냅니다.

• xxx % TOTAL에 집중 : xxx % user + xxx % kernel + xxx % iowait. 이러한 항목을 통해 CPU 사용량에 대해 알 수 있습니다.

2.4 구체적 분석

CPU 사용량을 분석 한 후에도 문제의 원인을 찾을 수 없으면 추적 파일을 추가로 분석해야합니다. 트레이스 파일은 ANR 발생 전후 프로세스의 각 스레드 스택을 자세히 설명합니다. 일반적으로 ANR 문제를 분석하기 전에 애플리케이션이 비정상인지 확인하기 위해 메인 스레드의 스택 분석부터 시작합니다.

이 중 다른 시나리오의 ANR 문제는 동일하지 않으며 특정 상황에 대한 구체적인 분석이 필요하므로 여기에서는 자세한 설명을 제공하지 않습니다.

3. ANR 문제의 어려움과 문제 해결을위한 아이디어

3.1 ANR의 어려움

  버튼 클릭, 리소스로드, 페이지 점프 등과 같은 앱에서 사용자의 대부분의 작업에는 앱의 적극적인 피드백이 필요합니다. 그러나 ANR이 발생하면 사용자가 몇 초 동안 기다린 후 "앱이 응답하지 않음"이라는 팝업 만 표시됩니다. ""팝업 창을 통해 사용자에게 "사용하기 어렵다"는 느낌을 주어 사용자 경험에 큰 영향을 미칩니다.

  그러나 라이브 네트워크의 ANR 문제는 처리하기 어렵습니다. 문제는 다음을 포함하지만 이에 국한되지 않습니다.

1. 일반적인 테스트는 다루기가 어렵습니다. 결국 ANR은 오래된 장비와 약한 네트워크 환경이있는 장면에서 자주 나타나며 테스트가 모든 시나리오를 다루기는 어렵습니다.

2. 라이브 네트워크 애플리케이션의 ANR 문제의 경우 문제가 반드시 발생하지 않으면 찾기가 어렵습니다. 특정 로그 추적 및 기타 정보를 얻으려면 문제를 재현 할 수있는 실제 장치가 있어야합니다.

   3. ANR 문제의 포지셔닝은 복잡하고 많은 영향 요인이 있습니다. ANR 문제를 포지셔닝하는 일부 신입생은 시작하기가 어렵고 문제 해결은 경험에 달려 있습니다.

3.2 ANR 처리 새로운 솔루션

기존의 기존 ANR 문제 위치 경험에 의존하는 것 외에도 ANR 문제를 처리하기 위해 타사 애플리케이션 모니터링 플랫폼과 협력하는 것도 편리하고 빠른 ANR 처리 방법입니다.

사용자 경험 개선이 임박했지만 ANR 문제는 사용자 경험에 큰 영향을 미치고 있습니다. ANR 문제를 찾아 해결하기가 어렵습니다. 이러한 요구 문제에 대응하여 점점 더 많은 제 3자가 외부 애플리케이션 성능 모니터링 도구를 조사하고 제공하기 시작했습니다.

성능 관리 (앱 성능 관리, 줄여서 APM) 는 Huawei의 AppGallery Connect 품질 서비스 시리즈 중 하나입니다.이 서비스는 미세 수준의 애플리케이션 성능 모니터링 기능을 제공합니다. ANR 분석 기능은 ANR 문제 포지셔닝 및 처리를 해결하기위한 최고의 파트너입니다. AGC 성능 관리 서비스를 사용하여 애플리케이션 ANR을 모니터링하면 다음과 같은 이점을 얻을 수 있습니다.

1. 라이브 네트워크 애플리케이션 ANR의 실시간 모니터링, 현재 네트워크 애플리케이션 ANR 추세를 완전히 파악합니다.

2. ANR 사이트 정보는 자동으로 수집되어 표시되며 대부분의 상황을 재현 할 필요가 없으며 문제는 온라인에 있습니다.

3. APM 페이지를 통해 포지셔닝 아이디어가 체계적이며 ANR 문제 포지셔닝을 신속하게 시작하여 문제를 제 시간에 해결할 수 있습니다.

4. ANR 문제 해결 사례 대조

다음으로 Huawei의 AGC 성능 관리 서비스를 예로 들어 AGC 성능 관리 서비스와 함께 일반적인 ANR 문제를 신속하게 찾는 방법을 소개합니다.

4.1 사례 (1) : 교착 상태로 인한 ANR 문제 위치

4.1.1 발견 된 문제
Huawei AGC 콘솔의 My Project-Quality-Performance Management 페이지의 "ANR Analysis"탭에서 첫 번째 "User ANR Rate"가 16.67 %에 달하는 것으로 확인되어이 문제를 해결하는 데 우선 순위를두기로 결정했습니다. 클래스 ANR 문제.

4.1.2 문제 찾기
TOP 순위 목록에서 문제 카드를 클릭하고 "ANR 문제 세부 정보"페이지로 들어가 ANR 문제를 분석 한 데이터 보고서를 추가로 볼 수 있습니다.

이 " ANR 문제 세부 정보 "페이지에서 사용자 수의 원형 차트를 분석하고 이러한 유형의 ANR 문제가 " 애플리케이션 버전 2.0 ", "휴대폰 모델 HUAWEI VOG-AL10"및 "시스템 버전 10" 의 세 가지 조건에 있음을 확인합니다. 가장 많은 영향을받는 사용자.

보고서 아래의 "발생 기록"에서 이러한 세 가지 조건을 충족하는 발생 기록을 찾고 "상세 정보보기"를 클릭하여 특정 문제의 분석을 준비합니다.

(1) 시스템 자원 상태 분석
먼저 보고서를 통해 문제 발생시 CPU 점유율 20 %, IO 점유율 0 %, 메모리 부족 없음, 애플리케이션 할당 힙 26.50MB, 애플리케이션 사용 힙 8.69 MB, 스레드 수는 61 개입니다. 다음 그림과 같이 시스템 리소스의 관점에서 볼 때 명백한 이상은 없습니다

. ANR 문제는 두 가지 범주로 나눌 수 있기 때문에 하나는 시스템 리소스 부족으로 발생하고 다른 하나는 자체 코드 논리로 인해 발생합니다. 위의 시스템 리소스 정보, ANR 문제는 시스템 리소스 부족으로 인한 것이 아니라 ANR 문제의 분석이 다음과 같이 변경됩니다. ANR 문제는 자체 코드 논리에 의해 발생하고이 아이디어에 따라 ANR 문제를 분석합니다.
(2) 메인 스레드 상태보기 : ANR 코드 조각
자체 의 코드 로직이 ANR 문제를 일으키는 것으로 확인되었습니다. 주요 분석 아이디어는 메인 스레드 스택 및 스레드 상태를 보는 것입니다. 성능 관리 페이지의 "메인 스레드 스택"탭에서 문제 스택을 찾을 수 있습니다. , 문제가 발생했을 때 메인 스레드가 잠금 상태에 있다는 것을 확인했습니다. 지금까지 결론을 내릴 수 있습니다. ANR 문제는 메인 스레드가 잠금 리소스를 기다리고 있고 차단되어 후속 입력 이벤트가 응답하지 않아 트리거링되기 때문입니다. 애플리케이션의 "입력 디스패치 시간 초과"유형의 ANR입니다.

특정 스택 정보를 살펴보면 ANR 문제 코드 스 니펫을 발견하고 "com.aiops.hiperformance.MainActivity.dispatchActivityDestroyed"호출에서 교착 상태가 발생했음을 발견했습니다. 코드를 살펴보면 "mLock.readLock (). lock ()"함수에서 교착 상태가 발생했음을 알 수 있습니다.

코드에서 mLock 잠금 코드 호출을 검색 한 결과 "mLock.readLock.lock ()"코드는 MainActivity 파일에만 존재한다는 것을 발견했습니다.이 판단에서 비정상 코드는 MainActivity에만 존재하므로 범위를 좁 힙니다. 문제 코드 범위. 코드를 작성하는 과정에서 잠금의 적용과 해제가 코딩 습관이되었고, 잠금이 해제되지 않으면 잠금이 해제되기 전에 코딩에서 고려하지 않았던 예외가 발생하여 잠금이 해제되지 않거나 해제가 실패한 것일 수 있습니다. . 이 분석에서 우리는 다음으로 "ANR 문제가 발생하기 전에 응용 프로그램에 이상이 있는지 확인"이라는 아이디어를 사용하여 분석을 계속하려고합니다.

먼저 잠금 응용 프로그램의 시작 시간을 찾고 차단 동작의 시작 시간부터 분석하여 이상 정보를 찾습니다. "ANR 정보"탭으로 전환 한 결과 주 실행 대기열의 첫 번째 요소가 5.5 초 전에 이미 존재하고 ANR 발생 시간이 "2020-09-27 09:48:27"임을 확인했습니다. 따라서 잠금 획득 동작이 대략 '2020-09-27 09:48:21'에 발생합니다.

(3) 응용 프로그램 로그보기
다음으로 탭을 "시스템 로그"로 잘라냅니다. 현재 "2020-09-27 09:48:21"즈음에 잠금 획득 작업이 발생했음을 알고 있습니다. 이 시점부터 로그를 분석하여 관련 이상이 잠금이 해제되지 않은 주요 요인인지 확인하기 만하면됩니다.

시스템에서 "09 : 48 : 18.365"에 "OutofBoundsException"예외가 발생하고 예외 스택이 인쇄되었음을 발견했습니다. 예외가 이전 문제 코드 범위 인 MainActivity에 나타나는 것을 발견했습니다. 스택을 통과했습니다. , 예외 코드를 찾았습니다.

"getShareDataInterceptor"가 호출되었을 때 "out-of-bounds 예외"가 발생하여 "mLock.readLock"이 해제되지 않았으므로 ANR 문제의 특정 원인을 이미 알고 있습니다. 비정상 시나리오로 인해 잠금 리소스가 해제되지 않았으므로 주 스레드에서 교착 상태가 발생했습니다.

4.1.3 문제 해결 문제
를 해결하기 위해 유사한 문제가 발생하지 않도록 문제를 해결하기 위해 다음과 같은 조치를 취했습니다.

1. 예외의 특정 원인을 분석하고 범위를 벗어난 예외가 다시 나타나지 않도록 코드를 수정합니다.

2. 예외를 포착하면 리소스가 해제되기 전에 보호 코드가 throw됩니다.

3. 리소스가 제 시간에 해제되도록 리소스가 해제되기 전에 다른 코드를 확인하고 보호 기능을 추가하십시오.

4.2 사례 (2) : IO 리소스가 부족하여 ANR 문제 포지셔닝이 발생합니다.

4.2.1 문제 찾기는 문제
의 핵심으로 곧바로 이동하여 "단일 ANR 문제"페이지로 직접 이동하여 문제를 분석하고 성능 관리 서비스의 도움으로 ANR 문제를 찾는 것에 대한 생각을 강화했습니다.

(1) 시스템 자원 상태 분석
먼저, 보고서를 통해 문제 발생시 CPU 점유율 100 %, IO 점유율 84 %, 메모리 부족 없음, 애플리케이션 할당 힙 26.50MB, 애플리케이션 사용 힙 시스템 리소스의 관점에서 8.69MB, CPU 및 IO 점유는 다음 그림과 같이 분명히 비정상입니다.

대부분의 ANR 문제를 찾은 경험을 통해 ANR 문제는 시스템 리소스 부족으로 인한 것임을 알 수 있습니다. ANR 문제를 분석하는 아이디어는 자체 애플리케이션의 ANR 코드 조각을 찾고, 코드를 최적화 할 수 있는지 분석하고, IO가 높은 경우 ANR을 트리거하지 않는 것입니다. .

(2) 메인 스레드 상태보기 :
"메인 스레드 스택"탭으로 전환 하여 문제의 원인 을 찾고 메인 스레드 코드를 관찰합니다.

메인 스레드의 스택을 관찰하여 문제를 발견했습니다. 메인 스레드가 직접 데이터베이스 작업을 수행하고 있습니다. 시스템 IO가 높은 경우이 작업은 확실히 메인 스레드를 차단합니다. 스택을 통해 해당 코드를 찾습니다.

이를 통해 코드에서 SQLite에 액세스하는 작업이 있는지 확인합니다. 현재 숙련 된 개발자는 최적화를 통해 문제를 해결할 수 있으며 스레드에서 IO 작업 만 실행하면 된다는 것을 이미 알고 있습니다 .

(3)
이전 링크에서 애플리케이션 로그를 확인하고 ANR의 원인을 분석하므로이 단계는 필요하지 않습니다.

4.2.2 문제 해결
ANR 문제 발생을 방지하기 위해 문제 코드를 최적화하기 위해 다음과 같은 조치를 취했습니다.

4.3 사례 (3) : 주 스레드의 무한 루프가 ANR 문제의 위치 결정
4.3.1 문제 위치에
대해 할 말이 많지 않음 문제 위치 아이디어를 수정하려면 "단일 ANR 문제"로 직접 이동하십시오.

(1) 우선 보고서를 통해 문제 발생시 CPU 점유율 25 %, IO 점유율 0 %, 메모리가 너무 적지 않고 애플리케이션 할당 힙 18.01MB, 애플리케이션 사용 힙 8.08MB, 스레드 수 43입니다. 다음 그림과 같이 시스템 자원의 관점에서 명백한 이상은 없습니다.

대부분의 ANR 문제를 찾은 경험을 통해 우리는 ANR 문제의 확률이 시스템 리소스 부족으로 인한 것이 아니라는 것을 알고 있습니다. 그러면 ANR 문제의 분석이 다음과 같이 변경됩니다. ANR 문제는 자체 코드 로직에 의해 발생합니다. 다음으로이 아이디어에 따라 이번 분석을 수행합니다. ANR 문제.

(2) 메인 스레드 상태보기 :
문제 의 원인을 찾고 자체 코드 로직으로 인해 ANR 문제가 발생합니다. 주요 분석 아이디어는 메인 스레드 스택 및 스레드 상태를 보는 것입니다. 성능 관리 페이지의 "메인 스레드 스택"탭에서 문제 스택을 찾을 수 있습니다.

문제가 발생했을 때 주 스레드 스택이 getActivity에서 차단되고 주 스레드가 "SUSPENDED"상태에있는 것으로 확인되었습니다. 이때 스택을 사용하여 문제 코드를 찾습니다.

코드 분석을 통해 메인 스레드에 무한 루프가있는 것으로 의심됩니다. 응용 프로그램에 무한 루프가있는 경우 응용 프로그램의 CPU 사용자 모드 시간 점유가 비정상적으로 증가한다는 것을 알고 있습니다. "ANR 정보"탭에는 ANR이 발생할 때 각 프로세스의 CPU 점유 정보가 기록되어 있으므로 페이지로 전환합니다. "ANR 정보"탭으로 이동합니다.

"ANR 정보"탭에서 애플리케이션의 CPU 사용자 모드 리소스 점유율이 94 %에 도달했음을 확인하여 이전 추측을 확인했습니다. 메인 스레드에 무한 루프가있어 ANR 문제가 발생했습니다.

(3)
이전 링크에서 애플리케이션 로그를 확인하고 ANR의 원인을 분석하므로이 단계는 필요하지 않습니다.

4.3.2 문제 해결
ANR 문제가 발생하지 않도록 문제 코드를 최적화하기 위해 다음과 같은 조치를 취했습니다.

5. 사례 요약

위 ANR 문제의 해결 및 처리는 Huawei AppGallery Connect 성능 관리 서비스와 협력하여 이루어지며, ANR 문제 분석 보고서 및 ANR 문제 발생시 문제 기록은 모두 AGC 성능 관리 서비스 인터페이스에서 제공됩니다.

AGC 성능 서비스의 ANR 분석 내역을 통해 애플리케이션 버전 별 분포, 휴대폰 모델 별 분포, 시스템 버전 별 분포, 실시간 문제 발생 추세 등 특정 유형의 ANR 문제 발생시 추세 및 분포 정보를 볼 수 있습니다. 이러한 유형의 ANR 문제가 사용자에게 미치는 영향의 추세와 문제의 재발 조건을 분석하는 데 도움이됩니다.

또한 개발자는 상세한 문제 발생 기록을 통해 문제 발생시보다 자세한 장치 정보, 시스템 정보, 애플리케이션 정보 및 스택 로그를 얻을 수있어 개발자가 문제를 신속하게 찾을 수 있습니다.

6. 관련 링크

• AGC 성능 관리 서비스의 매우 간단한 통합에 대해서는 https://developer.huawei.com/consumer/cn/forum/topicview?tid=0202378801038220228&fid=0101271690375130218 문서를 참조하십시오.

• AGC 성능 관리 서비스의 공식 문서는 https://developer.huawei.com/consumer/cn/doc/development/AppGallery-connect-Guides/agc-apms-introduction을 참조하십시오.