Students Save 30%! Learn & create with unlimited courses & creative assets Students Save 30%! Save Now
Advertisement
  1. Code
  2. Android SDK
Code

안드로이드 아키텍처 구성 요소 소개

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Android Architecture Components.
Android Architecture Components: Lifecycle and LiveModel

Korean (한국어) translation by h1ghqlty. (you can also view the original English article)

안드로이드는 2005년에 전 세계에 소개되었으며 12년 동안 플랫폼은 놀라운 성공을 거두어 가장 많이 설치된 모바일 OS가되었습니다. 그 시간 동안 14가지 버전의 운영 체제가 출시되었으며 안드로이드는 더욱 성숙해졌습니다. 그러나 플랫폼의 매우 중요한 영역인 플랫폼 특성을 처리할 수 있는 표준 아키텍처 패턴과 평균 개발자가 이해하고 채택할 수 있을만큼 단순한 플랫폼은 계속 무시되었습니다.

음, 결코 늦지 않는 것이 좋습니다. 마지막으로 Google I/O에서 안드로이드 팀은 이 문제를 해결하고 전 세계 개발자의 의견에 응답하여 안드로이드 애플리케이션 아키텍처에 대한 공식 권장 사항을 발표하고 이를 구현할 빌딩 블록을 제공하기로 결정했습니다. 새로운 아키텍처 구성 요소. 그리고 더 나은 아직, 그들은 우리 모두가 알고 사랑하는 시스템의 개방성을 손상시키지 않고 그것을 할 수 있었습니다.

Architecture Components

이 튜토리얼에서는 Google I/O에서 안드로이드 팀이 제안한 표준화 된 아키텍처를 살펴보고 Lifecycle, ViewModel, LifeDataRoom과 같은 새로운 아키텍처 구성 요소의 주요 요소를 살펴 보겠습니다. 이 주제에 대한 개념과 논리에 초점을 맞추지 않고 코드에 너무 많은 관심을 기울이지는 않을 것입니다. 또한 안드로이드에서 공식적으로 지원되는 놀라운 언어 인 Kotlin을 사용하여 작성된 간단한 스니펫을 살펴 봅니다.

1. 안드로이드가 놓친 것은 무었이었습니까?

개발자로서 여행을 시작하는 중이라면, 내가 말하는 것에 대해 정확히 알지 못할 수도 있습니다. 결국 응용 프로그램 아키텍처는 처음에는 모호한 주제가 될 수 있습니다. 그러나 저를 믿으십시오, 당신은 그것의 중요성을 충분히 빨리 배울 것이다! 응용 프로그램이 커지고 복잡해지면 아키텍처가 점점 더 중요해질 것입니다. 그것은 문자 그대로 당신의 일을 행복이나 살아있는 지옥으로 만들 수 있습니다.

응용 프로그램 아키텍처

대략적으로 말해서, 애플리케이션 아키텍처는 개발 프로세스가 시작되기 전에 일관성있는 계획을 세워야합니다. 이 계획은 서로 다른 응용 프로그램 구성 요소를 구성하고 함께 묶어야하는 방법에 대한 맵을 제공합니다. 개발 과정에서 따라야하는 지침을 제시하고 결국에는 더 많은 테스트와 확장 및 유지 보수가 가능한 잘 작성된 응용 프로그램을 작성하는 데 도움이되는 (일반적으로 더 많은 클래스와 상용구와 관련된) 희생을 강요합니다.

소프트웨어 응용 프로그램 아키텍처는 모든 기술 및 운영 요구 사항을 충족하면서 성능, 보안 및 관리 효율성과 같은 일반적인 품질 특성을 최적화하는 구조화 된 솔루션을 정의하는 프로세스입니다. 여기에는 광범위한 요소를 기반으로 한 일련의 결정이 포함되며, 이러한 각각의 결정은 애플리케이션의 품질, 성능, 유지 보수성 및 전반적인 성공에 상당한 영향을 줄 수 있습니다.
- Microsoft의 소프트웨어 아키텍처 및 디자인 가이드

좋은 아키텍처는 여러 요소, 특히 시스템 특성 및 한계를 고려합니다. 많은 다른 건축 솔루션이 있습니다. 모두 장단점이 있습니다. 그러나 몇 가지 핵심 컨셉은 모든 비전간에 공통적입니다.

오래된 실수

