{"id":13473,"url":"\/distributions\/13473\/click?bit=1&hash=0230b2c9c1795327978777f68c1836f3d5cbb11c39f14294a4fd37999e00f14c","title":"\u041a\u0430\u043a Tele2 \u0441\u0434\u0435\u043b\u0430\u043b \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0434\u043b\u044f \u043f\u0440\u043e\u0434\u0430\u0436\u0438 \u043d\u0435\u0438\u0441\u0442\u0440\u0430\u0447\u0435\u043d\u043d\u043e\u0433\u043e \u0442\u0440\u0430\u0444\u0438\u043a\u0430","buttonText":"","imageUuid":"","isPaidAndBannersEnabled":false}
Дизайн
Mish

Оптимизация проекта Figma на примере большого банковского приложения

Расскажем, как мы провели оптимизацию и ускорили работу больших файлов Figma в три раза. Подтолкнули нас к этому тормозящие и не открывающиеся файлы у команды на проекте. Особенно это ощутили ребята с не самым мощным железом: файлы загружались по пять-десять минут.

В процессе поиска решения мы столкнулись с некоторыми ограничениями и багами в Figma, о которых полезно знать заранее и которые мы подробно изложим ниже.

Статья поможет избежать фундаментальных ошибок при разработке дизайн-систем. Материал будет особенно полезен дизайнерам, разработчикам и бизнесу, которые работают над проектами, где свыше пятисот макетов в дизайне.

Мы студия Mish, преимущественно сфокусированы на дизайне сайтов и мобильных приложений. За время работы мы много сталкивались с крупными проектами, в частности, в банковской сфере. В рассматриваемом случае клиент поставил нам задачу разработать дизайн двух мобильных приложений для SBI: банкинг «для взрослых» и отдельное банковское приложение «для детей», в котором есть полноценный счет, можно выполнять задания родителей, получать награды и копить на мечты. Разработка приложений осуществлялась для двух платформ.

Через полгода работы только во «взрослом» приложении появилось свыше шести сотен экранов для каждой платформы. Тогда мы столкнулись с проблемой: люди, задействованные на проекте, — разработчики, аналитики, тестировщики, заметили, что файлы Figma стали работать медленнее. А именно: долго открывались, тормозили при зуме и порой даже вылетали. Даже дизайнеры, работающие на MacBook Pro, испытывали трудности. Например, десять фреймов могли копироваться около минуты: к примеру, выделил их, нажал Cmd+C и ждешь — Figma все это время не двигается. Потом, если не повезет, выскакивало сообщение «You run out of memory». После этого приходилось перезапускать Figma и копировать фреймы по одному.

Поискав информацию в Интернете и на сайте Figma, мы нашли причину и поняли, как решить проблему. Статья, которая нам помогла🇬🇧.

Две основные причины тормозов:

  1. В одном файле расположено слишком много макетов;
  2. Основные мастер-компоненты собраны с большим количеством скрытых слоев.

И то, и другое существенно снижало основные жизненные показатели файла: занимаемую память и общее количество слоев.

Расскажем подробнее о каждом пункте:

Причина 1. В одном файле расположено слишком много макетов

Дизайн в«взрослого» приложения состоит из трех файлов:

  • файл с макетами и компонентами iOS;
  • файл с макетами и компонентами Android;
  • файл с компонентами общих для платформ иконок и графики.

Есть еще два файла с «детским» приложением, но мы не стали их оптимизировать, так как эти файлы работают быстро: в них меньше пяти сотен макетов.

Мастер-компоненты мы хранили в одном файле с макетами. На момент старта проекта это не казалось нам чем-то неправильным. Это достаточно удобно, так как не нужно переходить в другой файл, чтобы сдвинуть иконку на два пикселя. Мы думали, что при необходимости можно легко поделить этот файл на несколько: мастер-компоненты оставить в одном файле, а макеты с дочерними компонентами вынести в отдельный. Но на тот момент мы не подозревали об одной фундаментальной баге программы Figma, о которой напишем чуть позже. А пока расскажем о двух известных нам способах, которыми можно поделить один большой файл на несколько маленьких:

Способ 1. Продублировать файл нужное количество раз и в каждом дубликате удалить лишние макеты или страницы.

Нам это способ не подходил, потому что мастер-компоненты хранились в одном файле с макетами и при дублировании потеряли бы связь с дочерними компонентами в новых файлах.

Способ 2. Создать несколько новых файлов, подключить к ним командную библиотеку и скопировать в них нужные макеты из исходного файла. В исходном же оставить только мастер-компоненты, так как их, в отличие от дочерних, перенести в другой файл нельзя — это печальное ограничение Figma, о котором мы знали.

