[Android] RecyclerView ViewHolder 패턴, DiffUtil 클래스

RecyclerView

  예전 안드로이드 개발하면서 리스트 형태로 데이터들을 표현해주는 데 사용하는 클래스는 ListView 였습니다. 하지만 데이터의 크기가 커질수록 뷰를 계속 생성함으로써 메모리 부족 현상이 발생하게 되고 getView 메소드에서 무분별한 findViewById를 사용하였기에 비효율적이였습니다. 이를 개선한 위젯이 RecyclerView로 화면이 보여지는 뷰까지만 생성한 후 스크롤 시에 가려지게 되는 뷰들은 재사용하는 데 사용됩니다. 또한, findViewById의 값 비싼 비용을 방지하고자 ViewHolder 패턴을 강제화 시킨 ListView라고 할 수 있습니다.

 

 

 

ViewHolder 패턴이란?

  ViewHolder 패턴을 이해하기 위해서는 ViewHolder 패턴이 왜 필요한지부터 이해하면 좋습니다. 

class ListAdapter(private val items : List<String>): BaseAdapter() {
    override fun getCount(): Int = items.size

    override fun getItem(position: Int): String = items.get(position)

    override fun getItemId(position: Int): Long = position.toLong()

    override fun getView(position: Int, convertView: View?, parent: ViewGroup?): View {
        var view = convertView
        if(view == null){
            view = LayoutInflater.from(parent?.context).inflate(R.layout.item_list, parent, false)
        }

        view?.findViewById<TextView>(R.id.textView).text = items.get(position)
        return view!!
    }
}

 위의 코드는 ListView의 어댑터인 ListAdapter 클래스로 getView메소드는 position에 해당하는 View를 반환하는 메소드입니다. getView 메소드의 파라미터로 convertView가 존재하는데 convertView는 재사용되는 뷰로서 ListView가 스크롤하여 이전에 생성했던 뷰가 가려졌을 때 해당 뷰로 재사용하게 됩니다. 즉, 보여주고자 하는 모든 데이터 갯수만큼 뷰를 생성하면 메모리가 낭비하게 되므로 화면에 보여지는 뷰만큼만 생성하고 재사용한다는 것입니다.

 

 뷰를 재사용하여 메모리 낭비는 방지하였지만 getView 메소드마다 findViewById가 호출됩니다. 간단한 뷰면 크게 문제되지 않지만 복잡한 뷰일수록 findViewById의 호출도 많아지고 findViewById의 비용도 커지게 됩니다. findViewById의 원리가 궁금하시면 아래 링크를 통해 확인하실 수 있습니다.

 

https://math-coding.tistory.com/251

[Android] findViewById 원리

 

class CustomAdapter(private val dataSet: Array<String>) :
        RecyclerView.Adapter<CustomAdapter.ViewHolder>() {

    /**
     * Provide a reference to the type of views that you are using
     * (custom ViewHolder).
     */
    class ViewHolder(view: View) : RecyclerView.ViewHolder(view) {
        val textView: TextView

        init {
            // Define click listener for the ViewHolder's View.
            textView = view.findViewById(R.id.textView)
        }
    }

    // Create new views (invoked by the layout manager)
    override fun onCreateViewHolder(viewGroup: ViewGroup, viewType: Int): ViewHolder {
        // Create a new view, which defines the UI of the list item
        val view = LayoutInflater.from(viewGroup.context)
                .inflate(R.layout.text_row_item, viewGroup, false)

        return ViewHolder(view)
    }

    // Replace the contents of a view (invoked by the layout manager)
    override fun onBindViewHolder(viewHolder: ViewHolder, position: Int) {

        // Get element from your dataset at this position and replace the
        // contents of the view with that element
        viewHolder.textView.text = dataSet[position]
    }

    // Return the size of your dataset (invoked by the layout manager)
    override fun getItemCount() = dataSet.size

}

 위의 코드는 Android 공식문서에 있는 코드로 추상 클래스인 RecyclerView.Adpater를 상속받은 CustomAdapter 클래스입니다.

