Нашим правилом в создании пользовательского интерфейса было создание его программно. Но недавно мы изменили этот подход и теперь наша iOS-команда может создавать UI кодом или сторибордами — в зависимости от предпочитаемых ими подходов.
Причина в том, что есть действительно хорошие вещи, если вы используете Storyboard:
- Меньше кода
- Меньше время компиляции
- Предварительный просмотр
- Предупреждения об ошибках
Основной причиной принятия решения является время компиляции.
Время компиляции: код против Storyboard
Представьте, что вам нужно изменить интервал в UIStackView.
Слева — это программный UI. Если вы измените только одну строку кода, компилятор Swift обнаружит изменения в исходном файле и скомпилирует его. Это может занять больше времени, если исходный файл зависит от других исходных файлов.
Справа используется Storyboard. Если вы измените интервал в StackView на сториборде, то ibtool скомпилирует его в несколько nib (файл NextStep Interface Build) во время компиляции.
Результаты: время компиляции раскадровки в 6.5 раз быстрее, чем в Swift.
- Swift: 46.8 секунды
- Storyboard: 7.2 секунды
Как видно из результатов, время компиляции при использовании сториборда намного быстрее, чем изменение файла.
Если вы хотите узнать параметры компиляции ibtool, посмотрите man ibtool в /Applications/Xcode.app/Contents/Developer/usr/bin.
Хотя это был главный плюс, у нас были некоторые опасения по поводу использования Storyboard:
- Проверка PR
- Конфликты Storyboard/Xib файлов
Чтобы решить эти проблемы, нам нужно знать о формате xib (расшифровывается как XML Interface Builder).
Формат xib
Storyboard/Xib — это формат XML. Это означает, что формат можно просмотреть. Иногда говорят, что файлы Storyboard/Xib трудно понять. Это правда, по сравнению с просмотром кода сториборды сложнее в понимании.
Но, познакомившись с форматом, вы можете научиться работать с ним, он похож на HTML.
Цифры в изображении означают:
1. toolVersion
Версия инструмента, использовавшегося для создания. Она может меняться при обновлении Xcode. Я настоятельно рекомендую всем членам команды использовать последнюю версию Xcode, чтобы избежать конфликтов слияния.
2. initialViewController
Указывает идентификатор начального контроллера представления в раскадровке. Если вы вызвали instanceInitialViewController(), он возвращает этот viewController.
3. device
Вы можете использовать это в предварительном просмотре макета. Любой может изменить его, но после проверки я рекомендую сбросить его на устройство вашей команды по умолчанию (например, iPhone X), чтобы избежать конфликтов слияния.
4. scenes
Сториборд может иметь несколько сцен. В сценах содержатся ViewController-ы.
5. segue
Segue — это соединение между ViewController-ами. У перехода есть свой идентификатор и идентификатор пункта назначения. Если идентификатор пункта назначения изменился, нам необходимо внимательно его просмотреть. Если нет ViewController-а с идентификатором получателя, это может привести к сбою во время выполнения.
PR review
Я покажу два примера.
- Минорные изменения
- Главные изменения (например, макет, objectId, переход и т.д.)
Небольшие изменения
Эти изменения обычно не влияют на ваш пользовательский интерфейс. Таким образом, вы можете легко просмотреть и утвердить Pull Request. Все должно быть в порядке.
- toolsVersion/версия плагина могут быть изменены автоматически, когда вы используете другую версию Xcode и редактируете макет в Interface Builder.
- rect можно изменить при смене устройства или перемещении subview. Эти небольшие изменения не должны ни на что влиять, потому что они используют autolayout.
- propertyAccessControl (Locking View) контролируется разработчиком. Я объясню это в следующем разделе.
Большие изменения
Большие изменения касаются вопросов компоновки. Я покажу вам несколько примеров.
Если вы встроили текстовые поля в UIStackView, вам нужно дважды проверить, находится ли идентификатор метки в stackView или нет.
Поле ambiguous=”YES” указывает на наличие проблемы с макетом! Так что это должно быть исправлено.
Шаблон для Pull Request
Крайне рекомендую добавить скриншот макета в PR. Чтобы побудить вашего товарища по команде добавить скриншот, сделайте шаблон пул реквеста.
Это шаблон нашей команды.
Description === Screens --- Links (JIRA / Confluence) --- Related PR --- Check Lists --- - [x] multiple devices - [x] confirmed by developer
Как избежать конфликтов слияния?
Изменения файлов вызывают конфликты слияния. Вы можете избежать этого, тщательно обрабатывая изменения файлов.
Следуя этим правилам, можно максимально избежать конфликтов слияния:
- используйте последнюю версию Xcode.
- не фиксируйте изменения, если вы не работаете над этим представлением
- блокируйте представления в сториборде и файлах XIB, над которыми вы работаете
Если ваша команда работает над одним и тем же макетом, я настоятельно рекомендую заблокировать представления, чтобы предотвратить нежелательные изменения.
Вы можете установить блокировку на любые компоненты пользовательского интерфейса (весь Storyboard, UIViewController, UIView, Segue, любые объекты, связанные с пользовательским интерфейсом, такие как Constraint), над которыми вы будете работать. Как я упоминал выше, propertyAccessControl будет добавлен в storyboard/xib файл, когда вы установите блокировку.
Изображение блокировки будет отображаться при попытке изменить элемент.
Заключение
Есть свои плюсы и минусы в использовании Storyboard/Xib. Производительность также различается в зависимости от предпочитаемого подхода к созданию пользовательского интерфейса. Но мы приняли решение использовать оба. Потому что мы можем сэкономить время компиляции и нашли хорошее решение для решения проблем, связанных с использованием сторибордов.
Кроме того, это фирменный инструмент. Apple разрабатывала инструмент IB более 34 лет. И он активно обновляется вместе с Xcode.
Я надеюсь, что наше решение поможет вам решить использовать Storyboard/Xib в вашей команде!