✨[Feat/fix]🐞 영상 버퍼링, 레이아웃 버그 수정 및 음악 미리듣기 기능 구현 (필수 과제 구현 완료)

[coduhee]

영상 재생 시점 수정: AVPlayerItem.Status의 값이 (.readyToPlay)인 시점에 player를 play하여 버퍼링 버그를 잡았습니다.

영상 레이아웃 수정: 오토레이아웃이 설정되기전에 영상이 play되어 레이아웃이 0으로 찌그러져있던 문제를 contentView.bounds를 플레이어 레이어에 대입해 버그를 잡았습니다.

미리듣기 오디오 재생: 리스트에서 곡을 선택하면 해당 음원이 재생되도록 구현했습니다.

재생 상태 UI 연동: ReactorKit의 State로 재생 중인 URL을 관리하여, 재생 중인 셀에만 dimView와 파동 아이콘(Indicator)이 뜨도록 데이터 흐름을 연결했습니다.

오디오 매니저 도입: 싱글톤 패턴의 AudioManager를 만들어, 화면을 넘나들거나 여러 곡을 눌러도 소리가 절대 겹치지 않도록 최적화했습니다.

예외 처리: 미리듣기 URL이 없는 곡을 클릭할 경우, Reactor 단에서 방어 로직을 타게 하여 에러 팝업을 띄우도록 디테일을 챙겼습니다.

[gemini-code-assist]

Code Review

이번 PR은 영상 버퍼링 및 레이아웃 버그를 수정하고, 음악 미리듣기 기능을 추가하는 등 많은 개선 사항을 포함하고 있습니다. 전반적으로 기능 구현은 잘 이루어졌으나, 앱의 성능, 테스트 용이성, 그리고 유지보수성을 향상시키기 위해 몇 가지 구조적인 개선이 필요해 보입니다. 주요 피드백은 다음과 같습니다:

• AudioManager를 싱글톤 대신 의존성 주입을 사용하도록 리팩토링하여 테스트 용이성을 높이는 것을 제안합니다.
• AVPlayer를 재사용 가능한 셀(UICollectionViewCell) 내에서 직접 관리하는 대신, ViewController에서 단일 인스턴스로 관리하여 리소스 사용을 최적화하고 잠재적인 성능 문제를 방지해야 합니다.
• 상태 변경에 따른 UI 업데이트 방식을 보다 반응형 패러다임에 맞게 수정하여 코드의 일관성과 안정성을 높이는 것을 권장합니다.

[gemini-code-assist]

현재 SearchCollectionViewCell 내부에 AVPlayer 인스턴스를 직접 생성하고 관리하고 있습니다. UICollectionViewCell은 재사용되기 때문에, 각 셀이 자신만의 AVPlayer를 가질 경우 여러 심각한 문제가 발생할 수 있습니다:

1. 과도한 리소스 사용: AVPlayer는 무거운 객체입니다. 화면에 여러 비디오 셀이 동시에 보이면 다수의 AVPlayer 인스턴스가 생성되어 메모리와 CPU 사용량이 급격히 증가하고, 앱 성능 저하 및 비정상 종료의 원인이 될 수 있습니다.
2. 재생 관리의 복잡성: ViewController가 visibleCells를 순회하며 각 셀의 비디오를 직접 제어(playVideo, pauseVideo)해야 하므로 ViewController와 Cell 간의 결합도가 높아집니다.

개선 방안:
ViewController 레벨에서 단 하나의 AVPlayer 인스턴스를 관리하는 것이 좋습니다.

• ViewController가 AVPlayer를 소유합니다.
• 사용자가 스크롤하여 특정 비디오 셀이 화면 중앙에 오거나 재생 조건이 충족되면, ViewController는 해당 셀의 비디오 URL로 AVPlayer의 AVPlayerItem을 교체합니다.
• AVPlayerLayer를 해당 셀의 contentView.layer에 추가하여 비디오를 표시합니다.
• 셀이 화면 밖으로 사라지면 AVPlayerLayer를 셀의 레이어에서 제거합니다.

이 방식을 통해 AVPlayer 인스턴스를 하나만 유지하여 리소스를 효율적으로 사용하고, 재생 로직을 ViewController에서 중앙 집중적으로 관리하여 코드 구조를 개선할 수 있습니다.

References

1. 셀 재사용 관리를 잘못하여 눈에 보이는 UI 버그나 리소스 누수를 유발할 수 있는 경우 P1(high)으로 분류해야 합니다. 각 셀에 무거운 AVPlayer 객체를 할당하는 것은 심각한 리소스 문제를 일으킬 수 있습니다. ^(link)

