물류 앱 회사에 입사한 후 업무에 투입 되기 위해 앱 사용 방법 및 코드 분석을 했다. 앱의 기능을 이리저리 사용 해보고 테스트 하던 중 앱이 비정상 종료 되는 경우들이 간혹 발생 했고 그 외에 기능이 정상적으로 동작 하지 않는 문제들도 나타났다. 문제 해결 방법을 고민 하던 중 Firebase Crashlytics와 Analytics를 통해 리포트를 확인하면 디버깅하기 수월하겠다고 생각 했고 관련 정보를 찾아본 후 팀원들과 상의 후 프로젝트에 적용 했다.
생각한 대로 앱 비정상 종료 문제들이 Crashlytics에 노출 되어 열심히 원인을 찾아가며 디버깅을 하던 중 크래시는 발생 했으나 어느 시점에 발생한지 확인이 불가능하여 디버깅이 어려운 문제들이 점점 생겨났다. 이 문제를 해결하기 위해 정보를 찾던 중 Analytics의 logEvent 라는 기능을 발견 했는데 정보를 찾아보니 화면 클릭, API 호출 등 여러 event에 대한 로그를 기록 해놓으면 크래시가 나는 경우에 Crashlytics에서 순서 및 메시지 확인이 가능해서 잘 활용하면 해결 안되던 문제들도 해결 가능할거 같았다.
문제 해결을 위해 바로 logEvent를 적용 하며 테스트를 했으나 얼마 지나지 않아 또 하나의 문제가 발견 됐는데 로그를 정상적으로 남겼으나 리포트에서 확인이 안 되는 문제들이 간혹 가다 생기는 것이였다. 이리 저리 테스트도 해보고 검색을 하던 중 logEvent에 대한 새로운 정보를 찾았는데, logEvent에서 로그를 저장할 수 있는 문자 유형과 길이의 제한이 있는 것이였다. 좀 더 찾아보니 logEvent는 40자 이하, 알파벳 대소문자 + 숫자 + 언더바(_)만 사용 가능 했고 그 외의 문자가 들어가면 아예 로그 저장이 안됐다. 이러한 상황을 고려하여 eventMessage를 만들 때 정규식과 replace를 통해 문자를 걸러 냈고 정상적으로 로그를 남겨 해결이 어렵던 크래시 문제들을 해결 했다.
처음 Firebase Crashlytics 적용 후 비정상 종료가 70퍼대 정도로 심각한 문제들이 많이 있었는데 현재는 95~99% 를 유지하고 있다.
