조각들

배경

작년에 어느 한 회사의 면접에서 "ANR을 모니터링 및 대응하는 본인만의 노하우가 있나요?"라는 질문을 받았었다. 그동안 개발하면서 한 번도 ANR을 만들어본 적이 없는데 얼마전에 처음으로 만들어봤다.
 
파베 crashlytics에 집계가 됐고 마지막으로 찍힌 이벤트와 로그를 보면서 추적했다. ANR이라는 것 자체가 메인 스레드 블락을 암시하기 때문에 어떤 게 문제가 됐을지 추려보는 건 어렵지 않았다. 
 

대응

"사용자의 디바이스 성능이 너무 떨어지는 건 아닐까?" 싶었는데 거의 최신 기종이라 이건 아닌 것 같았고 시간복잡도가 큰 로직이 메인 스레드에서 돌고 있어서 발생한 것으로 파악했다. 해시맵을 사용해서 로직의 시간복잡도를 n^2 -> n으로 개선했고 Dispatcher.Default에서 돌려주는 것으로 1차 대응을 하였다.
 
구현상 필요에 의해서가 아닌, 성능 개선 목적으로 적절한 자료구조를 선택해 대응을 한 건 거의 처음인 것 같다. 짤막하게나마 CS 공부를 했던 게 이렇게 도움이 될 줄이야.
 

느낀점

ANR은 크래시는 아니긴 하지만 사용자의 이탈을 만들어 낼 가능성이 높아 사실상 크래시랑 다를 바가 없다고 본다.
 
"내가 이번 작업을 하면서 어떤 태도로 접근했어야 ANR을 안 만들 수 있었을까?" 회고를 해봤고 사소한 부분조차 최적화를 하려고 세심히 작업해야겠단 결론을 얻었다.
 
로직을 짤 때 딱히 무거운 작업이라고 못 느껴서 시간 복잡도나 스레드를 신경 쓰지 않았었다. 실제로 여러 사람들 간 수차례 검증을 거치면서 문제된 적도 없었다. 그렇기에 예상치 못했던 상황인 건 맞지만 예상을 못했어도 최적화가 잘 돼있었으면 막을 수 있었을 것 같아서 아쉬움을 느꼈다.
    
좋은 경험하게 해주신 사용자 분께 감사와 죄송을!