[2] 영화 예매 피드백1

[gahyunkim]

[2] 영화 예매 피드백 관련 퀴즈 내용 정리해주세요

[gahyunkim]

안드로이드에서 View의 크기를 정의하는 데 사용되는 px, dp, sp 단위의 차이점과 각각 언제 사용하는 것이 적절할까요?

[gahyunkim]

px: 실제 디바이스 화면의 픽셀 수이기 때문에, 디바이스의 해상도에 따라 크기가 달라져서 거의 사용하지 않는 것이 좋다.
화면의 크기와 해상도에 따라서 일관된 UI의 제공이 어려움

dp(density-independent pixels): 화면 밀도에 독립적인 단위로, 해상도나 화면 크기에 상관없이 비슷한 크기로 보이도록 조정됨
View의 크기나 margin, padding과 같이 일관된 레이아웃을 위해서 많이 사용된다.

sp(scale-independent pixels): dp와 사용자의 글꼴 설정 크기를 고려한 단위로, 밀도 독립적이면서 사용자가 설정한 글자 크기에 따라 변한다.
텍스트 크기를 지정할 때 주로 사용된다

[rosemin928]

1. px

• 정의: 실제 화면에 보이는 물리적인 픽셀 수
• 화면 해상도에 따라 상대적으로 작거나 클 수 있다.
• 해상도가 다른 기기에서 UI 요소의 크기가 달라져 보일 수 있다.

2. dp (Density-independent Pixels, 밀도 독립 픽셀)

• 정의: 화면 밀도에 영향을 받지 않는 단위
• 해상도가 달라도 비슷한 크기로 보이게 해준다
• 대부분의 view 크기는 dp를 사용한다.

3. sp (Scale-independent Pixels, 스케일 독립 픽셀)

• 정의: dp와 비슷하지만, 사용자의 글꼴 크기 설정을 반영
• 유저가 시스템에서 “글자 크게 보기” 설정해두면 sp 단위도 커진다.
• 텍스트에는 sp를 사용한다.

[donghyun81]

px: 각 기기는 1인치당 px의 기준이 다르기 때문에
거리나 크기에 px을 사용하는걸 지양하는걸 권장

dp: 각 기기의 밀도에 따라 1인치당 px이 다르게 들어가는데,
각 기기 화면에 따라 크기가 맞춰지도록 하는 단위

픽셀과 dp 계산
px = dp * (dpi / 160)

sp: 기본적으로 dp와 같은 크기지만, 사용자 설정에 따라 크기가
달라질 수 있음

[gahyunkim]

Activity 간에 데이터를 전달하는 데 Intent를 사용합니다. 기본 데이터 타입(int, String 등)은 Intent의 Extra를 통해 쉽게 전달할 수 있습니다. 그렇다면 기본 타입이 아닌 객체는 어떻게 전달해야 할까요? 이때 자바의 원시 타입이 객체가 아니기 때문에 발생하는 Boxing의 개념도 함께 설명해주세요. (레벨 1 복습)

[gahyunkim]

기본 데이터가 아닌 클래스나 데이터 객체는 바로 전달할 수 없다. 따라서, 직렬화라는 단계가 필요하다.

직렬화: 메모리 내에 존재하는 정보를 보다 쉽게 전송 및 전달하기 위해 byte 코드로 나열하는 것

안드로이드에서 intent 데이터 이동시에 객체를 직렬화 해야하는 이유는 intent는 기본적으로 값의 복사본을 생성하여 넘기기 때문에 기본 데이터 타입은 바이트 크기가 정해져 있어 직렬화가 필요없지만, 객체는 바이트 크기를 알 수 없기 떄문에 직렬화가 필요하다.

Parcelable: 안드로이드에 최적화된 방식이고 빠르다.
Serializable: 자바에서 기본으로 제공하는 방식이고 코드가 간단하다. 하지만, reflection을 사용하기 때문에 느리다.

Boxing: 기본 타입을 객체 타입으로 자동 변환하는 것

[rosemin928]

1. Serializable

• 자바에서 제공하는 표준 직렬화 인터페이스
• 어떤 객체든 Serializable을 구현하면, 그 객체를 바이트 형태로 변환해서 저장하거나 다른 곳으로 보낼 수 있다.
• 장점: 구현이 매우 간단함
• 단점: 속도가 느리고 메모리 사용량이 많음

2. Parcelable

