티스토리 뷰
클래스의 공식 기능은 아래와 같습니다.
자식의 크기를 자식의 고유 높이로 조정하는 위젯입니다.
이 클래스는 예를 들어 무제한 높이를 사용할 수 있고 자녀가 더 합리적인 높이로 크기를 조정하기 위해 무한 확장을 시도하려는 경우에 유용합니다.
flutter에서 위젯작업을 하다보면,
세로 사이즈가 동적으로 변하는 경우가 있습니다.
가령 DB에서 데이터를 가져와 바인딩해주는데, 그 내용이 길어질수도, 짧아질수도 있다고해서 match_parent와 같은
Expand를 써버리면,
화면에서 무한대로 늘어나면서 오류가 발생합니다.
이때,
바인딩이 된 이후, 레이아웃을 다시 계산하면서 "너의 Height는 100으로 조정하면 되겠구나!!" 하면서 세로 사이즈를 만들어주는 역할을 합니다.
하지만...
이 클래스는 최종 레이아웃 단계 전에 예상 레이아웃 단계를 추가하기 때문에 상대적으로 비용이 많이 듭니다. 가능하면 사용하지 마십시오. 최악의 경우 이 위젯은 트리 깊이에서 O(N²) 레이아웃이 될 수 있습니다.
이렇게 안내하고 있습니다.
정말정말 어쩔수 없는 경우를 제외하고는 쓰지마라! 입니다.
개발을 하다보면, 기능구현이 우선이기 때문에 일단은 작동되게는 만들었다손 치더라도...
리소스를 제대로 관리하는지, 성능은 문제가 없는지 체크를 하면서
과연 내 프로젝트에는 IntrinsicHeight를 쓴적은 없는가?
있다면 꼭 필요했는가?
점검의 시간을 가져보겠습니다.
제가 작업하던 옛소스를 검색하면서 IntrinsicHeight를 쓴부분을 찾아봤습니다.
마이페이지 스크린중에서 위와같은 부분에 사용되었습니다.
이건 세로로 무한 늘어나는 부분도 아닌데 왜 쓴거지???
하면서 IntrinsicHeight를 제거해보았습니다.
각 항목옆에 가로로 구분선을 지어주는 라인이 사라졌습니다.
VerticalDivider(thickness: 1, color: AppTheme.textColor3,),
바로 위 부분이 적용이 안되었던건데요.
VerticalDivider는 세로값이 지정되어 있지 않으니, height:0으로 간주되어 화면에 그리질 못한겁니다.
그래서, IntrinsicHeight로 위젯의 세로값을 계산하게 해주니, 라인을 그릴 수 있게 되었던건데요.
이게 과연 리소스를 낭비해가면서까지 필요한가? 라고 생각해보면, 당연히 아니죠!
이제 IntrinsicHeight를 제거해야겠습니다.
가장 큰 문제는 위젯에 Height이 지정되어 있지 않았기 때문이니까
IntrinsicHeight을 Container위젯으로 변경하고, height을 60 지정해 주었습니다.
물론 저 height 60이란것도, 스마트폰 해상도에 따라서 사이즈 오류를 또 낼수도 있습니다.
이 부분은 다음에 또 다뤄보기로 하구요.
결론은...
IntrinsicHeight을 쓴곳이 있다면 다시한번 살펴보고, 성능을 위해서 제거할 수 있다면 제거합시다!