스테이지 12에서 앱이 꺼졌는데 시험 기기를 성능 좋은 것으로 바꾸니 안 꺼졌다. 기기 문제로 정리하고 넘어갔는데 며칠 뒤 그 기기에서도 꺼졌다. 스테이지 18이었다.
Table of contents
Open Table of contents
사라진 게 아니라 밀린 것이었다
기기를 바꿔 증상이 없어지면 두 경우가 있다. 그 기기에만 있는 문제였거나 문제는 그대로인데 여유가 늘어 늦게 나타나는 것이다.
두 번째면 언젠가 다시 나온다. 12에서 18로 밀렸을 뿐이다. 여유가 늘어 증상이 늦게 나온다는 것은 그 여유를 계속 먹고 있다는 뜻이기도 하다.
무엇을 먹고 있는지 봤다
CCTextureCache 에 캐시 내용을 찍는 dumpCachedTextureInfo() 가 있었다. 스테이지가 바뀔 때마다 불러서 logcat 으로 봤다.
cocos2d: "effect/fx_hit.png" rc=2 id=17 256 x 256 @ 32 bpp => 256 KB
cocos2d: "effect/fx_dust.png" rc=2 id=18 256 x 256 @ 32 bpp => 256 KB
cocos2d: CCTextureCache dumpDebugInfo: 44 textures, for 11264 KB (11.00 MB)줄 수가 스테이지마다 13개씩 늘고 줄어드는 시점이 없다. 이전 스테이지 것이 안 빠지는 것이다.
눈에 걸린 것은 rc= 였다. 그게 참조 수인데 2로 찍힌다. removeUnusedTextures() 는 retainCount 가 1인 것만 지우게 돼 있어서 2면 그냥 넘어간다. 어디서 하나를 더 잡고 있는지 찾아보니 이펙트를 미리 만들어 두는 CCMutableArray 가 전역에 있었고 스테이지마다 addObject 로 넣기만 하고 비우지 않았다.
원인과 여유를 구분했다
기기를 바꾸는 것은 여유를 늘리는 일이지 원인을 없애는 일이 아니다.
성능 좋은 기기와 리소스 크기 축소와 캐시 상향과 재시작 주기 단축이 전부 그렇다. 지금은 안 죽는다를 만들지만 어느 것도 새는 곳을 막지 않는다.
여유를 늘리는 것 자체가 잘못은 아니다. 당장 시연이 있으면 그것으로 넘긴다. 다만 그것을 해결로 적어 두면 안 된다.
늘어나는지 보는 방법
새는지 아닌지를 가르는 방법은 반복이다. 같은 스테이지를 열 번 들어갔다 나오면서 dumpCachedTextureInfo() 의 총계를 봤다.
[enter 1] cocos2d: CCTextureCache dumpDebugInfo: 18 textures, for 4608 KB
[enter 2] cocos2d: CCTextureCache dumpDebugInfo: 31 textures, for 7936 KB
[enter 10] cocos2d: CCTextureCache dumpDebugInfo: 130 textures, for 33280 KB한 번 들어갔다 나오면 원래대로 돌아와야 하는데 반복할수록 늘면 새는 것이다. 한 번만 보면 원래 그만큼 쓰나 보다로 넘어간다.
전역 목록을 비우게 하고 나서 CCSpriteFrameCache 쪽도 removeUnusedSpriteFrames() 를 같이 불러 줬다. 텍스처만 놓아 주고 프레임을 쥐고 있으면 참조가 그대로 남는다. 열 번을 반복해도 같은 값에서 멈추는 것을 확인하고 끝냈다. 고치기 전에 늘어나는 것을 보고 고친 뒤에 안 늘어나는 것을 봐야 고친 것이 맞다.
정리
- 환경을 바꿔 증상이 사라지면 여유가 달라진 것일 수 있다
- 증상이 늦게 나온다는 것은 그 여유를 계속 먹고 있다는 뜻이다
dumpCachedTextureInfo()는 텍스처별 크기와 총계를CCLOG로 찍는다removeUnusedTextures()는retainCount가 1인 것만 지운다- 전역
CCMutableArray가 참조를 잡고 있으면rc=2라 안 지워진다 - 여유를 늘리는 조치는 시간을 벌 뿐이고 해결로 기록하지 않는다
- 새는지 보려면 같은 동작을 반복해 값이 늘어나는지 본다
CCSpriteFrameCache의removeUnusedSpriteFrames()도 같이 부른다