Данный способ выглядит вполне жизнеспособным. Во всяком случае, не противоречит каким-либо очевидным правилам поведения программы. Но мы не знали о том, что в Figma есть серьезная скрытая проблема: при переносе макета в новый файл многие дочерние компоненты, находящиеся в нем, теряют связь с мастер-компонентом, т.е. часть скопированных дочерних компонентов при вставке превращается в обычные фреймы. Это та самая фундаментальная бага, о которой ребята из Figma в курсе и с которой они воюют уже года два. Подробнее о проблеме тут 🇬🇧.

Подобные баги могут происходить даже при копировании и вставке макета внутри одного файла, если делать это через «Cmd+C ⟶ Cmd+V» или «Копировать ⟶ Вставить». Нам показалось, что часто это происходит на сложных компонентах, а также если компонент уже копировался и вставлялся неоднократно. Чтобы избежать этого бага, нужно сложные многосоставные компоненты копировать через зажатый Opt или Alt. Если вы сталкивались с подобной проблемой, поделитесь в комментариях своими наблюдениями.

Быстро поделить файл на несколько и избавиться от первой причины тормозов у нас не получилось, поэтому переходим ко второй причине.

Причина 2. Основные компоненты собраны с большим количеством скрытых слоев

Есть такие элементы, которые используются почти на каждом макете и отличаются лишь деталями. Например, списки. Список может быть с иконкой или без, с одним заголовком или с заголовком и подстрочником, с суммой и подстрочником или с суммой без подстрочника, с кнопкой вместо суммы или стрелкой вместо кнопки. И не забываем еще про состояние загрузки, а также все те же самые состояния на темном фоне. Выходит, что высота элемента одна, набор основных элементов примерно тот же, но их комбинация и расположение отличаются.

К примеру, вариаций блока списка высотой 64px в нашем приложении получилось свыше тридцати. Плюс в каждом состоянии может быть еще около ста разных иконок на обложке.

Когда мы создавали первые компоненты на проекте, мы обсуждали два варианта создания дизайн-системы, учитывающих все подобные состояния:

Вариант 1. Создать один компонент и расположить в нем все состояния в виде скрытых слоев.

Мы так и сделали. В тот момент нам казалось, что это достаточно удобно: не нужно плодить кучу макетов в библиотеке, а переключать состояния проще в панели слоев, выключая видимость текущего слоя и включая видимость нужного. Главное понятно называть слои и группы слоев. Первое время это действительно казалось удобным всем дизайнерам.

Но оказалось, что в Figma дочерний компонент является не просто ссылкой на мастер-компонент, а полноценным его экземпляром, занимает столько же памяти и тянет за собой все скрытые слои. Получилось, что один экземпляр элемента «тащил» за собой все тридцать скрытых и увеличивал размер файла.

Вариант 2. Создать отдельный мастер-компонент под каждый случай.

При этом стоит учитывать только вариации верстки: если при одной и той же верстке есть еще пятьдесят состояний, в которых отличается только иконка, то эта иконка вставляется в виде вложенного компонента по принципу матрешки. Замена иконки занимает пару кликов в панели компонентов. По такому же принципу можно подменять любые другие блоки, например вкл/выкл свитчер, активный/неактивный чекбокс, радио-кнопка и проч.

Изначально мы пошли по первому варианту — сделали «супер-компоненты», внутри которых учитывались все возможные состояния в виде скрытых слоев. Это привело к увеличению количества слоев и размера файла. Лучшим решением оказался второй вариант, при котором для каждого состояния элемента создается отдельный компонент.

Далее мы решили оптимизировать проект: вынести мастер-компоненты в отдельный от макетов файл и оптимизировать их структуру — убрать лишние слои, а все состояния сделать отдельными компонентами. Это должно было решить несколько проблем: общий вес проекта сократился бы, и мы получили бы систему файлов, с помощью которой было бы удобно в будущем их делить.

При этом решили не переделывать существующие компоненты, а сделать все с нуля и последовательно, экран за экраном, целиком обновить проект. Помимо решения основной задачи мы также могли почистить макеты от ненужных слоев и артефактов.

Процесс работы

Работали на «живом» проекте, на котором параллельно присутствовали разработчики, аналитики, тестировщики и представители заказчика. Задачей занимался один дизайнер, параллельно разрабатывая новые фичи и занимаясь поддержкой разработки. На переработку двух платформ ушло около месяца. Мы вели лог основных показателей файла и скринили табличку используемых Figma ресурсов (View > Resource use) при закрытии каждого раздела. Итак, что получилось?

Объективные показатели по платформам

