안드로이드 Jetpack이란?

 

1. Jetpack
   1-1. Jetpack이란?
   1-2. Jetpack이 나오게 된 배경
   1-3. Support Library의 문제점
   1-4. 구성 요소
   1-5. Compose

 

 

---

 

1. Jetpack

1-1. Jetpack이란?

안드로이드 채용 공고 中, 자격요건

 

안드로이드 채용 공고를 조금만 둘러보면 위 사진처럼 Android Jetpack에 대한 이해와 경험을 요구하는 회사가 많다는 걸 알 수 있다. 과연 Jetpack이 무엇이길래 그러는 것일까?

jetpack을 장착하고 있는 안드로이드

 

Jetpack은 2018년 5월 8일에 구글이 발표한 라이브러리와 도구 모음집이다.

개발자들이 쉽고! 빠르고! 퀄리티 좋은! 앱을 만들 수 있도록 도와주는 라이브러리와 도구를 모아두었다.

 

1-2. Jetpack이 나오게 된 배경

https://developer.android.com/topic/libraries/support-library

사실 Jetpack이 나오기 전 Support library라고 하는 라이브러리 모음집이 이미 존재했었다.

그러나 Support library에는 여러 가지 문제점이 있었고 이를 개선하면서 새로운 이름을 붙여 다시 나온 것이 Jetpack인 것이다. Support library는 현재도 사용 가능하지만 위 사진(공식 문서)에 쓰여있듯이 AndroidX를 사용할 것을 권장하고 있다. (AndroidX는 Jetpack의 라이브러리들을 묶은 패키지 명이다)

 

1-3. Support Library의 문제점

이 목차의 내용은 당근마켓 기술 블로그를 보고 알게 되었다
안 궁금하면 넘어가도 되는 부분이다

 

이거 나만 궁금해?

그럼 대체 무슨 문제점들이 있었길래 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. 바이너리 호환성 제약>

	기능 A	기능 B
1.1.0 버전	정식 버전	베타 버전
1.1.1 버전	새로운 버전(문제 발생)	정식 버전

1.1.0 버전을 이용해 개발한 앱이 있다고 치자. 기능 B가 베타 버전이었지만 문제없이 잘 돌아갔다.

1.1.1 버전이 나오고 기능 B가 정식 버전으로 나왔다고 해서 헐레벌떡 업데이트를 했다.

근데 1.1.1 버전 기능 A에 문제가 생겨서 눈물을 머금고 다시 1.1.0 버전으로 다운그레이드를 했다.

 

이게 단일 라이브러리의 단점이었다. 한꺼번에 업데이트하고 다운그레이드 해야 한다는 것.

이를 해결하고자 AndroidX는 위젯 단위의 세분화된 형태로 모듈화 해서 라이브러리를 제공하게 되었다.

 

정리해서 말하자면 서포트 라이브러리는 위와 같은 문제점들이 있었고

이를 해결하면서 + 새로운 기능의 라이브러리들을 추가하면서 이름을 바꾸어 내놓은 것이 Jetpack인 것이다.

 

1-4. 구성요소

https://developer.android.com/jetpack/androidx/explorer?hl=ko

 

Jetpack을 구성하는 라이브러리는 굉장히 많으니 자세한 설명과 목록은 위 링크에 들어가서 확인하자.

몇몇 라이브러리는 내가 공부해서 글을 작성했다.

• Room
• ViewModel
• DataBinding
• ViewBinding

 

1-5. Compose

Jetpack에 추가된 새로운 도구 키트인데 중요한 듯하여 적어두려고 한다.

아직 알파 버전(2021.04.05 기준) 이기 때문에 사용하기엔 시기상조이지만 언젠가 쓰게 될 기능이지 않을까 싶다.

간단하게 말하면 UI를 구성하는 코드를 xml이 아니라 클래스 파일에다가 작성을 하는.. 그런 기술인데

잠깐 맛만 좀 볼까? 하고 구경했는데 되게 낯설었다... (xml 파일이 아니라 코드로 만드는 게...)

 

어쨌든 시간이 지나면 개발자들이 전부 이 기술을 쓰게 될 거라 생각한다.

구글에서는 이 기술이 코드 수를 감소시키고, 직관적이고, 개발이 빨라지고, 강력한 성능을 가지고 있다고 소개하고 있다. 아직 개발 단계에 있고 국내에 정보도 많이 없으니 난 일단 기초를 더 쌓으려고 한다.

 

Compose의 더 자세한 내용이 궁금하다면 공식문서를 확인하자

 

 

---

💡 느낀 점

• xml 파일에서 자동완성으로 androidx가 아니라 android를 사용하게 됐을 때 문제가 생긴 이유가 이거구나!!
• 내가 만든 앱이 dex가 3개인데 클래스가 그렇게 많나...? 그렇게 까진 아닌 것 같은데...
• compose가 얼른 정식으로 배포됐으면 좋겠다. 새로운 기술 두근두근...

📘 참고한 자료

• android 공식문서 - Jetpack
• 당근마켓 기술 블로그

---