기술나눔

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

성과 수집 및 분석 관련 도구 개요

모바일 애플리케이션 성능 데이터를 수집, 분석, 표시하기 위한 다양한 도구가 있으며, 이는 대략 다음 범주로 나눌 수 있습니다. 예를 들어 여러 성능 지표를 수집할 수 있는 모바일 성능 도구인 perfdog, Solopi가 있는데, 그 중 Solopi는 오픈 소스이고 pefdog은 상용 도구입니다. 상용 Firebase Crashlytics 및 오픈 소스 Sentry 도구와 같이 충돌 분석을 수행할 수 있는 도구입니다. 네트워크 관련 데이터를 분석해야 한다면 Charles나 Wireshark를 사용할 수 있습니다. 또한 Dynatrace와 같은 포괄적인 성능 관리 도구가 있습니다. 일반적으로 상업용 도구의 기능, 정확성 및 사용자 경험은 오픈 소스 도구보다 확실히 우수합니다. 개인 연구 및 연구를 시작하는 유일한 방법은 오픈 소스 도구에서 시작하는 것입니다. 따라서 이 블로그를 작성할 때 오픈 소스 도구도 예로 사용하겠습니다.

모바일 성능 테스트 도구：
PerfDog: 애플리케이션 성능, CPU, 메모리, 전력 소비 및 기타 데이터를 모니터링하고 모바일 애플리케이션의 성능 테스트 및 실시간 모니터링을 지원하는 도구입니다.
Solopi: 프레임 속도, CPU, 메모리 및 기타 지표의 실시간 모니터링을 포함하여 모바일 애플리케이션 성능의 테스트 및 모니터링에 중점을 둡니다.

충돌 분석 도구：
Firebase Crashlytics: 애플리케이션 충돌을 실시간으로 모니터링할 수 있는 Google에서 제공하는 강력한 충돌 보고 및 분석 도구입니다.
Sentry: 모바일 애플리케이션의 오류 보고 및 성능 모니터링을 포함하여 여러 플랫폼을 지원하는 오픈 소스 오류 추적 도구입니다.

네트워크 성능 테스트 도구：
Charles Proxy: 모바일 애플리케이션에 대한 네트워크 요청 및 응답 데이터를 캡처하고 분석하는 네트워크 디버깅 프록시 도구입니다.
Wireshark: 모바일 애플리케이션의 네트워크 패킷 캡처 및 분석을 지원하는 오픈 소스 네트워크 분석 도구입니다.

APM 도구(애플리케이션 성능 관리):
Dynatrace: 모바일 애플리케이션 성능 모니터링 및 사용자 경험 분석을 지원하는 클라우드 네이티브, 풀 스택 성능 모니터링 솔루션입니다.

수집되는 성능 측정항목 및 방법

  성능 분석을 수행하기 전에 먼저 각 성능 지표의 의미를 이해해야 합니다. Solopi에서 수집하는 성능 지표를 예로 들어 모바일 애플리케이션 성능에 대한 일반적인 지표와 이러한 지표가 수집되는 방법을 살펴보겠습니다.

프레임 속도

프레임 속도 계산 공식은 다음과 같습니다.프레임 속도 = 그려진 프레임 수/기간,대부분의 애플리케이션 및 게임 개발자의 목표 프레임 속도는 다음과 같습니다.60FPS( 프레임/초), 목표 프레임 속도가 60FPS인 이유는 무엇입니까? 대부분의 최신 스마트폰과 태블릿의 화면 새로 고침 빈도는 60Hz이므로 프레임 속도가 60FPS, 즉 초당 그려지는 프레임 수가 60이면 사용자의 시각 효과가 더 부드러워지고 지연이 발생하지 않습니다. 최소값은 30FPS보다 낮을 수 없습니다. 이는 모니터가 새 프레임을 기다리는 동안 이전 프레임의 이미지를 반복적으로 표시하여 사진이 매끄럽지 않기 때문입니다. 높은 값은 90FPS에 도달할 수 있습니다(예: 새로 고침 빈도가 높은 장치의 경우).