• 안드로이드에서 효율적인 객체 직렬화를 위해 제공하는 인터페이스
• 장점: 속도가 빠르고 메모리 효율이 좋음
• 단점: 코드가 조금 복잡할 수 있음 -> 하지만 kotlin에서는 @parcelize 어노테이션을 써서 직접 필요한 메서드를 구현하지 않고도 간단하게 사용할 수 있게 됨

Boxing이란?

• 자바에서 int, float, boolean 같은 기본 타입은 객체가 아니다. 그런데 Intent.putExtra()처럼 객체만 받을 수 있는 함수에 기본 타입을 넘길 때, 자동으로 객체 형태로 감싸주는 작업을 하는데 이걸 Boxing이라고 한다.

[donghyun81]

Intent는 putExtra를 통해 값을 전달하는데, 이때 전달하는 값에 따라서 Parcel이라는 객체에 직렬화 및 역직렬화를 사용하거나 input, output stream을 사용해서 직렬화 및 역직렬화를 사용합니다.
android 프레임워크에서 지원하는 기본 타입이나 특정 컬렉션은 Parcel이라는 객체에 직렬화 및 역직렬화를 사용합니다.
이는 Parcel 객체가 input, output stream의 직렬화 역직렬화 과정보다 효율적이게 설계 되었기 때문입니다.
사용자가 정의한 타입은 직렬화 역직렬화 방법을 지원하지 않아서 serializable 또는 parcelizable을 상속 받아서 메서드를 구현해야 합니다.
serializable를 상속 받으면 input, output stream의 직렬화 역직렬화 과정을 통해 값을 보관해서 전달하게 되고
parcelizable을 상속 받으면 Parcel의 직렬화 역직렬화 과정을 직접 구현해서 값을 보관하고 전달해야 합니다.

[gahyunkim]

화면 회전과 같은 구성 변경이 발생하면 Activity는 기본적으로 어떻게 동작하며, 이로 인해 어떤 문제가 발생할 수 있을까요? 또, 이 외에 어떤 경우에 Activity 소멸로 인해 데이터 유지를 고민해야 할까요? (이전 수업 생명 주기 복습)

[gahyunkim]

화면이 회전되면 Activity는 destroy된 후에 새롭게 생성되는 방식이다.

onPause() -> onStop() -> onDestroy() -> onCreate() -> onStart() -> onResume()
와 같은 위의 순서대로 화면이 다시 구성된다.

이렇게 화면 돌아가면서 기존의 Activitiy가 사라지고 새로운 Activity가 만들어지기 때문에, 화면에 표시되던 데이터나 사용자의 입력값들이 사라질 수도 있다.

따라서, onSavedInstanceState()와 onRestoreInstanceState()를 사용해서 화면 회전 전에 데이터를 Bundle()에 저장하고 회전한 후에 새롭게 복원해주도록 한다.

이 외에도 앱을 일시 중지한 상태에서 오래 지나 다시 돌아오는 경우 자동으로 메모리의 과도한 사용을 막기 위해 자동으로 종료시킬 수 있기 때문에 이러한 경우를 신경써야 한다.

[rosemin928]

1. 화면 회진 시 Activity의 기본 동작

• onDestoy() -> onCreate()

2. 생길 수 있는 문제

• Activity가 소멸되기 전까지의 UI 상태나 변수 값들이 초기화된다.

3. 데이터 유지를 고민해야 하는 다른 상황

• 다른 앱으로 전환 후 다시 돌아왔을 때
• 사용자가 뒤로가기 / 홈 버튼을 누를 때
• 백그라운드에 오래 있다가 시스템이 메모리 부족으로 앱을 종료할 때
• 다크모드 / 언어 변경 등 구성 변경이 발생할 때
  -> 이런 경우를 대비해 안드로이드에서는 onSaveInstanceState()를 제공한다.

[donghyun81]

onPause -> onStop -> onDestroy -> onCreate-> onStart -> onResume
순으로 실행되고 onDestroy 시점에 Activity인스턴스가 제거되고 다시 생성됩니다.
변경된 데이터가 내부 프로퍼티 생성 및 onCreate에서 초기화했던 데이터로 재생성 되기 때문에
기존에 사용하던 데이터가 다 초기화되는 문제가 발생 할 수 있습니다.
기본적으로 Activity이동은 onStop()까지 호출되어서 뒤로가기를 하면 데이터가 남아있지만,
우선 순위에 따라 onStop상태에 Activity는 강제 종료 될 수 있어서 꼭 필요한 데이터라면 관리가 필요 할 것 같습니다

