안드로이드 뷰 바인딩 (1) - 개요 및 다른 방식들과의 비교

필자는 그동안 개인적으로 개발하고 있는 프로젝트에 Kotlin synthetics 을 편리하게 사용하고 있었다.

하지만, kotlinx.android.synthetic 가 더 이상 권장되지 않는다고 하여 대안을 찾던 중 View Binding 을 알게 되었다.

 

현재는 Kotlin synthetics 를 버리고 View Binding 을 적용하고 있는 중이다.

이번 포스팅에서는 View Binding 에 대해 알아보자.

View Binding?

View Binding 은 'findViewById' 를 대체할 수 있는 기능이다.

 

구글 공식 문서 에서는 하단과 같이 설명하고 있다.

뷰와 상호 작용하는 코드를 쉽게 작성할 수 있는 기능이다.

각 XML 레이아웃 파일에 정의되어 있는 뷰의 바인딩 클래스가 자동으로 생성한다.

이를 이용하여 각 XML 에 존재하는 ID 가 있는 모든 View 를 직접 참조할 수 있다.

즉, XML 레이아웃 파일의 바인딩 클래스가 자동으로 생성되고 이를 이용하여 View 에 접근할 수 있다는 얘기다.

History

View Binding 외 View 접근을 위한 방식에 어떤 것들이 있는지 알아보자.

 

◼ findViewById

전통적인 방식으로 과거의 'findViewById' 는 View object 를 반환하여 강제 캐스팅을 해야 했고, compile-time safety 를 보장하지 않았다.

Android 8 (API 26) 부터는 'findViewById' 에 변경을 줘서 View 대신 <T extends View> T 를 반환하여 강제 캐스팅 없이 사용 가능해 진다.

 

 - 장점 : Runtime 에 동작하여 빌드 속도에 영향이 없다.

 - 단점 : Compile-time safety 를 보장하지 않는다.

 Boilerplate code 가 다수 발생한다.

 (Boilerplate code : 수정하지 않거나 최소한의 수정만을 거쳐 여러곳에 필수적으로 사용되는 코드)

◼ ButterKnife (https://jakewharton.github.io/butterknife)

개발자 JakeWharton 이 개발한 annotation 기반의 라이브러리로 binding 하려는 view 에 annotation 을 달아 접근할 수 있다.

현재는 본인이 deprecated 시킴.

 

 - 장점 : Runtime 에 동작하여 빌드 속도에 영향이 없다.

 Boilerplate code 가 상당히 줄어든다.

 - 단점 : Compile-time safety 를 보장하지 않는다.

◼ Data Binding (https://developer.android.com/topic/libraries/data-binding)

Android JetPack 라이브러리 중 하나의 기능으로 XML 파일에 data 를 binding 해서 사용한다. (데이터와 뷰를 연결하는 작업을 레이아웃에서 처리한다.)

모든 클래스를 바인딩하여 뷰를 직접 참조할 수 있다.

 

 - 장점 : Compile-time safty 가 보장된다. (null, type safty)

 양방향 데이터 바인딩을 통해 뷰에서 생성된 값을 뷰 모델에 전달할 수도 있다.

 - 단점 : Layout tag 사용으로 인한 boilerplate code 가 발생한다.

 빌드 시간이 늘어난다.

◼ Kotlin synthetic properties

2017 년에 출시된 Android Kotlin Extensions Gradle 플러그인과 함께 소개된 기능으로 XML layout 에 선언된 view ID 를 코드에서 직접 참조할 수 있다.

Kotlin 1.4.20 부터 deprecated 됨. (기본 플러그인에서도 퇴출되고 ViewBinding 이 기본이 됨)

 

 - 장점 : Boilerplate code 가 없다.

 Type safe 가 보장된다.

 - 단점 : 완전한 Null sfae 가 보장되지 않는다.

 View id 가 중복되는 경우와 같은 name space 오염(pollute) 이 발생한다.

 Kotlin 에서만 동작한다.

Deprecated Kotlin Synthetics

Kotlin synthetics 은 import 만 해주면 view 에 바로 접근할 수 있고 변수도 필요없어 매우 편리하다.

이런 편리성 때문에 개인적으로도 잘 사용해 왔다.

History 항목에서 간단하게 장단점을 알아봤지만 왜 deprecated 되었는지 단점 위주로 조금 더 잘 살펴보자.

 

◼ View id 가 중복되는 경우의 위험성

하단과 같은 layout 에서 동일한 view id 를 사용하는 widget 이 있다고 가정하자.

FragmentA 에서 test widget 에 접근할 때 fragment_a 의 test widget 이 아닌 fragment_b 의 test widget 을 import 한다면 Runtime exception 이 발생할 것이다.

 

◼ 비슷한 view id 를 혼동할 경우의 위험성

하단과 같은 layout 에서 비슷한 view id 를 사용하는 widget 이 있다고 가정하자.

FragmentA 에서 TextView 에 접근할 때 fragment_a 의 test1 widget 이 아닌 fragment_b 의 test2 widget 을 import 한다면 Runtime exception 이 발생할 것이다.

 

◼ ViewHolder 에서의 성능저하 (캐싱 문제)

앞의 두 경우는 실수를 유발할 수 있는 문제라면 성능 문제도 있다.

상세 설명은 하단의 링크에 잘 설명되어 있다.

(Kotlin Android Extensions - 리사이클러의 뷰홀더에서 올바르게 사용하는 방법)

View Binding vs Data Binding

View Binding & Data Binding 은 모두 binding class 를 제공하여 뷰를 직접 참조할 수 있다.

View Binding 은 Data Binding 보다 간단한 use case 를 처리할 목적으로 설계되었고, 하단과 같은 차이가 있다.

 

◼ View Binding

- 빠른 컴파일: 별도의 annotation 처리가 필요하지 않아 컴파일 시간이 단축된다.

- 간단한 사용: Tag 처리된 특수한 XML 을 사용하지 않기 때문에, 사용이 간단하다.

모듈 gradle 파일에서 허용하기만 하면, 모듈 내의 모든 레이아웃 파일에 자동으로 뷰 바인딩이 적용된다.

 

◼ Data Binding

- layout variable, layout expression 지원: Layout 에서의 변수, 표현식 등을 통해 XML 내에서 동적인 UI 콘텐츠 생성이 가능하다.

- Two-way Data Binding: 양방향 데이터 바인딩을 통해 뷰에서 생성된 값을 뷰 모델에 전달할 수도 있다.

 

두 기능의 장단점을 모두 이용하고 싶다면, 한 프로젝트에 뷰 바인딩과 데이터 바인딩을 모두 적용하는 것도 가능하다.

일반적인 상황에서는 뷰 바인딩을 사용하고, 다이내믹 UI가 필요한 부분에는 데이터 바인딩을 적용할 수 있다.

Summary