# Support Library

# Support Library의 필요성

구글에서는 Android API의 하위 호환성 문제를 해결하기 위해 Support Library를 만들었습니다. 예를들어 롤리팝(API 21)부터 도입된 RecyclerView는 API 21 이하의 기기에서는 사용할 수 없지만 다음 서포트 라이브러리를 추가하면 API 7 이상의 기기부터 RecyclerView를 사용할 수 있습니다.

1

com.android.support:recyclerview-v7:28.0.0

com.android.support로 시작하는 서포트 라이브러리는 수많은 종류가 준비되어 있습니다. 이중에는 v4, v7, v13 등 v가 붙은 패키지들이 있는데요, 이것들은 각각 사용가능한 최소 API 레벨을 의미합니다. 예를들어 v4가 붙어있으면 API 레벨 4부터 이용할 수 있는 라이브러리라는 의미이지요.

# Support Library의 문제점

그런데 Support Library에는 몇가지 문제점이 있었습니다.

• 최소지원 API레벨 문제 구글은 2017년 Google I/O 세션인 What’s new in Android Support Library에서 Support Library version 26.0.0 부터는 최소지원 API 레벨을 Android 4.0 (API level 14)으로 올리겠다는 발표를 합니다. 너무 오래된 기종들의 사용을 막기 위해 취한 조치이긴 하나, 이로인해 라이브러리 이름에 v7이 붙어있어도 최소지원 API 레벨은 14인 이상한 현상이 발생하게 된 것입니다.

• 필요없는 라이브러리의 추가 Support Library는 수많은 API들을 통합한 라이브러리이기 때문에 내가 사용하지 않는 기능도 같이 앱에 포함되게 됩니다. 단일 DEX가 65,536 개의 메소드만을 가질 수 있는 Dalvik 체계에서 서포트 라이브러리때문에 멀티DEX를 사용해야 하는 경우가 생길 수도 있습니다.

• 버전통일 문제 복수개의 서포트 라이브러리를 사용하는 경우 모든 버전을 동일하게 유지해야 합니다. 예를들어 다음과 같이 라이브러리를 사용중에 cardview에 문제가 있어서 27.1.0으로 버전을 내릴 경우 다른 라이브러리도 모두 27.1.0으로 내려야 하는 것이죠.

1
2
3

implementation com.android.support:appcompat-v7:27.1.1
implementation com.android.support:design:27.1.1
implementation com.android.support:cardview-v7:27.1.1

# Androidx 체계의 도입

이러한 이름체계의 혼란을 정리하기 위해 구글은 2018년 Google I/O 세션인 Android Jetpack: What’s new in Android Support Library에서 라이브러리 패키징방식의 변경을 발표합니다. 봄맞이 대청소를 통해 Android Extension Libraries라는 명칭으로 바뀐 서포트 라이브러리는 androidx라는 네임스페이스를 부여받게 되었고 다음과 같은 원칙하에 요소들을 관리하게 됩니다.

# 1. 라이브러리의 기능별 분리

발표에 따르면 support-core-ui는 asynclayoutinflater, drawerlayout, interpolator, cursoradapter, customview, slideingpanellayout, swiperefreshlayout, viewpager 등으로 쪼개집니다. 따라서 viewpager가 필요하면 쓰지도 않는 나머지 dependency를 모두 임포트할 필요 없이 viewpager를 바로 임포트하면 됩니다.

# 2. Versioning 방식 변경

API 레벨과 동기화되어 올라가던 Versioning 방식은 28.0.0 부터 1.0.0으로 리셋되고 Major.Minor.Patch 형식의 엄격한 Semantic Versioning을 준수하게 됩니다. 버전으로부터 Patch는 버그픽스이고, Minor는 기능추가, Major는 바이너리의 호환성이 없다는 사실을 이제 명확하게 파악할 수 있습니다.

라이브러리 전체의 변경이 아닌 아티팩트당 버전 변경이 이루어지게 되므로 예를들어 RecyclerView의 업데이트가 이루어지면 RecyclerView 패키지만을 개별적으로 업데이트할 수 있습니다.

# 3. 패키징 방식 변경

android.support.v7.app 과 같은 이름을 가져서, 어떤 기능이 포함되어 있는지 알 수 없었던 기존 Support library의 문제점을 개선하기 위해, 패키지 이름은 기능을 직관적으로 나타내도록 변경되었습니다.

• Java Package : androidx.<feature>.ClassName
• Maven id : androidx.<feature>:<feature>-<sub-feature>

변화된 Java package와 Maven artifact의 리스트는 각각 Class Mappings와 Artifact Mappings 문서에서 확인할 수 있습니다.

Androidx의 최신 릴리즈 내용은 AndroidX releases에서 확인할 수 있고 각 릴리즈 노트는 Recent Release Notes에 정리하고 있습니다. 그리고 각 릴리즈의 개별 커밋은 Github에서 확인할 수 있습니다.

# Android Jetpack

그리고 Androidx를 소개했던 세션에서 Jetpack도 같이 발표됩니다.

Jetpack is a suite of libraries to help developers follow best practices, reduce boilerplate code, and write code that works consistently across Android versions and devices so that developers can focus on the code they care about.

Jetpack은 한마디로 안드로이드 앱을 더 완성도 높게 만들 수 있는 라이브러리의 모음입니다. 주로 androidx의 라이브러리가 포함되지만 androidx가 아닌 라이브러리가 포함될 수도 있습니다.

같은 기능을 구현하더라도 개발자의 숙련도에 따라 앱의 안정성이 달라지는 현상을 가능한 줄이기 위해 구글에서 가이드라인을 만들었고 그 가이드라인에 따르기 위해 사용해야할 라이브러리를 정의한 문서스펙이라고 생각하시면 좋을 것 같습니다.

Jetpack은 Architecture, UI, Behavior, Foundation 의 네 가지 카테고리로 구성되어 있고 각 카테고리는 그림에 보이는 것과 같은 컴포넌트들이 해당됩니다. 각 컴포넌트는 개별적으로 앱에서 사용 가능하고 이전 버전과 호환성을 유지할 수 있게 구성되었는데요, Introducing Android Jetpack for developers에 따르면 Jetpack은 다음과 같은 특징을 갖는다고 하네요.

• Modern App Architecture
• Eliminate Boiler Plate Code
• Simplifying Complex Tasks
• Robust Backwards Compatibility

그림에 표시한 것 외에도 Jetpack에는 수많은 컴포넌트들이 있는데 이들의 전체 리스트와 각각의 기능은 Explore the Jetpack libraries에서 확인하실 수 있습니다.

이렇게 해서 Support library와 Androidx와 Jetpack에 대해 알아보았습니다.