CustomAdapter 내에는 내부 클래스인 Viewholder 클래스가 존재하는데 RecyclerView.Adapater를 상속받기 위해서는 RecyclerView.ViewHolder가 정의되어야 하기 때문에 Viewholder 클래스를 생성하였습니다. 이 Viewholder 클래스가 findViewByid의 단점을 개선시킬 수 있는 방법으로 해당 클래스에서 레이아웃에 존재하는 모든 뷰를 선언하고 할당까지 한 상태로 View를 가지고 있게 됩니다.

 

 먼저 RecyclerView의 동작 순서를 살펴보겠습니다.

 

1. 화면에 보여질 뷰보다 1~2개 더 많게 뷰홀더를 생성합니다.(onCreateViewHolder)
2. 각 뷰홀더에 position에 해당하는 데이터를 바인딩합니다.(onBindViewHolder)
3. 스크롤 시에 가려져서 보이지 않은 뷰홀더에 새로운 position의 데이터를 바인딩합니다.

 RecyclerView는 기본적으로 재사용 뷰를 사용하게 되는데 getView 메소드와 차이점은 findViewById를 하지 않아도 레이아웃 내에 존재하는 모든 뷰에 대한 참조가 되어 있어서 데이터를 바인딩만 시키면 됩니다. 이로 인해 findViewById는 onCreateViewHolder가 호출된 수만큼만 호출되기 때문에 성능 개선이 되었다고 볼 수 있습니다. 😀

 

반응형

 

 

 

notifyDataSetChanged

  위의 내용만 볼 때에 메모리 낭비도 개선하였고 findViewById도 개선하여서 RecyclerView는 문제점이 모두 개선이 되었다고 볼 수 있습니다. 하지만 RecyclerView에서도 비효율적인 구조가 존재하는데 그것은 바로 새로운 데이터 리스트들을 적용할 때 입니다. RecyclerView를 한 번이라도 사용하신 분들은 notifyDataSetChanged() 메소드를 호출하면 기존에 보여줬던 리스트를 갱신시켜 새로운 데이터들로 보여준다는 것을 알고 있을 것입니다.

        public void notifyChanged() {
            // since onChanged() is implemented by the app, it could do anything, including
            // removing itself from {@link mObservers} - and that could cause problems if
            // an iterator is used on the ArrayList {@link mObservers}.
            // to avoid such problems, just march thru the list in the reverse order.
            for (int i = mObservers.size() - 1; i >= 0; i--) {
                mObservers.get(i).onChanged();
            }
        }

 notifyDataSetChanged() 메소드 내부에서 notifyChanged 메소드가 호출되는데 모든 데이터들을 하나씩 변경을 하고 있습니다. 즉, 기존에 바인딩 했던 데이터들을 지우고 다시 처음부터 바인딩하고 렌더링 하는 과정을 거치게 됩니다. 만약 100개의 데이터 중 1개의 데이터 값만 변경했지만 전체 데이터를 바인딩하고 렌더링 과정을 거친다면 매우 비효율적인 구조가 되겠죠? 이를 개선시켜줄 수 있는 방법이 DiffUtil을 이용하는 것입니다.

 

 

 

DiffUtil

  위와 같은 문제를 해결하기 위해 사용되는 DiffUtil 클래스는 Eugene W.Myers's difference algorithm을 이용하여 데이터의 변경된 부분만 업데이트하도록 되어 있습니다. 

 

DiffUtil.Callback

위의 코드는 DiffUtil.Callback 추상클래스로 4개의 추상메소드와 1개의 메소드가 존재합니다. 

 

• getOldListSize : 기존에 있던 리스트의 크기 반환
• getNetListSize : 변경될 리스트의 크기 반환
• areItemsTheSame : 두 개의 객체가  같은지 확인, 주소값으로 비교하거나 고유의 값(ID)을 통해 비교
• areContentsTheSame : 두 개의 데이터가 같은지 확인
• getChangePayLoad : 변경 내용에 대한 페이로드를 가져옴

 

 위 메소드에서 중요한 것은 areItmesTheSame과 areContentsTheSame  메소드를 구별할 줄 알아야 하는데 areItemsTheSame은 객체가 같은지 판단해야 하기 때문에 주소값으로 비교하거나 객체 내 고유의 값으로 비교를 해야 합니다. 그리고 areItemsTheSame 메소드가 true를 반환해야 areContentTheSame 메소드를 호출합니다. 당연하듯이 객체가 다르면 객체 내 데이터를 확인할 필요도 없고 객체는 같더라도 데이터를 다른 값으로 세팅할 수 있어서 areContentTheSame 메소드로 확인합니다. 결론적으로 areItemsTheSame과 areContentsTheSame 메소드가 모두 true이면 같은 아이템으로 판단하여 업데이트 하지 않게 됩니다.