프레임 속도 정보를 수집하는 방법

  프레임 속도를 수집하는 방법에는 두 가지가 있습니다. 하나는 Choreographer 클래스를 사용하여 프레임 속도 통계를 수집하는 것입니다. 이를 위해서는 애플리케이션 내에서 코드를 작성해야 하며 애플리케이션의 프레임 속도 정보만 수집할 수 있습니다.또 다른 방법은 다음과 같습니다. gfxinfo 도구. 솔로피를 예로 들면, 1초 이내의 타임아웃 프레임 시간도 gfxinfo 툴 정보를 통해 계산되어 실제 프레임 레이트가 추론되기 때문에 정지 상태에 가까울 경우 프레임 레이트의 일부가 잘못 표시될 수 있습니다. 슬라이딩 또는 페이지 전환과 같은 동적 시나리오에서 프레임 속도 테스트를 수행하는 것이 좋습니다. gfxinfo 방법은 모든 애플리케이션의 프레임 속도 정보를 수집할 수 있으며 성능 데이터 수집 도구로 매우 적합합니다. 따라서 여기서는 gfxinfo를 통해 프레임 속도 정보를 수집하는 방법에도 중점을 둡니다.

프레임 속도 정보를 수집하는 두 가지 주요 단계가 있습니다.1단계: adb 명령어를 통해 gfxinfo 정보를 얻고,2 단계 : 정보를 분석하여 프레임 속도 정보를 계산합니다. gfxinfo 정보의 내용은 대략 다음과 같습니다.

이후 통계: 통계 시작 시간, 단위는 나노초입니다.
렌더링된 총 프레임: 렌더링된 총 프레임 수입니다.
버벅거리는 프레임 수: 버벅거리는 프레임 수, 즉 16ms(초당 새로 고침 간격 60프레임)를 초과하는 프레임 수입니다.
버벅거리는 프레임 비율: 총 프레임 수에 대한 버벅거리는 프레임의 비율입니다.
90번째 백분위수: 90번째 백분위수는 프레임의 90%가 이 값(밀리초) 미만의 렌더링 시간을 가짐을 나타냅니다.
95번째 백분위수: 95번째 백분위수는 프레임의 95%가 이 값(밀리초)보다 낮은 렌더링 시간을 가짐을 나타냅니다.
99번째 백분위수: 99번째 백분위수는 프레임의 99%가 이 값(밀리초) 미만의 렌더링 시간을 가짐을 나타냅니다.
누락된 Vsync 수: 동기화되지 않은 수직 동기화 수, 즉 시간 내에 렌더링하지 못해 발생하는 프레임 드롭 수입니다.
높은 입력 지연 수: 높은 입력 지연 수는 너무 긴 입력 이벤트 처리 시간으로 인해 발생한 지연 수를 나타냅니다.
느린 UI 스레드 수: UI 스레드가 느리게 응답한 횟수, 즉 UI 스레드를 처리하는 데 너무 오랜 시간이 걸린 횟수입니다.

Solopi를 예로 들면, gfxinfo 정보의 timeout 프레임 시간을 통해 프레임 속도를 추론합니다. 특정 프로젝트의 코드에 대해서는 solopi 소스 코드를 볼 수 있습니다.

지연율/지연 횟수

동결 횟수 : 테스트 기간 동안 프레임 속도가 임계값보다 낮은 것으로 감지되는 기간 수입니다. 프레임 속도가 일정 기간 동안 임계값 아래로 떨어질 때마다 끊김 현상으로 간주됩니다. 여기에서 임계값을 사용자 정의할 수 있습니다. 예를 들어 목표 프레임 속도보다 60FPS 낮은 경우 정지로 기록될 수 있습니다. 즉, 프레임 렌더링 시간이 16ms를 초과하면 정체된 것으로 계산됩니다.

