[안드로이드]Android support library/AndroidX/Jetpack

✅Android support library

• 안드로이드 지원 라이브러리
• Android support library는 표준 프레임워크 API(java API Framework)에서 사용할 수 없었던 손쉬운 개발 및 여러 기기에 걸친 지원을 위한 추가 편의 클래스 및 기능을 제공함하는 라이브러리 모음집이라고 생각하면됨
• Android support library의 버전에 따라 다르긴 하지만, 손쉽게 material 디자인을 사용할 수도, RecyclerView를 사용할 수도, 표준 프레임워크 API에서 제공되는 클래스의 업데이트된 버전을 사용할 수도 있게 해줌

✅Android support library의 용도

• 새로운 API에 대한 하위 호환성 - 지원 라이브러리의 많은 부분은 새로운 프레임워크 클래스 및 방식에 대한 하위 호환성을 제공합니다. 예를 들어 Fragment 지원 클래스는 Android 3.0(API 수준 11) 이전 버전을 실행하는 기기에서 프래그먼트를 지원합니다.
• 편의 및 도우미 클래스 - 이 지원 라이브러리는 다양한 도우미 클래스, 특히 사용자 인터페이스 개발용 도우미 클래스를 제공합니다. 예를 들어 RecyclerView 클래스는 Android 버전 API 수준 7 이상에서 사용할 수 있는 매우 긴 목록을 나타내고 관리하는 사용자 인터페이스 위젯을 제공합니다.
• 디버깅 및 유틸리티 - 메서드 입력에서 개선된 코드 린트 검사를 위한 support-annotations 라이브러리와 65,536개가 넘는 앱 구성 및 배포를 위한 멀티덱스 지원을 포함하여, 앱에 통합된 코드 외의 유틸리티를 제공하는 다양한 기능이 있습니다.

  가장 중요한건 이전 버전에 대한 하위 호환성 문제 해결임. 예를 들어 안드로이드 버전이 올라가면서 새로운 API가 나왔다면, 그 이전 버전에서도 새로운 API를 사용할 수 있도록 지원해줘야함.

  • EX)Fragment는 API Level 11(Android3.0)에서 표준기능으로 새롭게 추가된 뷰인데 API Level 10이하에서도 Fragment를 사용할 수 있게도와줌. 이 서포트 라이브러리가 없었다면, 코드에서 API레벨을 확인하고, API레벨 11이상인 경우와 그렇지 않은 경우를 나눠줘야 했을 것.

✅minSdk는 14 이상으로

출시 버전
implement 'com.android.support:appcompat-v7:26.1.0',
implement 'com.android.support:support-v4:26.1.0' 와 같이 v# 뒤에 출시 버전을 적어준다.

• v# 표기법 으로 지원하는 최소 API 레벨을 나타냈다고 한다.
• v4는 API Level 4 이상 기기부터 지원하고, v7는 API Level 7 이상 기기부터 서포트 패키지를 지원했다고 한다.
• implement 'com.android.support:appcompat-v7:26.1.0' 의 경우 이 서포트 라이브러리가 빌드된 API 버전을 나타낸다. 즉 당신이 사용하려고 하는 서포트라이브러리 버전이 26.1.0이라면, 이 라이브러리는 API Level 26에서 빌드해보며 만든 라이브러리이니 참고하라는 것이다.
• 이 말은 곧 당신이 API Level 26을 타겟으로 앱을 만들고 있다면, 문제없이 사용 가능하다는 것이다. 물론 API Level 26 이하, 14 이상의 기기도 하위 호환성이 어느정도 보장된다는 뜻이다.
• 다만 27 이상을 타겟으로 할 경우는 새롭게 나온 API 버전에 출시된 모든 기능과 호환될 것이라고 가정하면 안된다.
• 만약 당신이 가장 최근 API Level인 Pie(API Level 28)을 타겟으로 앱을 만들다면, 서포트 라이브러리 버전을 28.0.0 으로 바꾸는 것을 고려해보아야 할것이다.

✅AndroidX 이란?

