[UIKit] 메모리 관점에서의 CollectionView, PageView, ScrollView의 동작 방식

여러 데이터를 표현하기 위해선 다양한 방법으로 구현할 수 있습니다. 그 중에서 반복적인 형식의 데이터를 표현하는 방법 또한 여러 가지인데, 대표적으로 UICollectionView, UIPageViewController, UIScrollView가 있습니다. 각 뷰가 어떻게 동작하는지와 메모리의 관점에서 어떠한 특징을 보이고 있는지 학습하였고, 이를 기반으로 상황에 따라 어떠한 뷰를 사용할 지 정의하고자 합니다.

 

UICollectionView

• 동작 방식
  • UICollectionViewCell을 기반으로 데이터를 리스트 또는 그리드 형태로 표시합니다.
  • 재사용 큐를 사용하며, 보이지 않는 셀은 메모리에서 로드 또는 제거되지 않고, 재사용됩니다.
• 메모리 관점
  • 셀을 재사용하기 때문에 효율적입니다.

 

UIPageViewController

• 동작 방식
  • 한 번에 총 3개의 페이지 (현재 / 이전 / 다음 페이지)를 유지합니다.
  • 스와이프 시 자동으로 다음 뷰 컨트롤러를 요청합니다.
• 메모리 관점
  • 페이지가 많아도 3개의 페이지만 로드하기 때문에 메모리가 절약됩니다.
  • 하지만 뷰 컨트롤러를 로드하기 때문에 셀을 로드하는 것보다 파일이 무거울 수 있습니다.

 

ScrollView

• 동작 방식
  • 스크롤 가능한 컨텐츠를 한 번에 모두 배치합니다.
• 메모리 관점
  • 모든 컨텐츠의 메모리가 유지되기 때문에, 메모리를 많이 차지합니다.

 

결론

• 고화질의 이미지나 많은 양의 데이터를 보여주고자 할 때에는 CollectionView를 사용하는 것이 메모리 관점에서 효율적이라고 생각합니다. 하지만 PageControl 기능이 필요하다면 추가적인 구현이 불가피합니다.
• 보여줄 이미지가 적으면서 Cell 단위가 아닌 ViewController 단위의 페이지를 이동시키고자 한다면 UIPageViewController이 괜찮다고 생각합니다. 또한 이전 / 다음 페이지가 미리 로드되어 있기 때문에 유저가 이미지를 기다릴 일도 없어 사용자 경험을 개선할 수 있습니다.
  • Cell 단위와 ViewController의 기준은 화면 이동, 데이터 이동 등과 같은 ViewController의 역할이 포함되었는지에 따라 결정할 수 있을 것 같습니다.
• 만약 이미지가 많이 필요없거나 저사양일 때에 ScrollView를 사용할 수 있다고 생각하나, 애초에 CollectionView가 ScrollView를 상속받고 있기 때문에 여러 이미지를 렌더링하는 작업에서 굳이 사용할 필요는 없을 것 같다고 생각합니다. 또한 UIScrollView는 스크롤이 되는 뷰라고 정의되어 있기 때문에, 데이터를 렌더링하는 등의 작업은 UIScrollView의 역할과는 다르다고 생각하여, 위와 같은 작업에서 자주 사용하지는 않을 것 같습니다. 하지만 모든 이미지가 미리 불려져있어야 하는 경우에 사용할 수 있을 것 같습니다.