제품이 성숙해지면서 기능이 경쟁 제품을 따라잡고, 소그룹 효과가 점차 나타나게 되면 성능이 표면화되지만 미묘한 영향을 미치게 됩니다.
1. 배경
모바일 프로젝트가 성숙해짐에 따라 많은 앱과 경쟁사들은 초기에 시장 점유율을 점유하는 단계를 넘어 유지, 상환, 사용자 유지의 궤도에 진입하기 시작했습니다. 초기에는 아키텍처의 한계 등으로 인한 레거시 문제로 인해 일부 기능을 구현하더라도 사용자 경험이 좋지 않고, 문제가 발생하면 사용자가 망가지고 사용자를 잃게 됩니다.
물론 제품이 독특하고 꼭 필요한 경우에는 그 성능이 사용자들로부터 불만을 불러일으킬 수도 있지만, 현재 상황으로 인해 예전에는 12306처럼 계속해서 사용해야 하지만 지금은 사람들이 사용하는 데 익숙해졌습니다. Meituan, Ctrip, Fliggy 등은 "감각"이 좋고 안정적인 앱을 장기간 사용하고 있습니다.
따라서 제품이 선택사항인 경우 '감각적 경험'은 사용자 유지, 상환, 사용자 지속성에 영향을 미치는 주요 테스트가 될 것입니다. 예를 들어 저는 생방송을 보다가 항상 낮잠을 자는 습관이 있었는데, 2017년 이전에는 Douyu 클라이언트를 사용했는데, 이후에는 Douyu PC 클라이언트를 장시간 플레이할 때 '버벅임' 현상이 자주 발생했습니다. 재생', '음성 및 영상 싱크가 맞지 않음', 심지어 검은 화면에서 멈춤 현상이 발생하여 Huya Live로 전환했습니다. Douyu가 나중에 새 버전에서 이러한 문제를 수정했을 수도 있지만 저는 Huya's에 있었기 때문에 큰 문제는 없었습니다. 사용 중에 교체한 적이 없어서 지금까지 계속 사용하고 있습니다.
성능 최적화는 항상 지속적인 관심이 필요한 특별한 트랙이었습니다! 기능을 따라잡는 과정에서 효율성과 수익뿐만 아니라 장기적으로 지속 가능한 최적화도 고려해야 합니다. 일단 큰 진전을 이루면 쉽게 사용자를 잃을 것입니다~
2. 성과항목의 해석 및 영향
1. 육체적 직업
1.1 패키지 용량
1>패키지 볼륨은 설치 패키지의 크기를 나타냅니다.
2>영향:
2.1>공유
신규 사용자를 유치하는 일반적인 방법 중 공유는 필수적인 부분을 차지합니다.예를 들어 앱의 활동 페이지에서 공유를 클릭하면 해당 APK가 WhatsApp 채팅 상자로 자동으로 가져오는 것이 일반적입니다.(일부 회사에서는 속도 버전, 일부 모듈 설치 후 Wi-Fi 네트워크를 통해 다운로드)
2.2>다운로드 및 설치
일부 시나리오에서는 패키지 크기가 너무 커서 사용자의 다운로드 및 설치 결정에 영향을 미칠 수 있습니다. 예를 들어 사용자가 데이터를 사용하여 다운로드하는 경우 사용자의 휴대폰 공간이 부족합니다.
1.2 공간(물리적 기억) 점유
1>공간 사용량은 일반적으로 애플리케이션 사용량, 데이터 사용량, 캐시로 구성됩니다.
2>영향:
2.1>실행
공간 사용량이 높을수록 Android 기기의 부하가 증가하고 원활한 실행에 영향을 미치며 때로는 충돌, ANR 등이 발생할 수 있습니다.
2. 시작 시간
2.1 콜드 스타트
1>콜드 스타트(Cold start)는 일반적으로 백그라운드에 애플리케이션 프로세스가 없는 경우(연결 유지 시스템에서 수집한 데이터를 구별) 사용자가 앱을 시작한 시점부터 시스템이 프로세스를 생성하여 애플리케이션에 할당하는 것을 말합니다. , 애플리케이션 초기화가 완료된 후 홈페이지에 진입합니다(SplashActivity).
2>영향력
2.1> 빠른 진입은 사용자에게 더 좋고 빠른 경험을 제공할 수 있으며 일부 회사에서는 화면 광고를 설정하여 느린 시작 문제를 해결할 수도 있습니다.
2.2> 일반적으로 콜드 스타트의 경우 2/5/8 원리를 참고할 수 있는데, 2초 이내에 허용되고, 5초 이내에 최적화되어야 하며, 8초 이내에 경험이 나쁘고, 초과하면 사고입니다. 8초~
2.2 핫 스타트
1>핫 스타트는 백그라운드 프로세스(프로세스가 활성화됨)로 앱을 시작하는 데 걸리는 시간입니다.
2>영향력
2.1>컷인 거래 처리를 신속하게 완료하여 사용자가 가능한 한 빨리 사용을 재개할 수 있도록 합니다.
2.2>핫 리스타트(Hot Restart)는 일반적으로 1/2/4 원리를 참조할 수 있으며, 마찬가지로 앱이 백그라운드로 전환되었다가 다시 전환되어 프로세스가 활성화된 경우 이 경우 4초 이상 작동할 수 없습니다. 기본적으로 건너뛸 수 있습니다. 앱을 최적화하고 RD 및 QA를 직접 최적화합니다.
2.3 전체 시작
1> 경우에 따라 상황에 따라 사용자가 앱 아이콘을 클릭한 시점부터 홈페이지에서 첫 번째 작동 가능한 프레임까지의 기간에 주목하기도 합니다. 이러한 종류의 통계는 사용자의 관점에 더 가깝고, "체성 감각" 시작. 여기에서는 홈페이지의 논리적 판단, 캐싱, 데이터 로딩, 렌더링 등이 고려될 수 있습니다.
2>영향력
전체 시작 속도가 빨라지면 사용자에게 더 나은 경험을 제공하고 대기 비용을 줄일 수 있습니다.
2.4 딥링크 시작
1>일부 특정 시나리오에서는 랜딩 페이지를 공유하고 앱을 실행할 때와 같이 딥링크 시작 시간, 시작부터 페이지 렌더링으로 이동하는 데 걸리는 총 시간에 주의를 기울입니다. 시간이 너무 길면 영향을 미칩니다. 활동의 최종 전환;
2>영향력
딥링크에서 시작된 시나리오는 일반적으로 특정한 목적을 가지고 있습니다. 예를 들어 활동의 랜딩 페이지가 앱의 지정된 활동 페이지로 다시 이동합니다. 그런 다음 점프 경로에서 필수적이지 않은 요소를 로드하지 않거나 로드하지 않도록 선택할 수 있습니다.
2.5 네트워크 없이 시작
1>일반적으로 네트워크가 없을 때 로드, 재시도 및 기본 표시 기간에 중점을 둡니다.
2>영향력
다시 시작하는 것 외에는 복구할 수 없는 네트워크 문제로 인해 시작 오류가 발생한 적이 있는데 기본 페이지도 없고 새로 고침도 없고 재시도 버튼도 없고 구성 인터페이스도 실패했지만 후속 인터페이스에서는 재시도를 제한하지 않았습니다. ;
우리는 사용자가 다시 시작할 때마다 발생하는 비용에 주의를 기울여야 합니다. 이는 유창성 요구 사항이 높은 특정 시나리오에서는 치명적입니다.
3.PSS(메모리 사용량)
3.1 Android 시스템에서는 다른 프로세스와 메모리를 공유하는 것(shared dirty) 외에도 각 APP 프로세스도 개인 메모리(private dirty)를 사용합니다. 일반적으로 우리는 PSS(개인 메모리 + 비례 공유 메모리)를 사용하여 APP의 성능을 측정합니다. .메모리 오버헤드. 모바일 장치의 메모리는 고정되어 있으므로 메모리 소비가 너무 크면 애플리케이션이 멈추거나 충돌할 수 있으므로 메모리를 테스트해야 합니다. 정상적인 상황에서 애플리케이션은 너무 많은 메모리 리소스를 차지해서는 안 되며 적시에 메모리를 해제하여 전체 애플리케이션의 안정성과 유창성을 보장할 수 있습니다.
adb shell dumpsys meminfo packageName을 통해 얻을 수 있습니다.
3.2 영향
종료: 앱이 백그라운드에 배치될 때 Android 시스템이 메모리 오버헤드가 부족한 특정 상황에 직면하면 PSS의 내림차순으로 프로세스 종료를 시작합니다.
충돌: 충돌
기타: OOM(메모리 누수)이 발생하면 프로그램 지연, 응답 속도 저하, 재시작, ANR 등도 발생할 수 있습니다.
4.CPU
CPU 테스트를 할 때 장치 자체의 성능 특성에 주의를 기울이는 것 외에도 현재 환경의 성능 부하에도 주의를 기울일 것입니다. 예를 들어 국내 사용자는 일반적으로 WeChat, 음악 소프트웨어, 카메라 소프트웨어 등을 사용합니다. .백그라운드에서 열리며 일부 해외 지역의 사용자는 일반적으로 열어 둡니다. Facebook, WhatsApp, Instagram 등 성능 테스트를 할 때 테스트 중인 앱이 장치에 가져오는 성능 압박을 고려하는 것 외에도 또한 다양한 장치 성능 부하에서 테스트 중인 앱의 성능을 고려하십시오.
4.1 우려사항
1>전체 CPU 사용량
2>애플리케이션 CPU 사용량
4.2 팔로우 방법
1>Android 자체 DDMS 시각화 도구
2>Android Studio 3>Linux 시스템 /proc/stat 및 /proc/<pid>/stat 파일을 통해 점유율을 계산합니다.
3> top 명령어나 dumpsys cupinfo 및 기타 명령어를 통해 실시간으로 현재 CPU 상황을 확인한다.
4.4 영향
올해 하반기에 출시될 킹 오브 킹스의 특정 버전에서는 플레이해 보면 매우 뜨겁다는 것을 알 수 있을 것입니다.시스템 호환성의 특성 외에도 높은 CPU 사용량도 높은 비율의 이유입니다. ; 애플리케이션의 CPU 사용량에 주의를 기울일 때 효과적인 점유가 합리적인 범위 내에서 제어되도록 하려면 다양한 작동 환경 및 장비 성능 부하 하에서 유창성, 온도, 전력 등을 검증하는 데에도 주의를 기울여야 합니다.
과도한 CPU 사용은 운영 프로세스, 온도 및 전력 소비에 영향을 미칠 뿐만 아니라 앱 재시작, 충돌, ANR과 같은 치명적인 문제를 일으킬 수도 있습니다.
5.FPS
5.1 FPS(유창함), FPS 게임을 하는 학생들에게 친숙할 것입니다. 이론적으로 FPS가 시스템 기대치를 충족한다면(안드로이드 시스템에서는 일반적으로 각 프레임을 16ms 이내에 그려야 함) 뚜렷한 지연이 없을 것입니다. 16ms 이내에 지연이 없습니다. 그리기가 완료된 후 프레임 드롭이 발생하여 사용자의 관심을 끌 것입니다.
5.2 영향
불합리한 레이아웃, 과도한 그리기, 잦은 가비지 수집 등은 모두 프레임 드롭을 유발하는 원인일 수 있습니다. 프레임 드롭이 발생하면 사용자는 멈춤과 부드러움을 느끼지 않을 뿐만 아니라 화면 찢어짐 및 오프셋 및 기타 문제가 발생합니다. 일반적으로 FPS 게임의 경우 이는 매우 중요한 지표입니다. 예를 들어 치킨 게임을 할 때 누군가를 만날 때마다 멈춥니다. 네트워크 문제가 아니라 FPS 저하일 수도 있습니다. 프레임 문제~
6.GPU 렌더링(프로필 GPU 렌더링)
6.1 GPU 렌더링은 일반적으로 각 프레임의 렌더링 소비를 나타내며 일반적으로 그리기 시간, 실행 시간 및 처리 시간의 세 부분으로 구성됩니다. 대부분의 안드로이드 컴퓨터에는 GPU 렌더링의 디버그 기능이 있습니다.
6.2 영향
GPU 렌더링은 일반적으로 FPS 부드러움에 영향을 미칩니다.
GPU 오버드로:
파란색: 한 번 오버드로우됨;
녹색: 오버드로우 2회;
분홍색: 3번 오버드로우됨;
빨간색: 4번 이상 오버드로우되었습니다.
7.소비전력
7.1 앱의 전력 소비는 앱 작동 중에 관련된 모든 구성 요소의 총 전력 소비입니다.
Wakelock: 기기의 배터리 수명을 최대한 늘리기 위해 Android 시스템은 전력을 절약하기 위해 다양한 하드웨어 모듈을 지속적으로 종료합니다. 앱이 절전 모드인 동안 네트워크를 요청하려면 먼저 장치를 깨운 다음 네트워크를 요청하고 일정 시간이 지나면 장치가 천천히 다시 절전 상태로 전환됩니다.
기기가 포그라운드에서 실행 중일 때 CPU(I/O, 사물 처리), 네트워크(네트워크에서 전송되는 데이터의 양), 다양한 센서(자이로스코프, GPS) 등의 사용이 모두 앱의 성능을 결정합니다. 소비순위;
7.2 영향
과도하고 빠른 전력 소비는 일부 시나리오에서 사용자의 사용 의향에 영향을 미치며, 시나리오에서 불필요한 트랜잭션을 확인하여 전력 소비를 최적화할 수 있습니다. 또한 사용자 중심이 아닌 작업을 연기하고 일부 트랜잭션의 처리를 설정할 수도 있습니다. 타이밍과 같은 전략( 충전 중 데이터 백업), 특정 리소스의 Wi-Fi 다운로드, 분산된 작업 병합 등을 통해 충전되지 않는 상황에서 전력 소비에 대한 사용자의 인식을 개선합니다.
8. 전류 소비
8.1 요즘 안드로이드 애플리케이션 시장에는 앱 실행 과정에서 트래픽 소비 통계를 시각적으로 관찰할 수 있는 트래픽 통계 소프트웨어가 많이 있습니다.
8.2 통계적 차원
1>와이파이
2>3G/4G/5G
8.3 영향
일반적으로 사용자들은 네트워크 오버헤드가 높은 앱이 트래픽을 많이 소비할 뿐만 아니라 전력도 많이 소비할 것이라고 생각하며 심지어 휴대폰이 실행될 때 지연, 과열, 충돌 등의 문제를 비난하기도 합니다. 따라서 불필요한 리소스 요청, 캐싱, 리소스 다운로드 타이밍 등을 확인하여 네트워크 소비에 주의를 기울여 트래픽 소비가 많다는 사용자의 인식을 줄여야 합니다.
9. 호환성
9.1 호환성 테스트는 소프트웨어가 특정 하드웨어 생산 플랫폼, 다양한 응용 소프트웨어, 다양한 운영 체제 플랫폼, 다양한 네트워크 및 기타 환경에서 잘 작동할 수 있는지 여부를 테스트하는 것을 의미합니다.
9.2 영향
다양한 Android 브랜드, 모델, 해상도, 다양한 아키텍처의 CPU, 다양한 운영 체제 등이 모두 소프트웨어 성능에 영향을 미칩니다.
10. 안정성
10.1 안정성 충돌, ANR 및 성능 차원 외에도 비즈니스의 고가용성에도 주의를 기울여야 합니다. 일부 핵심 프로세스에서는 사용자 수가 증가하고 비즈니스 방문 횟수가 증가함에 따라 안정성 문제가 발생하기 쉽습니다. 발생하므로 핵심 프로세스의 안정성 보장이 매우 필요합니다.
10.2 분류
1>충돌
2>ANR
3>성능
4>비즈니스 고가용성
10.3 영향
높은 안정성은 사용자의 일상적인 제품 요구 사항을 충족할 뿐만 아니라 제품 신뢰도를 지속적으로 높여줍니다. 이는 사용자의 자기 홍보 및 자기 분열의 핵심 전제 조건 중 하나입니다. 안정성은 유지 및 상환에 영향을 미칠 뿐만 아니라 부작용도 있습니다. 성장 지표: 모니터링 및 자동화와 같은 조기 경고 메커니즘을 통해 안정성 보장을 향상하고 안정성 문제를 처리하는 데 필요한 시간을 단축할 수 있습니다.
3. 성능 삼각형
성능 테스트를 시작하기 전에 제품의 대상 국가, 대상 사용자, 장비 환경, 네트워크 환경 등을 기반으로 종합적으로 공식화되어야 하는 성능 테스트를 위한 데이터를 준비하는 것이 매우 중요합니다.
1. 장비 및 환경
과거 성능 테스트에서는 일반적으로 현재 제품이 다루고 있는 상위 모델과 상위 시스템(버전)을 포함한 관련 데이터를 먼저 하이브를 통해 확인하고, 성능 데이터 수집 장비에 대한 비율이 더 높은 모델을 선택하여 더 나은 결과를 얻을 수 있습니다. 실제 장면 데이터;
디바이스를 구매한 후 제품이 주로 적용되는 국가를 기반으로 현지 사용자의 다양한 환경을 시뮬레이션합니다. 예를 들어 app_list를 설치한 사용자를 수집한 후 해당 국가, 연령층 등의 사용자를 수집합니다. 웹사이트를 분석하고, 앱의 습관과 주기를 활용하여 환경을 준비합니다.
예: 제가 한때 수행한 해외 음악 소프트웨어 앱의 성능 테스트에서 기기 중 하나가 가장 많은 사용자 기반을 보유한 Redmi Note 4를 선택했습니다.
1>장치의 주요 매개변수: 4GB 메모리 + 64GB 플래시 메모리, 최대 CPU 주파수 2.1GHz, 5.5인치 화면, 4100mAh 배터리, 5V/2A 충전, 센서(적외선, 자이로스코프, 주변광 센서 등), GPS, 지문, 듀얼 SIM 듀얼 대기, MIUI8 등
2>환경의 주요 매개변수:
2.1>설치됨: 테스트할 앱, Facebook, WhatsApp, instagram, soloP, Messenger, Snapchat, Twitter, Paytm, Zomato, Swiggy, KFC, Pizza Hut, Amazon, My More Store, Big Basket, Google Map, Tinder, Book My 쇼, 인도 철도, Jugnoo 등
2.2>시작됨: 테스트할 앱, 메신저, WhatsApp, soloP 및 일부 기본 Google 서비스 및 기타 애플리케이션의 백그라운드 프로세스
2.3>네트워크: 특정 상황에 따라 다릅니다.
2. 장면
성능 테스트 시나리오 선정에 있어서도 핵심 사업 범위가 가장 높은 5개 주요 프로세스를 중심으로 정리하고, 이들 프로세스에 대한 시나리오를 설계하였으며, 설계가 완료된 후 검토, 경로 최적화를 통해 최종 계획을 확정하였습니다. , 등.;
3.지표
대부분의 성과 지표에는 두 개의 곡선이 있는데, 하나는 업계 평균이고 다른 하나는 경쟁 제품 곡선입니다. 우리는 일반적으로 업계 평균보다 낮지 않고 경쟁 제품 지표를 따라잡는 재고 버전의 성과 지표를 설정합니다. 일정 기간이 지나면 Incremental 버전의 성능 지표에 주의가 필요하며, 현재 버전과 이전 버전의 성능 데이터가 크게 다른 경우에는 기능 구현 여부를 분석해야 합니다. 합리적이고, 성능 데이터 로그를 분석하고, 문제 시나리오를 찾고, 특별한 최적화를 수행합니다.
4. 성과항목 획득 도구
1. 육체적 직업
1.1 패키지 용량
Jenkins 통계/APK 패키지 크기 통계
1.2 공간(물리적 기억) 점유
시스템 애플리케이션 통계
2. 시작 시간
adb/PerfDog/AirtestIDE
3.PSS(메모리 사용량)
adb/안드로이드 프로파일러(안드로이드 스튜디오)/PerfDog/soloP
4.CPU
adb/안드로이드 프로파일러(안드로이드 스튜디오)/PerfDog/soloP
5.FPS
adb/GT/PerfDog
6.GPU 렌더링
Android 시스템 개발자 도구/프로필 GPU 렌더링/PerfDog
7.소비전력
adb/배터리 역사가/PerfDog
8. 전류 소비
adb/안드로이드 프로파일러(안드로이드 스튜디오)/PerfDog
9. 호환성
클라우드 테스트/자동화
10. 안정성
특별 거버넌스/모니터링/자동화
5. 성능 자동화 및 CI(지속적 통합)
1. 물리적 점유: Python 또는 기타 언어 스크립트를 사용하여 획득합니다.
2. 시작 시간: AirtestIDE(poco+이미지 인식)+adb를 사용하여 구했습니다.
3. PSS, CPU: AirtestIDE+SoloP를 사용하여 UI 자동화 장면의 외부 중첩 성능을 기록한 다음 Python 스크립트를 통해 성능 데이터를 분석하고 계산합니다.
4. FPS, GPU, 전력 소비, 전류 소비: 마찬가지로 airtestIDE+PerfDog+python을 사용하여 자동화된 데이터 수집을 실현할 수 있습니다.
5. Jenkins 및 쉘 스크립트를 통해 이러한 기능을 통합한 다음 성능 자동화의 지속적인 통합을 위해 기존 패키징 도구, 가상 머신 또는 실제 머신을 통합합니다.
6. 부록 문서
Jenkins 자동 배포를 시작하기 위한 자세한 튜토리얼
열심히 노력해야 합격할 수 있고, 열심히 노력해야 훌륭해질 수 있어요~