오늘은 Storyboard에 대해서 얘기해보려 한다.
iOS 개발을 시작했을때 Storyboard가 굉장히 신기했고, 재밌었다.
Drag & Drop과 오토레이아웃을 지정해주면 화면이 뚝딱이니까!
오늘은 왜 Storyboard를 선호하지 않게 되었는지와 어떤 기준을 가지고 있는지에 대해 프로젝트를 진행하면서 느낀점과 함께 얘기해보려 한다.
물론 내 개인적인 생각이니 다른 의견이 있다면 말해주면 좋겠다.🙇♂️
협업으로 보는 Storyboard
iOS 프로젝트에서 첫 협업은 이미 80% 정도 화면이 나온 프로젝트였다.
로딩 속도
처음 Storyboard 파일을 여는데 너무 느렸다....
진짜 너무 느렸다...ㅋㅋㅋㅋㅋㅋ
느리고... 화면이 로딩되는 시간도 오래걸렸다.
이전에 공부하며 실습했던 프로젝트에서는 볼 수 없던 속도였다.
❗️Storyboard의 장점으로 빠른 초기화를 들 수 있다.
❗️하지만, 앱이 커지면 Storyboard 로딩 시간이 길어지게 된다.
흐름 파악
본격적으로 개발을 하기 전에 화면 흐름을 파악해야하는데 이미 Storyboard에서 화면 흐름 파악하는게 너무 어려웠다.
지금 생각해보면 Storyboard를 기능에 따라 좀 더 분리했으면 흐름 파악이 빠르지 않았을까라는 생각이 든다.
그 당시에는 하나의 Storyboard에 화면들이 뭉쳐져 있었다.
당시에는 화면 이동시 Segue를 사용하지 않았다.
즉, Storyboard에는 그냥 여러 화면들이 놓여져 있었다.
화면 흐름을 파악하기 위해서는 ViewController에서 화면 이동하는 코드를 확인하면서 어떤 Storyboard인지, 그리고 그 중에서 어떤 identifier를 가졌는지 확인해야 했다.
그리고 해당 Storyboard를 열어 화면들을 하나씩 클릭하며 identifier를 확인했다.
사실 이 과정 자체가 엄청난 overhead라고 생각한다.
만약 Segue를 사용했다면 어땠을까?
Segue를 사용했다면 Storyboard 상에서 화면의 흐름을 파악하는게 쉬워지긴할거 같다.
(화살표를 쭉 따라가면서 볼 수 있으니까)
하지만 하나의 Storyboard에 화면이 많아진다면?
과연 엄청난 화살표 속에서 내가 원하는 화면들을 쭉쭉 따라갈 수 있을까?
나는 아니라고 생각한다.
❗️Storyboard에서 앱의 흐름을 한 눈에 볼 수 있는 점은 장점이라고 생각한다.
❗️앱이 커지면서 Storyboard에 화면들이 많아지다보면 가독성이 떨어진다.
Git
새로운 화면 B를 추가하면서 이전에 있던 화면 A에 이동하는 버튼을 추가했다.
A 화면은 다른 팀원이 수정하고 있던 화면였는데 merge하려니 Conflict가 났다...
Conflict를 해결하기 위해 Storyboard 코드를 열었는데...ㅎㅎ
해결하느라 엄청 고생했던 기억이 있다.
지금이라면 팀원과 역할 분담을 확실히해서 Conflict나지 않도록 할거 같지만 그 당시에는 잘 몰랐다...
❗️Storyboard는 코드를 몰라도 view를 그릴 수 있고, 빌드하지 않고 다양한 디바이스에 화면을 적용한 모습을 확인할 수 있다.
❗️하지만, Storyboard 내부는 XML로 작성되어 있고, 단순하게 코드를 비교해서는 바뀐 곳을 알아차리기 어렵다.
❗️ 따라서 팀원과 화면을 수정하게 되는 경우 Merge Conflict가 발생할 가능성이 많다.
UI 작성
위에서 내가 프로젝트를 진행하면서 느꼈던 부분들을 정리했다.
물론 내가 느낀거이므로 다른 의견이 있을 수 있다.
내가 생각해도 "Storyboard를 좀 더 잘게 쪼갰으면 어떘을까?"라는 생각이 드는 부분들도 있어서...
이제 UI를 작성하는 방법인 Storyboard, XIB, Code의 장단점을 알아보자.
Storyboard
장점
- 가장 큰 장점은 화면이 직접적으로 눈에 보이기 때문에 직관적이다.
- 구현하기 쉽다.
- static cell을 사용할 수 있다.
- 최초의
ViewController하나만 초기화된 후Segue에 따라서 동적으로 메모리에 올라간다. - App을 빌드하지 않아도 다양한 디바이스 화면을 확인할 수 있다.
단점
- 가장 큰 단점은 협업시 Merge Conflict 가능성이 높고, 해결이 어렵다.
Storyboard는 의존하는 모든 ViewController를 함께 복사/이동해야하므로 재사용하기 까다롭다.Storyboard로 만든 View를 사용하기 위해서는Identifier를 부여하고, 연결해줘야 한다.Storyboard는 data의 흐름에는 관여하지 않는다.Segue의 이름이 잘못 되거나, 잘못된Identifier사용시 runtime error가 발생한다.
(빌드 전에는 알 수가 없다.)
XIB
화면이 눈에 보이고 재사용하기 편해 XIB도 즐겨 사용한다.
또한, Conflict가 나도 Storyboard보다 규모가 작기 때문에 부담이 덜하기도 하다.
장점
- View를 모듈로 분리할 수 있다.
모듈로 분리하면 테스트 및 디버깅이 쉬워진다. - Merge Conflict의 문제를 가지고 있긴하지만
Storyboard에 비해 부담이 적다. - 재사용하기 용이하다.
단점
- XIB는 필요할때만 메모리에 로드된다.
즉, 필요할 때 외에는 메모리에 올라가 있지 않으나 로드 시간이 걸릴 수 있다.
Code
화면을 그리다 보면 그림자가 있는 view나 모서리가 둥근 view가 필요할 때가 있다.
이럴때는 Code를 사용한다.
장점
Storyboard,XIB로 구현한 모든 화면을Code로 구현할 수 있다.Storyboard,XIB로 구현할 수 없는 모든 화면을Code로 구현할 수 있다.- 다이나믹 레이아웃에서는
Code로만 구현할 수 있는 경우가 있다. Storyboard,XIB는 여러 과정을 거쳐 최종적으로Code로 변환되지만Code는 그런 과정을 거치지 않는다.Code로 구현된 화면은 재사용하기 쉽다.- Merge Conflict 해결이
Storyboard,XIB에 비해 쉽다.
단점
Storyboard나XIB와 달리 view가 보이지 않으므로 동적으로 화면을 파악하기 어렵다.- 제약 조건들을 직접 코드로 작성해야하므로 코드의 양이 많다.
마무리
오늘은 UI를 작성하는 여러 방법들을 알아봤다.
각자의 장단점을 정리하고 나니 앞으로 유의할 점에 대해서 생각해보게 됐다.
그럼 이만👋
