배경
작년에 어느 한 회사의 면접에서 "ANR을 모니터링 및 대응하는 본인만의 노하우가 있나요?"라는 질문을 받았었다. 그동안 개발하면서 한 번도 ANR을 만들어본 적이 없는데 얼마전에 처음으로 만들어봤다.
파베 crashlytics에 집계가 됐고 마지막으로 찍힌 이벤트와 로그를 보면서 추적했다. ANR이라는 것 자체가 메인 스레드 블락을 암시하기 때문에 어떤 게 문제가 됐을지 추려보는 건 어렵지 않았다.
대응
"사용자의 디바이스 성능이 너무 떨어지는 건 아닐까?" 싶었는데 거의 최신 기종이라 이건 아닌 것 같았고 시간복잡도가 큰 로직이 메인 스레드에서 돌고 있어서 발생한 것으로 파악했다. 해시맵을 사용해서 로직의 시간복잡도를 n^2 -> n으로 개선했고 Dispatcher.Default에서 돌려주는 것으로 1차 대응을 하였다.
구현상 필요에 의해서가 아닌, 성능 개선 목적으로 적절한 자료구조를 선택해 대응을 한 건 거의 처음인 것 같다. 짤막하게나마 CS 공부를 했던 게 이렇게 도움이 될 줄이야.
느낀점
ANR은 크래시는 아니긴 하지만 사용자의 이탈을 만들어 낼 가능성이 높아 사실상 크래시랑 다를 바가 없다고 본다.
"내가 이번 작업을 하면서 어떤 태도로 접근했어야 ANR을 안 만들 수 있었을까?" 회고를 해봤고 사소한 부분조차 최적화를 하려고 세심히 작업해야겠단 결론을 얻었다.
로직을 짤 때 딱히 무거운 작업이라고 못 느껴서 시간 복잡도나 스레드를 신경 쓰지 않았었다. 실제로 여러 사람들 간 수차례 검증을 거치면서 문제된 적도 없었다. 그렇기에 예상치 못했던 상황인 건 맞지만 예상을 못했어도 최적화가 잘 돼있었으면 막을 수 있었을 것 같아서 아쉬움을 느꼈다.
좋은 경험하게 해주신 사용자 분께 감사와 죄송을!
'개발자취' 카테고리의 다른 글
디자인 시스템에 회의적이었다가 필요성을 느끼게 된 계기 (0) | 2025.03.07 |
---|---|
2년차에 들어서는 1년차의 회고 (36) | 2024.12.07 |
첫 이직 (카카오스타일) (4) | 2024.11.11 |
멘토링 및 코드 리뷰 활동 (0) | 2024.11.10 |
퇴사 (1) | 2024.10.31 |