class DiffUtilCallback(
    private val oldList: List<Book>,
    private val newList: List<Book>
): DiffUtil.Callback() {
    override fun getOldListSize(): Int = oldList.size

    override fun getNewListSize(): Int = newList.size

    override fun areItemsTheSame(oldItemPosition: Int, newItemPosition: Int): Boolean {
        return oldList.get(oldItemPosition).id == newList.get(newItemPosition).id
    }

    override fun areContentsTheSame(oldItemPosition: Int, newItemPosition: Int): Boolean {
        oldList.get(oldItemPosition) == newList.get(newItemPosition)
    }
}

 

 

 위의 코드처럼 DiffUtilCallback 클래스를 정의하고 Adapater 내부에 changeList라는 메소드를 만들어서 새로운 리스트 업데이트 시 사용할 수 있습니다. 먼저 DiffUtilCallback으로 이전 리스트와 새로운 리스트의 Diff를 계산한 후 dispatchUpdatesTo 메소드를 통해 Adapter에 변경된 부분을 알려줄 수 있게 됩니다.

    fun changeList(books: List<Book>){
        val diffUtilCallback = DiffUtilCallback(this.books,books)
        val diffResult = DiffUtil.calculateDiff(diffUtilCallback)
        
        this.books.apply { 
            clear()
            addAll(books)
            diffResult.dispatchUpdatesTo(this@BookListAdapter)
        }
    }

 

 

 

AsyncListDiffer

 DiffUtil.Callback 추상클래스를 구현하는 클래스를 직접 만들어서 RecyclerView Adpater에서 사용해도 좋지만 데이터가 많아질 수록 Eugene W.Myers's difference algorithm의 시간복잡도가 커지기에 백그라운드 스레드에서 처리하는 것이 좋습니다. AsyncListDiffer는 백그라운드 스레드에서 리스트의 변경사항을 계산하고 업데이트까지 진행을 시켜주기 때문에 효율적으로 사용할 수 있습니다.

 

 먼저 DiffUtil.ItemCallback 클래스를 만듭니다.

DiffUtil.Callback과 다르게 getOldListSize와 getNewListSize 메소드는 메소드로 존재하지 않기 때문에 areItemsTheSame과 areContentsTheSame만 오버라이딩 하였습니다.

class DiffUtilCallback(): DiffUtil.ItemCallback<Book>(){

    override fun areItemsTheSame(oldItem: Book, newItem: Book): Boolean {
        return oldItem.id == newItem.id
    }

    override fun areContentsTheSame(oldItem: Book, newItem: Book): Boolean {
        return oldItem == newItem
    }
}

 

 그리고 Adapter에 AsyncListDiffer 객체를 선언한 뒤 changeList 내부에 submitList를 호출만 해주면 됩니다.

 

 

 

 여기서만 멈추지 않고 AsyncListDiffer 의 submitList를 분석해봅시다. 아래 코드는 AsnycListDiffer 클래스의 submitList 메소드의 일부로 newList와 mList(이전 리스트)와 비교를 하게 됩니다. 여기서 중요한 점이 있는데 newList와 mList의 참조가 같으면 변경사항을 체크하지도 않고 종료시킵니다. 새로운 데이터를 대입할 때 서버나 DB로부터 새로운 리스트를 생성하고 데이터를 세팅한 후 submitList를 하게 되면 문제 없지만, 기존에 있던 데이트를 가지고 임의로 약간의 수정을 한 후 submitList를 하면 결국 같은 참조값을 가리키기 때문에 업데이트가 안되는 현상이 발생합니다.

 