마지막 Google I/O가 있기 전까지는 안드로으디 시스템에서 애플리케이션 개발을 위한 특정 아키텍처를 권장하지 않았습니다. 즉 MVP, MVC, MVPP 또는 전혀 패턴이 없는 모델을 자유롭게 채택할 수 있습니다. 게다가 안드로이드 프레임 워크는 시스템 자체, 특히 구성 요소의 수명주기에서 생성된 문제에 대한 고유 솔루션을 제공하지 않았습니다.

Great news at the Google IO 2017

따라서 응용 프로그램에서 Model View Presenter 패턴을 채택하려는 경우 자신 만의 솔루션을 처음부터 마련하거나, 많은 상용구 코드를 작성하거나, 공식적인 지원없이 라이브러리를 채택해야 했습니다. 그리고 표준이 없다면 유지 관리 및 테스트하기 어려운 코드베이스를 사용하여 제대로 작성되지 않은 응용 프로그램이 많이 생성되었습니다.

내가 말했듯이, 이 상황은 수년간 비난을 받아 왔습니다. 사실, 나는 최근에이 문제에 대해 썼습니다. 안드로이드 시리즈에서 Model View Presenter를 채택하는 방법에서 이 문제를 어떻게 다룰 것인가에 대해서 말이죠. 그러나 중요한 것은 12년이 지난 후에 안드로이드 팀이 마침내 불만 사항을 듣고 이 문제를 해결하기로 결정했습니다.

2. 안드로이드 아키텍처

새로운 안드로이드 아키텍처 가이드는 좋은 안드로이드 애플리케이션이 준수해야 하는 몇 가지 핵심 원칙을 정의하고 개발자가 훌륭한 앱을 만들 수있는 안전한 경로를 제안합니다. 그러나 가이드는 명시된 루트가 의무 사항은 아니며 궁극적으로 결정은 개인적인 것이라고 명시합니다. 채택 할 아키텍처 유형을 결정해야 하는것은 개발자입니다.

가이드에 따르면, 좋은 안드로이드 애플리케이션은 견고한 분리를 제공하고 UI에서 모델을 유도해야합니다. UI 또는 운영 체제 상호 작용을 처리하지 않는 코드는 Activity 또는 Fragment에 없어야 합니다. 가능한 한 깨끗하게 유지하면 많은 라이프 사이클 관련 문제를 피할 수 있습니다. 결국 시스템은 언제든지 활동이나 단편을 파괴할 수 있습니다. 또한 UI에서 격리된 모델로 데이터를 처리해야 하므로 결과적으로 라이프 사이클 문제가 발생합니다.

새로운 권장 아키텍처

안드로이드가 권장하는 아키텍처는 우리가 알고있는 표준 패턴 중에서 쉽게 분류할 수 없습니다. Model View Controller 패턴처럼 보이지만 시스템 아키텍처와 밀접하게 연결되어 있으므로 알려진 규칙을 사용하여 각 요소에 레이블을 지정하기가 어렵습니다. 중요한 것은 새로운 아키텍처 구성 요소를 사용하여 뛰어난 테스트 가능성과 유지 관리 가능성을 제공하는 것입니다. 그리고 더 나은 방법은 구현하기 쉽습니다.

안드로이드 팀이 제안하고 있는 것을 이해하기 위해, 우리는 구조 구성 요소의 모든 요소를 ​​알아야합니다. 왜냐하면 그것들은 우리를 위해 무거울 것입니다. Room, ViewModel, LiveDataLifecycle의 4가지 구성 요소가 있습니다. 이러한 모든 부분에는 고유한 책임이 있으며, 함께 협력하여 견고한 아키텍처를 만듭니다. 더 잘 이해하기 위해 제안된 아키텍처의 단순화 된 다이어그램을 살펴 보겠습니다.

Android Architecture

보시다시피 세 가지 주요 요소가 있으며 각 요소는 책임이 있습니다.

  1. ActivityFragment는 비즈니스 로직 및 복잡한 작업을 다루지 않는 View 레이어를 나타냅니다. 뷰를 구성하고 사용자 상호 작용을 처리하며 가장 중요한 것은 ViewModel에서 가져온 LiveData 요소를 관찰하고 표시합니다.
  2. ViewModel은 구성 변경 및 기타 안드로이드 Lifecycle이벤트 동안 일관성을 유지하면서 뷰의 라이프 사이클 상태를 자동으로 관찰합니다. 또한 뷰에 의해 관찰 가능한 LiveData로 제공되는 Repository에서 데이터를 가져오는 것이 요구됩니다. ViewModel은 View를 직접 참조하지 않으며 데이터의 업데이트는 항상 LiveData 실재에 의해 수행된다는 것을 이해하는 것이 중요합니다.
  3. Repository는 특별한 안드로이드 구성 요소가 아닙니다. 특정 구현없이 간단한 클래스이며 데이터베이스에서 웹 서비스에 이르는 모든 사용 가능한 소스의 데이터를 가져옵니다. 이 모든 데이터를 처리하여 일반적으로 관찰 가능한 LiveData로 변환하여 ViewModel에서 사용할 수 있도록 합니다.
  4. Room 데이터베이스는 SQLite 매핑 라이브러리로서 데이터베이스 처리 프로세스를 용이하게 합니다. 자동으로 많은양의 상용구를 작성하고 컴파일 타임에 오류를 검사하며, 무엇보다 중요한 것은 관찰 가능한 LiveData가있는 쿼리를 직접 반환할 수 있다는 것입니다.

