Всем привет тем кто смотрит нас на Ютюбе у нас для вас перед докладом есть одно небольшое но очень важное объявление в скором времени у нас выйдет целый бесплатный курс для начинающих по flator разработке всем кто хочет его посмотреть подписывайтесь на канал и следить за обновлениями Итак всем привет Сегодня у нас доклад разбор опросов собеседования на флаттер для начинающих А сегодня мы разберём 10 самых часто задаваемых вопросов на собеседованиях на позицию Джуна на флатере как на них можно ответить и это всё будет исходя из
00:00:00 - 00:01:05
собственного опыта собеседований и рабочего экспириенса первое самое распространённый вопрос - Это вообще А зачем использовать флаттер какие у него есть преимущества недостатки тут кандидат может перечислить что-то Из своего опыта Может взять примеры которые на официальном сайте flatra есть как здесь Но и собственно опыта могу сказать следующее значит во-первых у флаттера есть несомненный плюс Это единый кодовая база которая позволяет увеличить скорость разработке и из-за этого также выходит высокое масштабируемость потому
00:00:33 - 00:01:37
что 99 процентов кода оно портируется на Android iOS веб десктоп и так далее немаловажным плюсом flatra является декларативная верстка те кто писали в оперативном подходе понимаете о чем речь у флаттер есть такая особенность которая сейчас уже есть и на котлине в том числе это Hot reloade и hotterstarter кто опять же пробовал их использовать знает насколько крутая штука И насколько это сокращает время разработки Ну и не стоит забывать то что флаттер он довольно молодой у него сформировано довольно
00:01:04 - 00:02:08
крутое комьюнити поддержка видела огромное количество библиотека которая выложены на pubg и неимоверное количество статей Из минусов уже можно выделить это высокое требование к специалисту потому что хоть мы можем писать сразу под Android iOS но некоторые вещи Мы обязаны знать и изнатива поэтому среди требований к флота разработчику зачастую можно увидеть требования о том что нужно хотя бы какие-то базовые знания по одной из систем там по Android или IOS это связано в первую очередь например с тем
00:01:37 - 00:02:39
что человек который пишет Приложение он должен знать некоторые особенности подписки к примеру как вообще происходит процесс запуска и так далее соответственно больше платформ больше требований к опыту специалиста И следующий минус это достаточно субъективная вещь но я не могу не сказать то что Дарт он не такой сладкий как его нативные аналоги у него не так много синтаксического сахара как есть к примеру в котлели насчет лифта не уверен он не особо нравится Но вот по сравнению с котлином Дарт слегка отстаёт второй
00:02:07 - 00:03:10
вопрос который вы скорее всего услышите на собеседовании это уже всем приевшийся Чем отличается стоит если рассматривать картинку Ну сам UI как функцию от стейта то соответственно логично что стейтс - это те виджеты которые не имеют состояния какого-то внутреннего и зависят только от родителей Я не перерисовываются только когда родители об этом скажет А вот stateful виджеты они уже самостоятельные у них есть свой State они могут сами себя перерисовать через сайт State могут регулировать себя и так далее В основном вызов setta ведет
00:02:39 - 00:03:47
к тому что на следующей трассе данный элемент чуть позже мы о них поговорим он помечается флажком о том что ему требуется Перестройка Но есть один лайфхак что при помощи этой штуки вы можете запускать обновления даже stadles виджетов кто пробовал те знают О чём это в этом нет никакого смысла но так можно делать третий вопрос естественно Раз уж мы говорим о стейте такие ещё существуют способы и его управления Ну если рассматривать стоит в контексте отдельного виджета тут тут в целом всё понятно но здесь вопрос скорее будет про
00:03:12 - 00:04:19
архитектурный подход потому что флаттер какая-то более-менее серьёзная разработка она невозможна без использования чётко архитектуры просто по той причине что во-первых вы сами себя можете запутать и во-вторых другим будет очень тяжело разобраться коде в основе практически каждого архитектурного подхода лежат базовые принципы главный из них это использование Это связано с тем что у нас дерево виджетов она строится сверху вниз таким образом используя провайдер или value listenable или changendifire можно
00:03:46 - 00:04:54
изменять состояние Извне один из самых популярных подходов для контролирования стейта это использование блока блок расшифровывается как бизнес компонент и представляет собой некоторый мост между позволяет это сделать следующее То есть если мы просто бы напрямую делали связку то у нас бы зашивалось логика в юаре это как бы не хорошо нехорошо потому что у нас идет нарушение разграничения соответственно блок призван исправить данную проблему тем самым что он представляет собой некоторое звено которое уже описывает логику И таким
00:04:19 - 00:05:30
образом UI знает о данных которые он должен выразить но не знает Конкретно что он должен с ними делать один из самых популярных архитектурных подходов второй тоже один из самых популярных пришел во флаттер из Веба это архитектурный подход на основе редакса в отличие от блока здесь основными элементами являются не какие-то отдельные страницы со своей логикой А в редаксе ядром является наличие глобального стейта приложения которым обращается уже все остальные окна данный подход может использоваться
00:04:56 - 00:06:01
в комбинации с блоком к примеру Но это делается уже в каких-то очень больших приложениях где это действительно необходимо третьим архитектурным решением является не уверен правильного произнести К сожалению о нём я мало знаю но также можете упомянуть его на собеседовании потому что к примеру это один из основных архитектурных подходов которые используются в Яндексе данный подход он также основан на провайдере и работает примерно по той же логике Ну это конец Конечно стоит упомянуть про getax это не
00:05:27 - 00:06:29
самое Она хорошая так скажем архитектурные подходы по той причине что у людей которые с ним работали были так скажем плохие ассоциации в нашей компании это считается моветоном использовать соответственно поэтому мы стараемся избегать четвертым опросом который Вам скорее всего сдадут это вообще это понятие ключей во флаттер ничего не используется Вы можете сразу сказать что основное Что можно делать ключами это во-первых то что вы получаете как бы некоторые степени указатель на конкретный виджет с помощью
00:05:59 - 00:07:00
данного указателя к примеру Вы можете обратиться к его ренде роуджикту и вытянуть данные об этом Вите э например на экране его позицию размеры и так далее чуть дальше я расскажу про глобалки и почему это считается не ну не самым лучшим образом но зачастую он довольно полезен Также вы можете обратиться к контексту какого-то виджета или стоит и Вы даже можете сделать проверку на вообще существование данного виджета второй неочевидный подход это перерисовка виджеты через под включаем Чуть позже я расскажу о том что ключ определяет
00:06:30 - 00:07:39
элемент в дереве Но если вы изменяете ключ У виджета то на следующей итерации данный виджет будет пересоздан соответственно использование уникального ключа позволяет вам перерисовать виджет вы меня спросите А зачем это надо по факту Вы можете использовать просто стоит где-то выше или использовать архитектурный реактивный подход но я бы сам не смог ответить на данный вопрос пока просто по работе не столкнулся с тем что мне приходилось перестраивать Button sheet Дело в том что именно сам данный виджет вы не сможете перестроить
00:07:03 - 00:08:01
Извне потому что он вызывает Сколько оверлей возможно меня исправит но данный подход имеет место и он работает Ну и третье опять же пришло из опыта в общем если вы используете какие-то списки виджетов А без ключей то рано или поздно Скорее всего вы можете столкнуться с ошибкой Ну с конкретной ошибкой я просто с каким-то странным поведением и э-э как это называется на эксперта behavi а соответственно если вот к примеру есть два списка виджетов которые содержат изображение текстовые данные и так далее
00:07:33 - 00:08:38
эти два списка виджета они расположены на одном экране разделены эти списки разными табами соответственно Если вы не будете использовать ключи то с высокой вероятностью у вас рано или поздно возникнут проблемы в самих данных которые гоняются между этими списками если один из списков станет Короче например другой длиннее то получается так что данные перекидываются туда-сюда и Это не круто это происходит видимо из-за каких-то оптимизационных процессов во флатере но использование ключей избавляет нас от этой проблемы поэтому
00:08:05 - 00:09:05
Возьмите просто за привычку Если вы используете список виджетов то постарайтесь использовать данных виджетов ключи хотя бы какие-то просто уникальные типа идентификаторов и так далее ну и да и естественно это не все а те способы которые вы можете использовать ключи Наверняка есть ещё что-то Но это я рассказал из того что прямо вот приходит в голову в данный момент в принципе на собеседовании он будет от этого достаточно Следующий вопрос кстати достаточно интересный потому что многие забывают Какие бывают вообще ключи и какой тип
00:08:35 - 00:09:36
выбирается соответственно у нас есть главный класс Кия и от него у нас есть следующие Наследники У нас есть великие это ключ который содержит некоторую константу строку или конкретное значение используется для идентификации конкретного виджета также существует abject Key у него в качестве параметра можно использовать объекты Unity Я уже затрагивал чуть ранее это ключ который не принимает какие-то конкретные значения Но каждый раз Получается он генерируется уникальным идентификатом и глобалки это самый такой
00:09:06 - 00:10:13
э неоднозначный ключ но в некоторых сложных вёрстках он вам может очень хорошо пригодиться Вот как раз таки Дело в том что вот если вы хотите получить размеры виджеты к примеру после того как он отрисуется или конкретные позицию где он отрисовался то без использования глобалки Я не уверен что у вас получится это сделать но опять ниже ни злоупотребляете им потому что это что-то глобальное это что-то что можно изменить Извне соответственно лучше это делать когда в этом есть необходимость Следующий вопрос скорее всего который
00:09:39 - 00:10:43
вам зададут это то вообще как собственно флаг работает под капотом тут вы можете перечислить три основных слоя флаттер это слой Application фладеры платформы я не буду долго останавливаться на данных слоях если вам нужно сможете почитать обычно это не спрашивают но спрашивают следующее такой следующий слайды я не переводил чтобы не адаптировать текст в общем Вас могут спросить а вот почему Например у меня дебаг версия когда я собираю она тормозит а релизная там работает 120 кадров и прямо всё идеально летает тут
00:10:11 - 00:11:12
соответственно Подходим к двум подходам к компиляции которая вообще существует Значит существует статическая компиляция и так называемая динамическая интерпретация статическая компиляция Она работает за счёт того что Исходный код и исходные команды они скомпилированные в исполнении Мой файл какой-то как например это делается на оси плюс и соответственно данный исполняемый файл уже запускается данный подход называется или LT позже мы будем обращаться к нему именно так динамическая же интерпретация
00:10:42 - 00:11:48
она представляет собой некоторую некоторое выполнение скрипта То есть это выполнение единиц трансляции одно за одной к примеру это то как работает тот же самый JavaScript и данный подход называется Just in Time или сокращённо jit вопрос возникает А как это относится к флатеру Ну естественно что git он будет более слабым более медленный потому что он выполняется в процессе работы приложения а соответственно LT он так как уже при компилированный соответственно он будет выполняться явно быстрее потому что самый можно
00:11:14 - 00:12:24
использовать оптимизации и так далее как это относится к флатуру а очень просто если вы запускаете к примеру из Android Studio ваше приложение и оно запускается в дебаг время то данное приложение будет скомпилировано Джастин тайм это позволяет вам использовать главные фичи флаттера это Hot relo de Hot Restart без этого бы это не работало просто так в релизной сборке вы уже соответственно будете компилироваться в LT в нативный код самого приложения для того чтобы обеспечить лучшую производительность
00:11:49 - 00:12:52
минимальный размер и убрать вещь которая вам уже не нужны в релизе следующий вопрос вам интервьюер говорит ну компиляция конечно хорошо что ты знаешь на практике конечно не будешь использовать Но что такое Виджеты как он отрисовывается Итак Ну естественно все знают что все флаттер это виджеты а Виджет это описание некоторого элемента вопроса Что такое элемент что такое что такое виджет виджет это описание части пользуются по интерфейса а элемент управляет ее сущностью если к примеру у нас виджет использует какую-то
00:12:20 - 00:13:26
конфигурацию какой-то стоит то тут идёт связь элемента так как виджет он является вопросом конфигурация а элемент он держит именно состояние элемент создается из виджета посредством вызова метода createlment и также немаловажно стоит подчеркнуть что элементом может быть неактивен он может быть в состоянии он Mount и если он не активен то он исключается из дерева наверняка вас просто что такое Билд контекст довольно сложный вопрос но на него есть лёгкий ответ А это то что управляет позиция виджета в дереве виджетов этого
00:12:53 - 00:13:56
достаточно для ответа И также у нас есть это объект дерево визуализация он отвечает за то что он содержится информацию база протокола отрисовки и расположения данного виджета Итак то есть мы уже обсудили то что у нас есть виджеты есть элемент есть тренды рендер данные три сущности составляет три основных дерева отрисовки на флаттер дерево виджетов оно декларирует конфигурации и хранит свойства виджетов соответственно дерево элементов они уже управляют жизненным циклом стоит там и что немаловажно они это саму
00:13:25 - 00:14:35
конфигурацию то есть виджеты с тем как эта конфигурация будет отрисована то есть оно есть некоторые связующее звено между деревом виджет и деревом рендер abject соответственно дерево объект визуализации уже просто отвечает за отрисовку учет размеров положения и ограничения виджетов на данной презентации Вы можете видеть qr-коды в углах соответственно это если вы хотите обратиться к исходным каких-то к исходным документам и посмотреть поглубже проходит конкретно тему то можете навести ваш телефон И перейти по
00:14:00 - 00:15:02
ссылке наверняка вас также спросят простите за то что я повторяю о том что вот флаттерда многопоточность такая классная штука да А вот почему флатере Например используется только один поток ответить на этот вопрос можно следующим образом Ну потому что флат использовать Дарт Дарт однопоточный соответственно флаттер также работает в основном в одном потоке в основном Почему Потому что в контексте флаттер приложения а любой процесс даже вот само приложение является с некоторым потоком в контексте Дарта она называется айзалей там А нет
00:14:31 - 00:15:36
рядом как например в плюсах тех же потому что у него есть некоторые отличия от обычных трендов главный поток приложения Называется он никак называется так называется главный поток приложения он просто создается когда мы вызываем Main Соответственно что происходит вот у нас есть айзелей главный у него есть две очереди это Майк тайский ивентю они инициализируются при запуске приложения после этого запускается Main и запускается такой механизм как и вариант цикл событий ивент-клуб - это если абстрактно
00:15:03 - 00:16:04
представить это молотильня на которую есть на вход две очереди одна очередь толстая там большие события это очередь ивент вторая очередь там очень маленький краткосрочные действия это Майкл тестк соответственно ивент loop если представить себе в виде молотильны оно работает следующим образом оно принимает ивент долго с ним работает но долго в контексте процессорного времени как только она поработала она полностью Выполняет все накопившиеся microsk microses 50 отработали идёт следующая Event все Micro tesky которые собираются
00:15:34 - 00:16:38
в очереди после этого будут обработаны после завершения следующего ивента в основе Вот как раз данный концепции и лежит то как работает Дарт в одном потоке то есть по факту у нас есть асинхронность и это позволяет нам сделать так что у нас есть как бы единый процессорное время из момента можно в плане только один ивент но они как бы находятся в очереди и соответственно как только у нас есть э свободная процессорное время мы будем обрабатывать какие-то следующие кратко Я это и рассказал Надеюсь что Понятно Если нужно
00:16:06 - 00:17:06
Чуть более глубокое описание там также в конце будет QR как в принципе я уже рассказал то что есть очередь есть а ивент понятие синхронности да то есть если у нас есть какое-то событие которое мы э знаем что будет выполнено но не знаем И даже мы не знаем Будет ли оно выполнено оно вернёт какой-то результат но чуть позже то есть мы не можем его дождаться синхронно к примеру это какой-то там запрос kpi То есть тут мы гарантировать что ответ придет на секунду или за 30 секунд соответственно данные вещи они
00:16:36 - 00:17:32
выполняются в основном асинхронно в этом асинхронном подходе существует такое понятие как Future Future это тот самый Объект который представляет собой что-то что мы должны получить в будущем Когда у нас это синхронная операция будет выполнена и завершиться она может двумя способами либо будет это какой-то результат который мы получим либо через zn ну либо стандартным присваиванием либо же мы можем отловить ошибку которая произойдет в результате выполнение данного ивента Ну в принципе как и сказал то что вы синхронные операции
00:17:04 - 00:18:02
выполнения метода это фьюча вот всё что записано в методе в которой имеет возвращаемое значение типа Future оно выполняется синхронно до момента пока у нас нету строчки с ключом словом После чего выполнения метода пресс останавливается и данный а метод дожидается пока выполнится процесс который у нас выполняется в ходе собственного уэйта Ну и как я уже так правильно сказал то что а это не выполняется параллельно выполняется последовательности определяемый Event loop Следующий вопрос Вот вы нам сказали
00:17:32 - 00:18:38
про айслейд Да а что это такое Что такое айзелей как я уже сказал что айзелайт от некоторые аналог трейдеров тому же плюсовому вот у него есть одно серьезное отличие во-первых то что треды не разделяют память соответственно мы не можем данные перегонять напрямую То есть у нас Априори не может возникнуть проблема Dead блока и реализовано именно общение между лаитами на основе сообщений которые мы шлём на порты вот если например у нас есть два это Например основной и какой-то дополнительный который Мы создали у
00:18:05 - 00:19:05
каждого это будет свой Event loop у каждого будет свой участок памяти с которым он работает ну и соответственно так как у каждого из свой вариант у каждого в своей очереди майкрософская ивент общение происходит посредством месседжей на порты итак хорошо А как вообще можно его запустить значит основных подхода два Значит первый подход - это низкоуровневые решения на основе объектов класса и на основе портов Но это нужно только если мы хотим какое-то долго операцию к примеру и которая будет общаться посредством
00:18:35 - 00:19:33
сообщений в общем случае скорее всего вам это не нужно и будете вы работать скорее всего с изолятом через метод компьютер который предоставляет стартам и Суть в том что она сама порождает изолят выполняет он колбэк который мы передаём возвращает результат и убивает его то есть мы полностью исключаем наш вклад в создание объектов вы их здесь полосы и так далее но важное ограничение то что если мы запускаем через компьютер Мы уже никакого общения между портами сделать не сможем поэтому тут уже Смотрите по ситуации где вам компьютер
00:19:04 - 00:20:07
будет недостаточно нужно будет использовать низкого уровня решение Ну важное ограничение то что колбек должен быть функция верхнем уровне а и также важное ограничение то что у нас вот есть главное и данные icelade только он может делать платформенное взаимодействие то есть из дополнительного дилета вы например не сможете обратиться к каким-то платформенным каналам Ну и да последний вопрос который задают практически всем У нас есть такой принцип соли да Или Солид Как его правильно произнести я точно не знаю
00:19:36 - 00:20:34
скорее всего вас поспрашивают что там это означает что такое lid и спросит А вот Работают ли принципы солится флаттер Да маловероятно что этого будет достаточно поэтому останавливать чуть подробнее значит принцип с принципе здесь просто достаточно сказать что грамотная организация классов отсутствие года объект и так далее принцип открыться закрытости можно показать на примере то что если у нас есть какие-то например действия которые выполняют разные объекты то мы можем унаследоваться от единой абстракции
00:20:04 - 00:21:07
соответственно реализацией уже а-а делать непосредственно в наследниках Вот например в принципе так показано То есть у нас а-а было Два метода э у Круга и квадрата соответственно если мы бы наследовать этот абстракции Shape интерфейс соответственно Мы бы могли сделать реализацию а отдельную и таким образом мы могли бы обратиться к конкретным объекту через его интерфейс следующие два подхода я объединил но Если хотите опять же по qr-коду сможете посмотреть более подробно в данном направлении соответственно первый это
00:20:36 - 00:21:36
принцип установки Барбара и лисков и сегрегации интерфейсов если кратко принцип установки Барбара рисков он говорит о том что объекты Наследники должны выполнять те методы которые может сделать родитель а принцип сегрегации интерфейсов он безумно простой о том что интерфейс они должны быть непригорожены выполнять конкретное какое-то операцию то есть не конкретная операция какой-то конкретное поведение реализовывать соответственно Если бы у нас вот здесь вот был единый интерфейс с двумя методами и мы от него наследовали ещё
00:21:06 - 00:22:04
два класса то а у нас бы возникало нарушение принципа секреции интерфейсов на том что у нас есть один из классов в котором мы вообще нафиг не нужен второй метод но это так как он наследуется от интерфейса мы соответственно должны его развить мы должны его реализовать что-то такого не было разбиваем один большой интерфейс на несколько маленьких и уже понимаете как те которые конкретно Нам необходимо Ну или максимум можно использовать и последний принцип инверсии зависимости То есть если кратко реализация должна
00:21:34 - 00:22:39
зависеть от абстракций в данном случае к примеру У нас есть классика от Мы выполняем оплату как это Оплата будет происходить классика вот вообще не знает он знает что у него есть интерфейс payment и вот один из объектов данных классов которые реализуют данный интерфейс и каждого из них там оплата как-то идёт по-своему соответственно таким образом реализация зависит не от конкретного уже вида того как он будет реализован от абстракции А уже э то что наслед от абстракции оно уже определяет то как это будет
00:22:06 - 00:23:05
реализовано также здесь можно а-а рассказать что такое дитьё А что такое API соответственно Ну тут уже из личного опыта это бы слишком перегрузила данный слайд А в принципе на этом всё Благодарю вас за внимание Я с эльфов старший разработчиков на флаттер в компании Если хотите продолжение и например ещё до каких-то 10 советов то 100 лайков под этим видео не вообще не вопрос про бонус уже вам сказали в самом начале Подписывайтесь смотрите всем хорошего настроения хороших выходных Всем пока всем удачи всем пока
Всем привет тем кто смотрит нас на Ютюбе у нас для вас перед докладом есть одно небольшое но очень важное объявление в скором времени у нас выйдет целый бесплатный курс для начинающих по flator разработке всем кто хочет его посмотреть подписывайтесь на канал и следить за обновлениями Итак всем привет Сегодня у нас доклад разбор опросов собеседования на флаттер для начинающих А сегодня мы разберём 10 самых часто задаваемых вопросов на собеседованиях на позицию Джуна на флатере как на них можно ответить и это всё будет исходя из
00:00:00 - 00:01:05
собственного опыта собеседований и рабочего экспириенса первое самое распространённый вопрос - Это вообще А зачем использовать флаттер какие у него есть преимущества недостатки тут кандидат может перечислить что-то Из своего опыта Может взять примеры которые на официальном сайте flatra есть как здесь Но и собственно опыта могу сказать следующее значит во-первых у флаттера есть несомненный плюс Это единый кодовая база которая позволяет увеличить скорость разработке и из-за этого также выходит высокое масштабируемость потому
00:00:33 - 00:01:37
что 99 процентов кода оно портируется на Android iOS веб десктоп и так далее немаловажным плюсом flatra является декларативная верстка те кто писали в оперативном подходе понимаете о чем речь у флаттер есть такая особенность которая сейчас уже есть и на котлине в том числе это Hot reloade и hotterstarter кто опять же пробовал их использовать знает насколько крутая штука И насколько это сокращает время разработки Ну и не стоит забывать то что флаттер он довольно молодой у него сформировано довольно
00:01:04 - 00:02:08
крутое комьюнити поддержка видела огромное количество библиотека которая выложены на pubg и неимоверное количество статей Из минусов уже можно выделить это высокое требование к специалисту потому что хоть мы можем писать сразу под Android iOS но некоторые вещи Мы обязаны знать и изнатива поэтому среди требований к флота разработчику зачастую можно увидеть требования о том что нужно хотя бы какие-то базовые знания по одной из систем там по Android или IOS это связано в первую очередь например с тем
00:01:37 - 00:02:39
что человек который пишет Приложение он должен знать некоторые особенности подписки к примеру как вообще происходит процесс запуска и так далее соответственно больше платформ больше требований к опыту специалиста И следующий минус это достаточно субъективная вещь но я не могу не сказать то что Дарт он не такой сладкий как его нативные аналоги у него не так много синтаксического сахара как есть к примеру в котлели насчет лифта не уверен он не особо нравится Но вот по сравнению с котлином Дарт слегка отстаёт второй
00:02:07 - 00:03:10
вопрос который вы скорее всего услышите на собеседовании это уже всем приевшийся Чем отличается стоит если рассматривать картинку Ну сам UI как функцию от стейта то соответственно логично что стейтс - это те виджеты которые не имеют состояния какого-то внутреннего и зависят только от родителей Я не перерисовываются только когда родители об этом скажет А вот stateful виджеты они уже самостоятельные у них есть свой State они могут сами себя перерисовать через сайт State могут регулировать себя и так далее В основном вызов setta ведет
00:02:39 - 00:03:47
к тому что на следующей трассе данный элемент чуть позже мы о них поговорим он помечается флажком о том что ему требуется Перестройка Но есть один лайфхак что при помощи этой штуки вы можете запускать обновления даже stadles виджетов кто пробовал те знают О чём это в этом нет никакого смысла но так можно делать третий вопрос естественно Раз уж мы говорим о стейте такие ещё существуют способы и его управления Ну если рассматривать стоит в контексте отдельного виджета тут тут в целом всё понятно но здесь вопрос скорее будет про
00:03:12 - 00:04:19
архитектурный подход потому что флаттер какая-то более-менее серьёзная разработка она невозможна без использования чётко архитектуры просто по той причине что во-первых вы сами себя можете запутать и во-вторых другим будет очень тяжело разобраться коде в основе практически каждого архитектурного подхода лежат базовые принципы главный из них это использование Это связано с тем что у нас дерево виджетов она строится сверху вниз таким образом используя провайдер или value listenable или changendifire можно
00:03:46 - 00:04:54
изменять состояние Извне один из самых популярных подходов для контролирования стейта это использование блока блок расшифровывается как бизнес компонент и представляет собой некоторый мост между позволяет это сделать следующее То есть если мы просто бы напрямую делали связку то у нас бы зашивалось логика в юаре это как бы не хорошо нехорошо потому что у нас идет нарушение разграничения соответственно блок призван исправить данную проблему тем самым что он представляет собой некоторое звено которое уже описывает логику И таким
00:04:19 - 00:05:30
образом UI знает о данных которые он должен выразить но не знает Конкретно что он должен с ними делать один из самых популярных архитектурных подходов второй тоже один из самых популярных пришел во флаттер из Веба это архитектурный подход на основе редакса в отличие от блока здесь основными элементами являются не какие-то отдельные страницы со своей логикой А в редаксе ядром является наличие глобального стейта приложения которым обращается уже все остальные окна данный подход может использоваться
00:04:56 - 00:06:01
в комбинации с блоком к примеру Но это делается уже в каких-то очень больших приложениях где это действительно необходимо третьим архитектурным решением является не уверен правильного произнести К сожалению о нём я мало знаю но также можете упомянуть его на собеседовании потому что к примеру это один из основных архитектурных подходов которые используются в Яндексе данный подход он также основан на провайдере и работает примерно по той же логике Ну это конец Конечно стоит упомянуть про getax это не
00:05:27 - 00:06:29
самое Она хорошая так скажем архитектурные подходы по той причине что у людей которые с ним работали были так скажем плохие ассоциации в нашей компании это считается моветоном использовать соответственно поэтому мы стараемся избегать четвертым опросом который Вам скорее всего сдадут это вообще это понятие ключей во флаттер ничего не используется Вы можете сразу сказать что основное Что можно делать ключами это во-первых то что вы получаете как бы некоторые степени указатель на конкретный виджет с помощью
00:05:59 - 00:07:00
данного указателя к примеру Вы можете обратиться к его ренде роуджикту и вытянуть данные об этом Вите э например на экране его позицию размеры и так далее чуть дальше я расскажу про глобалки и почему это считается не ну не самым лучшим образом но зачастую он довольно полезен Также вы можете обратиться к контексту какого-то виджета или стоит и Вы даже можете сделать проверку на вообще существование данного виджета второй неочевидный подход это перерисовка виджеты через под включаем Чуть позже я расскажу о том что ключ определяет
00:06:30 - 00:07:39
элемент в дереве Но если вы изменяете ключ У виджета то на следующей итерации данный виджет будет пересоздан соответственно использование уникального ключа позволяет вам перерисовать виджет вы меня спросите А зачем это надо по факту Вы можете использовать просто стоит где-то выше или использовать архитектурный реактивный подход но я бы сам не смог ответить на данный вопрос пока просто по работе не столкнулся с тем что мне приходилось перестраивать Button sheet Дело в том что именно сам данный виджет вы не сможете перестроить
00:07:03 - 00:08:01
Извне потому что он вызывает Сколько оверлей возможно меня исправит но данный подход имеет место и он работает Ну и третье опять же пришло из опыта в общем если вы используете какие-то списки виджетов А без ключей то рано или поздно Скорее всего вы можете столкнуться с ошибкой Ну с конкретной ошибкой я просто с каким-то странным поведением и э-э как это называется на эксперта behavi а соответственно если вот к примеру есть два списка виджетов которые содержат изображение текстовые данные и так далее
00:07:33 - 00:08:38
эти два списка виджета они расположены на одном экране разделены эти списки разными табами соответственно Если вы не будете использовать ключи то с высокой вероятностью у вас рано или поздно возникнут проблемы в самих данных которые гоняются между этими списками если один из списков станет Короче например другой длиннее то получается так что данные перекидываются туда-сюда и Это не круто это происходит видимо из-за каких-то оптимизационных процессов во флатере но использование ключей избавляет нас от этой проблемы поэтому
00:08:05 - 00:09:05
Возьмите просто за привычку Если вы используете список виджетов то постарайтесь использовать данных виджетов ключи хотя бы какие-то просто уникальные типа идентификаторов и так далее ну и да и естественно это не все а те способы которые вы можете использовать ключи Наверняка есть ещё что-то Но это я рассказал из того что прямо вот приходит в голову в данный момент в принципе на собеседовании он будет от этого достаточно Следующий вопрос кстати достаточно интересный потому что многие забывают Какие бывают вообще ключи и какой тип
00:08:35 - 00:09:36
выбирается соответственно у нас есть главный класс Кия и от него у нас есть следующие Наследники У нас есть великие это ключ который содержит некоторую константу строку или конкретное значение используется для идентификации конкретного виджета также существует abject Key у него в качестве параметра можно использовать объекты Unity Я уже затрагивал чуть ранее это ключ который не принимает какие-то конкретные значения Но каждый раз Получается он генерируется уникальным идентификатом и глобалки это самый такой
00:09:06 - 00:10:13
э неоднозначный ключ но в некоторых сложных вёрстках он вам может очень хорошо пригодиться Вот как раз таки Дело в том что вот если вы хотите получить размеры виджеты к примеру после того как он отрисуется или конкретные позицию где он отрисовался то без использования глобалки Я не уверен что у вас получится это сделать но опять ниже ни злоупотребляете им потому что это что-то глобальное это что-то что можно изменить Извне соответственно лучше это делать когда в этом есть необходимость Следующий вопрос скорее всего который
00:09:39 - 00:10:43
вам зададут это то вообще как собственно флаг работает под капотом тут вы можете перечислить три основных слоя флаттер это слой Application фладеры платформы я не буду долго останавливаться на данных слоях если вам нужно сможете почитать обычно это не спрашивают но спрашивают следующее такой следующий слайды я не переводил чтобы не адаптировать текст в общем Вас могут спросить а вот почему Например у меня дебаг версия когда я собираю она тормозит а релизная там работает 120 кадров и прямо всё идеально летает тут
00:10:11 - 00:11:12
соответственно Подходим к двум подходам к компиляции которая вообще существует Значит существует статическая компиляция и так называемая динамическая интерпретация статическая компиляция Она работает за счёт того что Исходный код и исходные команды они скомпилированные в исполнении Мой файл какой-то как например это делается на оси плюс и соответственно данный исполняемый файл уже запускается данный подход называется или LT позже мы будем обращаться к нему именно так динамическая же интерпретация
00:10:42 - 00:11:48
она представляет собой некоторую некоторое выполнение скрипта То есть это выполнение единиц трансляции одно за одной к примеру это то как работает тот же самый JavaScript и данный подход называется Just in Time или сокращённо jit вопрос возникает А как это относится к флатеру Ну естественно что git он будет более слабым более медленный потому что он выполняется в процессе работы приложения а соответственно LT он так как уже при компилированный соответственно он будет выполняться явно быстрее потому что самый можно
00:11:14 - 00:12:24
использовать оптимизации и так далее как это относится к флатуру а очень просто если вы запускаете к примеру из Android Studio ваше приложение и оно запускается в дебаг время то данное приложение будет скомпилировано Джастин тайм это позволяет вам использовать главные фичи флаттера это Hot relo de Hot Restart без этого бы это не работало просто так в релизной сборке вы уже соответственно будете компилироваться в LT в нативный код самого приложения для того чтобы обеспечить лучшую производительность
00:11:49 - 00:12:52
минимальный размер и убрать вещь которая вам уже не нужны в релизе следующий вопрос вам интервьюер говорит ну компиляция конечно хорошо что ты знаешь на практике конечно не будешь использовать Но что такое Виджеты как он отрисовывается Итак Ну естественно все знают что все флаттер это виджеты а Виджет это описание некоторого элемента вопроса Что такое элемент что такое что такое виджет виджет это описание части пользуются по интерфейса а элемент управляет ее сущностью если к примеру у нас виджет использует какую-то
00:12:20 - 00:13:26
конфигурацию какой-то стоит то тут идёт связь элемента так как виджет он является вопросом конфигурация а элемент он держит именно состояние элемент создается из виджета посредством вызова метода createlment и также немаловажно стоит подчеркнуть что элементом может быть неактивен он может быть в состоянии он Mount и если он не активен то он исключается из дерева наверняка вас просто что такое Билд контекст довольно сложный вопрос но на него есть лёгкий ответ А это то что управляет позиция виджета в дереве виджетов этого
00:12:53 - 00:13:56
достаточно для ответа И также у нас есть это объект дерево визуализация он отвечает за то что он содержится информацию база протокола отрисовки и расположения данного виджета Итак то есть мы уже обсудили то что у нас есть виджеты есть элемент есть тренды рендер данные три сущности составляет три основных дерева отрисовки на флаттер дерево виджетов оно декларирует конфигурации и хранит свойства виджетов соответственно дерево элементов они уже управляют жизненным циклом стоит там и что немаловажно они это саму
00:13:25 - 00:14:35
конфигурацию то есть виджеты с тем как эта конфигурация будет отрисована то есть оно есть некоторые связующее звено между деревом виджет и деревом рендер abject соответственно дерево объект визуализации уже просто отвечает за отрисовку учет размеров положения и ограничения виджетов на данной презентации Вы можете видеть qr-коды в углах соответственно это если вы хотите обратиться к исходным каких-то к исходным документам и посмотреть поглубже проходит конкретно тему то можете навести ваш телефон И перейти по
00:14:00 - 00:15:02
ссылке наверняка вас также спросят простите за то что я повторяю о том что вот флаттерда многопоточность такая классная штука да А вот почему флатере Например используется только один поток ответить на этот вопрос можно следующим образом Ну потому что флат использовать Дарт Дарт однопоточный соответственно флаттер также работает в основном в одном потоке в основном Почему Потому что в контексте флаттер приложения а любой процесс даже вот само приложение является с некоторым потоком в контексте Дарта она называется айзалей там А нет
00:14:31 - 00:15:36
рядом как например в плюсах тех же потому что у него есть некоторые отличия от обычных трендов главный поток приложения Называется он никак называется так называется главный поток приложения он просто создается когда мы вызываем Main Соответственно что происходит вот у нас есть айзелей главный у него есть две очереди это Майк тайский ивентю они инициализируются при запуске приложения после этого запускается Main и запускается такой механизм как и вариант цикл событий ивент-клуб - это если абстрактно
00:15:03 - 00:16:04
представить это молотильня на которую есть на вход две очереди одна очередь толстая там большие события это очередь ивент вторая очередь там очень маленький краткосрочные действия это Майкл тестк соответственно ивент loop если представить себе в виде молотильны оно работает следующим образом оно принимает ивент долго с ним работает но долго в контексте процессорного времени как только она поработала она полностью Выполняет все накопившиеся microsk microses 50 отработали идёт следующая Event все Micro tesky которые собираются
00:15:34 - 00:16:38
в очереди после этого будут обработаны после завершения следующего ивента в основе Вот как раз данный концепции и лежит то как работает Дарт в одном потоке то есть по факту у нас есть асинхронность и это позволяет нам сделать так что у нас есть как бы единый процессорное время из момента можно в плане только один ивент но они как бы находятся в очереди и соответственно как только у нас есть э свободная процессорное время мы будем обрабатывать какие-то следующие кратко Я это и рассказал Надеюсь что Понятно Если нужно
00:16:06 - 00:17:06
Чуть более глубокое описание там также в конце будет QR как в принципе я уже рассказал то что есть очередь есть а ивент понятие синхронности да то есть если у нас есть какое-то событие которое мы э знаем что будет выполнено но не знаем И даже мы не знаем Будет ли оно выполнено оно вернёт какой-то результат но чуть позже то есть мы не можем его дождаться синхронно к примеру это какой-то там запрос kpi То есть тут мы гарантировать что ответ придет на секунду или за 30 секунд соответственно данные вещи они
00:16:36 - 00:17:32
выполняются в основном асинхронно в этом асинхронном подходе существует такое понятие как Future Future это тот самый Объект который представляет собой что-то что мы должны получить в будущем Когда у нас это синхронная операция будет выполнена и завершиться она может двумя способами либо будет это какой-то результат который мы получим либо через zn ну либо стандартным присваиванием либо же мы можем отловить ошибку которая произойдет в результате выполнение данного ивента Ну в принципе как и сказал то что вы синхронные операции
00:17:04 - 00:18:02
выполнения метода это фьюча вот всё что записано в методе в которой имеет возвращаемое значение типа Future оно выполняется синхронно до момента пока у нас нету строчки с ключом словом После чего выполнения метода пресс останавливается и данный а метод дожидается пока выполнится процесс который у нас выполняется в ходе собственного уэйта Ну и как я уже так правильно сказал то что а это не выполняется параллельно выполняется последовательности определяемый Event loop Следующий вопрос Вот вы нам сказали
00:17:32 - 00:18:38
про айслейд Да а что это такое Что такое айзелей как я уже сказал что айзелайт от некоторые аналог трейдеров тому же плюсовому вот у него есть одно серьезное отличие во-первых то что треды не разделяют память соответственно мы не можем данные перегонять напрямую То есть у нас Априори не может возникнуть проблема Dead блока и реализовано именно общение между лаитами на основе сообщений которые мы шлём на порты вот если например у нас есть два это Например основной и какой-то дополнительный который Мы создали у
00:18:05 - 00:19:05
каждого это будет свой Event loop у каждого будет свой участок памяти с которым он работает ну и соответственно так как у каждого из свой вариант у каждого в своей очереди майкрософская ивент общение происходит посредством месседжей на порты итак хорошо А как вообще можно его запустить значит основных подхода два Значит первый подход - это низкоуровневые решения на основе объектов класса и на основе портов Но это нужно только если мы хотим какое-то долго операцию к примеру и которая будет общаться посредством
00:18:35 - 00:19:33
сообщений в общем случае скорее всего вам это не нужно и будете вы работать скорее всего с изолятом через метод компьютер который предоставляет стартам и Суть в том что она сама порождает изолят выполняет он колбэк который мы передаём возвращает результат и убивает его то есть мы полностью исключаем наш вклад в создание объектов вы их здесь полосы и так далее но важное ограничение то что если мы запускаем через компьютер Мы уже никакого общения между портами сделать не сможем поэтому тут уже Смотрите по ситуации где вам компьютер
00:19:04 - 00:20:07
будет недостаточно нужно будет использовать низкого уровня решение Ну важное ограничение то что колбек должен быть функция верхнем уровне а и также важное ограничение то что у нас вот есть главное и данные icelade только он может делать платформенное взаимодействие то есть из дополнительного дилета вы например не сможете обратиться к каким-то платформенным каналам Ну и да последний вопрос который задают практически всем У нас есть такой принцип соли да Или Солид Как его правильно произнести я точно не знаю
00:19:36 - 00:20:34
скорее всего вас поспрашивают что там это означает что такое lid и спросит А вот Работают ли принципы солится флаттер Да маловероятно что этого будет достаточно поэтому останавливать чуть подробнее значит принцип с принципе здесь просто достаточно сказать что грамотная организация классов отсутствие года объект и так далее принцип открыться закрытости можно показать на примере то что если у нас есть какие-то например действия которые выполняют разные объекты то мы можем унаследоваться от единой абстракции
00:20:04 - 00:21:07
соответственно реализацией уже а-а делать непосредственно в наследниках Вот например в принципе так показано То есть у нас а-а было Два метода э у Круга и квадрата соответственно если мы бы наследовать этот абстракции Shape интерфейс соответственно Мы бы могли сделать реализацию а отдельную и таким образом мы могли бы обратиться к конкретным объекту через его интерфейс следующие два подхода я объединил но Если хотите опять же по qr-коду сможете посмотреть более подробно в данном направлении соответственно первый это
00:20:36 - 00:21:36
принцип установки Барбара и лисков и сегрегации интерфейсов если кратко принцип установки Барбара рисков он говорит о том что объекты Наследники должны выполнять те методы которые может сделать родитель а принцип сегрегации интерфейсов он безумно простой о том что интерфейс они должны быть непригорожены выполнять конкретное какое-то операцию то есть не конкретная операция какой-то конкретное поведение реализовывать соответственно Если бы у нас вот здесь вот был единый интерфейс с двумя методами и мы от него наследовали ещё
00:21:06 - 00:22:04
два класса то а у нас бы возникало нарушение принципа секреции интерфейсов на том что у нас есть один из классов в котором мы вообще нафиг не нужен второй метод но это так как он наследуется от интерфейса мы соответственно должны его развить мы должны его реализовать что-то такого не было разбиваем один большой интерфейс на несколько маленьких и уже понимаете как те которые конкретно Нам необходимо Ну или максимум можно использовать и последний принцип инверсии зависимости То есть если кратко реализация должна
00:21:34 - 00:22:39
зависеть от абстракций в данном случае к примеру У нас есть классика от Мы выполняем оплату как это Оплата будет происходить классика вот вообще не знает он знает что у него есть интерфейс payment и вот один из объектов данных классов которые реализуют данный интерфейс и каждого из них там оплата как-то идёт по-своему соответственно таким образом реализация зависит не от конкретного уже вида того как он будет реализован от абстракции А уже э то что наслед от абстракции оно уже определяет то как это будет
00:22:06 - 00:23:05
реализовано также здесь можно а-а рассказать что такое дитьё А что такое API соответственно Ну тут уже из личного опыта это бы слишком перегрузила данный слайд А в принципе на этом всё Благодарю вас за внимание Я с эльфов старший разработчиков на флаттер в компании Если хотите продолжение и например ещё до каких-то 10 советов то 100 лайков под этим видео не вообще не вопрос про бонус уже вам сказали в самом начале Подписывайтесь смотрите всем хорошего настроения хороших выходных Всем пока всем удачи всем пока
00:22:36 - 00:23:50
[музыка]
00:23:13 - 00:23:16