한달전부터 Manifest-for-android-interview라는 책으로 북 스터디를 진행하고 있다.면접 질문 모음집? 같은 느낌의 책이고, 안드로이드 전반에 걸친 질문들이 수록되어 있는 책이다.android GDE이신 sky-doves 님이 집필하신 책인데, 난이도(깊이)는 중-중상 정도 되는 것 같다. 스터디를 진행하면서 아쉬웠던 점은 책에 적혀있는 지식들로만 스터디가 진행된다는 점이였다.중소기업 면접이라면 단순히 A가 무엇인가요?라고 묻고 끝나는 경우가 많겠지만,근거 있는 기술 사용을 중요하게 여기는 대기업들의 면접을 가게 될 경우에는 작은 주제라도 꼬리 질문이 깊이 들어올 수 있기 때문에 피상적인 학습은 오히려 면접 상황에서 독이 될 수 있다. 그래서 매 스터디 회차마다 공용 리포지토리에 고민..
안드로이드 UI 대세인 컴포즈를 사용할 때에는 좀 더 스테이블한 Coil 라이브러리를 사용한다.하지만 xml을 통해 뷰 시스템을 사용하는 경우에는 캐시 성능이 뛰어난 Glide를 사용하는데, 오늘은 Glide의 디스크/메모리 캐시가 내부적으로 어떻게 구현되어 있는지에 대해 살펴보고자 한다. 우선, Glide의 캐시는 크게 메모리 캐시와 디스크 캐시로 구성되어 있다.우리는 diskCacheStrategy() 메서드를 통해 디스크 캐시 전략을, isMemoryCacheable/skipMemoryCache 메서드 등을 통해 메모리 캐시 사용 여부를 설정할 수 있다. 0. 전체 이미지 로딩 과정ActiveResources 조회MemoryCache 조회DishCache 조회네트워크/파일 로딩Glide를 통해 이미..
가변성을 활용하면 변동성이 큰 데이터에 대해 명시적이고 단순하게 처리를 할 수 있다.기존 객체를 복사하지 않고 직접 변경함으로써 불변 객체에 비해 메모리 할당이나 복사에 드는 오버헤드가 적다는 장점 또한 존재한다. 하지만 간혹 코드를 짜다보면, 가변성이 굴린 스노우볼로 인해 트러블슈팅에 애먹었던 경험들이 있을 것이다. 가변성의 이점을 취하기 위해 우리가 간과할 수 있는 문제점이 뭘까?가변성이 가지는 문제점코틀린의 구성요소들 중 일부는 상태를 가질 수 있도록 설계되어 있으며, 그 중 우리가 가장 자주 사용하게 되는 건 가변 프로퍼티나 MutableList, MutableSet, MutableMap 등이 있다.사용자는 이를 통해 가변성을 활용할 수 있는데, 여기서 문제는 이 가변성을 어떻게 활용하느냐에 따라..
p.s 이 글에서 R8과 R8 컴파일러는 같은 것을 지칭하며, D8과 R8은 친구지만 서로 다른 개념입니다.코틀린 코드는 코틀린 컴파일러를 통해 바이트코드로 컴파일되며, 이 바이트 코드를 R8 컴파일러가 최적화하고 D8 컴파일러가 DEX 파일로 변환한다.이후 앱 실행시에 AOT나 JIT 컴파일을 통해 네이티브 코드로 변환되어 실행되는 원리이다.Proguard나 R8은 개발자가 설정 파일 외에는 추가적으로 설정해야하는 것들이 적어서 Proguard나 R8의 차이점이나 변경점을 모르는 경우가 많다.실 개발 단계에서도 안드로이드 개발자들은 각 라이브러리나 Kotlin 프로젝트에 필요한 Proguard 설정을 제외하고는 구체적으로 알아볼 필요성을 느끼지 못한다. 많은 라이브러리들이 정상적인 동작을 위해, 난독화..
1. Drawable안드로이드의 Drawable API는 화면에 그래픽을 그리기 위한 추상화된 계층을 제공한다.Drawable은 BitmapDrawable, VectorDrawable , NinePatchDrawable , ShapeDrawable 등의 다양한 구현체들이 존재한다.지난 포스팅에서 Bitmap Drawable의 densityDpi별 대응을 위해 밀도별 스케일 펙터를 적용한 Bitmap을 사용한다고 했는데, 왜 사진이나 복잡한 이미지는 Vector Drawable로 사용하지 않는 지 의문이 들었다. 2. VectorDrawable주로 애플리케이션에서 사용하는 로고, 아이콘에 사용되는 Drawable 구현체이다.앞선 포스팅에서는 밀도 별 버전을 만들어서 해상도 별로 대응을 한다고 했는데, Ve..
안드로이드 스튜디오를 레이디버그 피쳐 드롭으로 업데이트한 이후에 갑자기 이런 오류가 발생했다.관련해서 국내 개발자들의 정보는 아예 없었고, 같은 증상이 발생한 외국인들의 토론 글이 있었지만 유용한 해결책은 찾을 수 없었다.다행히도 매번 invalidate cache하면 일시적으로 발생하지 않아서 그걸 반복하며 사이드 프로젝트를 개발하고 있었다. 그러다 이제는 이 비효율적인 프로세스를 먼저 해결하고 개발을 이어나가고자 여러 설정을 확인해봤는데,(1) compileSdk 버전도 변경하지 않았고(2) 현재 사용중인 버전의 AGP와 JDK의 조합은 문제 없이 잘 사용해오던 조합이였고(3) invalidate cache, build clean 등모든 방법을 다 해봤지만 일시적일 뿐, 완벽하게 해결되지 않았다. ..
1.Throwable과 Exception, ErrorThrowable은 예외와 오류의 최상위 클래스이다.예외와 오류의 차이점은 복구 가능성으로, 예외에 대해서는 개발자가 적절한 처리를 통해 정상적인 실행을 유지할 수 있으나 오류는 그렇지 않다. 이 때문에 이 둘을 구분하여 개발자가 핸들링할 수 없는 오류에 대해서는 처리를 하지 않도록 설계되었다. 2. Kotlin에는 checked exception이 없다Java에서는 RuntimeException의 서브클래스가 아닌 Exception들을 checked exception이라 부르며, 이에 대한 처리를 컴파일러 수준에서 강제한다. 하지만 Kotlin은 Jvm 기반으로 설계되었음에도 checked exception을 지원하지 않는데, 그 이유가 뭘까?💡Ko..
1. Dalvik과 ART안드로이드에서 사용하는 Dalvik과 ART(Android runtime)은 바이트 코드를 네이티브 코드로 변환하는 런타임이다.Dalvik의 JIT 컴파일 방식은 앱 실행 시마다 바이트코드를 해석하기 때문에 메모리 사용량이 높고 실행 속도가 느리다는 단점이 있고, GC도 모바일 환경에 최적화되어 있지 않아 구글은 이를 개선하기 위해 ART를 도입하게 된다.ART의 AOT 컴파일 방식은 설치 시에 미리 네이티브 코드로 변환하고 디스크에 저장한 후 실행 시에 저장된 네이티브 코드를 메모리에 로드해 실행함으로써 실행 속도를 개선하고, GC 메커니즘 또한 모바일 환경에 적합하도록 개선되었다. 2. Dalvik GC의 문제점Android 5.0 이전까지 사용된 Dalvik의 GC 메커니즘..
0. 개요안드로이드 면접에서 나오는 단골 질문들 중 하나인 "화면 회전 시에 어떻게 되고, ViewModel을 사용하면 어떤 이점이 있나요?"를 많이 들어봤을 것이다.대부분의 기술 블로그에서는 "ViewModel이 Fragment/Activity와 독립적인 생명주기를 가져서 재생성 시에도 데이터를 유지할 수 있습니다"라고 설명하고 있다.오늘의 포스팅은 "과연 독립적인 생명주기 때문이라는 설명이 적절할까?"는 의문에서 출발한다. 1. ViewModel과 친구들(1) ViewModelStoreViewModel 인스턴스들을 저장하는 컨테이너이다. ViewModelProvider가 이를 활용하여 존재하는 ViewModel이 있으면 재사용하고, 없으면 새로 생성하여 저장한다. (2) ViewModelStoreOw..
✔️ Gson을 Moshi로 마이그레이션하기로 결정한 이유지금까지 Json 직렬화 라이브러리로 Gson을 사용해 왔는데, 되돌아보니 Gson을 선택한 이유가 없었다.그냥 다들 Gson을 사용한다니까 사용했던 것 같아서, 다른 라이브러리들과의 비교를 통해 Moshi로 마이그레이션 하기로 결정했다.Gson / Moshi / Jackson을 비교했고, 그 중에서 (1) Kotlin 호환성 (2) 라이브러리 지속성 (3) 런타임 퍼포먼스위 세 가지를 주요 비교점으로 두었다.Retrofit의 개발사인 Square사의 라이브러리이며, 셋 중 Kotiln 호환성이 가장 뛰어나고, 런타임 퍼포먼스가 높은 Moshi로 결정하게 되었다. ✔️ Moshi 란?Square에서 개발한 경량 Json 라이브러리이다.Kotlin ..
