일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
- Android MVVM
- 안드로이드 의존성주입
- RxJava
- 안드로이드 앱 아키텍처 가이드라인 예시
- 안드로이드 앱 아키텍처 가이드라인 사용법
- 안드로이드 mvvm
- 리싸이클러뷰 최적화
- Koin
- 안드로이드 아키텍처 컴포넌트
- 안드로이드 Mockito
- 안드로이드 클린 아키텍처
- 안드로이드 앱 아키텍처 가이드라인 설명
- 안드로이드 앱 아키텍처 가이드라인
- MVVM
- android memory leak
- 안드로이드 최적화
- Android App Architecture Guideline
- 안드로이드 JUnit
- android DI
- 안드로이드 mvvm예제
- coroutine
- 코루틴
- sharedFlow
- android clean architecture
- 스타트업 코딩테스트
- 안드로이드 테스트코드
- Hilt
- 안드로이드 리싸이클러뷰
- 안드로이드 Espresso
- 안드로이드 hilt
- Today
- Total
안드로이드 연구소
[리싸이클러뷰 박사 교육과정] 리싸이클러뷰 최적화(0) - Recyclerview 탄생배경과 작동원리와 문제점 본문
우리의 코드에서 가장 문제가 많은 곳 중에 하나는
리싸이클러뷰 Recyclerview가 아닐까 싶습니다.
저부터 리스트 목록을 만들어 구현하는 것이 목적이였지,
한번도 리싸이클러뷰의 성능을 계산하며 성능을 높이 목표를 가져본적이 없었습니다.
하지만 버벅거림 없이 렌더링을 극대화하기 위해서는 리싸이클러뷰를 최적화해야만합니다.
그러면 Recyclerview의 A부터 Z까지
Q1. chatGPT, 리싸이클러뷰에 대해 설명해줘
이전 ListView 및 GridView 구성 요소를 대체하기 위해
Android Lollipop(Android5.0, 2014)에 도입된
목록 또는 그리드 형식으로 대규모 데이터 집합을 효율적으로 표시되는 UI Component이다.
위에 내용에서 리싸이클러뷰 이전에는 ListView와 GridView를 사용했었는데
두 컴포넌트에서 문제가 있었어서 리싸이클러뷰로 대체가 된 것 같습니다.
Q2. 그러면 Recyclerview이전에 Listview와 GridView를 사용할 때 어떤 문제가 있었니?
- 대용량 데이터에서 느린 렌더링
긴 목록으로 스크롤할 때 느려지는 경향이 있다이는 뷰가 현재 화면에 표시되지 않더라도 목록 또는 표의 각 항목에 대한 보기를 생성하기 때문입니다. 이로 인해 메모리 사용량이 늘어나고 렌더링 시간이 느려질 수 있습니다.
- 커스터마이징이 어려움
: 엇갈린 그리드 형식(각 행의 열 수가 다른 형식)으로 표시하려는 경우 사용자 지정 어댑터 및 레이아웃 알고리즘을 구현해야 할 수 있습니다. 이 작업은 시간이 오래 걸리고 오류가 발생하기 쉽습니다.
- 애니메이션을 지원하지 않음
데이터 세트에 대한 변경 사항(예: 항목 추가 또는 제거)에 애니메이션을 적용하려면 이 기능을 수동으로 구현해야 합니다.
첫번째 이슈인 많은 양의 데이터를 리스트로 보여줄 경우 느리게 보여지는 문제가 가장 눈에 들어오네요.
그렇다면 리싸이클러뷰는 어떤 원리로 이런 문제들을 해결하였을까요?
Q3. 그렇다면 어떻게 리싸이클러뷰는 "긴 목록으로 스크롤이 느려지는 문제"를 해결하였니?
첫번째로 ViewHolder패턴을 사용하여 해결하였다.
데이터 목록이 100개일 때 ListView는 100개의 View를 만들어낸다.
하지만 Recyclerview는 "10개만의 View만 생성"하여 100개의 데이터를 표현한다.
새로운 데이터를 보여주기위해 스크롤되어 보이지 않는 이전에 생성되었던 view 재활용한다.
이는 Adapter에서 아래와 같은 순서로 작동합니다.
1. getItemCount(): Adapter생성시, 가장 먼저 호출되는 함수입니다. 데이터의 전체 길이를 리턴함.
2. onCreateViewHolder(): 뷰 홀더를 생성하는 함수. 리스트 목록이 10개라면 위 아래 버퍼까지 포함하여 여유있게 13~15개 정도의 객체를 생성합니다.
3. onBindViewHolder(): 생성한 뷰홀더에 데이터를 바인딩하는 함수. 또 아래로 스크롤하여 새로운 데이터를 불러온다면 스크롤되어 없어진 뷰홀더는 재활용되어 데이터만 바인딩됨.
두번째로 LayoutManager를 사용하여 해결하였다.
LayoutManager는 항목이 화면에 배치되는 방식을 결정한다.
LayoutManager가 없으면 RecyclerView는 뷰를 올바르게 배치하는 방법을 알지 못하므로 항목이 겹치거나 잘못된 위치에 나타날 수 있습니다.
세로, 가로 리스트 형식에는 LinearLayoutManager,
다양한 그리드 형식을 제공하는 GridLayoutManager, StaggeredGridLayoutManager등
사용 사례에 적합한 LayoutManager를 선택하면 보기가 효율적으로 배치되어 성능 향상에 도움이 될 수 있습니다.
리싸이클러뷰에서 "Adapter에서 사용하던 ViewHolder", "Activity에서 사용하던 LayoutManager"
이 두 기능이 핵심이였네요.
이미지와 함께 자세한 설명으로 보고 싶으시면 이 블로그로 추천드립니다. https://frtt0608.tistory.com/99
Q4. ViewHolder, LayoutManager을 사용함에도 불구하고, 리싸이클러뷰에서 앱이 버벅거리는 느린 렌더링 이슈가 왜 발생하니?
1. 복잡한 아이템 레이아웃 사용
: RecyclerView가 화면에 표시되기 전에 각 각 뷰를 확장하고 측정해야 해야하는데, 레이아웃이 너무 복잡하거나 많은 수의 중첩된 보기를 포함하는 경우 렌더링 프로세스가 느려질 수 있습니다.
2. 대용량 데이터 호출
:RecyclerView가 각 항목에 대한 보기를 만들고 바인딩해야 하므로 리소스를 많이 사용하는 프로세스일 수 있기 때문입니다.
3. 비효율적인 뷰의 재활용
: LayoutManager가 올바르게 구성되지 않았거나, 뷰가 쉽게 재활용할 수 있도록 설계되지 않은 경우에 발생할 수 있습니다.
4. 느린 데이터 검색
: 리스트로 출력한 데이터를 느린 데이터 소스(네트워크, 데이터베이스)에서 검색하면 렌더링 프로세스가 느려질 수 있습니다.
5. 애니메이션 사용
: 복잡한 항목 애니메이션이 포함되어 있으면 렌더링 프로세스가 느려질 수 있습니다. 화면에 표시되기 전에 각 항목에 대한 애니메이션을 수행해야 하기 때문입니다.
리싸이클러뷰에도 다양한 이유로 느린 렌더링이 발생하고 있었네요.
그말은 즉슨
-효율적인 항목 레이아웃 사용
-적절한 뷰 재활용하게 끔 생성
-페이지네이션의 기능을 사용하여 한번에 출력되는 데이터를 제한
-애니메이션 사용 최소화 등
다양한 방법들로 리싸이클러뷰를 최적화해주어야지 렌더링 성능을 높일 수 있음을 의미하는 말입니다.
그냥 유투브를 보고 따로 카피한 리싸이클러뷰가 아니라
누군가의 블로그에서 복사 붙여넣기를 한 리싸이클러뷰가 아니라
chatGPT에게 물어본 리싸이클러뷰 예제 코드가 아니라
위와 같은 요소들을 고려해 최적화된 멋진 리싸이클러뷰를 설계해야지만 좋은 성능 또한 유지할 수 있습니다.
우리 개발자들 화이팅.
그렇다면 리싸이클러뷰를 최적화해주는 방법에는 무엇이 있을까요?
다음 블로그에 이어서
'안드로이드 연구소' 카테고리의 다른 글
[리싸이클러뷰 박사 교육과정] 리싸이클러뷰 최적화(2) - onCreateViewHolder 최적화 (0) | 2023.05.08 |
---|---|
[리싸이클러뷰 박사 교육과정] 리싸이클러뷰 최적화(1) - onBindViewHolder 최적화 (0) | 2023.05.08 |
[코딩테스트 제출 시 필독] 주석(@어노테이션)으로 코드 검사 개선 (0) | 2023.05.05 |
[코딩테스트 제출 시 필독] Deprecated메서드 제거 (0) | 2023.05.05 |
[코딩테스트 제출 시 필독] 안드로이드 린트 검사(Android Lint) (0) | 2023.05.04 |