Android 미드레벨 트러블슈팅 면접
새 면접Q. 프로덕션 환경에서 사용자들이 앱을 오래 사용할수록 점점 느려지고 결국 ANR이 발생한다는 리포트가 들어왔습니다. LeakCanary를 통해 확인한 결과 특정 Activity에서 메모리 누수가 발생하고 있습니다. 이 문제를 어떤 순서로 진단하고 해결하시겠습니까? 그리고 Android에서 메모리 누수가 자주 발생하는 패턴들과 예방 방법을 설명해주세요.
Activity 생명주기와 관련된 리스너, 핸들러, 비동기 작업들이 어떻게 참조를 유지하는지 생각해보세요.
먼저 LeakCanary의 상세 리포트를 통해 어떤 객체가 Activity를 참조하고 있는지 체인을 확인합니다. Android Studio Profiler로 힙 덤프를 떠서 메모리 증가 패턴을 분석하고, 의심되는 시점에 GC를 강제로 실행해도 메모리가 해제되지 않는지 확인합니다. 주요 원인으로는 Context를 참조하는 static 변수, Handler의 non-static inner class 사용, 리스너 등록 후 미해제, LiveData/RxJava 구독 해제 누락 등이 있습니다. 해결 방법은 WeakReference 사용, onDestroy에서 명시적 해제, ViewModel 활용, Lifecycle-aware 컴포넌트 사용 등입니다. 재발 방지를 위해 CI/CD 파이프라인에 LeakCanary 자동 테스트를 추가하고, 코드 리뷰 체크리스트에 생명주기 관리 항목을 포함시킵니다.
- • LeakCanary와 Profiler를 활용한 체계적인 진단 프로세스
- • Android에서 메모리 누수가 발생하는 대표적인 패턴 이해
- • WeakReference, Lifecycle-aware 컴포넌트 등 구체적인 해결 방법
- • 재발 방지를 위한 자동화 및 프로세스 개선
장시간 실행되는 앱이나 복잡한 화면 전환이 많은 앱에서 메모리 누수는 사용자 경험을 크게 저하시키는 주요 원인입니다.
ViewModel을 사용하면 메모리 누수를 완전히 방지할 수 있나요? ViewModel 자체에서 메모리 누수가 발생할 수 있는 경우는 어떤 것이 있을까요?
Q. 사용자들로부터 특정 API 호출이 간헐적으로 실패한다는 제보가 들어왔습니다. 서버팀에서는 문제가 없다고 하고, 로그를 확인해보니 일부 기기에서만 발생하며 재현이 어렵습니다. Retrofit을 사용하고 있고, OkHttp 인터셉터 로그에는 IOException: unexpected end of stream이 나타납니다. 이 문제를 어떻게 분석하고 해결하시겠습니까?
네트워크 연결 상태 변화, HTTP/2 프로토콜 특성, 그리고 연결 풀 관리를 중심으로 생각해보세요.
unexpected end of stream 에러는 주로 연결이 재사용될 때 서버 측에서 이미 연결을 닫았지만 클라이언트는 아직 유효하다고 판단하는 경우 발생합니다. 먼저 OkHttp의 ConnectionPool 설정을 확인하고, keepAlive 시간과 서버의 타임아웃 설정이 일치하는지 점검합니다. Firebase Crashlytics나 Sentry에 네트워크 환경 정보(WiFi/모바일, 통신사)를 함께 로깅하여 패턴을 찾습니다. 해결 방법으로는 Retry 메커니즘 구현, ConnectionPool의 keepAliveDuration 조정, HTTP/1.1로 프로토콜 다운그레이드 테스트, eventListener를 통한 상세 연결 로깅 추가 등이 있습니다. 또한 네트워크 전환 시점에 기존 연결을 명시적으로 정리하는 로직을 추가하고, 앱이 백그라운드에서 포그라운드로 전환될 때 연결 상태를 검증합니다.
- • unexpected end of stream 에러의 원인과 발생 조건 이해
- • OkHttp ConnectionPool과 keepAlive 메커니즘에 대한 지식
- • 재현이 어려운 버그를 위한 체계적인 로깅 전략
- • 네트워크 상태 변화에 대한 방어적 프로그래밍
모바일 네트워크 환경의 불안정성과 다양한 기기 특성으로 인해 간헐적 네트워크 오류는 실무에서 자주 마주치는 문제입니다.
Retrofit에서 자동 재시도를 구현할 때 멱등성이 보장되지 않는 POST 요청은 어떻게 처리해야 할까요?
Q. RecyclerView를 사용하는 피드 화면에서 스크롤할 때 버벅거림이 발생한다는 이슈가 제기되었습니다. Systrace를 통해 확인한 결과 onBindViewHolder에서 프레임 드롭이 발생하고 있습니다. 어떤 항목들을 점검하고 최적화하시겠습니까? 그리고 최적화 후 개선 효과를 어떻게 측정하시겠습니까?
onBindViewHolder는 메인 스레드에서 실행되므로 무거운 작업이 있는지, 그리고 뷰 재사용이 제대로 되고 있는지 확인해보세요.
먼저 onBindViewHolder 내부에서 findViewById 대신 ViewBinding을 사용하는지, 복잡한 계산이나 문자열 포맷팅이 있는지 확인합니다. 이미지 로딩 시 Glide나 Coil의 placeholder와 캐싱이 적절히 설정되어 있는지, 중첩된 RecyclerView가 있다면 RecycledViewPool을 공유하고 있는지 점검합니다. ViewHolder 내부에서 불필요한 뷰 초기화나 리스너 재설정이 반복되지 않도록 개선하고, DiffUtil을 사용해 변경된 아이템만 업데이트되도록 합니다. 측정은 Android Studio Profiler의 Frame Rendering 그래프로 16ms 기준 프레임 드롭 비율을 확인하고, setHasStableIds와 payload를 활용한 부분 업데이트 효과를 검증합니다. 또한 실제 사용자 기기에서 다양한 네트워크 환경과 기기 스펙으로 테스트하여 개선 효과를 정량화합니다.
- • onBindViewHolder의 성능 병목 지점 파악
- • RecyclerView 최적화 기법들(DiffUtil, ViewBinding, RecycledViewPool)
- • 이미지 로딩 최적화와 캐싱 전략
- • Systrace와 Profiler를 활용한 정량적 성능 측정
피드, 리스트 등 RecyclerView는 Android 앱의 핵심 UI 컴포넌트이므로 스크롤 성능은 사용자 경험에 직접적인 영향을 미칩니다.
RecyclerView에서 아이템 타입이 여러 개인 경우 성능 최적화를 위해 추가로 고려해야 할 사항은 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!