• android.support 패키지 형태로 배포하는 버전은 빌드툴 28.0.0이 마지막.
• 그 이유는, v4, v7... 등 버전이 혼잡해질수록 호환성 문제가 발생하면서, 다양한 버전을 통합하고 자체적으로 관리하는 새로운 네임스페이스 androidx를 구성한 것임. 따라서 28 이상의 API Level부터는 모두 AndroidX 형태로 제공함.
• AndroidX는 기존에 사용 중인 com.android.support.* 라이브러리들을 하나로 통합한 것
• AndroidX는 기존의 지원 라이브러리와 마찬가지로 Android OS와는 별도로 실행되며 Android release전반에 걸쳐 이전 버전과의 호환성을 제공함
  • AndroidX의 모든 패키지는 androidX 문자열로 시작하는 일관된 네임 스페이스가 있음. 그리고 Android Support Library 패키지는 해당 androidx*패키지로 매핑되었음.
  • Android Support Library개발은 AndroidX라이브러리에서 이루어질 것.여기에는 원래 Support Library artifact유지 보수 및 새로운 jetpack구성 요소 도입이 포함됨
• 요약하면, Support Library의 문제점을 개선해서 다시 나온게 AndroidX이고, 이 AndroidX 패키지 안에는 Jetpack이 있음

  ✅지원 라이브러리의 문제점

  1. Support Library는 패키지명과 버전 규칙이 모호했다

  com.android.support:support-v4
  com.android.support:support-v13
  서포트 라이브러리는 위와 같은 패키지명을 사용했는데, v13이 v4의 기능을 포함한 상위 버전인 것 같은 느낌을 주지만사실 API레벨 13 이상에서 사용 가능이라는 뜻을 가지고 있다. 충분히 착각할 수 있는 여지를 주는 버전 규칙이었다.
  또, 스마트폰의 스펙이 상향 표준화된 요즘에는 minSdkVersion이 19 이상만 되어도 95% 이상의 기기를 지원하기 때문에 사실상 버전명에 큰 의미가 없어지게 되었다. (마지막 버전이 28인데 사실상 숫자를 증가시키는 게 더 이상 무의미...)
  더군다나 24.2.0 버전을 릴리즈하면서 v4를 사용하려면 API 레벨 14 이상이 되어야 하게 바뀌었으며 이는 v4 = API 4 레벨 이상이라는 규칙성을 상실하게 되었다.

2. 단일 라이브러리로 제공된다

서포트 라이브러리는 3만 여개의 함수를 제공하는 단일 라이브러리였다.
이게 무슨 말이냐면 난 ViewPager 기능을 사용하고 싶어서 라이브러리를 추가했는데
원치 않는 다른 라이브러리도 함께 추가된다는 뜻이다.
이게 무슨 문제를 일으켰는지 다음을 통해 알아보자.

'아냥이'앱을 만들다가 규모가 커져서 dex를 쪼갰다. (= multidex라고 함)
앱의 규모가 커지거나 라이브러리 내의 메서드가 많으면 '64K reference limit'이라는 에러를 만나게 된다. 이 에러는 dex파일이 64K를 넘어가면서 뜨는 에러이다.

안드로이드는 MainActivity.java -> MainActivity.class -> MainActivity.dex 이렇게 변환해서 사용한다.

즉, 클래스 파일이 많아질수록 dex파일의 용량도 커진다.

기본적으로 APK당 하나의 DEX파일을 사용하기 때문에 64K 이내의 용량을 사용해야 하는데 서포트 라이브러리는 이 에러가 뜨게 만드는 주원인이 되었다.
이 문제를 해결할 수 있는 multidex라는 기술이 나왔지만 여전히 단일 라이브러리는 좋은 방법이 아니라는 게 분명하다.

3. 바이너리 호환성 제약

1.1.0 버전을 이용해 개발한 앱이 있다고 치자. 기능 B가 베타 버전이었지만 문제없이 잘 돌아갔다.
1.1.1 버전이 나오고 기능 B가 정식 버전으로 나왔다고 해서 헐레벌떡 업데이트를 했다.
근데 1.1.1 버전 기능 A에 문제가 생겨서 눈물을 머금고 다시 1.1.0 버전으로 다운그레이드를 했다. 이게 단일 라이브러리의 단점이었다. 한꺼번에 업데이트하고 다운그레이드 해야 한다는 것. 이를 해결하고자 AndroidX는 위젯 단위의 세분화된 형태로 모듈화 해서 라이브러리를 제공하게 되었다.

