💰 Поддержать проект на Boosty boosty.to/androidbroadcast 🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast 🔗 Telegram канал "Kotlin Broadcast" ttttt.me/android_broadcast
Кирилл, спасибо за шикарный контент Коротко и без воды, шикарный формат А кому что-то не понятно - гугл в помощь) Если бы автор рассказывал о каждой мелочи - то видео бы получилось очень длинным и не охватило бы такую широкую аудиторию, которую охватывает сейчас Так как для тех, кто, что-то знает по корутинам - было бы много воды
Да, присоединюсь. Супер подача, коротко и не напряжно. Вопрос от новичка. Как практиковаться в этом? С чего начать практику? Как именно ты начинал практиковаться. Именно начинал. Смотрю разные источники, везде много теории и элементарные примеры, но хотелось бы примеров посложнее, причем с нарастающим уровнем сложности. Буду рад получить ответ, но даже если не получу, все равно продолжу смотреть тебя👍
Я практиковался уже с опытом в разработке, так что просто взял pet проект или начал писать его чтобы попробовать технологию. + повезло что на работе смог затащить корутины даже в альфа версии в 2017
Кирилл, ты случайно не оговорился на 4:55, когда сказал, что в пуле потоков IO количество потоков не менее 64? Другие источники говорят "не БОЛЕЕ 64". Присоединяюсь к благодарностям за чертовски годный курс по корутинам!
Отличное начало курса, в голове прям щелкает от понимания 😄 Отсюда у меня возник вопрос: можно ли указать саспенд функции, что она должна быть запущена в определенном диспатчере? Я видел вариант, что тело функции можно обернуть в нужный withContext, но не хотелось бы лишний раз переключаться
Я так понимаю, что withContext и есть рекомендуемый подход, плюс вообще все функции лучше проектировать main-safe, что если функция может заблочить main поток, ей нужно самой переключить контекст на всякий случай
Вот рекомендую отличный мини курс молодого бойца по корутинам, уверен его можно еще даже расширить и дополнить примерами: ruclips.net/p/PLQkwcJG4YTCQcFEPuYGuv54nYai_lwil_
Кирилл, спасибо за видео! На 3:33 кажется не совсем корректная инфа - родитель у которого SupervisorJob не отменяется ведь сам при ошибке в дочерней корутине
На счёт оберток для провайда диспетчеров, мы отказались от этой штуки, т.к. появилась возможность в тестах напрямую сетить диспетчер в класс Dispatchers. Тесты от этого никак не пострадали, а куча классов убрала лишнюю зависимость, которая больше мозолила глаза
Очень красивое лицо, но лучше было бы смотреть на код, который мелькает не понятно для чего. Речь лучше не как на рынке при навязывании товара, а помедленнее, если, конечно же, это разъяснение для новичков, а не хвастаство перед равными.
Спасибо огромное за серию видео. Материал немного сложный, пересматриваю повторно. Вопрос что будет если использовать Default dispatcher с IO операциями? Если при этом Default пул потоков загружен сложной математикой, то часть ядер процессора будут недозагружены?
Кирилл, можете пояснить один момент? Функция Join приостанавливает коррутину пока job'а не выполниться(Suspends the coroutine until this job is complete. ) Если Job это абстракция над коррутингой, то как она может выполняться с приостановленной корутиной? В некоторых статьях вижу такую формулировку "Например, его метод join() позволяет ожидать, пока корутина не завершится"
При создание корутины через launch или async вы получаете объект Job, который и представляет её. join() - это suspend функция, которая приостановит корутину в которой была вызвана, до тех пор пока не будет выполнена Job (корутина) у которой вызвали join()
В IO количество потоков равно количеству ядер процессора, но не меньше 64х? Т.е. всегда не меньше 64х? Потому что я не знаю SOC, в котором есть столько ядер) Upd. Разобрался в вопросе. На самом деле, по умолчанию в IO НЕ БОЛЬШЕ 64х потоков.
Как всегда, поверхностно, без объяснения. Тем, кому это действительно важно и они хотят понять, здесь делать нечего. Элементарный пример, ИО, ИО... Не все кто хочет разобраться с корутинами знают, что это абревиатура InputOutput и для чего этот поток. В общем как и с даггером, контент ради контента, а не для людей...
Ещё раз - это контент не для новичков, а уже понимающих профессию. Пишите вопросы и я сделаю доп разбор со всеми пояснениями. Знаете как сделать лучше, покажите мне своим примерос
Вот рекомендую отличный мини курс молодого бойца по корутинам, уверен его можно еще даже расширить и дополнить примерами: ruclips.net/p/PLQkwcJG4YTCQcFEPuYGuv54nYai_lwil_
спасибо за крутой контент. Одно не понял: Зачем нужен лишние потоки (64 потоков) для io если у нас 8 процессоров (кажется 8 потоков достаточна)? Вед корутины (в отличий от обычных потоков) освобождают свой поток при блокирующем вызове (например запрос в сеть). То есть потоки никогда не будут в wait состояние и нет необходимости для context switch
@@AndroidBroadcast то есть сейчас при io запросах (в отличий от delay() допустим) поток не освобождается? Или я чето не понял? В первом видео вроде в обратном говорили: что несколько корутин могут в отдом потоке выполнятся
Благодарю за этот курс! Круто Подскажите пожалуйста какой контекст нужно использовать в CoroutineScope для работы с базой , когда корутина что-то вытаскивает из Room ? У меня, например val coroutineScope = CoroutineScope(Dispatchers.Default), но не уверен, что это правильно
Если в Dao у метода прописать suspend, то запросы будут выполнятся на Room-овском Dispatcher-е и не надо использовать какой то другой диспатчер. Такое же поведение и у Retrofit-a
Я где-то давно читал, что IO dispatcher умеет только расширяться, но не умеет утилизировать ненужные потоки. Ты не знаешь, они уже это поправили или так и осталось?
@@AndroidBroadcast Тут проблема, что если во время каких-то нагрузок количество потоков сильно увеличится(например до 40), то потом они будут простаивать. Думаю именно по этому и создали limitedParallelism.
Привет Я правильно понимаю, что пул потоков, при использовании Dispatcher.IO состоит из нативныех потоков (которых ещё 64)? Буду очень благодарен за ответ, давно не могу разобраться в этом простом вопросе
Почему вы советуете не использовать Dispatchers напрямую, а закидывать их обёртку через DI? Я пользуюсь ими напрямую, не могу вспомнить, чтобы возникали проблемы с этим
Главный поток больше служит как координатор и гарант последовательного вызова. Например, работа с UI, запуск асинхронных операций на других потоках и применение их результата, системные вызовы. Этот потом должен быть загружен как можно меньше, так как в него попадают все взаимодействия пользователя с экраном
💰 Поддержать проект на Boosty boosty.to/androidbroadcast
🔗 Telegram канал "Android Broadcast" ttttt.me/android_broadcast
🔗 Telegram канал "Kotlin Broadcast" ttttt.me/android_broadcast
Кирилл, спасибо за годноту и за вклад в community! Ты делаешь этот мир лучше)
Лучший утренний контент перед работой)
Кирилл, спасибо за шикарный контент
Коротко и без воды, шикарный формат
А кому что-то не понятно - гугл в помощь)
Если бы автор рассказывал о каждой мелочи - то видео бы получилось очень длинным и не охватило бы такую широкую аудиторию, которую охватывает сейчас
Так как для тех, кто, что-то знает по корутинам - было бы много воды
Я уже разбираюсь в корутинах, но мне кажется если бы до этого с корутинами не работал было бы сложно все это понять, даже после rx
Я сам их не понял с первого раза и не думаю что такую концепцию легко сразу понять с первого раза
Кирилл, спасибо за отличный контент по kotlin coroutines!
Да, присоединюсь. Супер подача, коротко и не напряжно. Вопрос от новичка. Как практиковаться в этом? С чего начать практику? Как именно ты начинал практиковаться. Именно начинал.
Смотрю разные источники, везде много теории и элементарные примеры, но хотелось бы примеров посложнее, причем с нарастающим уровнем сложности. Буду рад получить ответ, но даже если не получу, все равно продолжу смотреть тебя👍
Я практиковался уже с опытом в разработке, так что просто взял pet проект или начал писать его чтобы попробовать технологию. + повезло что на работе смог затащить корутины даже в альфа версии в 2017
@@AndroidBroadcast посоветуете как начать практику без опыта, если есть представление как это сделать?
@@speedrages если ты серьезно задаешь такие вопросы, то лучше и не начинать
Кирилл, ты случайно не оговорился на 4:55, когда сказал, что в пуле потоков IO количество потоков не менее 64? Другие источники говорят "не БОЛЕЕ 64".
Присоединяюсь к благодарностям за чертовски годный курс по корутинам!
Можно посмотреть формулу в исходниках. Для IO максимальный размер пулла очень большой, но все эти потоки создаются по необходимости
Лучший контент в утро субботы!
Отличное начало курса, в голове прям щелкает от понимания 😄
Отсюда у меня возник вопрос: можно ли указать саспенд функции, что она должна быть запущена в определенном диспатчере? Я видел вариант, что тело функции можно обернуть в нужный withContext, но не хотелось бы лишний раз переключаться
Тот способ через withContext и есть который используется для вызова функции в необходимом контексте, другого пути я не видел
Я так понимаю, что withContext и есть рекомендуемый подход, плюс вообще все функции лучше проектировать main-safe, что если функция может заблочить main поток, ей нужно самой переключить контекст на всякий случай
Спасибо за знания) успехов тебе)
Вот рекомендую отличный мини курс молодого бойца по корутинам, уверен его можно еще даже расширить и дополнить примерами:
ruclips.net/p/PLQkwcJG4YTCQcFEPuYGuv54nYai_lwil_
спасибо!👍
Ну тогда ждем урок еще завтра)))
Спасибо за материал!
Кратко и по существу
Кирилл, спасибо за видео!
На 3:33 кажется не совсем корректная инфа - родитель у которого SupervisorJob не отменяется ведь сам при ошибке в дочерней корутине
Верно. Надо будет поправить
Кирилл, спасибо, полезно, интересно ;)
Балдежный курс
На счёт оберток для провайда диспетчеров, мы отказались от этой штуки, т.к. появилась возможность в тестах напрямую сетить диспетчер в класс Dispatchers. Тесты от этого никак не пострадали, а куча классов убрала лишнюю зависимость, которая больше мозолила глаза
Сетать напрямую можно только Main Dispatcher, или я что-то упустил в обновлениях?
Спасибо
Очень красивое лицо, но лучше было бы смотреть на код, который мелькает не понятно для чего.
Речь лучше не как на рынке при навязывании товара, а помедленнее, если, конечно же, это разъяснение для новичков, а не хвастаство перед равными.
Спасибо! По поводу ссылки на енам, не увидел в описании(
Добавлю немного позже
Спасибо огромное за серию видео. Материал немного сложный, пересматриваю повторно.
Вопрос что будет если использовать Default dispatcher с IO операциями? Если при этом Default пул потоков загружен сложной математикой, то часть ядер процессора будут недозагружены?
Default и IO настроены с учётом специфики такого рода операций, если вы выберите неправильно -ничего страшного нет
Кирилл, можете пояснить один момент? Функция Join приостанавливает коррутину пока job'а не выполниться(Suspends the coroutine until this job is complete. ) Если Job это абстракция над коррутингой, то как она может выполняться с приостановленной корутиной? В некоторых статьях вижу такую формулировку "Например, его метод join() позволяет ожидать, пока корутина не завершится"
При создание корутины через launch или async вы получаете объект Job, который и представляет её. join() - это suspend функция, которая приостановит корутину в которой была вызвана, до тех пор пока не будет выполнена Job (корутина) у которой вызвали join()
Ещё не хватило инфы про переключение контекста с помощью withContext) о его плюсах и минусах
Оно будет в следующем видео
В курсе будет какое-нибудь (например, итоговое) видео с разбором того, во что компилятор преобразовывает корутину и как она под капотом работает?
Нет
@@AndroidBroadcast спасибо за ответ) а мне на работе уже пару коллег советовали извучить данный вопрос
В IO количество потоков равно количеству ядер процессора, но не меньше 64х?
Т.е. всегда не меньше 64х?
Потому что я не знаю SOC, в котором есть столько ядер)
Upd.
Разобрался в вопросе. На самом деле, по умолчанию в IO НЕ БОЛЬШЕ 64х потоков.
Как всегда, поверхностно, без объяснения. Тем, кому это действительно важно и они хотят понять, здесь делать нечего. Элементарный пример, ИО, ИО... Не все кто хочет разобраться с корутинами знают, что это абревиатура InputOutput и для чего этот поток. В общем как и с даггером, контент ради контента, а не для людей...
Коммент не критики ради, просто хочется действительно толкового объяснения, а не просто пересказ доки.
Ещё раз - это контент не для новичков, а уже понимающих профессию. Пишите вопросы и я сделаю доп разбор со всеми пояснениями. Знаете как сделать лучше, покажите мне своим примерос
Вот рекомендую отличный мини курс молодого бойца по корутинам, уверен его можно еще даже расширить и дополнить примерами:
ruclips.net/p/PLQkwcJG4YTCQcFEPuYGuv54nYai_lwil_
спасибо за крутой контент.
Одно не понял:
Зачем нужен лишние потоки (64 потоков) для io если у нас 8 процессоров (кажется 8 потоков достаточна)? Вед корутины (в отличий от обычных потоков) освобождают свой поток при блокирующем вызове (например запрос в сеть). То есть потоки никогда не будут в wait состояние и нет необходимости для context switch
Для того чтобы так происходило, I/O должен быть тоже suspend, но пока он только блокирующий (
@@AndroidBroadcast то есть сейчас при io запросах (в отличий от delay() допустим) поток не освобождается? Или я чето не понял? В первом видео вроде в обратном говорили: что несколько корутин могут в отдом потоке выполнятся
Благодарю за этот курс! Круто
Подскажите пожалуйста какой контекст нужно использовать в CoroutineScope для работы с базой , когда корутина что-то вытаскивает из Room ?
У меня, например val coroutineScope = CoroutineScope(Dispatchers.Default), но не уверен, что это правильно
Лучше взять IO, так как БД - это чтение/запись с/на диск
Если в Dao у метода прописать suspend, то запросы будут выполнятся на Room-овском Dispatcher-е и не надо использовать какой то другой диспатчер. Такое же поведение и у Retrofit-a
@@BelokonRoman , а с Realm такое возможно?
@@user-eh2jg6oh5b не знаю, я с Realm не работаю.
Я где-то давно читал, что IO dispatcher умеет только расширяться, но не умеет утилизировать ненужные потоки.
Ты не знаешь, они уже это поправили или так и осталось?
Без понятия такой подробности. Но каждый раз уничтожать потоки и убивать их невыгодно, так что такое поведение оправдано
@@AndroidBroadcast Тут проблема, что если во время каких-то нагрузок количество потоков сильно увеличится(например до 40), то потом они будут простаивать. Думаю именно по этому и создали limitedParallelism.
Да, там его и в Changelog так и объяснили
Привет
Я правильно понимаю, что пул потоков, при использовании Dispatcher.IO состоит из нативныех потоков (которых ещё 64)?
Буду очень благодарен за ответ, давно не могу разобраться в этом простом вопросе
64 - это максимум. Потоком создаются отложенно по необходимости
Почему вы советуете не использовать Dispatchers напрямую, а закидывать их обёртку через DI? Я пользуюсь ими напрямую, не могу вспомнить, чтобы возникали проблемы с этим
Проблем нет, но вот в тестах из удобнее подменять
Привет
Спасибо за курс.
Воспрос: может ли входить main-поток в пул потоков Default dispatcher?
Нет, в том то и суть чтобы разгрузить главный поток
Что значит интенсивно вычислительных операций? main же главный поток вроде
Главный поток больше служит как координатор и гарант последовательного вызова. Например, работа с UI, запуск асинхронных операций на других потоках и применение их результата, системные вызовы. Этот потом должен быть загружен как можно меньше, так как в него попадают все взаимодействия пользователя с экраном
Комментарий.
2:53 2 и 4 одинаковые вроде
Ага, проверю. Спасибо
+