в общем список вопросов он был уже скинут general но мы сейчас просто пойдем подряд и будем рассматривать все а еще в чем смысл смысл в том что все эти сложные вопросы обычно сопровождаются кучи документации которую никто не читает и всем лень я постарался каждый из этих вопросов запихнуть в рамки 5 минут и в рамках этих пяти минут разобрать большую часть всего что может быть с этим связано и потом соответственно поставок доклад закончится я скину просто все то же самое в текстовом формате со ссылками на
00:00:00 - 00:01:04
документацию если кто-то захочет более конкретно это все почитать итак поехали первый наш вопрос это тол фри bridging многие наверно слышали про это но никогда не знали вообще что это такое и чтобы разобраться что такое туфли bridging стоит немножечко обратиться к истории зайти и так сказать издалека в один прекрасный момент стив джобс со своей командой решил создать mac os x за основу было решено взять mac os 9 но при этом переработать его на манер next step nextep их операционная система которую они сделали параллельно основная
00:00:32 - 00:01:43
разница была в том что оно xt объектно-ориентированная операционная система в то время как mac os соответственно который был до mac os x он был написан в основном носи использовал процедурный подход и это были категорически две разные вещи и для создания новых приложений под новую операционную систему которая не хотели сделать использовался api open step это такая apes к для условно говоря разработки вот именно новых приложений под nextep узкие архитектуры в дальнейшем он будет переименован в cocoa который нам известен как бы сосуа
00:01:07 - 00:02:19
какого коко как его называют по разному но сейчас про него все слышат все знают он использовал язык объекте все имел как базу известны многим мирный foundation кит вы встречаете с ним буквально постоянно когда создаете новый файл им портится foundation это как это как раз таки вот и есть тот самый фонд foundation кит и в нем были свои классы например н срнс string и прочее н.с. всякие штуки которые вы тоже довольно часто видели но это для разработки конкретно новых приложений надо было еще как-то портировать старые
00:01:43 - 00:02:49
приложения которые разрабатывались под macos делись и под более ранние версии и вот с этим была проблема для этого было решено разработать конкретно новую описку под названием карбон которая существовала она была разработана она существовала до насколько я помню маклая скатали на но в биг сирии и уже полностью выпилили сейчас никакого карбона там нет и отсылок к этому нет то есть полностью и плохо переноса старых приложений закончилась и вот смысл ты был в чем смысл был в том что стив джобс и разработчики сразу задумались о том а
00:02:16 - 00:03:26
как обеспечить удобное взаимодействие этих двух опишет в рамках одной операционной системы все-таки надо было чтобы они умели как-то между собой взаимодействовать и чтобы это было не совсем костыль на и для этого было принято решение создать общий фундамент для обоих интерфейсов его написали на чистом си и назвали core foundation ну как бы корр foundation это ядро фундамента ядро основания то есть это то самое ядро которое лежало в базе обоих опишет и какао и соответственно карбон по структуре по сути он полностью
00:02:51 - 00:04:00
копировал своего прародителя поскольку core foundation по большей части был взят из foundation кита но переписан объекте все на чистый син и в итоге получилось как полностью практически структура повторялось структура foundation только соответственно пор foundation были использованы свои классы например вместо n с array там был съев р.ф. вместо n с strings эстрин грех и так далее то есть вот на этой таблице можно посмотреть большую часть соотносящихся друг с другом классов и увидеть что по большей части они
00:03:25 - 00:04:41
называются плюс-минус похоже единственное что добавляется в кор fondation это добавляет царёв в конце чтобы явно указать на то что это как бы ссылка на какой-то объект ессеев соответствует аккор fondation а н с насколько я помню это сокращение от nextep и вот как то вот так выглядит сравнительная таблица классов в двух framework of a по сути большая часть foundation кита стала оберткой над над различными классами и методами core foundation а то есть когда мы обращаемся конец арию по сути мы работаем с серой рифам но
00:04:02 - 00:05:25
посредством foundation of sky обертки вот и наконец-то мы подошли к заголовку нашей темы что же такое толпы bridging a toll free bridging это возможность использовать объекты core fondation там где требуется их аналоги из foundation и наоборот например если какой-то метод принимает на вход ns string то вы совершенно спокойно можете закинуть туда объект типа осев stren грех и наоборот если метод принимает например сиф ловок и евреев вы можете подменить его объектом типа ns локаль все что нужно при этом
00:04:44 - 00:05:54
это просто сделать кастинг объектах его аналогов требуемой опишите ну например вот это примеры из официальной документации выглядят они очень стара потому что написаны они были очень стара объекте все все дела и в первом примере что мы делаем мы создаем объект типа ns локаль затем мы этот м с локаль просто берем и костюм в sea of local риф и уже в таком-то методе а который принимает соответственно а нет в первом как раз таки примере мы создаем да мы получаем 7-ой бинти fire и затем мы 7-ой бинти fair преобразовываем внс
00:05:19 - 00:06:38
string поскольку и не слог у нас просто принимает ns string на вход для отображения и мы просто прокидываем туда этот сев убить fire который мы за кастили и все работает в примере пониже мы создали соответственно нс1 the fire через стрелку а затем с помощью методы сев шоу который принимает внутрь соответственно 7 стрингеров мы просто за заказ теле закинули туда и это все работает и работает этот для большинства методов для большинства соответственно классов при но для всех классов представленных
00:05:59 - 00:07:18
но помимо этих есть еще некоторые классы которые не поддерживают the free bridging но обычно о них они указываются явно и в той же самой документации вы можете почитать какие конкретно классы не поддерживают этот толстый bridging то есть не поддерживают такой легкий интернет между собой вот принципе про the free bridging наверное все потому что здесь говорить то в общем то и не о чем это просто возможность кастить объекты и легко применять их в рамках foundation и core foundation а такой удобный интернет короче вот ничего
00:06:37 - 00:07:54
сложного здесь вообще капитально нет если у кого-то есть какие-то вопросы конкретно потолще bridging можете задать сразу и после этого мы пойдем дальше и меняйте может быть ну вообще нужны это может смотри это может быть нужно тогда когда ты будешь использовать не foundation of ski и объекты ну это может понадобиться тогда когда ты почувствуешь что foundation дает тебе слишком мало когда коко дает себе слишком мало и если ты вдруг захочешь написать свой лейбл или захочешь написать какой-то свой компонент который
00:07:17 - 00:08:23
будет использовать объекты именно core foundation а то есть если ты пойдешь использовать core графику если ты пойдешь использовать core текст если ты пойдешь использовать еще какие-то core библиотеки которые дадут себе больше возможностей нежели какие-то function of ski и соответственно класс и вот 10 обращаются допустим допустим лук тоже самый core графики ты будешь работать именно с вот эти миссия в классами по большей части илистом сиджей классами которые будут оборачивать по большей части те же сейф классы и в
00:07:50 - 00:09:09
таком случае ты сможешь прокидывать какие-то объекты ns не оттуда если тебе это будет проще допустим в принципе в 2021 году наверное это применяться будет очень редко если только ты не полезешь прям самую глубь и не захочешь написать какие-то свои компании ты базовых но по большей части сейчас это наверное уже не пригодится никогда особенно если вы не пишете на объекте все а если вы пишете на свете и просто кушаете то что вам дает apple как бы и используете то что в принципе используют все вот как то так
00:08:29 - 00:09:48
окей спасибо вопрос 2 jean-luc про ран лук тоже очень многие слышали если открыть официальную документацию и плату можно немножко с того насколько все это сложно устроено и с того насколько давно это всё писалось насколько это выглядит прям архаичное но мы попробуем это все рассмотреть чуть быстрее чуть проще что же такое разлук ранду pva с этот цикл который координирует получение и обработку входящих событий в конкретном потоки его основная цель это загружать поток работает тогда когда эта работа
00:09:07 - 00:10:15
есть а в остальное время усыплять поток чтобы он не расходовал лишние ресурсы и что сразу стоит отметить это то что каждый поток имеет ассоциированы с ним рангу ран глуп для главного потока приложения запускает и поддерживает автоматически в то время как для вторичных потока фронтов конфигурируется и запускается руками разработчика если ему вдруг это сильно понадобилось чтобы выяснить общее эти случаи необходимости сначала разберемся какие же события вообще может обрабатывать ран луп существует
00:09:42 - 00:10:47
несколько источников принципе если мы посмотрим на эту схему то отсюда уже все можно будет понять это различные устройства ввода такие как мышь клавиатура тачскрин и так далее так далее все что вы можете подключить в принципе она будет обрабатываться через через ран лук второе это различные порты вы можете прослушивать порты чтобы получать своевременно какую-то информацию и все это будет тоже обрабатываться через ран лук есть кастомные источники которые нужны по сути для того чтобы между двумя или
00:10:15 - 00:11:22
более потоками прокидывать быстро какую-то информацию про gastone и из источники в принципе можно говорить долго сегодня мы на них останавливаться не будем поскольку применяется это в одном случае из миллиона скорее всего в это не понадобится никогда еще вызову убер форм селектора по отношению к отрядам тоже завязаны на ран лупи и что самое важное для нас сегодня будет это то что все таймер и работают по сути поверх ран лупа без ропота мира и работать просто не будут если суммировать это все резюмировать
00:10:48 - 00:11:58
то для того чтобы прослушать порты добавить таймер вызвать пир форм селектор по отношению к кому-то по току или настроить кастомную пересылку сообщений между потоками вам придется использовать разлук более того при запуске ран лут можно явно будет указать какие же источники событий ему стоит отслеживать на текущей итерации для этого существует несколько режимов называемых ран лук маус и если посмотреть на документацию можно увидеть в принципе 5 базовых ран лук модов первый это дефолтный мозг это основной
00:11:23 - 00:12:32
режим в котором отслеживаются основные события режим connection которые отслеживают ns connection и которые по сути вам никогда не не пригодятся здесь даже написано что вам скорее всего не придется никогда это руками использовать и насколько я помню н с connection ее в разработке под ios конкретно они не существуют и нужны только для разработки под mac os модал опять же нужно только для разработки под macos это это специальный режим для работы с модальными окнами в mac os останавливаться на этом не будем
00:11:57 - 00:13:17
рассмотрим последние два года event tracking even tracking мод нужен в принципе понятно для чего для того чтобы отслеживать какие то нажатии на мышь нажатии на клавиатуру нажатии на тачскрин движение скроллинг и так далее и самый последний мод и the common mode который по сути объединяет в себе три мода это дефолтный мод это модальный мод и event tracking мод ну если мы говорим про ios про разработку под какие-то мобилки то модальный можно отсюда смело выкинуть и говорить что по сути команд для мобилок поддерживает
00:12:37 - 00:13:53
дефолтный мод и event tracking и вот на этом стоит обратить внимание с этим связано и довольно распространенная проблема а да вот еще соответственно когда пользователь начинает взаимодействие с ей основной разлук переходит в режим треккинга и временно откладывает обработку всех остальных событий чтобы обеспечить интерфейсу хорошую плавность для того чтобы все это работало быстро и вот с этим связано распространенная проблема когда у пользователя просто перестает работать таймер во время скроллинга причина это
00:13:15 - 00:14:17
кроется в реализации стандартного метода таймер скетч л таймер который мы можем увидеть вот здесь и чуть ниже будет просто строчка из официальной документации что здесь происходит этой командой мы создаем таймер добавляем его в текущей рану в дефолтном моде как мы уже выяснили дефолтный мод по сути что делает если мы добавляем это только для дефолтного года то когда мы начинаем скроллинг а когда мы начинаем скроллинг у нас наш основной ран лук переходит в режим трейдинга все другие события кроме
00:13:47 - 00:14:53
тех которые относятся непосредственно к нажать young скроллинг еще чему-то связанному с интерфейсом они будут просто проигнорированы и поскольку мы добавляем это в дефолтный мод наш таймер просто перестает работать как можно пофиксить эту проблему эту проблему можно пофиксить вот так вот вместо того чтобы использовать метод с кетил таймер мы просто создаем этот таймер руками с помощью конца с помощью конструктора и добавляем этот таймер для не дефолтного мода однако man мода a common мод на сколько мы знаем он
00:14:20 - 00:15:32
включает в себя дефолтный мод и режим треккинга то есть даже когда ваш разум будет переключен в режим tracking и когда вы скроллите ваш таймер все равно будет корректно обработан и вот это наверное as the основная проблема часто встречающиеся проблемы с таймером которую люди на том же 100 каир flow очень часто спрашивают как это фиксить а фиксится это очень прост более того есть еще одна распространенная проблема таймеров срабатывают они не совсем в то время когда ожидалось и могут вообще не сработать и почему же
00:14:56 - 00:16:06
это происходит происходит это в связи с тем что действие на каждой итерации ран лупы вы выполняются в строгом порядке строго заданном порядке он очень сложно его можно будет посмотреть в официальной документации там что-то в районе 10 10 шагов они все вы выполняются последовательно и например проверка таймеров на срабатывание выполняется в самом начале этого цикла и если вдруг мы этот шаг уже прошли и после этого только сработает таймер мы не поймем это до тех пор пока ран губ не пройдет на следующую итерацию именно
00:15:31 - 00:16:42
поэтому появляются задержки и по сути таймер он не является гарантией того что ровно там через десять секунд допустим если вы указали 10 секунд нет гарантий что ваши действия выполнится ровно через десять 7 она может выполняться через десять с половиной секунд или через пятнадцать секунд если вдруг ран лук будет выполнять что-то что-то очень жирное массивное в себе именно поэтому на таймер и никогда не стоит завязываться для того чтобы обеспечить какой-то супер великую точность в в во временной
00:16:06 - 00:17:22
координацией короче вот в принципе пор он лупу тоже наверное все основной я рассказал если у кого-то есть еще какие то вопросы потому что я тут немножечко перечислил то можете задавать остальное все будет опять же в документации но туда без пол-литра лучше не соваться сразу говорю там все довольно жестко на что тогда завязываться если не на таймер и смотри если ты хочешь прям чтобы максимально точно у тебя по времени что-то было выполнено наверное просто изначально вообще не стоит делать такие задачи то есть смотри в принципе ты
00:16:44 - 00:18:03
можешь использовать gcd использовать dispatch автор а какое то время но в любом случае если у тебя поток будет в это время занят то в любом случае твой таймер не сможет вы вот эту задачу в срок то есть все убирается просто в то будет занят поток или нет условно говоря если тебе повезёт и если таймер сработает ровно за миллисекунду до того как ты начнешь очередную операцию в разлуке то у тебя все сработает во время если мы даже не используем таймер и а используем допустим gchq и запускаем какую-то
00:17:24 - 00:18:43
задачу условно говоря выполнится ровно через пять секунд если у нас поток будет в это время занят то твоя задача в любом случае будет просрочена и как-то гарантировать что у тебя поток не будет занят ровно через пять секунд скорее всего мы не сможем и поэтому вообще выполнение каких-то задач которые прям строгую завязку на на миллисекунды требуют наверное изначально их просто не должно быть я даже не знаю каким способом можно нормально разрулить вот такую максимальную точность но здесь я могу подсказать единственное что я не помню
00:18:04 - 00:19:21
точно как эта штука называется если не ошибаюсь может кто-то помнит цех дисплей линк или как то так называются мир м сек отрисовки кадров они происходят чаще соответственно в идеале там ну 30 1 секунду да и тут вероятность попасть в это просто больше и точность будет побольше но идея примерно тоже остается что если какой-то какое-то events твоя блочит поток то все равно все идет приезде и соответственно да здесь нужно аккуратнее таймер мы из этого точные там и миллисекунды вчера мне сделали но в рамках там одной
00:18:42 - 00:19:55
секунды мы можем так делать обновлять какой-то таймер по секундам как не знаю как буду до пиццы там что ваша пицца бред через толком минут и секунд такое можно сделать но вот что-то точнее уже нужно прямо понимать что то делать и всегда брака просчет что может сломаться да ну либо если тебе прям надо явно делать максимально точный таймер ты можешь создать другой поток в нем явно создать ран loops запустить там ран лук и запустить в нем таймер и не запускать в этом потоке больше ничего и тогда возможно в том потоке ты сможешь
00:19:18 - 00:20:32
прямо во время поймать этот сигнал и перекинуть как то событие обратно в основной поток но опять же если он будет занят то от этого толку не будет досей displaying принципе хороший вариант но опять же если у тебя основной поток будет заблочен а весёлой работает в основном потоке и сейди spoiling опять же привязывается к основному потоку насколько я понимаю если у тебя вдруг будут не 60fps допустимо там сколько 30 или сколько сейчас вообще fps доступного и 60 или 30 на девайс по моему тридцатку не гарантирует могу ошибаться вот но
00:19:54 - 00:21:12
если вдруг чего то будет в главном потоке сильно блочить этот поток скорее всего сейди spoiling тоже развалится поэтому какого-то точного метода для того чтобы гарантировать выполнение в какой-то гарантированный срок но такого нет насколько я понимаю но это просто исходит из того как работается систему тут мы ничего с этим сделать не сможем но удар следующий вопрос это of the release пул про него тоже очень много кто слышал но много кто до сих пор про него не знает и сегодня мы про него поговорим что такое of the release пул
00:20:34 - 00:21:45
опять же немножечко обратимся к истории во времена ручного управления памятью разработчикам приходилось руками писать команды вроде литейная релиза для того чтобы повышать или понижать счетчик ссылок для некоторого объекта сейчас это все уже заменено automatic reference counting им но раньше это приходилось делать руками и проблема возникала тогда когда объект создавался внутри метода и возвращался из этого метода допустим вот выглядело это как то вот так ну да тут же написано что это работать не будет
00:21:09 - 00:22:13
если вызвать релиз прямо перед ритер нам то по сути объект уничтожится еще до того как будет получен тем кто вызвал метод и что же делать блин если мы не напишем этот релиз или если мы после ритер на напишем релиз или вообще не будем его писать то тогда на этот объект останется вечно висящая ссылка которая просто не позволит обе то уничтожится позже и это порождало утечки памяти и в данном случае в данном случае для этого и нужен автор или spool что он делает фактически нам нужно будет избавиться от ссылки на
00:21:41 - 00:22:53
объект но сделать это не сразу а через некоторое время автор или spool позволяет нам сделать как раз таки вот это он хранит в себе все объекты у которых был вызван метод of the release is если мы напишем вот так вот то мы поместим наш new instance этот объект в авторе виспу он будет хранить себе все объекты до тех пор пока не будет очищен когда пул очищается к ко всем объектам которые содержатся внутри этого пула будет применен метод релиз соответственно который уменьшит количество ссылок на эти объекты и
00:22:17 - 00:23:30
позволят их не держать в памяти вопрос а в какой же момент очищается of the release пул вопрос на самом деле хороший потому что если кратко говорить то очищается он в момент вызова метода drain у of the release пула есть метод соответственно drain который позволяет очистить of the release пул и ко всей начинки которые в нем содержатся применить методы релиз но в большинстве случаев вызывать метод drain руками вам придется только в большинстве случаев вам не придется руками вызывать его вообще вам
00:22:53 - 00:23:56
придется вызывать его руками только тогда когда сам автор или spool вы создаете руками например для какого-то вторичного потока или для оптимизации цикла но в главном потоке все полностью автоматизировано ран лук сам создает автор или spool в начале каждой итерации а в конце и итерации этого рану про он его сам очищает соответственно если мы делаем все это в главном потоке то когда мы просто пишем вот как здесь нас на скрине когда мы вызываем of the release у какого-то объекта мы помещаем этот объект в of the release пул который был
00:23:26 - 00:24:35
автоматически создан ран глупом в главном потоке и когда этот разлук завершить свою итерацию объекты будут соответственно релизнут и сейчас когда орк уже в принципе заменил мануальный подсчет ссылок нам об этом думать вообще не надо и сейчас все это выглядит намного проще не надо писать не релиз не of the release ничего но of the release пул в принципе еще может пригодиться в 2021 году и даже в свифти для чего он нужен сейчас он применяется в основном тогда когда нужно оптимизировать циклы снизить
00:24:00 - 00:25:11
максимальное потребление оперативной памяти в них например у нас есть какая-то функция которая в цикле создает объекты из foundation или и айкидо я опять же не все но некоторые например видим лишь смысл в том что эти объекты а помеченные тегом of the release и если их создать они останутся в памяти до тех пор пока не будет завершён весь цикл а по факту они будут ждать по факту пока не завершится текущая итерация ран лупа в основном потоке и соответственно не будет очищен off of the release pool и
00:24:36 - 00:25:53
поэтому если мы запускаем большой цикл какой то в главном потоке то of the release пул не будет очищен до тех пор пока весь цикл не закончится как это можно исправить а исправить это можно вот так вот если завернуть внутренности этого циклов of the release пул то мы явно даем понять что что короче что делает этот код по сути он создаёт отдельный автор или spool который автоматически очищается после каждой итерации то есть вот этот of the release пол блок это довольно удобная штука которую добавили не сразу
00:25:14 - 00:26:28
которая появилась намного позже чем вся основная масса операторов связанных с авторе лизингом что она делает мы создаем of the release пул а в конце когда все действия заканчиваются мы очищаем его и получается что на каждую итерацию мы соответственно очищаем автор или spool и в конце каждой итерации мы получается освобождаем ресурсы занятые вот этими дикими джами и соответственно каждой итерации в целом и получается что получается что если мы не используем авторы из пол внутри цикла то наша память продолжает накапливаться до
00:25:50 - 00:27:09
тех пор пока цикл полностью не закончится здесь например это заняло сорок пять мегабайт но зачастую если вы обрабатываете какие-то объекты core графики допустим это может быть не сорок пять мегабайт а 500 мегабайт или еще того больше поэтому автор или спал реально пригождаются если же мы будем использовать автор или spool руками то мы увидим что выше 5 мегабайт выше 6 мегабайт точнее на протяжении всего цикла наше потребление памяти не вырастала и соответственно иногда автор или spool даже в 20 в 2021 году может
00:26:31 - 00:27:49
вам пригодится вот опять же если есть какие то вопросы задавайте насколько это перформанс билет насколько это бьет по перформанс у имеешь ввиду освобождение ресурсов на каждой итерации но до создавать автор или сполна конфедерацию суши на смотри если просто если просто даже посмотреть вот по этим графиком мы увидим что цикл на первом графике когда мы не использовали of the release пул закончился где-то на 4 полосках примерно может быть чуть раньше ой 4 полоски это у нас давай посмотрим сколько это так 3
00:27:10 - 00:28:36
4 5 короче две полоски это получается 1 1 секунда насколько я понимаю или одна миллисекунда в общем заканчиваются они на самом деле примерно в одно и то же время начинать нет 4 полос очках поэтому какого-то сильного удара по перформанса это не нанесет явно но да это будет работать чуть медленнее чем соответственно вариант без постоянной очистки ресурсов но в 2021 году как бы девайсы уже достаточно сильные и эта разница будет просто неощутимым окей двигаем дальше дальше о чем мы поговорим это те
00:27:53 - 00:29:09
блоки и лай блоке d блок эта ситуация при которой а при которой несколько процессов находится в состоянии ожидания ресурсов заняты друг с другом и при этом они оказываются просто взаимно заблокированы поскольку один процесс ждет пока закончится 2 2 проц с ждет пока закончится первый стоит сразу отметить что белок может произойти только тогда когда доступ к ресурсам является эксклюзивным то есть в том случае когда один объект может быть одновременно занят только одним каким-то процессом простейший пример 2 блока
00:28:31 - 00:29:48
можно воспроизвести с помощью следующего кода и я думаю много где уже это было разобрано наверное в нескольких докладах до этого да вот это прям это приводит просто к падению приложения и где блоком что происходит здесь можно просто разобрать это по очереди main это последовательная очередь то есть в ней одновременно может выполняться только одна задача сначала мы добавляем в очередь задачу номер один и начинаем ее выполнение это как раз таки вот здесь вот помечено комментарием task номер один в рамках задачей номер
00:29:12 - 00:30:28
один мы должны добавить и выполнить в основной очереди задаче номер два она помечена соответственно комментариям task номер два но это невозможно задача номер два является синхронной вот тут можно увидеть опять же что мы вызвали и методом sing а что делает метод sing это блокирует поток до тех пор пока задача не будет выполнено но это не получится ни в каком случае потому что эта задача даже никогда не сможет начаться так как очередь занята задачей номер один и получается что задача номер один вот это
00:29:52 - 00:31:05
не выполнится до тех пор пока не выполнится задача номер 2 и соответственно оно так и будет занимать очередь а задача номер два даже не сможет начаться до того как выполнится задача номер один и соответственно это просто приведет к вечному ожиданию и система решит что как бы такое приложение лучше всего завалить сразу такое довольно часто происходит и если в приложении встречается очень много ручного перекидывания между потоками опять же сейчас я не могу придумать какого-то большого количества кейсов когда это действительно было бы
00:30:28 - 00:31:43
уместно потому что мы по большей части вы просто перекидываете куда-то бэкграунд поток какие-то жирные от операции потом возвращаетесь в main и у вас нет такого жесткого пинг-понга между потоками скорее всего это в основном пригождается если вы пишите какую то либо или какой-то отдельный фреймворк там возможно до в обычной жизни вряд ли вас это будет происходить часто и возможно даже не произойдет никогда но верно с точки зрения там использования рыкса там тоже можно это на по рации что прям рукожоп это все делать мочи специфично
00:31:06 - 00:32:25
нужно извернуться это надо постараться на самом деле потому что rx тоже не такой тупой и в принципе там все обработано за вас вам просто будет кинут error в консоль как бы и будет сказано что скорее всего вы что-то делаете не так вот за это уже как бы можно не беспокоиться поскольку по большей части разработчики ли бы все уже продумали за вас вот пример блоков из реальной жизни если у нас есть какой-то перекресток который не и не регулируемый абсолютно на нем нет светофоров там нет какой-то главной дороге они всех все обе главные
00:31:46 - 00:33:01
как бы может получиться такая штука что вот эти четыре машины подъедут одновременно соответственно перекрестку соответственно центру дороги и получится просто так что никто из них не сможет разъехаться если они продолжат ехать по правилам как все смерть и а что же в таком случае вообще делать в таком случае надо как то наверное попытаться исправить эту ситуацию не по правилам то есть добавить какой-то алгоритм который будет выполняться в случае возникновения 2 блока возможно который будет автоматически обнаруживать
00:32:23 - 00:33:39
эти ситуации и подавляй этих но может возникнуть кейс когда подобные алгоритмы будут недостаточно хорошо проработаны и тогда возникнет противоположно id2q ситуация lifelog lifelog эта ситуация когда оба процесса которым нужен один и тот же какой-то ресурс они будут бесконечно уступать друг другу право владения то есть в принципе самый простой пример который мы можем увидеть я его наглый украл просто но больше наверное настолько наглядному ничего не придумаешь если у нас есть какая-то узкая дорога и понятные узкой дороге
00:33:00 - 00:34:13
навстречу друг другу и идут два человека одновременно по этой узкой дороге они как бы пройти не смогут поэтому кто-то должен будет уступить соответственно своему своему таинственному незнакомцу который идет на встречу и отойти соответственно к обочине но если вдруг получится так что они будут отходить в одну и ту же сторону постоянно то они просто никогда не пройдут если в реальной жизни одному из этих людей просто в один прекрасный момент надоест бегать туда-сюда и он просто встанет на месте то достаточно много
00:33:38 - 00:34:51
алгоритмов написанных как бы на каких-то языках они могут не быть такими умными и будут просто продолжать в одни и те же стороны отходить что также принципе завалит как бы ваше приложение но опять же лайфхаки встречаются намного реже потому что для этого нужно начинать править д блоки а те блоки обычно стараются избегать вовсе то есть не исправлять их последствия а стараться избегать вообще то есть не допускать ситуаций таких в принципе то есть облегчать как то возможно облегчать логику в приложении
00:34:14 - 00:35:32
возможно использовать какие то другие методы синхронизации не использовать там уже можно говорить об этом очень много но по большей части в реальной жизни опять же если вы пишете обычное приложение скорее всего d-блок у вас может возникнуть только в случае если вы пытаетесь в одной и той же очереди через gcd вызвать синхронную задачи это скорее всего 99 процентов кейсов когда вы встретите вообще предлог в следующей теме мы поговорим еще про то как можно вызвать те блоки но сейчас давайте пока по вот этой теме если у кого-то есть
00:34:53 - 00:36:11
вопросы то можете опять же задавать мне есть небольшой комментарий по поводу life лаков их можно делать создать скажем так не только тогда когда разрешаются до блоки а например косвенно ну это не совсем лайфхак они в чистом виде но например когда у нас одно какое-то событие день ну точнее одно действие генерит какое-то событие происходит какая-то работа которая генерирует другое событие и соответственно поэтому события опять происходит какое-то первоначальное действие и в итоге приложения зацикливается о том что она обработку
00:35:32 - 00:36:39
какую-то делаем но в результате получается что она просто гоняет по кругу одно и то же такие ситуации уже проще воспроизвести даже там где то опустим в рамках объявим с рексом что мы что-то отправляем туда это как-то отрабатывает мы о из где модельки что-то отправляем в юшку это как-то отрабатывает отправляя папе модельку и вот тут можно зациклиться и в итоге получится что не замечаешь этого действа всего которое происходит там на фоне а приложение почета подтормаживает начинает вот эта ситуация вполне
00:36:06 - 00:37:13
реальная и такое можно достаточно легко накосячить ну если неправильно приготавливать это все и не отслеживать тоже что вызывает какие события и это да окей да да едем дальше и следующий вопрос который мы рассмотрим это локи и мьютекс ее семафоры и так далее обычно это все объединяется в одну тему поскольку это все является по большей части механизмами для singsing синхронизации работы потоков для их доступ и каким-то ресурсам зачем они нужны чтобы предотвратить ситуацию когда разные потоки одновременно пытаются
00:36:39 - 00:37:51
получить доступ к одному и тому же какому-то ресурсу есть два способа первый не допускать подобные ситуации в принципе что звучит хорошо в теории но не всегда реализуемые на практике но опять же если вы можете их не допускать то лучше их не допускать вообще и вариант 2 исправлять последствия исправлять последствия с помощью специальных инструментов для синхронизации потоков и одним из простейших инструментов синхронизации является мьютекс мьютекс это сокращение от не учел эксклюзив то есть взаимное из
00:37:15 - 00:38:27
исключения как можно понять из названия мьютекс исключает одновременный доступ из разных потоков к одному и тому же никому ресурсу для примера возьмем например для примера можно взять абстрактную примерочную кабинку в магазине или вход в дом какой-то где может жить только один человек абстрактный дверь может быть либо закрытая либо открыто если дом свободен если кабинка свободна то человек не и заходит закрывает дверь на защелку и начинает там что то что то делать если вдруг затем появляется еще
00:37:51 - 00:39:03
один человек который хочет зайти в этот дом или в эту кабинку он не сможет это сделать до тех пор пока оттуда не выйдет первый человек не от не откроет дверь и соответственно этот другой человек который стоит около этой двери он вынужден ждать до тех пор пока тот кто находится внутри до тех пор пока тот кто первый забронировал этот дом или эту кабинку не закончит свое взаимодействие с ресурсами дверь в данном случае это не что иное как и мьютекс и стоит сразу отметить что в некоторых из языках программирования понятие лоб и
00:38:27 - 00:39:39
мьютекс могут быть отдельными сущностями со своими особенностями но в ios в объектив сивцев те мьютекс это простая разновидность лог что следует принципе рис официальной документации если мы посмотрим на соответственно типы log off мы увидим что мьютекс это простейший лог который служит таким защитным барьером вокруг ресурса и в принципе тут в официальной документации все это описание также предоставлено и чуть ниже в той же самой документация я не стал это вставлять сюда но там написано что и не слог это самый
00:39:03 - 00:40:19
простейший лог который есть в айосе он и реализует этот самый мьютекс и одной из важных особенностей ns лака заключается в том что у него есть владелец и разблокирован этот замок должен быть ровно тем же потоком которым он был заблокирован можно по этой же картинки додумать немного что допустим если человек зашел в этот дом он закрыл допустим дверь на какую-то защелку которая может быть открыт открыта только изнутри это как раз таки есть и не слог то есть если человек даже попробует открыть эту дверь снаружи он это сделать
00:39:41 - 00:40:57
не сможет поскольку из из внутри это дверь захлопни то на защелку это основная особенность ns лака и о том что у меня слово есть владелец который обязан открыть этот лог перед тем как выйти и никто кроме этого владельца лоб открыть не может об этом надо помнить если попытаться разблокировать замок из другого потока то произойдет underwear о чем нам говорит в принципе документация и наверное стоит стоит избегать таких кейсов вообще и лучше так не делать более того блокировать и разблокировать замок нужно только тогда когда это
00:40:19 - 00:41:39
действительно вам нужно если попытка разблокировать уже разблокированный замок просто кинет ошибку в консоль то если вы попытаетесь заблокировать уже заблокированный замок это приведет к дидло q такова особенность реализации и если ваш метод нас например вызывает царь и рекурсивно и вам действительно нужно не несколько раз вызвать блокирование одного и того же ресурса то для этого есть а н с и курсе флаг который в принципе мы вот здесь же опять в списке лаков видим он реален он есть он реализован через и не
00:40:59 - 00:42:14
сорить в курсе флаг и в таком кейсе вам нужно будет использовать именно его но важно помнить что чтобы разблокировать этот замок нужно разблокировать его ровно столько же раз сколько он был заблокирован иначе ресурс станица опять же вечно висеть заблокированным и никто не сможет получить к нему доступ на самом деле помимо мьютекс а есть еще один очень распространенный тип синхронизации которые мы называется семафор и семафор он в принципе похож на мьютекс но отличается несколькими особенностями
00:41:36 - 00:42:47
во-первых главное его отличие от мьютекс заключается в том что семафор позволяет предоставить доступ к одному и тому же лесу сразу нескольким потоком число может быть от одного до бесконечности в принципе сколько вам требуется то есть если мьютекс всегда дает только одному какому-то потоку завладеть одним ресурсам то 7 семафор в принципе может позволить нескольким сразу потоком завладеть одним и тем же ресурсам в ios он реализован классом dispatch семафор добавлен насколько я помню когда появилась gcd в целом да в
00:42:12 - 00:43:26
принципе вы можете просто задать один и тогда механизм будет очень похож на то что предоставляет мьютекс но между бьют иксом и семафором есть одно очень важное различие семафор может быть разблокирован из любого потока не только из того потока который заблокировал изначально который за забрал себе ресурс разблокирована может быть из любого потока это основное различие между new так сам и семафором в том что у них разное отношение владения то есть в нью такса есть такое понятие как отношение владения убьют икса есть владелец
00:42:49 - 00:44:04
и именно он должен разблокировать мьютекс у семафора нет владельца поэтому он может быть принципе разблокирован из любого потока простейший пример 7 семафора это допустим фейс-контроль в клубе который просто пропускает всех но считает сколько осталось свободных мест внутри этого клуба если допустим если он уже впустил допустим 20 человек и больше он просто не может впустить внутрь он будет ждать до тех пор пока хотя бы одно место не освободиться и когда это место освободится он сможет забыть ведь туда следующего человека и так
00:43:27 - 00:44:45
далее и так далее так далее то есть отличие по большей части 2 первое что семафор позволяет сразу нескольким потоком получить доступ к одному и тому же лесу и второе то что у семафора нет понятия владения в то время как у мьютекс а есть понятие владения и с семафорами в принципе да вы можете вызвать сигнал семафора то есть разблокировать какой-то ресурс из другого потока но вопрос уже другой а действительно ли вам оно надо и зачастую это пахнет грязным кодом если вы пытаетесь разблокировать ресурс который занят другим потоком ну в
00:44:06 - 00:45:29
общем как то вот так если есть вопросы по этой теме задавайте о кей судя по всему вопросов нет тогда мы идем дальше и следующая тема бит код пробит код довольно тоже многие слышали те кто связан союз разработкой и и те кто выливали хотя бы хоть раз сборку в appstore connect они наверное видели вообще и слышали про это слово что же такое bitcoin если говорить максимально просто the beat код это промежуточная ступень между исходным кодом и машинным кодом зачем он нужен рассмотрим на примерах допустим вырос разработали некоторые
00:44:47 - 00:46:03
приложения и хотите распространить его в appstore xcode сбил did ваши приложения под все указанные процессор ные архитектуры которые заданы обычно сейчас это aero м-64 armv7 ну обычно только n64 если мы говорим про самые последние приложения в принципе вы можете поддерживать и какие-то более старые архитектуры но тогда при билде ваш бинарник окажется чуть жирнее потому что все это по сути с вся поддержка всех архитектуры которые вы указали она вся за запаковывается в один бинарник и поэтому чем больше
00:45:26 - 00:46:42
архитектуру вы поддерживаете тем жирнее бинарник будет и соответственно тем больше придется скачивать вашему пользователю более того если вдруг появится устройство с процессорами на новой архитектуре они не смогут использовать старую версию приложения которое залита в appstore вам придется руками пересобирать сборку с поддержкой новой архитектуры и опять же заливать новую версию в appstore руками так было до появления бит кода теперь же если в настройках проекта включить эту опцию то xcode не станет
00:46:04 - 00:47:11
бил бить ваши приложения под каждую конкретную архитектуру процессора которую вы указали вместо этого он создаст общей промежуточный код который будет загружен в appstore connect ну вот здесь вот он указан как айтюнс connect потому что немножко устаревший скриншот из документации опять же финальные бинарники под конкретные архитектуры в том в том числе которые появятся в будущем appstore сгенерирует автоматически то есть если вдруг появится какая-то новая архитектура прилла а если появится новая
00:46:38 - 00:47:42
процессорная архитектура то все новые девайсы которые сделаны на этой арке архитектуре а не смог бы просто зайти в appstore и скачать старую версию приложения потому что appstore автоматически выльет для них нужный вариант и это приводит к тому что во-первых вы не должны будете руками пересобирать сборку во вторых это позволяет вам уменьшить размер бинарник а более того apple постоянно старается улучшать эффективность своего компилятора поэтому если вдруг сам компилятор будет каким-то образом улучшен appstore автоматически
00:47:09 - 00:48:23
перри соберет бинарники чтобы оптимизировать код внутри и возможно это еще уменьшить размер приложения для конечного пользователя в основном конечно здесь плюс и но могут быть и минусы опять же если вдруг вы боитесь что ваше приложение на новый процессор на архитектуре будет вести себя как то не так и она сломается и что допустим если придут какие-то новые девайсы ваши пользователи скачаю туда приложения и просто не получат должны user experience который они ожидают приложение будет работать не так то
00:47:47 - 00:49:06
наверное не стоит включать бит код с если вы очень тщательно к этому всему этому всему подходите если вы предпочитаете чтобы сначала тестеры все прогнали посмотрели чтобы убедились что все работает нормально лучше выключите бит код и на самом деле это сэкономит вам еще немножечко времени в дальнейшем об этом мы поговорим с этим следующей теме почему бит код это не всегда хорошо и не всегда удобно но если вы беспокоитесь о том что размер вашего приложения слишком жирный вы хотите немножечко облегчить ваше приложение вы хотите
00:48:26 - 00:49:42
сделать так чтобы пользователь своевременно получал новые более оптимизированной версии то включайте бит код и будет вам щастье принципе опять же на этом все если у кого-то вопросы побит кода есть можете задать здесь не не вопрос наверное все из дополнения что в андроиде примерно такая же штука существует она называется об вариант что лили как-то вот здесь могу ошибаться названием точно подскажите если кто помнит то есть не не ripple только такой штукой снимается и есть возможности в андроиде уменьшать скажем так размер
00:49:04 - 00:50:11
приложения которое лежит в 100 report соответствующий там девайс соответствующее разрешение допустим на ожидая если говорим про ресурсы какие-то вопросы смартфон да да да как это как раз будет в следующей в следующем пункте скажем так здесь все идет по порядку и как бы следующие темы они немножечко завязываются на предыдущий поэтому про firebase я расскажу но есть такая если вопросов больше нет по ну если точнее вопросов нет по этой теме то опять же немножко дополню то ли она до бит код это одна из нескольких один из
00:49:37 - 00:51:07
нескольких механизмов которые теплом были придуманы для как раз таки да облегчения общего приложения а помимо бит кода насколько я помню там есть еще несколько механизмов которые опять же также включают в себя различные менеджмент ресурсами то есть для разных девайсов можно засовывать разные-разные подходящие к ним ресурсы разные картинки и так далее документации сейчас я даже попробую это найти блин не могу к сожалению найти но где-то ссылка у меня на это на это было я обязательно приложу в общем да скорее
00:50:22 - 00:51:28
всего apple просто украли все с android я сомневаюсь что это android украл сипло потому что я хожу в данном случае бит код появился не так давно не супер давно поэтому я думаю что в android and ios раньше а может быть и нет если кто-то на андроиде шарит за это то в принципе можете сказать когда у вас это появилось ну или пишите в коментах если на youtube жар окей тогда ладно едем дальше и следующая тема это 7 что такое темы про это тоже многие слышали но не совсем понимают как это вообще работает и что это если говорить кратко
00:50:57 - 00:52:11
то когда xcode компилирует исходный код в машиной он автоматически генерирует отладочные символы эта информация которая показывается соответствие между исходным кодом и скомпилированных бинар ником благодаря этой информации вы можете использовать дебаггер например чтобы поставить breakpoint на определенной строке или определить по краж логу какая строка исходного кода привела к этому крашу дэбак сборки эти отладочные символы хранят прямо в бинарники то есть если вы просто за запустили что-то в дебат
00:51:35 - 00:52:44
режиме вам особо думать не надо релизный сборки отладочные символы закладывают в отдельный гасим файл вынесение в отдельный файл позволяет снизить размер отгружаемого пользователю приложения потому что допустим я я вот сегодня пытался скопировать носимые для того чтобы посмотреть кое-что и полный пакет симов весил 12 мегабайт то есть это довольно большой размер именно поэтому было решено вынести это в отдельный файл для того чтобы не нагружать пользователи еще сильнее в то же время поскольку этот
00:52:08 - 00:53:17
файл выносится отдельно от бинарник а это вносит некоторые сложности например заливать этот файл символами в сервисы вроде фабрика краж лить x и так далее друг других трекеров каких-то для ошибок вам придется руками либо через скрипт так знакомый многим build фэй скрипт который мы видим вот здесь он как раз таки и делают то что при билде отправляет соответственно все 7 которые были созданы он их заливает фарба искра шлите кс и вы впоследствии сможете этими темами нормально воспользоваться для того чтобы
00:52:43 - 00:54:00
получить информацию о том на какой строке произошел краж чуть больше сложностей появляется если в проекте включена поддержка бит кода при архивации и отгрузки сборки в appstore xcode of us и рует все имеющиеся отладочные символы и создает еще один файл то есть помимо симов он создает еще один файл который по сути хранит в себе информацию о том как закодированы внутри эти цены и в этом вся проблема в том что если просто залить обфусцированы зимы в сервисы вроде соответственно файла искра шли текса вы
00:53:21 - 00:54:38
не получите никакой нормальной информации поскольку они за зож зашифрованы и их заливка по сути не даст вам ничего в случае с биткойном надо действовать немножко по-другому сначала вы заливаете это в appstore в принципе как как как и делаете всегда вам надо будет поставить галочку о том что да я хочу залить 7 туда затем внутри appstore коннекта когда вы зайдете туда зальете сборку зайдете в настройки сборке вы сможете увидеть вот такую штучку эта информация полностью о сборке которую вы залили и в графе включает символы да или нет
00:54:00 - 00:55:23
если они есть вы сможете скачать их себе затем залить руками firebase и только тогда firebase прошли тег сможет нормально обработать ваш и краше и показать вам где на какой строчки они произошли если вы не зальете этим и туда то скорее всего никакой подробной информации вы не получите в этом как раз таки на мой от и заключается основная проблема бит кода в том что если вы включаете бит код вам приходится каждую залитую сборку в test flight руками проверять на наличие симов скачивать их заливать руками опять же
00:54:41 - 00:56:03
файл bass и только тогда это все будет работать если вы выливаете в то спать сборки не так часто может быть раз в месяц или раз в неделю тогда это не особо большая проблема просто когда выходит какой-то мажорный допустим релиз вы загружаете отсюда дасима и заливаете их соответственно firebase но если вы используете test flight как ваше основное средство для диз дистрибуции приложений и если вы отгружается туда какие-то сборки постоянно то наверное это будет не особо удобно и проще будет отказаться от firebase
00:55:22 - 00:56:38
прошли текса вообще и использовать встроенные методы и apple а для соответственно просмотра краше льда такие есть но видимо мало кто ими пользуется работа кто-то полежать которые нихера не работают гулять а в чем там проблема кстати я ни разу не пользовал прост как они блин я не знаю ни разу не показывали нормально так также как тот же прошли текст о том как где произошла ошибка во сколько я ни пытался не воспользоваться всегда какое-то получался в честный слов нихера не габай полезную информацию
00:56:00 - 00:57:13
apple болеть если вы это читаете поправьте уже хотя бы это оспы сколько лет ну в принципе я не удивлен на самом деле тому что очередная фича то плохо работает как я не удивлена абсолютно дима у тебя вроде был вопрос я надеюсь я на него ответил да потому что я хочу еще может быть профи bass boost как раз начали с этим сталкивались ну на самом деле по большей части на большинстве проектов которые мы мы либо поддерживали ли либо писали мы просто вырубали нафиг бит код и все как бы на этом как бы все
00:56:37 - 00:58:04
и еще может быть сбит кодом проблемы одна связана она с тем что если вы в своем проекте храните какие-то либо которые добавлены как бинарники прямо которые уже скомпилированы были скорее всего вы не сможете отгрузить это как бит код в соответственно appstore если у самих этих lip не была включена поддержка бит кода то есть на сколько я понимаю если у вас уже есть некий скомпилированный под определенную архитектуру бинарник вы не можете этот бинарник перевести в бит код вам надо иметь соответственно с урсы для того чтобы эти
00:57:20 - 00:58:49
старцы перегнать в бит код из бинарник off beat код вы скорее всего это не сможете сделать и вот как раз таки на проектах где у нас были всякие не помню openstreetmap и или еще отчеты которые просто добавлялись как которые добавлялись как бинарник они не позволяли короче скомпилировать это в бит код поэтому там приходилось изначально вырубать и даже не думать о том типа включать бит код или нет вот по до сего мне побит коду наверно я даже не знаю больше чем рассказать если у кого-то есть вопросы то можете опять же
00:58:04 - 00:59:14
задать видимо нет ну видимо нет да и в восьмой вопрос по которому у меня даже нет никаких слайдов потому что там принципе ничего на слайды выносить это довольно часто встречающийся вопрос инесса песенку против g сидишь тоже лучшие что следует применять и ответ на самом деле просто я могу сразу сказать от ответ выбор весь сводится только к здравому смыслу для простых задач вам понадобится скорее всего джи си ди для более сложных инесса песенку рассмотрим чуть подробнее и потом вернемся к нашему выводу для работы с потоками у вас
00:58:38 - 00:59:58
разработчика есть несколько инструментов основными из них являются джеси д и н с от racing yoon-g сиди это низкоуровневая а фишка основанная на сяс инесса первичном кью в свою очередь это высокого уровня обертка на g сиди написанная над на объекте все будучи надстройкой над джесси днс api рисунки у имеет некоторые свои плюсы первые инесса трещинку позволяет задавать зависимости между отдельными тоска me определяя порядок их выполнения это позволяет вам создавать сложные графы задач которые должны быть
00:59:19 - 01:00:30
выполнены в определенных условиях один после другого и так далее с помощью g среди вы такого сделать либо не сможете либо сможете с большим количеством оверхеды и выглядеть это будет немножечко ужасно второе инесса першингу позволяет задавать лимит на количество одновременно выполняющихся задач то есть по сути это как семафор он позволяет только нескольким задачам одновременно выполняться джи си ди вы опять же без костылей это сделать не сможете но либо вы можете добавить туда dispatch семафор и с помощью dispatch
00:59:54 - 01:01:13
семафора гонять несколько задач но зачем если можно с помощью двух строк буквально с атрошенко это зависти и третье и на операцию позволяет немножечко проще манипулировать тасс камень ежели в g сиди с помощью операций по us can sell rise ум внс апельсинку также легко отслеживать состояние отдельных задач а над большинством state of можно наблюдать с помощью кого он и выглядит это реально круто и работает это реально круто но помимо плюсов у инесса перешейку есть и очевидные минусы первый это то что н.с. апельсинку
01:00:33 - 01:01:51
это обертка на g сиди она чисто физически не может работать быстрее чем джи си ди поэтому каждый раз когда вы используете н.с. operational вы закладываете некий оверхед что немножечко скорее всего незначительно ударит по перформанса но опять же в 2021 году думать о перформансе в таких мелких задачах которые не ставят перед собой чего-то глобального и скорее всего не повлияют примерно никак ну это глупость и это то что синтаксис внс апельсинку в принципе не такой простой как джесси день если вы хотите перекинуть какой-то
01:01:12 - 01:02:35
task в другой поток в джи си ди вы сделаете это буквально за одну строчку кода вы не собираешь никки это будет выглядеть немножко более массивная и ним немножко более страшно плюс опять же в 2021 году вы не так часто встретите использование н.с. operational прямо повсюду скорее всего для операции с потоками по большей части будет использоваться g сиди и только в самых редких случаях когда нужно использовать какие-то явные преимущества н.с. operational вроде зависимости между задачами или лимита для задач или допустим там
01:01:54 - 01:03:10
при остановке задач там наверное да там будет использован н.с. operational что использовать вам опять же зависит только от вас зависит от того что вам нужно если вам нужно сделать какую-то сложную задачу то используйте ns отбираешь секунд а если у вас что-то простое просто используете g сиди и не морочьте себе голову и не морочьте голову тем кто будет рябить машку как как то так если какие-то вопросы есть то давайте постараюсь ответить ну так серьезно нюанс что прозвучало так как будто джесси деприм низкоуровневое
01:02:32 - 01:03:38
session и да это действительно так но здесь один есть маленький нюанс она очень круто интегрирована с ее вт соответственно командами и здесь никакой сложности с использованием juice де вообще нет скорее наоборот она иногда бывали а проще и короче в использовании чем вот отдельная создаваемые объекты мастеришь хотя у ты не собираешь им весь блок и получается так же практически в одну строку так что здесь вкусовщина да здесь все верно госказну ну и плюс по большей части метаться все гады сейчас они
01:03:05 - 01:04:18
включают в себя именно работу с потоками на g сиди поэтому большая часть людей скорее всего знают написать на g сиди и поэтому лучше пишите на g сиди потому что все знают как это работает не все знают как работает н.с. operations in сокровищницы но если вдруг вам сильно нужно так окей тогда наверное все или нет вопрос вообще по теме про а если есть какие то вопросы и кстати да если у вас есть еще какие то вопросы которые вы хотели бы чтобы они были рассмотрены то кидайте в df или еще куда то кидайте в
01:03:41 - 01:04:51
комментарии если вы смотрите это видео на youtube и будем рады на них ответить потому что тем реально не так много осталось и если кто-то может что-то интересное подсказать мы будем рады сами разборы по действительно сложным темам которые самому копать будет чаще всего просто в лом и потому что особой необходимости нет а так периодически сталкиваешься спасибо огромную на этом наверно россию
в общем список вопросов он был уже скинут general но мы сейчас просто пойдем подряд и будем рассматривать все а еще в чем смысл смысл в том что все эти сложные вопросы обычно сопровождаются кучи документации которую никто не читает и всем лень я постарался каждый из этих вопросов запихнуть в рамки 5 минут и в рамках этих пяти минут разобрать большую часть всего что может быть с этим связано и потом соответственно поставок доклад закончится я скину просто все то же самое в текстовом формате со ссылками на
00:00:00 - 00:01:04
документацию если кто-то захочет более конкретно это все почитать итак поехали первый наш вопрос это тол фри bridging многие наверно слышали про это но никогда не знали вообще что это такое и чтобы разобраться что такое туфли bridging стоит немножечко обратиться к истории зайти и так сказать издалека в один прекрасный момент стив джобс со своей командой решил создать mac os x за основу было решено взять mac os 9 но при этом переработать его на манер next step nextep их операционная система которую они сделали параллельно основная
00:00:32 - 00:01:43
разница была в том что оно xt объектно-ориентированная операционная система в то время как mac os соответственно который был до mac os x он был написан в основном носи использовал процедурный подход и это были категорически две разные вещи и для создания новых приложений под новую операционную систему которая не хотели сделать использовался api open step это такая apes к для условно говоря разработки вот именно новых приложений под nextep узкие архитектуры в дальнейшем он будет переименован в cocoa который нам известен как бы сосуа
00:01:07 - 00:02:19
какого коко как его называют по разному но сейчас про него все слышат все знают он использовал язык объекте все имел как базу известны многим мирный foundation кит вы встречаете с ним буквально постоянно когда создаете новый файл им портится foundation это как это как раз таки вот и есть тот самый фонд foundation кит и в нем были свои классы например н срнс string и прочее н.с. всякие штуки которые вы тоже довольно часто видели но это для разработки конкретно новых приложений надо было еще как-то портировать старые
00:01:43 - 00:02:49
приложения которые разрабатывались под macos делись и под более ранние версии и вот с этим была проблема для этого было решено разработать конкретно новую описку под названием карбон которая существовала она была разработана она существовала до насколько я помню маклая скатали на но в биг сирии и уже полностью выпилили сейчас никакого карбона там нет и отсылок к этому нет то есть полностью и плохо переноса старых приложений закончилась и вот смысл ты был в чем смысл был в том что стив джобс и разработчики сразу задумались о том а
00:02:16 - 00:03:26
как обеспечить удобное взаимодействие этих двух опишет в рамках одной операционной системы все-таки надо было чтобы они умели как-то между собой взаимодействовать и чтобы это было не совсем костыль на и для этого было принято решение создать общий фундамент для обоих интерфейсов его написали на чистом си и назвали core foundation ну как бы корр foundation это ядро фундамента ядро основания то есть это то самое ядро которое лежало в базе обоих опишет и какао и соответственно карбон по структуре по сути он полностью
00:02:51 - 00:04:00
копировал своего прародителя поскольку core foundation по большей части был взят из foundation кита но переписан объекте все на чистый син и в итоге получилось как полностью практически структура повторялось структура foundation только соответственно пор foundation были использованы свои классы например вместо n с array там был съев р.ф. вместо n с strings эстрин грех и так далее то есть вот на этой таблице можно посмотреть большую часть соотносящихся друг с другом классов и увидеть что по большей части они
00:03:25 - 00:04:41
называются плюс-минус похоже единственное что добавляется в кор fondation это добавляет царёв в конце чтобы явно указать на то что это как бы ссылка на какой-то объект ессеев соответствует аккор fondation а н с насколько я помню это сокращение от nextep и вот как то вот так выглядит сравнительная таблица классов в двух framework of a по сути большая часть foundation кита стала оберткой над над различными классами и методами core foundation а то есть когда мы обращаемся конец арию по сути мы работаем с серой рифам но
00:04:02 - 00:05:25
посредством foundation of sky обертки вот и наконец-то мы подошли к заголовку нашей темы что же такое толпы bridging a toll free bridging это возможность использовать объекты core fondation там где требуется их аналоги из foundation и наоборот например если какой-то метод принимает на вход ns string то вы совершенно спокойно можете закинуть туда объект типа осев stren грех и наоборот если метод принимает например сиф ловок и евреев вы можете подменить его объектом типа ns локаль все что нужно при этом
00:04:44 - 00:05:54
это просто сделать кастинг объектах его аналогов требуемой опишите ну например вот это примеры из официальной документации выглядят они очень стара потому что написаны они были очень стара объекте все все дела и в первом примере что мы делаем мы создаем объект типа ns локаль затем мы этот м с локаль просто берем и костюм в sea of local риф и уже в таком-то методе а который принимает соответственно а нет в первом как раз таки примере мы создаем да мы получаем 7-ой бинти fire и затем мы 7-ой бинти fair преобразовываем внс
00:05:19 - 00:06:38
string поскольку и не слог у нас просто принимает ns string на вход для отображения и мы просто прокидываем туда этот сев убить fire который мы за кастили и все работает в примере пониже мы создали соответственно нс1 the fire через стрелку а затем с помощью методы сев шоу который принимает внутрь соответственно 7 стрингеров мы просто за заказ теле закинули туда и это все работает и работает этот для большинства методов для большинства соответственно классов при но для всех классов представленных
00:05:59 - 00:07:18
но помимо этих есть еще некоторые классы которые не поддерживают the free bridging но обычно о них они указываются явно и в той же самой документации вы можете почитать какие конкретно классы не поддерживают этот толстый bridging то есть не поддерживают такой легкий интернет между собой вот принципе про the free bridging наверное все потому что здесь говорить то в общем то и не о чем это просто возможность кастить объекты и легко применять их в рамках foundation и core foundation а такой удобный интернет короче вот ничего
00:06:37 - 00:07:54
сложного здесь вообще капитально нет если у кого-то есть какие-то вопросы конкретно потолще bridging можете задать сразу и после этого мы пойдем дальше и меняйте может быть ну вообще нужны это может смотри это может быть нужно тогда когда ты будешь использовать не foundation of ski и объекты ну это может понадобиться тогда когда ты почувствуешь что foundation дает тебе слишком мало когда коко дает себе слишком мало и если ты вдруг захочешь написать свой лейбл или захочешь написать какой-то свой компонент который
00:07:17 - 00:08:23
будет использовать объекты именно core foundation а то есть если ты пойдешь использовать core графику если ты пойдешь использовать core текст если ты пойдешь использовать еще какие-то core библиотеки которые дадут себе больше возможностей нежели какие-то function of ski и соответственно класс и вот 10 обращаются допустим допустим лук тоже самый core графики ты будешь работать именно с вот эти миссия в классами по большей части илистом сиджей классами которые будут оборачивать по большей части те же сейф классы и в
00:07:50 - 00:09:09
таком случае ты сможешь прокидывать какие-то объекты ns не оттуда если тебе это будет проще допустим в принципе в 2021 году наверное это применяться будет очень редко если только ты не полезешь прям самую глубь и не захочешь написать какие-то свои компании ты базовых но по большей части сейчас это наверное уже не пригодится никогда особенно если вы не пишете на объекте все а если вы пишете на свете и просто кушаете то что вам дает apple как бы и используете то что в принципе используют все вот как то так
00:08:29 - 00:09:48
окей спасибо вопрос 2 jean-luc про ран лук тоже очень многие слышали если открыть официальную документацию и плату можно немножко с того насколько все это сложно устроено и с того насколько давно это всё писалось насколько это выглядит прям архаичное но мы попробуем это все рассмотреть чуть быстрее чуть проще что же такое разлук ранду pva с этот цикл который координирует получение и обработку входящих событий в конкретном потоки его основная цель это загружать поток работает тогда когда эта работа
00:09:07 - 00:10:15
есть а в остальное время усыплять поток чтобы он не расходовал лишние ресурсы и что сразу стоит отметить это то что каждый поток имеет ассоциированы с ним рангу ран глуп для главного потока приложения запускает и поддерживает автоматически в то время как для вторичных потока фронтов конфигурируется и запускается руками разработчика если ему вдруг это сильно понадобилось чтобы выяснить общее эти случаи необходимости сначала разберемся какие же события вообще может обрабатывать ран луп существует
00:09:42 - 00:10:47
несколько источников принципе если мы посмотрим на эту схему то отсюда уже все можно будет понять это различные устройства ввода такие как мышь клавиатура тачскрин и так далее так далее все что вы можете подключить в принципе она будет обрабатываться через через ран лук второе это различные порты вы можете прослушивать порты чтобы получать своевременно какую-то информацию и все это будет тоже обрабатываться через ран лук есть кастомные источники которые нужны по сути для того чтобы между двумя или
00:10:15 - 00:11:22
более потоками прокидывать быстро какую-то информацию про gastone и из источники в принципе можно говорить долго сегодня мы на них останавливаться не будем поскольку применяется это в одном случае из миллиона скорее всего в это не понадобится никогда еще вызову убер форм селектора по отношению к отрядам тоже завязаны на ран лупи и что самое важное для нас сегодня будет это то что все таймер и работают по сути поверх ран лупа без ропота мира и работать просто не будут если суммировать это все резюмировать
00:10:48 - 00:11:58
то для того чтобы прослушать порты добавить таймер вызвать пир форм селектор по отношению к кому-то по току или настроить кастомную пересылку сообщений между потоками вам придется использовать разлук более того при запуске ран лут можно явно будет указать какие же источники событий ему стоит отслеживать на текущей итерации для этого существует несколько режимов называемых ран лук маус и если посмотреть на документацию можно увидеть в принципе 5 базовых ран лук модов первый это дефолтный мозг это основной
00:11:23 - 00:12:32
режим в котором отслеживаются основные события режим connection которые отслеживают ns connection и которые по сути вам никогда не не пригодятся здесь даже написано что вам скорее всего не придется никогда это руками использовать и насколько я помню н с connection ее в разработке под ios конкретно они не существуют и нужны только для разработки под mac os модал опять же нужно только для разработки под macos это это специальный режим для работы с модальными окнами в mac os останавливаться на этом не будем
00:11:57 - 00:13:17
рассмотрим последние два года event tracking even tracking мод нужен в принципе понятно для чего для того чтобы отслеживать какие то нажатии на мышь нажатии на клавиатуру нажатии на тачскрин движение скроллинг и так далее и самый последний мод и the common mode который по сути объединяет в себе три мода это дефолтный мод это модальный мод и event tracking мод ну если мы говорим про ios про разработку под какие-то мобилки то модальный можно отсюда смело выкинуть и говорить что по сути команд для мобилок поддерживает
00:12:37 - 00:13:53
дефолтный мод и event tracking и вот на этом стоит обратить внимание с этим связано и довольно распространенная проблема а да вот еще соответственно когда пользователь начинает взаимодействие с ей основной разлук переходит в режим треккинга и временно откладывает обработку всех остальных событий чтобы обеспечить интерфейсу хорошую плавность для того чтобы все это работало быстро и вот с этим связано распространенная проблема когда у пользователя просто перестает работать таймер во время скроллинга причина это
00:13:15 - 00:14:17
кроется в реализации стандартного метода таймер скетч л таймер который мы можем увидеть вот здесь и чуть ниже будет просто строчка из официальной документации что здесь происходит этой командой мы создаем таймер добавляем его в текущей рану в дефолтном моде как мы уже выяснили дефолтный мод по сути что делает если мы добавляем это только для дефолтного года то когда мы начинаем скроллинг а когда мы начинаем скроллинг у нас наш основной ран лук переходит в режим трейдинга все другие события кроме
00:13:47 - 00:14:53
тех которые относятся непосредственно к нажать young скроллинг еще чему-то связанному с интерфейсом они будут просто проигнорированы и поскольку мы добавляем это в дефолтный мод наш таймер просто перестает работать как можно пофиксить эту проблему эту проблему можно пофиксить вот так вот вместо того чтобы использовать метод с кетил таймер мы просто создаем этот таймер руками с помощью конца с помощью конструктора и добавляем этот таймер для не дефолтного мода однако man мода a common мод на сколько мы знаем он
00:14:20 - 00:15:32
включает в себя дефолтный мод и режим треккинга то есть даже когда ваш разум будет переключен в режим tracking и когда вы скроллите ваш таймер все равно будет корректно обработан и вот это наверное as the основная проблема часто встречающиеся проблемы с таймером которую люди на том же 100 каир flow очень часто спрашивают как это фиксить а фиксится это очень прост более того есть еще одна распространенная проблема таймеров срабатывают они не совсем в то время когда ожидалось и могут вообще не сработать и почему же
00:14:56 - 00:16:06
это происходит происходит это в связи с тем что действие на каждой итерации ран лупы вы выполняются в строгом порядке строго заданном порядке он очень сложно его можно будет посмотреть в официальной документации там что-то в районе 10 10 шагов они все вы выполняются последовательно и например проверка таймеров на срабатывание выполняется в самом начале этого цикла и если вдруг мы этот шаг уже прошли и после этого только сработает таймер мы не поймем это до тех пор пока ран губ не пройдет на следующую итерацию именно
00:15:31 - 00:16:42
поэтому появляются задержки и по сути таймер он не является гарантией того что ровно там через десять секунд допустим если вы указали 10 секунд нет гарантий что ваши действия выполнится ровно через десять 7 она может выполняться через десять с половиной секунд или через пятнадцать секунд если вдруг ран лук будет выполнять что-то что-то очень жирное массивное в себе именно поэтому на таймер и никогда не стоит завязываться для того чтобы обеспечить какой-то супер великую точность в в во временной
00:16:06 - 00:17:22
координацией короче вот в принципе пор он лупу тоже наверное все основной я рассказал если у кого-то есть еще какие то вопросы потому что я тут немножечко перечислил то можете задавать остальное все будет опять же в документации но туда без пол-литра лучше не соваться сразу говорю там все довольно жестко на что тогда завязываться если не на таймер и смотри если ты хочешь прям чтобы максимально точно у тебя по времени что-то было выполнено наверное просто изначально вообще не стоит делать такие задачи то есть смотри в принципе ты
00:16:44 - 00:18:03
можешь использовать gcd использовать dispatch автор а какое то время но в любом случае если у тебя поток будет в это время занят то в любом случае твой таймер не сможет вы вот эту задачу в срок то есть все убирается просто в то будет занят поток или нет условно говоря если тебе повезёт и если таймер сработает ровно за миллисекунду до того как ты начнешь очередную операцию в разлуке то у тебя все сработает во время если мы даже не используем таймер и а используем допустим gchq и запускаем какую-то
00:17:24 - 00:18:43
задачу условно говоря выполнится ровно через пять секунд если у нас поток будет в это время занят то твоя задача в любом случае будет просрочена и как-то гарантировать что у тебя поток не будет занят ровно через пять секунд скорее всего мы не сможем и поэтому вообще выполнение каких-то задач которые прям строгую завязку на на миллисекунды требуют наверное изначально их просто не должно быть я даже не знаю каким способом можно нормально разрулить вот такую максимальную точность но здесь я могу подсказать единственное что я не помню
00:18:04 - 00:19:21
точно как эта штука называется если не ошибаюсь может кто-то помнит цех дисплей линк или как то так называются мир м сек отрисовки кадров они происходят чаще соответственно в идеале там ну 30 1 секунду да и тут вероятность попасть в это просто больше и точность будет побольше но идея примерно тоже остается что если какой-то какое-то events твоя блочит поток то все равно все идет приезде и соответственно да здесь нужно аккуратнее таймер мы из этого точные там и миллисекунды вчера мне сделали но в рамках там одной
00:18:42 - 00:19:55
секунды мы можем так делать обновлять какой-то таймер по секундам как не знаю как буду до пиццы там что ваша пицца бред через толком минут и секунд такое можно сделать но вот что-то точнее уже нужно прямо понимать что то делать и всегда брака просчет что может сломаться да ну либо если тебе прям надо явно делать максимально точный таймер ты можешь создать другой поток в нем явно создать ран loops запустить там ран лук и запустить в нем таймер и не запускать в этом потоке больше ничего и тогда возможно в том потоке ты сможешь
00:19:18 - 00:20:32
прямо во время поймать этот сигнал и перекинуть как то событие обратно в основной поток но опять же если он будет занят то от этого толку не будет досей displaying принципе хороший вариант но опять же если у тебя основной поток будет заблочен а весёлой работает в основном потоке и сейди spoiling опять же привязывается к основному потоку насколько я понимаю если у тебя вдруг будут не 60fps допустимо там сколько 30 или сколько сейчас вообще fps доступного и 60 или 30 на девайс по моему тридцатку не гарантирует могу ошибаться вот но
00:19:54 - 00:21:12
если вдруг чего то будет в главном потоке сильно блочить этот поток скорее всего сейди spoiling тоже развалится поэтому какого-то точного метода для того чтобы гарантировать выполнение в какой-то гарантированный срок но такого нет насколько я понимаю но это просто исходит из того как работается систему тут мы ничего с этим сделать не сможем но удар следующий вопрос это of the release пул про него тоже очень много кто слышал но много кто до сих пор про него не знает и сегодня мы про него поговорим что такое of the release пул
00:20:34 - 00:21:45
опять же немножечко обратимся к истории во времена ручного управления памятью разработчикам приходилось руками писать команды вроде литейная релиза для того чтобы повышать или понижать счетчик ссылок для некоторого объекта сейчас это все уже заменено automatic reference counting им но раньше это приходилось делать руками и проблема возникала тогда когда объект создавался внутри метода и возвращался из этого метода допустим вот выглядело это как то вот так ну да тут же написано что это работать не будет
00:21:09 - 00:22:13
если вызвать релиз прямо перед ритер нам то по сути объект уничтожится еще до того как будет получен тем кто вызвал метод и что же делать блин если мы не напишем этот релиз или если мы после ритер на напишем релиз или вообще не будем его писать то тогда на этот объект останется вечно висящая ссылка которая просто не позволит обе то уничтожится позже и это порождало утечки памяти и в данном случае в данном случае для этого и нужен автор или spool что он делает фактически нам нужно будет избавиться от ссылки на
00:21:41 - 00:22:53
объект но сделать это не сразу а через некоторое время автор или spool позволяет нам сделать как раз таки вот это он хранит в себе все объекты у которых был вызван метод of the release is если мы напишем вот так вот то мы поместим наш new instance этот объект в авторе виспу он будет хранить себе все объекты до тех пор пока не будет очищен когда пул очищается к ко всем объектам которые содержатся внутри этого пула будет применен метод релиз соответственно который уменьшит количество ссылок на эти объекты и
00:22:17 - 00:23:30
позволят их не держать в памяти вопрос а в какой же момент очищается of the release пул вопрос на самом деле хороший потому что если кратко говорить то очищается он в момент вызова метода drain у of the release пула есть метод соответственно drain который позволяет очистить of the release пул и ко всей начинки которые в нем содержатся применить методы релиз но в большинстве случаев вызывать метод drain руками вам придется только в большинстве случаев вам не придется руками вызывать его вообще вам
00:22:53 - 00:23:56
придется вызывать его руками только тогда когда сам автор или spool вы создаете руками например для какого-то вторичного потока или для оптимизации цикла но в главном потоке все полностью автоматизировано ран лук сам создает автор или spool в начале каждой итерации а в конце и итерации этого рану про он его сам очищает соответственно если мы делаем все это в главном потоке то когда мы просто пишем вот как здесь нас на скрине когда мы вызываем of the release у какого-то объекта мы помещаем этот объект в of the release пул который был
00:23:26 - 00:24:35
автоматически создан ран глупом в главном потоке и когда этот разлук завершить свою итерацию объекты будут соответственно релизнут и сейчас когда орк уже в принципе заменил мануальный подсчет ссылок нам об этом думать вообще не надо и сейчас все это выглядит намного проще не надо писать не релиз не of the release ничего но of the release пул в принципе еще может пригодиться в 2021 году и даже в свифти для чего он нужен сейчас он применяется в основном тогда когда нужно оптимизировать циклы снизить
00:24:00 - 00:25:11
максимальное потребление оперативной памяти в них например у нас есть какая-то функция которая в цикле создает объекты из foundation или и айкидо я опять же не все но некоторые например видим лишь смысл в том что эти объекты а помеченные тегом of the release и если их создать они останутся в памяти до тех пор пока не будет завершён весь цикл а по факту они будут ждать по факту пока не завершится текущая итерация ран лупа в основном потоке и соответственно не будет очищен off of the release pool и
00:24:36 - 00:25:53
поэтому если мы запускаем большой цикл какой то в главном потоке то of the release пул не будет очищен до тех пор пока весь цикл не закончится как это можно исправить а исправить это можно вот так вот если завернуть внутренности этого циклов of the release пул то мы явно даем понять что что короче что делает этот код по сути он создаёт отдельный автор или spool который автоматически очищается после каждой итерации то есть вот этот of the release пол блок это довольно удобная штука которую добавили не сразу
00:25:14 - 00:26:28
которая появилась намного позже чем вся основная масса операторов связанных с авторе лизингом что она делает мы создаем of the release пул а в конце когда все действия заканчиваются мы очищаем его и получается что на каждую итерацию мы соответственно очищаем автор или spool и в конце каждой итерации мы получается освобождаем ресурсы занятые вот этими дикими джами и соответственно каждой итерации в целом и получается что получается что если мы не используем авторы из пол внутри цикла то наша память продолжает накапливаться до
00:25:50 - 00:27:09
тех пор пока цикл полностью не закончится здесь например это заняло сорок пять мегабайт но зачастую если вы обрабатываете какие-то объекты core графики допустим это может быть не сорок пять мегабайт а 500 мегабайт или еще того больше поэтому автор или спал реально пригождаются если же мы будем использовать автор или spool руками то мы увидим что выше 5 мегабайт выше 6 мегабайт точнее на протяжении всего цикла наше потребление памяти не вырастала и соответственно иногда автор или spool даже в 20 в 2021 году может
00:26:31 - 00:27:49
вам пригодится вот опять же если есть какие то вопросы задавайте насколько это перформанс билет насколько это бьет по перформанс у имеешь ввиду освобождение ресурсов на каждой итерации но до создавать автор или сполна конфедерацию суши на смотри если просто если просто даже посмотреть вот по этим графиком мы увидим что цикл на первом графике когда мы не использовали of the release пул закончился где-то на 4 полосках примерно может быть чуть раньше ой 4 полоски это у нас давай посмотрим сколько это так 3
00:27:10 - 00:28:36
4 5 короче две полоски это получается 1 1 секунда насколько я понимаю или одна миллисекунда в общем заканчиваются они на самом деле примерно в одно и то же время начинать нет 4 полос очках поэтому какого-то сильного удара по перформанса это не нанесет явно но да это будет работать чуть медленнее чем соответственно вариант без постоянной очистки ресурсов но в 2021 году как бы девайсы уже достаточно сильные и эта разница будет просто неощутимым окей двигаем дальше дальше о чем мы поговорим это те
00:27:53 - 00:29:09
блоки и лай блоке d блок эта ситуация при которой а при которой несколько процессов находится в состоянии ожидания ресурсов заняты друг с другом и при этом они оказываются просто взаимно заблокированы поскольку один процесс ждет пока закончится 2 2 проц с ждет пока закончится первый стоит сразу отметить что белок может произойти только тогда когда доступ к ресурсам является эксклюзивным то есть в том случае когда один объект может быть одновременно занят только одним каким-то процессом простейший пример 2 блока
00:28:31 - 00:29:48
можно воспроизвести с помощью следующего кода и я думаю много где уже это было разобрано наверное в нескольких докладах до этого да вот это прям это приводит просто к падению приложения и где блоком что происходит здесь можно просто разобрать это по очереди main это последовательная очередь то есть в ней одновременно может выполняться только одна задача сначала мы добавляем в очередь задачу номер один и начинаем ее выполнение это как раз таки вот здесь вот помечено комментарием task номер один в рамках задачей номер
00:29:12 - 00:30:28
один мы должны добавить и выполнить в основной очереди задаче номер два она помечена соответственно комментариям task номер два но это невозможно задача номер два является синхронной вот тут можно увидеть опять же что мы вызвали и методом sing а что делает метод sing это блокирует поток до тех пор пока задача не будет выполнено но это не получится ни в каком случае потому что эта задача даже никогда не сможет начаться так как очередь занята задачей номер один и получается что задача номер один вот это
00:29:52 - 00:31:05
не выполнится до тех пор пока не выполнится задача номер 2 и соответственно оно так и будет занимать очередь а задача номер два даже не сможет начаться до того как выполнится задача номер один и соответственно это просто приведет к вечному ожиданию и система решит что как бы такое приложение лучше всего завалить сразу такое довольно часто происходит и если в приложении встречается очень много ручного перекидывания между потоками опять же сейчас я не могу придумать какого-то большого количества кейсов когда это действительно было бы
00:30:28 - 00:31:43
уместно потому что мы по большей части вы просто перекидываете куда-то бэкграунд поток какие-то жирные от операции потом возвращаетесь в main и у вас нет такого жесткого пинг-понга между потоками скорее всего это в основном пригождается если вы пишите какую то либо или какой-то отдельный фреймворк там возможно до в обычной жизни вряд ли вас это будет происходить часто и возможно даже не произойдет никогда но верно с точки зрения там использования рыкса там тоже можно это на по рации что прям рукожоп это все делать мочи специфично
00:31:06 - 00:32:25
нужно извернуться это надо постараться на самом деле потому что rx тоже не такой тупой и в принципе там все обработано за вас вам просто будет кинут error в консоль как бы и будет сказано что скорее всего вы что-то делаете не так вот за это уже как бы можно не беспокоиться поскольку по большей части разработчики ли бы все уже продумали за вас вот пример блоков из реальной жизни если у нас есть какой-то перекресток который не и не регулируемый абсолютно на нем нет светофоров там нет какой-то главной дороге они всех все обе главные
00:31:46 - 00:33:01
как бы может получиться такая штука что вот эти четыре машины подъедут одновременно соответственно перекрестку соответственно центру дороги и получится просто так что никто из них не сможет разъехаться если они продолжат ехать по правилам как все смерть и а что же в таком случае вообще делать в таком случае надо как то наверное попытаться исправить эту ситуацию не по правилам то есть добавить какой-то алгоритм который будет выполняться в случае возникновения 2 блока возможно который будет автоматически обнаруживать
00:32:23 - 00:33:39
эти ситуации и подавляй этих но может возникнуть кейс когда подобные алгоритмы будут недостаточно хорошо проработаны и тогда возникнет противоположно id2q ситуация lifelog lifelog эта ситуация когда оба процесса которым нужен один и тот же какой-то ресурс они будут бесконечно уступать друг другу право владения то есть в принципе самый простой пример который мы можем увидеть я его наглый украл просто но больше наверное настолько наглядному ничего не придумаешь если у нас есть какая-то узкая дорога и понятные узкой дороге
00:33:00 - 00:34:13
навстречу друг другу и идут два человека одновременно по этой узкой дороге они как бы пройти не смогут поэтому кто-то должен будет уступить соответственно своему своему таинственному незнакомцу который идет на встречу и отойти соответственно к обочине но если вдруг получится так что они будут отходить в одну и ту же сторону постоянно то они просто никогда не пройдут если в реальной жизни одному из этих людей просто в один прекрасный момент надоест бегать туда-сюда и он просто встанет на месте то достаточно много
00:33:38 - 00:34:51
алгоритмов написанных как бы на каких-то языках они могут не быть такими умными и будут просто продолжать в одни и те же стороны отходить что также принципе завалит как бы ваше приложение но опять же лайфхаки встречаются намного реже потому что для этого нужно начинать править д блоки а те блоки обычно стараются избегать вовсе то есть не исправлять их последствия а стараться избегать вообще то есть не допускать ситуаций таких в принципе то есть облегчать как то возможно облегчать логику в приложении
00:34:14 - 00:35:32
возможно использовать какие то другие методы синхронизации не использовать там уже можно говорить об этом очень много но по большей части в реальной жизни опять же если вы пишете обычное приложение скорее всего d-блок у вас может возникнуть только в случае если вы пытаетесь в одной и той же очереди через gcd вызвать синхронную задачи это скорее всего 99 процентов кейсов когда вы встретите вообще предлог в следующей теме мы поговорим еще про то как можно вызвать те блоки но сейчас давайте пока по вот этой теме если у кого-то есть
00:34:53 - 00:36:11
вопросы то можете опять же задавать мне есть небольшой комментарий по поводу life лаков их можно делать создать скажем так не только тогда когда разрешаются до блоки а например косвенно ну это не совсем лайфхак они в чистом виде но например когда у нас одно какое-то событие день ну точнее одно действие генерит какое-то событие происходит какая-то работа которая генерирует другое событие и соответственно поэтому события опять происходит какое-то первоначальное действие и в итоге приложения зацикливается о том что она обработку
00:35:32 - 00:36:39
какую-то делаем но в результате получается что она просто гоняет по кругу одно и то же такие ситуации уже проще воспроизвести даже там где то опустим в рамках объявим с рексом что мы что-то отправляем туда это как-то отрабатывает мы о из где модельки что-то отправляем в юшку это как-то отрабатывает отправляя папе модельку и вот тут можно зациклиться и в итоге получится что не замечаешь этого действа всего которое происходит там на фоне а приложение почета подтормаживает начинает вот эта ситуация вполне
00:36:06 - 00:37:13
реальная и такое можно достаточно легко накосячить ну если неправильно приготавливать это все и не отслеживать тоже что вызывает какие события и это да окей да да едем дальше и следующий вопрос который мы рассмотрим это локи и мьютекс ее семафоры и так далее обычно это все объединяется в одну тему поскольку это все является по большей части механизмами для singsing синхронизации работы потоков для их доступ и каким-то ресурсам зачем они нужны чтобы предотвратить ситуацию когда разные потоки одновременно пытаются
00:36:39 - 00:37:51
получить доступ к одному и тому же какому-то ресурсу есть два способа первый не допускать подобные ситуации в принципе что звучит хорошо в теории но не всегда реализуемые на практике но опять же если вы можете их не допускать то лучше их не допускать вообще и вариант 2 исправлять последствия исправлять последствия с помощью специальных инструментов для синхронизации потоков и одним из простейших инструментов синхронизации является мьютекс мьютекс это сокращение от не учел эксклюзив то есть взаимное из
00:37:15 - 00:38:27
исключения как можно понять из названия мьютекс исключает одновременный доступ из разных потоков к одному и тому же никому ресурсу для примера возьмем например для примера можно взять абстрактную примерочную кабинку в магазине или вход в дом какой-то где может жить только один человек абстрактный дверь может быть либо закрытая либо открыто если дом свободен если кабинка свободна то человек не и заходит закрывает дверь на защелку и начинает там что то что то делать если вдруг затем появляется еще
00:37:51 - 00:39:03
один человек который хочет зайти в этот дом или в эту кабинку он не сможет это сделать до тех пор пока оттуда не выйдет первый человек не от не откроет дверь и соответственно этот другой человек который стоит около этой двери он вынужден ждать до тех пор пока тот кто находится внутри до тех пор пока тот кто первый забронировал этот дом или эту кабинку не закончит свое взаимодействие с ресурсами дверь в данном случае это не что иное как и мьютекс и стоит сразу отметить что в некоторых из языках программирования понятие лоб и
00:38:27 - 00:39:39
мьютекс могут быть отдельными сущностями со своими особенностями но в ios в объектив сивцев те мьютекс это простая разновидность лог что следует принципе рис официальной документации если мы посмотрим на соответственно типы log off мы увидим что мьютекс это простейший лог который служит таким защитным барьером вокруг ресурса и в принципе тут в официальной документации все это описание также предоставлено и чуть ниже в той же самой документация я не стал это вставлять сюда но там написано что и не слог это самый
00:39:03 - 00:40:19
простейший лог который есть в айосе он и реализует этот самый мьютекс и одной из важных особенностей ns лака заключается в том что у него есть владелец и разблокирован этот замок должен быть ровно тем же потоком которым он был заблокирован можно по этой же картинки додумать немного что допустим если человек зашел в этот дом он закрыл допустим дверь на какую-то защелку которая может быть открыт открыта только изнутри это как раз таки есть и не слог то есть если человек даже попробует открыть эту дверь снаружи он это сделать
00:39:41 - 00:40:57
не сможет поскольку из из внутри это дверь захлопни то на защелку это основная особенность ns лака и о том что у меня слово есть владелец который обязан открыть этот лог перед тем как выйти и никто кроме этого владельца лоб открыть не может об этом надо помнить если попытаться разблокировать замок из другого потока то произойдет underwear о чем нам говорит в принципе документация и наверное стоит стоит избегать таких кейсов вообще и лучше так не делать более того блокировать и разблокировать замок нужно только тогда когда это
00:40:19 - 00:41:39
действительно вам нужно если попытка разблокировать уже разблокированный замок просто кинет ошибку в консоль то если вы попытаетесь заблокировать уже заблокированный замок это приведет к дидло q такова особенность реализации и если ваш метод нас например вызывает царь и рекурсивно и вам действительно нужно не несколько раз вызвать блокирование одного и того же ресурса то для этого есть а н с и курсе флаг который в принципе мы вот здесь же опять в списке лаков видим он реален он есть он реализован через и не
00:40:59 - 00:42:14
сорить в курсе флаг и в таком кейсе вам нужно будет использовать именно его но важно помнить что чтобы разблокировать этот замок нужно разблокировать его ровно столько же раз сколько он был заблокирован иначе ресурс станица опять же вечно висеть заблокированным и никто не сможет получить к нему доступ на самом деле помимо мьютекс а есть еще один очень распространенный тип синхронизации которые мы называется семафор и семафор он в принципе похож на мьютекс но отличается несколькими особенностями
00:41:36 - 00:42:47
во-первых главное его отличие от мьютекс заключается в том что семафор позволяет предоставить доступ к одному и тому же лесу сразу нескольким потоком число может быть от одного до бесконечности в принципе сколько вам требуется то есть если мьютекс всегда дает только одному какому-то потоку завладеть одним ресурсам то 7 семафор в принципе может позволить нескольким сразу потоком завладеть одним и тем же ресурсам в ios он реализован классом dispatch семафор добавлен насколько я помню когда появилась gcd в целом да в
00:42:12 - 00:43:26
принципе вы можете просто задать один и тогда механизм будет очень похож на то что предоставляет мьютекс но между бьют иксом и семафором есть одно очень важное различие семафор может быть разблокирован из любого потока не только из того потока который заблокировал изначально который за забрал себе ресурс разблокирована может быть из любого потока это основное различие между new так сам и семафором в том что у них разное отношение владения то есть в нью такса есть такое понятие как отношение владения убьют икса есть владелец
00:42:49 - 00:44:04
и именно он должен разблокировать мьютекс у семафора нет владельца поэтому он может быть принципе разблокирован из любого потока простейший пример 7 семафора это допустим фейс-контроль в клубе который просто пропускает всех но считает сколько осталось свободных мест внутри этого клуба если допустим если он уже впустил допустим 20 человек и больше он просто не может впустить внутрь он будет ждать до тех пор пока хотя бы одно место не освободиться и когда это место освободится он сможет забыть ведь туда следующего человека и так
00:43:27 - 00:44:45
далее и так далее так далее то есть отличие по большей части 2 первое что семафор позволяет сразу нескольким потоком получить доступ к одному и тому же лесу и второе то что у семафора нет понятия владения в то время как у мьютекс а есть понятие владения и с семафорами в принципе да вы можете вызвать сигнал семафора то есть разблокировать какой-то ресурс из другого потока но вопрос уже другой а действительно ли вам оно надо и зачастую это пахнет грязным кодом если вы пытаетесь разблокировать ресурс который занят другим потоком ну в
00:44:06 - 00:45:29
общем как то вот так если есть вопросы по этой теме задавайте о кей судя по всему вопросов нет тогда мы идем дальше и следующая тема бит код пробит код довольно тоже многие слышали те кто связан союз разработкой и и те кто выливали хотя бы хоть раз сборку в appstore connect они наверное видели вообще и слышали про это слово что же такое bitcoin если говорить максимально просто the beat код это промежуточная ступень между исходным кодом и машинным кодом зачем он нужен рассмотрим на примерах допустим вырос разработали некоторые
00:44:47 - 00:46:03
приложения и хотите распространить его в appstore xcode сбил did ваши приложения под все указанные процессор ные архитектуры которые заданы обычно сейчас это aero м-64 armv7 ну обычно только n64 если мы говорим про самые последние приложения в принципе вы можете поддерживать и какие-то более старые архитектуры но тогда при билде ваш бинарник окажется чуть жирнее потому что все это по сути с вся поддержка всех архитектуры которые вы указали она вся за запаковывается в один бинарник и поэтому чем больше
00:45:26 - 00:46:42
архитектуру вы поддерживаете тем жирнее бинарник будет и соответственно тем больше придется скачивать вашему пользователю более того если вдруг появится устройство с процессорами на новой архитектуре они не смогут использовать старую версию приложения которое залита в appstore вам придется руками пересобирать сборку с поддержкой новой архитектуры и опять же заливать новую версию в appstore руками так было до появления бит кода теперь же если в настройках проекта включить эту опцию то xcode не станет
00:46:04 - 00:47:11
бил бить ваши приложения под каждую конкретную архитектуру процессора которую вы указали вместо этого он создаст общей промежуточный код который будет загружен в appstore connect ну вот здесь вот он указан как айтюнс connect потому что немножко устаревший скриншот из документации опять же финальные бинарники под конкретные архитектуры в том в том числе которые появятся в будущем appstore сгенерирует автоматически то есть если вдруг появится какая-то новая архитектура прилла а если появится новая
00:46:38 - 00:47:42
процессорная архитектура то все новые девайсы которые сделаны на этой арке архитектуре а не смог бы просто зайти в appstore и скачать старую версию приложения потому что appstore автоматически выльет для них нужный вариант и это приводит к тому что во-первых вы не должны будете руками пересобирать сборку во вторых это позволяет вам уменьшить размер бинарник а более того apple постоянно старается улучшать эффективность своего компилятора поэтому если вдруг сам компилятор будет каким-то образом улучшен appstore автоматически
00:47:09 - 00:48:23
перри соберет бинарники чтобы оптимизировать код внутри и возможно это еще уменьшить размер приложения для конечного пользователя в основном конечно здесь плюс и но могут быть и минусы опять же если вдруг вы боитесь что ваше приложение на новый процессор на архитектуре будет вести себя как то не так и она сломается и что допустим если придут какие-то новые девайсы ваши пользователи скачаю туда приложения и просто не получат должны user experience который они ожидают приложение будет работать не так то
00:47:47 - 00:49:06
наверное не стоит включать бит код с если вы очень тщательно к этому всему этому всему подходите если вы предпочитаете чтобы сначала тестеры все прогнали посмотрели чтобы убедились что все работает нормально лучше выключите бит код и на самом деле это сэкономит вам еще немножечко времени в дальнейшем об этом мы поговорим с этим следующей теме почему бит код это не всегда хорошо и не всегда удобно но если вы беспокоитесь о том что размер вашего приложения слишком жирный вы хотите немножечко облегчить ваше приложение вы хотите
00:48:26 - 00:49:42
сделать так чтобы пользователь своевременно получал новые более оптимизированной версии то включайте бит код и будет вам щастье принципе опять же на этом все если у кого-то вопросы побит кода есть можете задать здесь не не вопрос наверное все из дополнения что в андроиде примерно такая же штука существует она называется об вариант что лили как-то вот здесь могу ошибаться названием точно подскажите если кто помнит то есть не не ripple только такой штукой снимается и есть возможности в андроиде уменьшать скажем так размер
00:49:04 - 00:50:11
приложения которое лежит в 100 report соответствующий там девайс соответствующее разрешение допустим на ожидая если говорим про ресурсы какие-то вопросы смартфон да да да как это как раз будет в следующей в следующем пункте скажем так здесь все идет по порядку и как бы следующие темы они немножечко завязываются на предыдущий поэтому про firebase я расскажу но есть такая если вопросов больше нет по ну если точнее вопросов нет по этой теме то опять же немножко дополню то ли она до бит код это одна из нескольких один из
00:49:37 - 00:51:07
нескольких механизмов которые теплом были придуманы для как раз таки да облегчения общего приложения а помимо бит кода насколько я помню там есть еще несколько механизмов которые опять же также включают в себя различные менеджмент ресурсами то есть для разных девайсов можно засовывать разные-разные подходящие к ним ресурсы разные картинки и так далее документации сейчас я даже попробую это найти блин не могу к сожалению найти но где-то ссылка у меня на это на это было я обязательно приложу в общем да скорее
00:50:22 - 00:51:28
всего apple просто украли все с android я сомневаюсь что это android украл сипло потому что я хожу в данном случае бит код появился не так давно не супер давно поэтому я думаю что в android and ios раньше а может быть и нет если кто-то на андроиде шарит за это то в принципе можете сказать когда у вас это появилось ну или пишите в коментах если на youtube жар окей тогда ладно едем дальше и следующая тема это 7 что такое темы про это тоже многие слышали но не совсем понимают как это вообще работает и что это если говорить кратко
00:50:57 - 00:52:11
то когда xcode компилирует исходный код в машиной он автоматически генерирует отладочные символы эта информация которая показывается соответствие между исходным кодом и скомпилированных бинар ником благодаря этой информации вы можете использовать дебаггер например чтобы поставить breakpoint на определенной строке или определить по краж логу какая строка исходного кода привела к этому крашу дэбак сборки эти отладочные символы хранят прямо в бинарники то есть если вы просто за запустили что-то в дебат
00:51:35 - 00:52:44
режиме вам особо думать не надо релизный сборки отладочные символы закладывают в отдельный гасим файл вынесение в отдельный файл позволяет снизить размер отгружаемого пользователю приложения потому что допустим я я вот сегодня пытался скопировать носимые для того чтобы посмотреть кое-что и полный пакет симов весил 12 мегабайт то есть это довольно большой размер именно поэтому было решено вынести это в отдельный файл для того чтобы не нагружать пользователи еще сильнее в то же время поскольку этот
00:52:08 - 00:53:17
файл выносится отдельно от бинарник а это вносит некоторые сложности например заливать этот файл символами в сервисы вроде фабрика краж лить x и так далее друг других трекеров каких-то для ошибок вам придется руками либо через скрипт так знакомый многим build фэй скрипт который мы видим вот здесь он как раз таки и делают то что при билде отправляет соответственно все 7 которые были созданы он их заливает фарба искра шлите кс и вы впоследствии сможете этими темами нормально воспользоваться для того чтобы
00:52:43 - 00:54:00
получить информацию о том на какой строке произошел краж чуть больше сложностей появляется если в проекте включена поддержка бит кода при архивации и отгрузки сборки в appstore xcode of us и рует все имеющиеся отладочные символы и создает еще один файл то есть помимо симов он создает еще один файл который по сути хранит в себе информацию о том как закодированы внутри эти цены и в этом вся проблема в том что если просто залить обфусцированы зимы в сервисы вроде соответственно файла искра шли текса вы
00:53:21 - 00:54:38
не получите никакой нормальной информации поскольку они за зож зашифрованы и их заливка по сути не даст вам ничего в случае с биткойном надо действовать немножко по-другому сначала вы заливаете это в appstore в принципе как как как и делаете всегда вам надо будет поставить галочку о том что да я хочу залить 7 туда затем внутри appstore коннекта когда вы зайдете туда зальете сборку зайдете в настройки сборке вы сможете увидеть вот такую штучку эта информация полностью о сборке которую вы залили и в графе включает символы да или нет
00:54:00 - 00:55:23
если они есть вы сможете скачать их себе затем залить руками firebase и только тогда firebase прошли тег сможет нормально обработать ваш и краше и показать вам где на какой строчки они произошли если вы не зальете этим и туда то скорее всего никакой подробной информации вы не получите в этом как раз таки на мой от и заключается основная проблема бит кода в том что если вы включаете бит код вам приходится каждую залитую сборку в test flight руками проверять на наличие симов скачивать их заливать руками опять же
00:54:41 - 00:56:03
файл bass и только тогда это все будет работать если вы выливаете в то спать сборки не так часто может быть раз в месяц или раз в неделю тогда это не особо большая проблема просто когда выходит какой-то мажорный допустим релиз вы загружаете отсюда дасима и заливаете их соответственно firebase но если вы используете test flight как ваше основное средство для диз дистрибуции приложений и если вы отгружается туда какие-то сборки постоянно то наверное это будет не особо удобно и проще будет отказаться от firebase
00:55:22 - 00:56:38
прошли текса вообще и использовать встроенные методы и apple а для соответственно просмотра краше льда такие есть но видимо мало кто ими пользуется работа кто-то полежать которые нихера не работают гулять а в чем там проблема кстати я ни разу не пользовал прост как они блин я не знаю ни разу не показывали нормально так также как тот же прошли текст о том как где произошла ошибка во сколько я ни пытался не воспользоваться всегда какое-то получался в честный слов нихера не габай полезную информацию
00:56:00 - 00:57:13
apple болеть если вы это читаете поправьте уже хотя бы это оспы сколько лет ну в принципе я не удивлен на самом деле тому что очередная фича то плохо работает как я не удивлена абсолютно дима у тебя вроде был вопрос я надеюсь я на него ответил да потому что я хочу еще может быть профи bass boost как раз начали с этим сталкивались ну на самом деле по большей части на большинстве проектов которые мы мы либо поддерживали ли либо писали мы просто вырубали нафиг бит код и все как бы на этом как бы все
00:56:37 - 00:58:04
и еще может быть сбит кодом проблемы одна связана она с тем что если вы в своем проекте храните какие-то либо которые добавлены как бинарники прямо которые уже скомпилированы были скорее всего вы не сможете отгрузить это как бит код в соответственно appstore если у самих этих lip не была включена поддержка бит кода то есть на сколько я понимаю если у вас уже есть некий скомпилированный под определенную архитектуру бинарник вы не можете этот бинарник перевести в бит код вам надо иметь соответственно с урсы для того чтобы эти
00:57:20 - 00:58:49
старцы перегнать в бит код из бинарник off beat код вы скорее всего это не сможете сделать и вот как раз таки на проектах где у нас были всякие не помню openstreetmap и или еще отчеты которые просто добавлялись как которые добавлялись как бинарник они не позволяли короче скомпилировать это в бит код поэтому там приходилось изначально вырубать и даже не думать о том типа включать бит код или нет вот по до сего мне побит коду наверно я даже не знаю больше чем рассказать если у кого-то есть вопросы то можете опять же
00:58:04 - 00:59:14
задать видимо нет ну видимо нет да и в восьмой вопрос по которому у меня даже нет никаких слайдов потому что там принципе ничего на слайды выносить это довольно часто встречающийся вопрос инесса песенку против g сидишь тоже лучшие что следует применять и ответ на самом деле просто я могу сразу сказать от ответ выбор весь сводится только к здравому смыслу для простых задач вам понадобится скорее всего джи си ди для более сложных инесса песенку рассмотрим чуть подробнее и потом вернемся к нашему выводу для работы с потоками у вас
00:58:38 - 00:59:58
разработчика есть несколько инструментов основными из них являются джеси д и н с от racing yoon-g сиди это низкоуровневая а фишка основанная на сяс инесса первичном кью в свою очередь это высокого уровня обертка на g сиди написанная над на объекте все будучи надстройкой над джесси днс api рисунки у имеет некоторые свои плюсы первые инесса трещинку позволяет задавать зависимости между отдельными тоска me определяя порядок их выполнения это позволяет вам создавать сложные графы задач которые должны быть
00:59:19 - 01:00:30
выполнены в определенных условиях один после другого и так далее с помощью g среди вы такого сделать либо не сможете либо сможете с большим количеством оверхеды и выглядеть это будет немножечко ужасно второе инесса першингу позволяет задавать лимит на количество одновременно выполняющихся задач то есть по сути это как семафор он позволяет только нескольким задачам одновременно выполняться джи си ди вы опять же без костылей это сделать не сможете но либо вы можете добавить туда dispatch семафор и с помощью dispatch
00:59:54 - 01:01:13
семафора гонять несколько задач но зачем если можно с помощью двух строк буквально с атрошенко это зависти и третье и на операцию позволяет немножечко проще манипулировать тасс камень ежели в g сиди с помощью операций по us can sell rise ум внс апельсинку также легко отслеживать состояние отдельных задач а над большинством state of можно наблюдать с помощью кого он и выглядит это реально круто и работает это реально круто но помимо плюсов у инесса перешейку есть и очевидные минусы первый это то что н.с. апельсинку
01:00:33 - 01:01:51
это обертка на g сиди она чисто физически не может работать быстрее чем джи си ди поэтому каждый раз когда вы используете н.с. operational вы закладываете некий оверхед что немножечко скорее всего незначительно ударит по перформанса но опять же в 2021 году думать о перформансе в таких мелких задачах которые не ставят перед собой чего-то глобального и скорее всего не повлияют примерно никак ну это глупость и это то что синтаксис внс апельсинку в принципе не такой простой как джесси день если вы хотите перекинуть какой-то
01:01:12 - 01:02:35
task в другой поток в джи си ди вы сделаете это буквально за одну строчку кода вы не собираешь никки это будет выглядеть немножко более массивная и ним немножко более страшно плюс опять же в 2021 году вы не так часто встретите использование н.с. operational прямо повсюду скорее всего для операции с потоками по большей части будет использоваться g сиди и только в самых редких случаях когда нужно использовать какие-то явные преимущества н.с. operational вроде зависимости между задачами или лимита для задач или допустим там
01:01:54 - 01:03:10
при остановке задач там наверное да там будет использован н.с. operational что использовать вам опять же зависит только от вас зависит от того что вам нужно если вам нужно сделать какую-то сложную задачу то используйте ns отбираешь секунд а если у вас что-то простое просто используете g сиди и не морочьте себе голову и не морочьте голову тем кто будет рябить машку как как то так если какие-то вопросы есть то давайте постараюсь ответить ну так серьезно нюанс что прозвучало так как будто джесси деприм низкоуровневое
01:02:32 - 01:03:38
session и да это действительно так но здесь один есть маленький нюанс она очень круто интегрирована с ее вт соответственно командами и здесь никакой сложности с использованием juice де вообще нет скорее наоборот она иногда бывали а проще и короче в использовании чем вот отдельная создаваемые объекты мастеришь хотя у ты не собираешь им весь блок и получается так же практически в одну строку так что здесь вкусовщина да здесь все верно госказну ну и плюс по большей части метаться все гады сейчас они
01:03:05 - 01:04:18
включают в себя именно работу с потоками на g сиди поэтому большая часть людей скорее всего знают написать на g сиди и поэтому лучше пишите на g сиди потому что все знают как это работает не все знают как работает н.с. operations in сокровищницы но если вдруг вам сильно нужно так окей тогда наверное все или нет вопрос вообще по теме про а если есть какие то вопросы и кстати да если у вас есть еще какие то вопросы которые вы хотели бы чтобы они были рассмотрены то кидайте в df или еще куда то кидайте в
01:03:41 - 01:04:51
комментарии если вы смотрите это видео на youtube и будем рады на них ответить потому что тем реально не так много осталось и если кто-то может что-то интересное подсказать мы будем рады сами разборы по действительно сложным темам которые самому копать будет чаще всего просто в лом и потому что особой необходимости нет а так периодически сталкиваешься спасибо огромную на этом наверно россию
01:04:17 - 01:05:10