tg-me.com/iosdev/522
Last Update:
Разбор принципов RunLoop на примере создания своей собственной командной оболочки для macOS
Отличный материал для чтения в воскресенье того, чтобы отложить до понедельника
Когда мы обнаруживаем, что слушаем события, реагируем на них, а затем возвращаемся к прослушиванию новых событий, то перед нами Event-Loop.
Event-Loop — это настолько распространенный сценарий, что Apple решила предоставить нам модель для последовательной обработки таких циклов.
📖 В этом посте рассматривается, как работает RunLoop и приводится пример создания командной оболочки (он же shell или шелл) для наглядности.
Одним из наиболее распространенных случаев цикла событий является REPL (Read Eval Print Loop). И, вероятно, одним из наиболее часто используемых REPL являются оболочки (bash, zsh, fish, в зависимости от того, что вы предпочитаете).
Командная оболочка работает очень знакомо: ожидает вашего ввода —> считывает информацию —> выполняет отправленные вами команды —> возвращается к ожиданию следующего ввода.
В примере создаётся их аналог, который имеет только одну полезную команду (две, если считать exit), а именно выводит список файлов в текущем каталоге с помощью ls.
В той же macOS мы получаем объект RunLoop с каждым потоком, независимо от того, как поток создается (через pthread или Thread). Кроме того, использование RunLoop не является обязательным, но ваш поток может создать его по запросу, если вам это нужно.
Почему стоит прочесть этот материал?
💡 С помощью наглядного примера объясняется, почему не рекомендуется запускать блокирующие задачи в основном потоке в ваших приложениях (как для macOS, так и для iOS). А ещё вы сможете детальнее изучить преимущества использования RunLoop.
🛠 Код из примера доступен на GitHub.
@iOS Dev
BY iOS Dev
Share with your friend now:
tg-me.com/iosdev/522