[gahyunkim]

복잡한 UI를 가진 앱이 성능 저하를 겪는 주요 이유는 무엇일까요? 특히 ListView와 같이 많은 수의 아이템을 표시하는 경우 성능 문제가 더 두드러지는 이유는 무엇일까요?

[gahyunkim]

복잡한 UI를 가지는 경우, 화면을 그리는 과정에서 레이아웃 요소들을 탐색하고 처리하는 데 많은 리소스가 사용되어 과도한 메모리를 소비할 수 있습니다. 특히 뷰를 재사용하지 않는다면, 매번 새로운 뷰를 생성하게 되어 성능 저하나 메모리 문제가 발생할 수 있습니다.

또한, ListView처럼 많은 아이템을 한 번에 표시해야 하는 경우에는 스크롤할 때마다 새로운 뷰를 반복해서 생성하게 되어 성능 저하가 더욱 두드러질 것 같습니다.

[rosemin928]

1. 뷰 재사용이 안 되는 경우

• listView에서 convertView를 재활용하지 않거나 RecyclerView에서 ViewHolder 패턴을 제대로 쓰지 않으면 스크롤 할 때마다 매번 뷰를 새로 inflate하게 되어 메모리 낭비가 생긴다.

2. 과도한 뷰 계층 구조

• 뷰가 너무 많거나 중첩된 레이아웃이 많을 경우 그리는 과정이 반복되어 성능에 안 좋은 영향을 준다.

특히 listView는 RecylcerView와 비교해서 ViewHolder 패턴을 직접 구현해야 하고 레이아웃 재활용이 상대적으로 불안정하다는 점에서 특히 성능 문제가 두드러진다.

[donghyun81]

복잡한 중첩 레이아웃은

1. 값을 조회할때 각 레이아웃안에 값을 하나씩 탐색 하기 때문에
   탐색 횟수가 많아져서 성능이 저하됩니다.
2. 중첩된 View 객체가 많아져서 성능 저하

ListView는 새로운 아이템을 생성할때마다
중첩된 View를 지속적으로 생성하고 접근해야해서 위에 언급했던,
새로운 아이템을 생성할때 중첩된 View도 더 늘어나고,
각 아이템의 값을 할당하기 위해서 Id를 조회할때도 더 많은 탐색을 하기 때문에

[gahyunkim]

ListView를 효율적으로 만들기 위해 ViewHolder 패턴을 사용하는 이유는 무엇이며, 이 패턴을 적용하면 메모리 사용량과 성능에 어떤 개선 효과를 가져올 수 있을까요?

[gahyunkim]

ListView에서 ViewHolder 패턴을 사용하는 이유는 중복된 findViewById() 호출을 줄이고, 뷰 재사용을 통해 성능을 향상시키기 위함이라고 생각합니다.

ListView는 스크롤을 할 때마다 여러 아이템의 뷰를 생성하고 제거하게 되는데 이 과정에서 계속해서 findViewById()를 사용하게 되면 성능상 큰 문제를 줄 수 있습니다.

불필요한 뷰 객체 생성을 줄여 메모리 낭비를 방지하고, 스크롤시에 끊김 현상을 개선할 수 있습니다

[rosemin928]

listview에서 ViewHolder 패턴을 사용하는 이유는 성능 최적화와 메모리의 효율성을 향상시키기 위함이다.

1. ViewHolder 패턴이란?

• 뷰들을 한 번만 찾고 저장해서, 다음에 재사용할 때는 저장된 뷰를 바로 참조할 수 있게 도와주는 패턴이다.

2. 성능이 좋아지는 이유

• ViewHolder에 참조를 저장하면 xml에서 findViewById()를 통해 뷰를 찾아오는 과정을 한 번만 수행하게 된다.
• 뷰를 재사용하며 메모리가 절약된다.

[donghyun81]

ViewHolder 패턴을 사용하면,
View의 틀을 만들고 재사용해서 findViewById() 호출을 줄일 수 있어서 탐색 성능을 향상 시킬 수 있고,
View틀의 값만 바꿔주기 때문에 View 생성 자체를 줄일 수 있어서 메모리 사용량을 줄일 수 있습니다.