iOS:

  • Количество слоев уменьшилось в 3 раза с 750 тыс. до 250 тыс.
  • Вес файла уменьшился в 2,3 раза с 0,89 ГБ до 0,39 ГБ.

Android:

  • Количество слоев уменьшилось в 4 раза с 940 тыс. до 230 тыс.
  • Вес файла уменьшился в 4 раза с 1,4 ГБ до 0,35 ГБ.

Файл стал работать в разы быстрее, что сразу вызвало позитивный фидбек от команды проекта. Также мы получили возможность поделить файл, но не стали пока этого делать, так как это могло ухудшить навигацию: людям приходилось бы постоянно переключаться между файлами, а скорость работы и так оптимизировалась.

В самом начале мы упоминали, что десять макетов могли копироваться около минуты. После оптимизации даже тридцать макетов начали копироваться меньше десяти секунд. Сообщение о том, что ресурсы закончились, появляться перестали.

Кстати, если ваш файл займет 2GB, он может перестать открываться, так что не доводите до такого и вовремя проводите оптимизацию. Следить за показателями тут View > Resource use.

Выводы:

  1. Если в проекте предполагается свыше тысячи экранов — храните компоненты в отдельном файле.
  2. Сразу закладывайте возможность дробления одного файла на несколько.
  3. Заранее продумайте структуру библиотеки.
  4. Если размер файла больше 700–800 МВ, следует планировать оптимизацию. Больше 1,5 GB — проводить оптимизацию немедленно, иначе есть риск на какое-то время остаться без доступа к файлу и ждать помощи от службы поддержки.
  5. Если нужно провести оптимизацию, обсудите это с заказчиком, объясните, почему это важно, договоритесь о сроках и бюджете заранее.
  6. Периодически проводите тестирование скорости работы файлов на слабом железе.
  7. Изучайте матчасть, читайте статьи на английском. Это расширит ваш кругозор и поможет лучше понять особенности работы с вашим рабочим инструментом.
0
57 комментариев
Написать комментарий...
Юрий Б.

Даже дизайнеры, работающие на MacBook Pro, испытывали трудности

Ответить
Развернуть ветку
Andrew

По опыту, на относительно мощных маках в основном работают дизайнеры и iOS-разработчики. У большинства людей в команде стандартные офисные ПК. Команды на таких проектах большие — 30–50 человек: дизайнеры, тестировщики, бизнес-аналитики, проджект-менеджеры, представители заказчика, разработчики, редакторы, юристы и тд. Если проект начинает тормозить на прошке, это значит, что бОльшая часть команды страдает в разы сильнее.

Ответить
Развернуть ветку
7 комментариев
Михаил Анюков

Взял некоторые советы, благодарочка

Ответить
Развернуть ветку
Pixel Lens

Хорошая статья, молодцы! 

PS: что-то не так с логотипом московской биржи - у нее будто строук не удалили или пикселёк не дотравили:

Ответить
Развернуть ветку
Mish
Автор

Да знаем, спасибо, бага от SVG уже в следующем релизе поправим, новый сайт пока в бетте.

Ответить
Развернуть ветку
7 комментариев
Oleh Shvedetsky

"Также мы получили возможность поделить файл" – так вам удалось поделить файл таким образом, чтобы сохранить связь инстансов с мастер-компонентами в файлах дупликатах?

Ответить
Развернуть ветку
Andrew

Мы не стали пока этого делить файл, так как скорость работы системы и так выросла в ходе оптимизации. Мы вынесли мастер-компоненты в отдельные файлы и теперь сможем поделить файл с макетами на любое количество частей. Тестировали эту возможность, при необходимости — сделаем это за 5–10 минут. 

Ответить
Развернуть ветку
Kuznetsov.website

Спасибо, отличная статья!

Ответить
Развернуть ветку
Александр Куликов

Как раз сегодня столкнулся с этим. Благодарочка в виде апвоута!

Ответить
Развернуть ветку
Захар Лобанов

Спасибо, тоже пересмотрю свои проекты на работе, фронты жалуются на торможение. Очень много скрытых слоев в компонентах.
Пока лечили это переносом страниц в отдельные проекты.

Ответить
Развернуть ветку
Александр Воробьёв

