안녕하세요 오늘은 AAC(Android Architecture Components)에 대해 포스팅 해보려고 합니다.
먼저 간단하게 AAC란 2017년도에 발표한 안드로이드 앱의 아키텍처를 구축하고 관리하기 위한 라이브러리의 모음입니다.

AAC는 총 8개의 구성 요소로 이루어져있습니다.
각 구성 요소들에 대해서 간단하게 정리 하자면
Lifecycles는 라이브러리 이름을 보며 유추하셧겠지만 앱의 컴포넌트의 라이프사이클을 관리하기 위한 라이브러리입니다. 앱의 컴포넌트의 상태 변화에 따라 작업을 수행하고, 수명 주기 관련 문제를 처리하는데 도움을 줍니다.
LifecycleOwner는 액티비티나 프래그먼트와 같은 수명 주기를 가진 컴포넌트를 나타냅니다. 'getLifecycle()' 메서드를 구현하여 Lifecycle 객체를 반환해야 합니다.
class MyLifecycleOwner : LifecycleOwner {
private val lifecycle = LifecycleRegistry(this)
fun start() {
lifecycle.handleLifecycleEvent(Lifecycle.Event.ON_START)
}
fun stop() {
lifecycle.handleLifecycleEvent(Lifecycle.Event.ON_STOP)
}
fun destroy() {
lifecycle.handleLifecycleEvent(Lifecycle.Event.ON_DESTROY)
}
override fun getLifecycle(): Lifecycle {
return lifecycle
}
}
LifecylceObserver는 Lifecycle 이벤트에 대한 관찰자(observer) 입니다. LifecycleOwner에 연결되어 해당 수명 주기 이벤트에 대한 콜백을 수신하고, 이를 기반으로 작업을 수행할 수 있습니다.
class MyLifecycleObserver : LifecycleEventObserver {
override fun onStateChanged(source: LifecycleOwner, event: Lifecycle.Event) {
when (event) {
Lifecycle.Event.ON_START -> {
Log.d(TAG, "onStart")
}
Lifecycle.Event.ON_STOP -> {
Log.d(TAG, "onStop")
}
Lifecycle.Event.ON_DESTROY -> {
Log.d(TAG, "onDestroy")
}
else -> {
// 다른 이벤트에 대한 처리
}
}
Lifecycle.Event는 수명 주기 이벤트를 나타내는 열거형입니다.
ON_CREATE, ON_START, ON_RESUME, ON_PAUSE, ON_STOP, ON_DESTORY 등의 이벤트를 나타냅니다.
LiveData는 Observable 형태로 사용하며, 안드로이드 Lifecycle에 따라 데이터를 관리합니다.
Activity, Fragment의 라이프 사이클을 따르기에 활동에 대한 처리를 알아서 관리해줍니다.
수명주기를 인식하며, 관찰자(Observer)에게 데이터 변경을 알리고 UI갱신을 쉽게 처리할 수 있도록 도와줍니다.
LiveData의 주요 특징을 적어보겠습니다.
LiveData는 수명 주기를 인식하고, 관찰자가 활성 상태일 때만 데이터를 전달합니다. 활성 상태에서 벗어난 관찰자는 업데이트를 받지 않으며, 다시 활성 상태로 돌아올 때 최신 데이터를 받게 됩니다. 이를 통해 메모리 누수나 비정상적인 데이터 업데이트를 방지할 수 있습니다.
관찰자가 활성 상태일 때만 데이터를 전달하기 때문에 UI 업데이트를 간편하게 처리할 수 있습니다. 데이터가 변경되면 자동으로 UI를 갱신하므로, 수동으로 UI를 업데이트하는 작업을 줄일 수 있습니다.
구성 변경(화면 회전)과 같은 상황에서도 수명 주기를 인식하여 데이터를 올바르게 전달합니다.(viewModel 필요)
액티비티, 프래그먼트. 서비스 등 Android 컴포넌트 간에 데이터를 공유하기 적합합니다
한번에 여러 관찰자가 동일한 데이터를 구독할 수 있습니다.
ViewModel은 UI관련 데이터의 저장과 관리를 담당하도록 설계되었습니다.
액티비티나 프래그먼트와 같은 UI 컴포넌트와 분리되어 동작하며, 수명 주기 변화에 영향을 받지 않고 데이터를 보존할 수 있습니다.
viewModel의 주요 특징을 적어보겠습니다.
ViewModel은 수명 주기를 인식하여 데이터를 보존합니다. 액티비티나 프래그먼트가 구성 변경 등의 이유로 재생성되더라도 ViewModel은 새로 생성되지 않고 기존 인스턴스를 유지합니다.
이를 통해 데이터 유지와 UI 상태의 일관성을 유지할 수 있습니다.
UI와 관련된 데이터를 저장하고 관리합니다. 데이터를 저장하여 여러 UI 컴포넌트에서 공유할 수 있습니다. 앱 전역적으로 사용되는 데이터의 중앙 저장소 역할을 수행할 수 있습니다.
화면회전과 같은 상황에서도 데이터를 유지합니다. 이를 통해 구성 변경시에도 데이터의 재로딩이나 초기화 없이 UI를 유지할 수 있습니다.
UI와 관련된 데이터 처리와 비즈니스 로직을 분리하여 구현 가능합니다. ViewModel을 사용하여 코드의 가독성과 유지 보수성을 향상 시킬 수 있습니다.
Room은 SQLite를 기반으로한 데이터베이스 엑세스 라이브러리입니다. SQLite 데이터베이스에 대한 추상화 계층을 제공하여 개발자가 더 쉽게 데이터베이스를 관리할 수 있도록 도와줍니다.
ORM(Object-Relational Mapping)패턴을 따르고 있으며, DB의 테이블, 쿼리 ,스키마를 객체로 표현할 수 있는 기능 및 컴파일 시간 확인을 제공합니다.

Paging은 대량의 데이터를 페이지로 나누어 로드하고 표시하는데 사용되는 라이브러리입니다.
RecyclerView와 함께 사용되며, 효율적인 메모리 사용과 부드러운 스크롤 성능을 제공하여 사용자가 원활하게 데이터를 탐색할 수 있도록 도와줍니다. 데이터를 청크(chunk) 단위로 로드하여 무한 스크롤, 빠른 로딩 속도, 캐싱 및 사전 로딩과 같은 기능을 제공하빈다.
Databinding은 선언형 형식으로 Data를 UI에 바인딩하는 라이브러리입니다.
XML 레이아웃 파일에서 직접 데이터를 바인딩하고 UI를 업데이트할 수 있습니다.
Databinding을 사용하면 수동으로 작성해야 하는 코드를 줄이고, 코드의 가독성과 유지보수성을 향상 시킬 수 있습니다.
Navigation은 화면 간의 전환과 탐색을 관리하기 위한 라이브러리이빈다.
이것을 사용해 복잡한 화면 전환과 탐색 로직을 간소화하고, 일관된 사용자 경험을 제공할 수 있습니다.

주요 개념에 대해 설명해보겠습니다.
Navigation 그래프는 앱의 화면 구조와 화면 간의 관계를 시각적으로 나타내는 XML 리소스입니다. 이 그래프는 앱의 모든 화면을 포함하고, 각 화면 간의 연결 및 전환 규칙을 정의합니다.
Navigation Editor를 사용해 그래프를 시각적으로 구성할 수 있습니다.
Navigation 그래프 내의 화면을 나타내는 개념입니다. 예를 들어 액티비티, 프래그먼트 등이 Destination이 될 수 있습니다. 각 Destination은 고유한 식별자와 해당 화면에 필요한 정보를 포함합니다.
Action은 Navigation 그래프에서 한 화면에서 다른 화면으로의 전환을 정의하는 개념입니다.
예를 들어, 버튼 클릭시 다음 화면으로 이동하는 전환을 정의할 수 있습니다.
출발 Destination 과 도착 Destination 간의 연결을 나타내며, 필요에 따라 추가 정보를 전달할 수 있습니다.
NavHost는 Navigation 그래프에서 화면을 표시하는 컨테이너 역할을 수행하는 뷰입니다. 액티비티나 프래그먼트의 일부로 사용되며, 그래프 내의 현재 위치에 해당하는 화면을 표시합니다.
NavController는 Navigation 그래프를 관리하고 화면 전환을 처리하는 컨트롤러입니다. NavController를 사용하여 액션을 트리거하고, 현재 위치를 추적하며, 화면 전환을 수행할 수 있습니다. NavController는 NavHost와 함께 사용되며, 그래프 내의 화면 전환을 처리합니다.
workManager는 안드로이드 앱에서 백그라운드에서 실행되는 작업을 예약하고 관리하기 위한 라이브러리 입니다.
지속적인 작업에 권장되고 앱이 다시 시작하거나 시스템이 재부팅될 때 작업이 예약된채로 남아있으면 그 작업은 유지됩니다.
이를 통해 앱이 활성화되지 않은 상태에서도 작업을 처리할 수 있으며, 배터리 수명과 시스템 리소스를 효율적으로 관리할 수 있습니다.
대부분의 백그라운드 처리는 지속적인 작업을 통해 가장 잘 처리되므로 WorkManager는 백그라운드 처리에 권장하는 기본 API 입니다.