2025년에 안드로이드 앱을 만들기
(dev.to)요즘 기준의 안드로이드 앱 개발 환경 소개
- 빌드 : gradle
- 빌드 설정: convention plugin
- 의존 관리 : version catalog
- build cache 도입
- 빌드 성능 분석 : build-scan
- 모듈 구성 : feature 별 분리
- 네트워킹 - retrofit
- json 매핑 - kotlinx serialization
- 영속적 데이터 저장 - jetpack datastore, room
- DI - koin
- 이미지 로더 - coil
- UI - compose
- View 와 ViewModel 간의 커뮤니케이션 - flow
- 코드 품질 관리 - ktlint , konsist
- 단위 테스트 - junit 4
어쩌다가 안드로이드 앱 빌드 엔지니어로 정착하게 된 사람으로서 의견을 남긴다면..
빌드 : gradle
대단히 크거나, 복잡해도 gradle 써야합니다... (먼산)
대단히 크거나 복잡한 프로젝트에서 gradle의 빌드 성능을 개선하기 위해 아래 프로젝트들이 진행되고 있으니, 큰 프로젝트에서 gradle을 사용중이라면, 미리미리 마이그레이션 준비 해두는게 좋습니다.
- https://docs.gradle.org/current/userguide/configuration_cache.html
- https://docs.gradle.org/current/userguide/isolated_projects.html
모듈 구성 : feature 별 분리
개인적으로는 아키텍쳐 레이어를 굳이 빌드 시스템에 노출시킬 이유는 없다고 봅니다.
제가 관리하는 앱의 경우 feature-api / feature-impl 로 모듈을 빌드시스템에 노출시키도록 하고 있습니다.
- feature-app :
- 데이터 모델, 또는 다른 모듈과 연계되는 interface
- feature-impl:
- feature의 실제 구현
이렇게 구성하면, feature-impl의 코드 변경이 feature-api를 참조하는 다른 모듈에 영향을 끼치지 않기 때문에(의존성 격리), incremental build나 build cache hit rate 상승에 많은 도움이 됩니다.
단위 테스트 - junit 4
이건 구글의 결정이 큰 역할을 한 것 같습니다.
- https://issuetracker.google.com/issues/127100532
- Android Platform의 경우 JUnit3 (처럼 보이는 JUnit4), Android빌드 툴의 테스트 프레임워크는 JUnit4 기반으로 동작하는데, JUnit5로 이전할 생각없다고 Google이 못박았습니다.
그런데 최근에 출시된 screenshot testing plugin은 JUnit5 기반입니다.
그런데 최신 기술(?)을 도입하려면 JUnit4 가 발목잡는 경우가 종종 있어서, 개인적으로는 JUnit5로 이전이 되었으면 하는 자그만한 소망이 있긴합니다.
https://docs.gradle.com/develocity/test-distribution/
junit-vintage-engine 을 쓰면 큰 수정없이 junit4 테스트를 junit5에서 동작시킬 수는 있는데, 오버헤드가 상당히 큽니다. (대략 20% 정도 느려짐)
음.. 여담으로 최근 몇년사이 start-up은 대부분 Flutter, META, OpenAI같은 큰 기업들은 native로 가는 기이한 현상이 목격되고 있죠..