나는 당신이 우리가 관측 가능한 것들에 대해 많이 이야기한 것을 알아 차렸을 것입니다. 옵저버 패턴LiveData 요소 및 Lifecycle 인식 구성 요소의 기반 중 하나입니다. 이 패턴을 사용하면 객체가 관찰자 목록에 상태 나 데이터의 변경 사항을 알릴 수 있습니다. 따라서 Activity가 LiveData 의 실재를 관찰하면 해당 데이터가 어떤 종류의 수정을 거칠때 업데이트를 수신하게 됩니다.

또 다른 안드로이드 권장 사항은 Google의 Dagger 2와 같은 Dependency Injection 시스템을 사용하거나 DI보다 간단하지만 장점이없는 Service Locator 패턴을 사용하여 아키텍처를 통합하는 것입니다. 이 튜토리얼에서는 DI 또는 Service Locator에 대해서는 다루지 않지만 Envato Tuts+에는 이러한 주제에 대한 훌륭한 자습서가 있습니다. 그러나이 시리즈의 두 번째 부분에서 설명 할 Dagger 2 및 안드로이드 구성 요소를 사용하는 데에는 몇 가지 특수성이 있습니다.

3. 아키텍처 구성 요소

우리는 이 아키텍처 모델을 실제로 이해하고 채택할 수 있도록 새로운 구성 요소의 측면을 깊이 파고 들어야합니다. 그러나 이 튜토리얼에서는 모든 세부 사항을 다루지 않을 것입니다. 이 튜토리얼에서는 각 요소의 복잡성으로 인해 각 요소의 일반적인 개념에 대해서만 설명하고 간단한 코드 스니펫을 살펴 보겠습니다. 우리는 구성 요소를 제시하고 시작하도록 충분한 근거를 다룰 것입니다. 하지만 이 시리즈의 향후 기사에서는 아키텍처 구성 요소의 모든 특수성을 다룰 것이므로 두려워하지 않아야 합니다.

라이프 사이클-인식 구성 요소

대부분의 안드로이드 앱 구성 요소에는 시스템에 직접 관리되는 라이프 사이클이 첨부되어 있습니다. 최근까지는 개발자가 구성 요소의 상태를 모니터링 하고 이에 따라 조치를 취하고 적절한 시기에 작업을 초기화하고 종료하는 것이 개발자의 몫이었습니다. 그러나 이 유형의 작업과 관련하여 혼란스러워 실수를 하는 것은 정말 쉽습니다. 그러나 android.arch.lifecycle 패키지가 이 모든 것을 변경했습니다.

이제 Activity 및 Fragments에는 LifecycleObserver 클래스에서 볼 수있는 Lifecycle 객체(예 : ViewModel 또는 이 인터페이스를 구현하는 객체)가 첨부되어 있습니다. 이는 관찰자가 활동이 일시 중지되거나 시작될 때와 같이 관찰중인 객체의 상태 변화에 대한 업데이트를 수신한다는 것을 의미합니다. 또한 관찰된 객체의 현재 상태를 확인할 수 있습니다. 따라서 프레임 워크 라이프 사이클을 고려해야하는 작업을 처리하는 것이 훨씬 쉽습니다.

LifecycleObserver reacts to LifecycleEvents

지금은이 새로운 표준을 준수하는 Activity 또는 Fragment을 작성하려면 LifecycleActivity 또는 LifecycleFragment를 확장해야 합니다. 그러나 안드로이드 팀이 이러한 새로운 도구를 프레임 워크와 완전히 통합하기 위해 항상 필요한 것은 아니기 때문일 수 있습니다.

LifecycleObserver는 Lifecycle 이벤트를 수신하고 주석을 통해 대응할 수 있습니다. 메소드 대체는 필요하지 않습니다.

LiveData 구성 요소

