일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- CM-50
- hutc
- 엠블록
- TP4056
- 무명의개발자
- 아두이노코딩봇
- 아두이노
- 업로드모드
- Dynamixel
- 절벽아래은둔자
- MBLOCK
- c#
- 효용감
- 다이나믹셀
- 코딩봇
- testautomation
- chromedriver
- automation
- QA
- ChatGPT
- NocoDB
- Robotis
- 올로
- 테스트 자동화
- 로보티즈
- 크롬드라이버
- mysql4
- 테스트자동화
- arduino
- Ollo
- Today
- Total
Hermit Under the Cliff
[Android Memory Leak Test #1] 메모리릭의 절대값을 찾기 본문
[Android Memory Leak Test #1] 메모리릭의 절대값을 찾기
AnonymousDeveloper 2022. 7. 20. 16:34우선 들어가기에 앞서 안드로이드의 메모리 구조를 살짝만 살펴봅시다.
안드로이드의 메모리 모니터링을 한다고 하면
대부분의 경우 PSS 값을 확인 합니다.
안드로이드의 메모리는 Page라는 단위로 관리된다고 간단히 생각하시면 되고,
App은 위 그림과 같이 다른 여러 프로세스들과 메모리를 공유 합니다.
이렇게 메모리를 공유를 하기 때문에 각각의 영역에 대한 구분이 필요합니다.
USS (Unique Set Size)
위 그림에서 파란색으로 표시된 부분입니다.
오직 App만이 사용하는 메모리 영역을 의미합니다.
RSS (Resident Set Size)
위 그림에서 빨간색으로 표시된 부분입니다.
App이 사용하는 총 메모리 영역을 의미합니다.
PSS (Proportional Set Size)
위 그림에서 노란색으로 표시된 부분입니다.
USS + (공유된 페이지 수 / 공유하고 있는 프로세스의 갯수) 로 계산 됩니다.
RSS로 메모리 사용량을 측정할 경우 공유된 메모리의 경우는
App 별로 중복 카운트가 되기 때문에 이를 적절한 비율로 나누어준 값입니다.
최근 회사에서 제가 만들어서 배포하는 테스트 자동화 프로그램에
안드로이드의 메모리 상태를 확인하는 새로운 기능을 추가하였습니다.
아래의 adb command를 이용하여
특정 시간동안 메모리 사용량을 확인하는 기능입니다.
adb shell dumpsys procstats [package name] --hours [hours] |
이 명령어를 사용하면 주어진 시간 동안 프로세스의
최소, 최대, 평균값의 PSS 사용량을 알 수가 있습니다.
이 기능을 추가하고 나서 아래와 같은 질문들을 자주 듣습니다.
"메모리 릭을 판별하려고 하면 기준 값을 몇 MB로 설정해야 하나요?"
이에 대한 저의 대답은 항상 같습니다.
"그건 테스트 시나리오에 따라 달라요."
모든 상황에 맞는 메모리 사용량의 기준 값이 있다면
테스터의 입장에서는 참 편할 것 같습니다만,
실제는 그렇게 돌아갈 리가 없습니다.
아래 두 그래프는 같은 App을 대상으로 메모리 사용량을 조사한 그래프 입니다.
평균 사용량, 혹은 최대 사용량이 아래쪽이 위 쪽보다 조금 더 크기 때문에
아래쪽의 경우가 memory leak이라고 볼 수 있을까요?
물론 두개의 시나리오가 동일한 시나리오 였다면 아래쪽의 경우에 대해
조금 더 자세한 메모리 분석이 필요할 수도 있습니다.
하지만 이 경우는 두 가지 테스트의 시나리오가 달랐습니다.
첫 번째 시나리오는 단순히 이미지를 하나 불러오는 것을 반복하는 것이었고
두 번째 시나리오는 이미지를 불러와서 List에 쌓는 것을 반복하는 것입니다.
예를 들어 App이 카메라로 촬영을 해서 연속된 파일을 하나의 PDF 파일로 만드는 앱이라고 가정할 때
당연히 여러번 촬영을 해서 파일 사이즈가 큰 PDF 파일을 만드는 것이
메모리 사용량이 훨씬 더 많아 지겠죠.
이 경우에는 아무리 메모리 사용량이 많아진다고 하더라도
이를 메모리 릭이라고 할 수는 없을 것 입니다.
실제로 메모리 릭은 여러번 반복 수행시
안드로이드 내부에서 GC(Garbage Collection)이 일어나도
더 이상 사용되지 않는 메모리가 반환이 되지 않을때,
이를 메모리 릭으로 의심하고 분석하기 시작합니다.
다음번에는 QA 테스터의 입장에서
메모리릭 테스트를 하는 방법을 간단하게 살펴보겠습니다.
'Test Automation - Technical' 카테고리의 다른 글
[NocoDB] NocoDB 소개 - CRUD API 자동 생성 및 User Pool 관리 (0) | 2022.09.28 |
---|---|
[Selenium] 브라우저 버전에 맞는 크롬 드라이버를 자동으로 가져오기 (1) | 2022.01.25 |