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
음.. 여담으로 최근 몇년사이 start-up은 대부분 Flutter, META, OpenAI같은 큰 기업들은 native로 가는 기이한 현상이 목격되고 있죠..
어쩌다가 안드로이드 앱 빌드 엔지니어로 정착하게 된 사람으로서 의견을 남긴다면..
빌드 : 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 기반입니다.