지연율 : 전체 테스트 시간에 대한 동결 시간의 비율입니다. 테스트에서 애플리케이션이 120초 동안 실행되었고 그 동안 프레임 속도가 총 4번 16FPS보다 낮았고 총 지연 시간이 8초였다고 가정하면 지연 횟수는 4번입니다. 말더듬 비율: 8/120*100%=6.7%. 위의 gfxinfo에는 지연율에 대한 데이터 정보도 있습니다.

CPU/메모리

  solopi를 예로 들면, CPU에는 애플리케이션의 최상위 활동이 있는 프로세스의 CPU 사용량 비율과 단일 프로세스 애플리케이션의 경우 해당 애플리케이션의 CPU 사용량이 포함됩니다. 다중 프로세스 프로세스 애플리케이션에서 이 데이터는 최상위 UI 프로세스를 나타내며, 프로세스 전환이 발생하면 Soloπ는 자동으로 새로운 프로세스 데이터로 전환할 수 있습니다.

import subprocess
 
def get_memory_info(pid):
    try:
        # Run adb shell command to read /proc/<pid>/statm
        command = f"adb shell cat /proc/{pid}/statm"
        result = subprocess.check_output(command, shell=True)
        statm_data = result.decode('utf-8').strip().split()
        
        # Parse statm data
        size, resident, shared, text, lib, data, dt = map(int, statm_data)
        
        memory_info = {
            'size': size,         # total program size (pages)
            'resident': resident, # resident set size (pages)
            'shared': shared,     # shared pages (pages)
            'text': text,         # text (code) size (pages)
            'lib': lib,           # library (unused since Linux 2.6; always 0)
            'data': data,         # data + stack (pages)
            'dt': dt              # dirty pages (unused since Linux 2.6; always 0)
        }
        
        return memory_info
    except subprocess.CalledProcessError as e:
        print(f"Error executing command: {e}")
        return None
    except Exception as e:
        print(f"Error: {e}")
        return None
 
# Replace with your application's PID
pid = '12345'
memory_info = get_memory_info(pid)
if memory_info:
    print(f"Memory info for PID {pid}:")
    print(f"Size: {memory_info['size']} pages")
    print(f"Resident set size (RSS): {memory_info['resident']} pages")
    print(f"Shared pages: {memory_info['shared']} pages")
    print(f"Text (code) size: {memory_info['text']} pages")
    print(f"Data + stack size: {memory_info['data']} pages")

응답 시간

  솔로피를 예로 들어보자. 애플리케이션 클릭에 대한 응답 시간 및 새로 고침 시간 데이터가 포함되어 있습니다. 애플리케이션 차원 데이터에 속합니다. 사용자가 클릭한 시점부터 시스템이 인터페이스 업데이트를 처음 실행하는 시점까지의 시간이 응답 시간이고, 시스템이 인터페이스 새로 고침을 중지할 때까지의 시간이 새로 고침 시간입니다. 응답 시간을 계산하는 논리는 화면을 프레임으로 기록하는 것입니다. Solopi 공식 웹 사이트에서는 시작 프레임과 끝 프레임을 자동으로 인식하여 응답 시간을 계산한다고 소개합니다. 실제로 Solopi를 사용하면 통계적인 페이지 응답 시간을 알 수 있습니다. 예를 들어 사용자가 시작을 클릭하면 응용 프로그램 페이지를 클릭할 때 중간에 있는 사람의 손 속도 작업 시간이 포함되며 이 부분이 응답 시간에 계산됩니다. 따라서 준비된 페이지 응답 시간을 계산하려면 화면만 녹화하고 페이지의 시작 프레임과 끝 프레임을 수동으로 식별하는 것이 더 정확합니다. 화면 프레임을 기록하는 구체적인 단계는 다음과 같습니다.

위 내용은 모바일 애플리케이션의 일반적인 성과 지표의 의미에 대한 이해와 이를 수집하는 방법에 대한 자세한 지침입니다. 충돌 등에 대해서는 다음 블로그에서 자세히 소개하겠습니다.