[coduhee]

고침

[gemini-code-assist]

AudioManager가 싱글톤으로 구현되어 있어 앱의 다른 부분과 강하게 결합됩니다. 이는 유닛 테스트를 어렵게 만들고, 오디오 재생 로직을 다른 구현으로 교체하기 어렵게 만듭니다. 예를 들어, HomeViewController나 SearchViewController를 테스트할 때 실제 AVPlayer에 의존하게 되어 테스트가 복잡해지고 느려질 수 있습니다. 의존성 주입(Dependency Injection)을 사용하여 이 문제를 해결하는 것이 좋습니다.

1. AudioManagerType 프로토콜을 정의합니다.
2. AudioManager가 이 프로토콜을 준수하도록 합니다.
3. SceneDelegate에서 AudioManager 인스턴스를 생성하고, 이를 필요로 하는 뷰 컨트롤러의 생성자를 통해 주입합니다.

이렇게 하면 테스트 시에는 실제 AudioManager 대신 오디오 재생 동작을 흉내 내는 가짜 객체(mock object)를 주입하여, 뷰 컨트롤러의 로직을 독립적으로 테스트할 수 있습니다.

References

1. 직접적인 전역/공유 의존성 사용은 테스트 용이성과 유연성을 크게 저해할 때 P1(high)으로 분류되어야 합니다. 싱글톤 패턴은 전역 상태에 대한 의존성을 만들어 유닛 테스트를 어렵게 합니다. ^(link)

[coduhee]

일부러 싱글톤으로 한거임

[gemini-code-assist]

현재 playingURL 상태가 변경될 때마다 visibleCells를 순회하며 직접 UI를 업데이트하고 있습니다. 이 방식은 여러 문제를 가질 수 있습니다:

1. 불완전한 업데이트: 현재 보이지 않는 셀(스크롤해야 보이는 셀)의 상태는 업데이트되지 않아, 스크롤 시 재생 상태가 올바르게 표시되지 않을 수 있습니다.
2. 반응형 패러다임 위반: ReactorKit과 같은 반응형 프레임워크를 사용하는 목적은 상태(State)가 변경되면 UI가 자동으로 업데이트되도록 하는 것입니다. 현재 코드는 상태 변경에 따라 수동으로 UI를 조작하고 있어 반응형 패러다임을 거스릅니다.

configureCell 클로저에서 이미 isPlaying 상태를 기반으로 UI를 설정하는 로직(cell.updatePlayUI(...))이 있으므로, 이 로직을 유일한 진실의 원천(Single Source of Truth)으로 활용하는 것이 좋습니다.

playingURL이 변경될 때 collectionView.reloadData()를 호출하여 전체 셀의 UI를 다시 그리도록 하는 것이 더 간단하고 반응형 패러다임에 부합하는 해결책입니다. 이렇게 하면 visibleCells를 순회하는 코드를 제거하고 코드의 일관성을 높일 수 있습니다.

                    // 재생 이미지
                    self.collectionView.reloadData()

References

1. 여러 제어되지 않는 소스에서 UI 상태를 변경하면 렌더링이 일관되지 않을 수 있으므로 P1(high)으로 분류해야 합니다. 현재 UI 상태는 configureCell과 subscribe 블록 두 곳에서 변경되고 있어 잠재적인 비일관성을 유발할 수 있습니다. ^(link)

[coduhee]

.reloadData()하는건 너무 비효율적일거같음 변경될때마다 컬렉션뷰를 다 갈아엎으면 너무 낭비고 사용자 눈에 깜빡거리는게 눈에 보일거같음

[gemini-code-assist]

HomeViewController에서와 동일한 문제가 여기서도 발견됩니다. playingURL 상태가 변경될 때 visibleCells를 직접 순회하여 UI를 업데이트하는 방식은 비효율적이며 반응형 프로그래밍 패러다임에 맞지 않습니다.

configureCell에 이미 재생 상태에 따른 UI 설정 로직이 있으므로, playingURL이 변경될 때 collectionView.reloadData()를 호출하여 데이터 소스를 통해 UI를 일관성 있게 업데이트하는 것이 좋습니다.

                    // 재생 이미지
                    self.collectionView.reloadData()

References

1. 여러 제어되지 않는 소스에서 UI 상태를 변경하면 렌더링이 일관되지 않을 수 있으므로 P1(high)으로 분류해야 합니다. 현재 UI 상태는 configureCell과 subscribe 블록 두 곳에서 변경되고 있어 잠재적인 비일관성을 유발할 수 있습니다. ^(link)

[coduhee]

우우우