저번주에 삽질한 내용 소개입니다.
일단 모바일 프로그램팀에서 받은 제약사항은 다음과 같습니다.
- 그래픽 메모리는 40메가가 한계입니다
네, 이것이 최대 수치. 총 80메가 정도의 메모리 사용량에, 그래픽에 배정된 메모리 양입니다.
물론 이것이 최대이기 때문에 이보다 줄면 줄수록 좋습니다..
이것은 3Gs때와도 마찬가지이기 때문에, 이미 만들어 놓은 데이터로 문제 없는 상황입니다.
게다가 Vertex 수를 줄이기 위해 Normal까지 합치는 작업을 해버렸으니 더 작겠지요.
그치만 안드로이드에서 메모리 체크하는건 정말 만만한 작업이 아니더군요.
정확하게 예측할 수 없는건 둘째치고, 그 수치도 매우 불안하게 요동칩니다.
일단 40마리가 출현해도 30프레임을 유지.
그치만 메모리가 60메가가 넘어가는 사태가 발생...
생각보다 너무 커서 정신이 없습니다.
오차율은 대충 이 정도쯤.
그래서 처음부터 역추적하기로 했습니다.
또한, 안드로이드 개발할때 가장 정확하게 메모리를 체크해 준다는 ADB Shell을 같이 가동하였습니다.
아무것도 없는 빈 화면. 플렌 하나 넣었습니다.
프레임은 55프레임.
작업관리자에서는 아무것도 없는데 28메가를 칩니다!!!
아무래도 기본으로 뭔가 먹는게 있다는 뜻.
하지만 저 28메가라는 수치도 그다지 믿을게 못됩니다.
왜냐면
ADB Shell로 봤을때 이렇게 결과가 나옵니다. size는 나름 유동적인데, allocated는 변칙적.
그래서 캐릭터 하나를 띄워 봤습니다.
...
작업관리자에서는 이정도.
Adb shell 의 size 가 의미있는 결과를 도출해 내고 있습니다. 약 1메가 늘었네요.
예전 IOS 검사에서도 캐릭터 한마리는 1메가 정도였습니다.
두 마리 테스트입니다.
역시 증가
증가...
3마리 버전입니다.
나름 의미있는 데이터가 도출되었습니다
Shell의 Allocated의 용량은 또한 너무 비정상적입니다.
그러므로 가장 안정적인 데이터는 Shell total 메모리라고 볼 수 있겠습니다.
데이터 증감도 가장 이쁘네요.
그리고 여기서 다시 40마리 테스트를 거친 결과입니다.
그리고 결과물로 역산한 증감량 계산도 같이 있습니다.
역시 작업관리자의 데이터는 편차가 너무 크고,
shell total의 수치가 가장 안정적입니다.
여기까지의 테스트로 알 수 있는 것은 다음과 같습니다.
- (이유는 정확하지 않지만) 안드로이드로 넘기면 24메가 정도를 스스로 잡아버린다.
- 그러므로 24메가를 빼고 계산하면 정확한 그래픽 데이터의 메모리 양을 산출해 낼 수 있다.
- 정확한 메모리의 양은 Adb Shell의 Total을 참고하는 것이 가장 정확하다.
- 그러므로 24메가를 빼고 계산하면 정확한 그래픽 데이터의 메모리 양을 산출해 낼 수 있다.
- 정확한 메모리의 양은 Adb Shell의 Total을 참고하는 것이 가장 정확하다.
다음은 이렇게 산출된 데이터를 가지고 배경 데이터를 테스트하도록 하겠습니다.
반응형
댓글