AsyncListDiffer submitList

  이후 getBackgroundThreadExecutor를 통해 백그라운드에 작업을 실행하고 DiffUtil.Callback을 정의합니다. getOldListSize와 getNewListSize 메소드 내부적으로 리스트로 반환하게 되고 areItemsTheSame 과 areContentsTheSame은 DiffUitl.ItemCallback에서 정의한 클래스를 그대로 사용하고 있습니다. 정리하자면 DiffUtil.Callback 메소드를 동일하게 사용하되 백그라운드 스레드에서 변경사항을 계산한다고 보면 됩니다.

 

 

 

ListAdapter

  RecyclerView의 notifyDataSetChanged 를 개선하기 위해서 DiffUtil.Callback 추상클래스를 구현하거나 AsyncListDiffer 클래스를 사용하였습니다. 하지만 구글에서 더더욱 쉽게 사용하라고 AsyncListDiffer 를 래핑한 ListAdapter를 만들었습니다.

class BookAdapter(private val itemClickedListener: (Book) -> Unit) : ListAdapter<Book, BookAdapter.BookItemViewHolder>(diffUtil) {

    inner class BookItemViewHolder(private val binding: ItemBookBinding) : RecyclerView.ViewHolder(binding.root){

        fun bind(bookModel: Book){
            binding.titleTextView.text = bookModel.title
            binding.descriptionTextView.text = bookModel.description
            binding.root.setOnClickListener {
                itemClickedListener(bookModel)
            }

            Glide
                .with(binding.coverImageView.context)
                .load(bookModel.converSmallUrl)
                .into(binding.coverImageView)
        }
    }

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): BookItemViewHolder {
        return BookItemViewHolder(ItemBookBinding.inflate(LayoutInflater.from(parent.context),parent,false))
    }

    override fun onBindViewHolder(holder: BookItemViewHolder, position: Int) {
        holder.bind(currentList[position])
    }


    companion object {
        val diffUtil = object : DiffUtil.ItemCallback<Book>() {
            override fun areItemsTheSame(oldItem: Book, newItem: Book): Boolean {
                return oldItem.id == newItem.id
            }

            override fun areContentsTheSame(oldItem: Book, newItem: Book): Boolean {
                return oldItem == newItem
            }
        }
    }
}

 위 코드는 ListAdpater를 확장한 BookAdpater로 ListAdpater의 제너릭 타입으로 리스트 아이템 타입인 Book과 내부 클래스로 정의한 BookItemViewHolder를 선언하였습니다. 그리고 생성자 매개변수로 DiffUtil.ItemCallback 클래스를 동반 객체로 정의한 변수값을 대입하였습니다. ListAdapter에서는 내부 속성 값으로 AsyncListDiffer가 존재하고 매개변수로 대입된 DiffUtil.ItemCallback 클래스를 이용하여 submitList 시 변경사항을 체크하고 업데이트 시켜주게 됩니다. 😘  

 하지만 아직까지 ListAdapter에 이슈가 조금 많은 것처럼 보입니다. 변경 내역을 계산하기까지 시간이 소요되어 업데이트 시 끊김이 발생한다거나, scroll position이 자동으로 맨 마지막으로 이동하는 이슈를 겪어본적이 있습니다. scrollToPosition도 정상적으로 수정이 되지 않아 submitList(null) 이후 submitList(newList)를 호출하여 수정하였습니다. 이러면 ListAdpater를 쓰는 의미가 없긴 한데... 해결하신 선배님들 있으시면 댓글 남겨주세요.😂

 

 

 

참고

• https://developer.android.com/guide/topics/ui/layout/recyclerview?gclid=CjwKCAjwoduRBhA4EiwACL5RP9n3ox-0RVJBc1mRQuxX2GW-rU0xj5kUlBgqBYZspS-ZX-wdh8MKBhoC6lIQAvD_BwE&gclsrc=aw.ds 

RecyclerView로 동적 목록 만들기  |  Android 개발자  |  Android Developers

• https://voiddani.tistory.com/7

[Android] RecyclerView DiffUtil

• https://velog.io/@haero_kim/Android-DiffUtil-%EC%82%AC%EC%9A%A9%EB%B2%95-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0

[Android] DiffUtil 사용법 알아보기