티스토리 뷰
원래 블로그 제목을 뻘짓으로 지을려고 했을 정도로 간단한 문제를 빙빙 돌아서 해결하는 경향이 짖다. 시간낭비로 인한 멘탈 붕괴는 덤.
나 같은 사람이 있다면 조금이라도 도움이 되길 바라며 시리즈를 써보기로 했다.
내 나쁜 코딩 습관은 생각 하던 결과가 나오지 않을 때 디버깅과 코드 체크를 매우 매우 매우 비효율적으로 한다는 점이다.
한번 코드를 뒤지고 나면 열은 다 깨져있고 온통 주석칠에 원인을 찾고나면 이전 커밋 버전을 다시 불러와 작업을 이어 나갈 정도로 더 이상 써먹지 못하는 코드 상태가 된다. 매번 고쳐야 하는 걸 알면서도 원하는 결과가 안나온다는 빡침모드에 들어서면 원인부터 찾고보자 상태가 되버려서 바꾸기가 쉽지 않다...
무튼간 오늘의 뻘짓은 matchedGeometryEffect 적용문제인데 한줄 요약하자면
matchedGeometryEffect를 적용했음에도 불구하고 전환되는 애니메이션이 크기가 제대로 변하지 않거나 프레임이 끊기거나 무튼간 좀 이상하다면 matchedGeometryEffect Modifier를 적용할 View 바로 밑으로 순서를 옮겨라
코드 순서만 바꾸면 되는건데 4시간을 버렸다! 와! 대단해!
밑은 원인과 시도해본 가정들.
이런 네모네모 리스트가 있고
클릭하면 Hero 애니메이션으로 이런 직사각형으로 변해야 하는데
이따구로 양 쪽의 뷰가 페이드 인 아웃으로 왔다갔다 보여진다.
추정 1 ->자꾸 뷰가 Transition이 기본으로 opacity 값이 들어있으니 transition이 원인일 것이다. 그러므로 AnyTransition에 animatableModifier를 구현해서 뷰가 보여질 시에는 무조건 오파시티가 1값으로 사라질시에는 0으로 주자
결과 ->그럴듯 한 결과가 나오나 애니메이션 시작 및 끝 부분에서 오파시티를 1에서 0으로 바꾸는 과정에서 깜빡임이 생길 수 밖에 없어서 원하는 아웃풋이 나오지 않으며 차후 뷰 구성 코드에도 악영향을 준다.
추정 2 ->frame(maxWidth:)나 GeometryReader가 정상적인 크기가 변하는 애니메이션을 만드는 계산 과정에 영향을 줄 것이다.
결과 ->전혀 상관 없음
추정3 ->혹시 내가 matchedGeometryEffect를 처음부터 잘못 알고 있던게 아닐까? 커스텀 뷰는 애초에 불가능했던 것인가?
결과 ->전혀 문제 없음
추정 4 ->forEach문에서 matchedGeometryEffect에게 구별할 수 있도록 id를 뿌려주는데 리스트의 아이템들이 늘어날 수록 id를 각각 비교하는 시간이 늘어나서 즉각적으로 애니메이션이 일어나야 하는 상황에 늦게 연산이 되어서 이상하게 나오는 것이 아닌가?
결과 ->전혀 문제 없음 애초에 이 추정 자체가 비동기를 공부했다면 말도 안되는 소리라는 걸 진작에 깨달았어야 했다.
추정 5 ->원래 아이템의 경우 백그라운드에 블러값을 주기 위해서 보여질 아이템의 크기보다 2배 이상 크고 clipshape로 원하는 크기만큼 잘라줘서 사용했는데 이 잘려진 뒷부분의 뷰의 frame 때문에 예상치 못한 아웃풋이 나오나?
결과 -> 위에 보듯이 단순한 Rectangle로 아이템의 뷰를 변경했음에도 아무 상관이 없다.
이거랑 쓰기도 부끄러운 말도 안되는 추정 몇개를 해보느라 귀한 주말의 하루를 날렸다.
정말 능력있는 사람이 어서 되고 싶다. 열심히 하자.