✅Jetpack 이란?

• 위처럼 안드로이드 지원 라이브러리의 문제점때문에 AndroidX가 나왔고 이 AndroidX 패키지를 포함하는 라이브러리 모음집이 Jetpack임
• 즉, Jetpack에 포함되는 라이브러리들은 androidX*라는 이름으로 패키지화되어있고 안드로이드 플랫폼 API로부터 분리되어있음
• Jetpack은 androidx.* 패키지 라이브러리로 구성되므로 Jetpack에서 제공되는 라이브러리, 도구, 가이드에 따르려면 androidx로의 마이그레이션이 필요
• Android 플랫폼보다 더 자주 업데이트되므로 개발자는 항상 가장 뛰어난 최신 버전의 Jetpack 구성요소에 액세스할 수 있습니다.

✅Jetpack의 구성요소

• Jetpack은 크게 4가지로 분류해서 생각할 수 있음
  • Foundation
  • Architecture
  • Behavior
  • UI
• JetPack의 컴포넌트는 안드로이드 플랫폼의 일부가 아니므로 개발자는 원하는 androidx.* 패키지 라이브러리를 이용하여 원하는 컴포넌트만 취사선택하여 이용할 수 있다.
• 개발자가 고품질 앱을 손쉽게 개발할 수 있게 돕는 라이브러리, 도구, 가이드 모음으로, 플랫폼 API와는 별도로 제공되는 androidx.* 패키지 라이브러리로 구성
  향상된 Android 기능의 이점을 활용하기 위한 일련의 구성 요소인 Support Library 로, 이전 버전까지 호환한다.구성요소는 Architecture(아키텍처), Foundation(기초), Behavior(동작), UI로 총 4가지로 나뉜다. 가장 많이 사용하고 있는 부분은 Architecture Component 이다.

Jetpack 사용하기

• Jetpack에 포함된 라이브러리를 사용하기 위해선 project수준의 build.gradle파일에 google() 레포지토리 명시 필요
• 이렇게 google() 이라는 레포지토리를 명시한 후에야 Jetpack 안에 들어있는 LiveData나 ViewModel, ViewPager2과 같은 여러 라이브러리들을 사용가능
  
  
• Jetpack 라이브러리를 본격적으로 사용하기 위해선 사용하고자하는 라이브러리의 종속성을 추가하면됨
• Jetpack 라이브러리

Jetpack compose

• 구글은 Jetpack을 공개하면서 개발자들이 고품질 애플리케이션을 더 쉽게 만들 수 있도록 했지만, 제대로 해결하지 못한 영역이 UI였습니다.
• Jetpack Compose는 바로 이 UI영역을 획기적으로 개선하기 위해 만들어진 것.
• 지금의 안드로이드 UI는 xml로 레이아웃과 뷰들을 만들어 배치하고
  소스에서 뷰들의 id를 바인딩하여 이벤트를 붙이고 사용하는 방식이었습니다.
• 하지만 Jetpack Compose는 기존과는 전혀 다른 방식으로 UI가 개발됩니다.
  개발자가 xml 레이아웃을 수정하거나 UI 위젯을 직접 만들지 않습니다. 대신 Jetpack Compose 함수를 호출하여 원하는 요소를 말하면 Compose 컴파일러에서 나머지 작업을 완료합니다.
  Flutter 와 매우 비슷한데요.. 소스영역에 UI영역을 코딩하고 거기에 이벤트를 함께 처리하는 방식처럼 보입니다.
• 개발언어는 Kotlin 을 사용하고 @Composable 어노테이션을 붙이고 함수안에 UI를 이용하는 코딩을 합니다.
• Jetpack Compose는 아직 알파버전 수준입니다.
  정식 출시되려면 1~2년은 더 있어야 할듯 합니다만 출시되고 나면 기존 안드로이드 개발 방식에 정말 많은 변화를 줄듯합니다.