Спасибо за статью, у меня 3 вопроса:
1. Итак, вы решили не делить один большой файл с макетами приложения на несколько файлов. Не боитесь наступить на те же грабли, на которые наступили при создании UI-кита в одном файле с макетами? Насколько понял, у вас проект рос, растёт и будет расти. Собственно, сколько оптимизацией одного файла не занимайся, макетов будет всё больше и больше. В итоге у вас просто закончится место в файле и вы вынуждены будете дробить всё на несколько файлов. Вы специально ждёте этого момента? :) 
2. Что с бэкапами? Если что-то критичное случится (тьфу-тьфу) на конкретной страничке файла, то бэкапить придётся весь файл со всеми страницами. А если придётся бэкапиться на несколько недель, а то и на месяц назад, то в трубу улетает весь труд за несколько недель/месяц. От этой мысли страшно не становится?) 
3. Что там у вас по autolayout? Уже юзаете его в компонентах или ждёте пока фигма доведёт его до ума?

peace 🙌🏻

Ответить
Развернуть ветку
Yury

При таких объемах (в одном проекте например) и если предположить, что это еще будет рости дальше (возможно в разы), то заниматься заниматься дизайном (в статике) уже выглядит избыточным. В какой то момент такое количество экранов (которые в итоге отличаются допустим на 2-3 элемента) будет настолько большим, что поддерживать будет нереально. 

Адекватный выход, похоже, это писать код — и объем работы сократится и поддержка проще и быстрее, места меньше, навигация проще и с версиями все понятно. 
При этом не обязательно дизайн-студии брать всю разработку. Если сам процесс разработки организован нормально, то UI layer можно писать отдельно от моделей. Это в любом случае хорошая практика

Ответить
Развернуть ветку
1 комментарий
Andrew

Отвечу от Mish, так как я принимал участие в процессе.

1. В ходе оптимизации мы вынесли мастер-компоненты в отдельные файлы. Теперь можем делить файл с макетами на любое количество частей методом дублирования и удаления лишних разделов. Мы не стали пока этого делать, так как скорость работы системы и так выросла. При необходимости поделить — сделаем это за 5–10 минут.

 2. В фигме есть история версий. В день автоматически делаются десятки бэкапов. Каждый из них хранится на сервере Figma. Можно восстановить файл таким, какой он был вчера вечером или в полдень 19 декабря 2019 года.

 3. Autolayout очень любим и активно пользуемся на каждом проекте. При помощи пары лайфхаков можно делать удобные штуки. Например такие:

Ответить
Развернуть ветку
Константин Витевский

ребят, огромное спасибо за статью, добавил в закладки

Ответить
Развернуть ветку
Захар Лобанов

Пункт меню View >  Resource use.
Почему-то у меня такого пункта нет, версия фигмы Release 85

Ответить
Развернуть ветку
Mish
Автор

Смотри не системное меню, а меню фигмы :)

Ответить
Развернуть ветку
1 комментарий
Sasha Belichenko

Не в том View ищите.
Вам надо нажать на гамбургер меню Фигмы -> View -> Resource Use

Ответить
Развернуть ветку
2 комментария
Максим Тимшин

Я решаю проблему тормозов так: в одном файле создаю несколько page и раскидываю по ним все макеты сайта. 

Ответить
Развернуть ветку
Andrew

Когда макетов 300–400 это действительно может отсрочить возникновение проблем. Но когда одних page уже штук 20 и в каждом из них макетов по 50–100, нужны более радикальные меры :—)

Ответить
Развернуть ветку
8 комментариев
Denis Bystruev

При 500 макетах и работает быстро?  Что-то мой дизайнер делает не так.

Ответить
Развернуть ветку
Mish
Автор

Мы всегда рады подсказать и помочь! Пусть обращается!

Ответить
Развернуть ветку
Yury

Может быть там растровых картинок много? Из за этого может тормозить даже если сам файл не очень большой. 

Ответить
Развернуть ветку
Marfa Razmakhova

Ребят, у вас «Разлел» на скринах

Ответить
Развернуть ветку
Mish
Автор

🙄 Никто ничего не видел! Фотошоп! Нас подставили!

Ответить
Развернуть ветку
Andrey Antar

Была такая проблема. Мы просто расфигачили файл на несколько файлов и стало проще)))

Ответить
Развернуть ветку
Tony Fox

В фигме размер файла самого проекта ограничен 3 гб. Я недавно сам себе проблем подкинул, когда решил сделать компонент для логотипов и засунул туда около 30 изображений. При копировании компонента, копировались и скрытые изображения. А на одном экране таких компонентов могло быть более десяти (делал интерфейс для инвестиционной платформы). Когда счётчик слоев приблизился к нескольким миллионам, фигма перестала открывать проект и предложила только восстановить предыдущую копию. 

Ответить
Развернуть ветку
Mish
Автор

"Кстати, если ваш файл займет 2GB, он может перестать открываться, так что не доводите до такого и вовремя проводите оптимизацию." :)

Ответить
Развернуть ветку
4 комментария
Читать все 57 комментариев
null