LiveData 구성 요소는 관찰할 수 있는 값을 포함하는 데이터 홀더입니다. 관찰자가 LiveData 인스턴스화 중 Lifecycle을 제공 한 경우 LiveData는 Lifecycle 상태에 따라 작동합니다. 관찰자의 Lifecycle 상태가 STARTED 또는 RESUMED이면 관찰자가 active 상태입니다. 그렇지 않으면 inactive 상태입니다.

LiveData는 데이터가 변경된 시기와 관찰자가 active 되어 있고 업데이트를 받아야 하는지 알고 있습니다. LiveData의 또 다른 흥미로운 특징은 관찰자가 Lifecycle.State.DESTROYED 상태에 있는 경우 관찰자를 제거할 수 있다는 것입니다. 이는 활동 및 조각에서 관찰할 때 메모리 누수를 방지합니다.

LiveData value updating process

LiveDataonActiveonInactive 메소드를 구현해야 합니다.

LiveData 구성 요소를 관찰하려면 observer(LifecycleOwner, Observer<T>)를 호출해야 합니다.

ViewModel 구성 요소

새로운 아키텍처 구성 요소 중 가장 중요한 클래스 중 하나인 ViewModel은 UI와 관련된 데이터를 보유하고 화면 회전과 같은 구성 변경 중에 무결성을 유지하도록 설계되었습니다. ViewModelRepository와 대화하고 LiveData를 가져와 뷰에서 볼 수 있도록 사용할 수 있게합니다. ViewModel은 구성 변경 후 Repository를 새로 호출 할 필요가 없으므로 코드가 많이 최적화됩니다.

ViewModel is tight to UI Lifecycle

뷰 모델을 만들려면 ViewModel 클래스를 확장합니다.

뷰에서 액세스하려면 ViewProviders.of(Activity|Fragment) .get (ViewModel::class)를 호출할 수 있습니다. 이 팩토리 메서드는, ViewModel의 새로운 인스턴스를 돌려 주거나, 보존된 인스턴스를 적절히 가져옵니다.

Room 구성 요소

안드로이드는 처음부터 SQLite를 지원했습니다; 그러나 작동 시키려면 많은 상용구를 작성해야 했습니다. 또한 SQLite는 POJO (평범한 Java 객체)를 저장하지 않았으며 컴파일 타임에 쿼리를 확인하지 않았습니다. 함께 이 문제를 해결하는 Room이 옵니다! Java POJO를 유지하고, 쿼리를 객체로 직접 변환하고, 컴파일 타임에 오류를 확인하고, 쿼리 결과에서 LiveData 관측 값을 생성할 수 있는 SQLite 매핑 라이브러리입니다. Room은 멋진 안드로이드 용 부가 기능이 포함된 객체 관계 매핑 라이브러리입니다.

지금까지 다른 ORM 안드로이드 라이브러리를 사용할 수있는 Room의 대부분을 수행 할 수있었습니다. 그러나 이들 중 어느 것도 공식적으로 지원되지 않으며 가장 중요한 것은 LifeData 결과를 산출할 수 없다는 것입니다. Room 라이브러리는 제안된 안드로이드 아키텍처의 영구 레이어로 완벽하게 들어 맞습니다.

Room 데이터베이스를 만들려면 Java POJO, 쿼리 및 입출력 작업을 수행하는 @Dao 인터페이스, RoomDatabase를 확장해야 하는 @Database 추상 클래스가 될 수 있는 @Entity가 필요합니다.

프로젝트에 아키텍처 구성 요소 추가하기

지금은 새로운 아키텍처 구성 요소를 사용하려면 먼저 build.gradle 파일에 Google 저장소를 추가해야 합니다. 자세한 내용은 공식 가이드를 참조하십시오.

결론

보시다시피 안드로이드가 제안한 표준화된 아키텍처 에는 많은 개념이 포함되어 있습니다. 이 주제에 대한 완전한 이해를 아직 기대하지 마십시오. 결국, 우리는 테마를 소개하는 것일 뿐입니다.그러나 아키텍처의 논리와 다양한 아키텍처 구성 요소의 역할을 이해하려면 충분한 지식이 있어야 합니다.

제안된 안드로이드 아키텍처 및 해당 구성 요소와 관련된 대부분의 주제에 대해 이야기했습니다. 그러나 Repository 클래스 및 Dagger 2 시스템과 같이 구성 요소 구현 및 일부 추가 기능에 대한 세부 정보는 이 첫 번째 부분에서 다룰 수 없습니다. 우리는 다음 포스트에서 이러한 주제를 탐구할 것입니다.

곧 봅시다!

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.