# RunLoop
iOS Layout Update
안녕하세요, szzang입니다!! 굉장히 오랜만의 포스트입니다 😅 그동안 놀고있었던건 아니고… 나름 여러가지 공부를 하느라 헿.. 그래도 오늘은 오랜만에 묵혀두었던 공부하고 싶었던 주제에 대한 공부를 해보고 나름대로 정리한 내용을 공유해보려 합니다! 바로 iOS의 Layout은 어떻게 업데이트 되는가..!! 출발해 보시죠! 😎 Run Loop 먼저 iOS Layout Update를 이해하기 위해서는 Run Loop에 대해 알아야 합니다. 쓰레드와 관련된 기본적인 인프라로써 작업이 예약된 이벤트의 수신을 조정하는데 사용하는 이벤트 처리 Loop로써 Run Loop의 목적은 수신된 이벤트가 존재한다면 쓰레드가 해당 이벤트를 처리하고, 수신된 이벤트가 없다면 쓰레드를 절전모드로 전환하기 위함입니다. Run Loop는 완전히 자동으로 관리되지 않기 때문에 적절한 시간에 RunLoop를 시작하고 이후에 들어오는 이벤트에 응답하도록 쓰레드 코드를 설계해야 하며
[번역] RunLoop.main과 DispatchQueue.main의 차이
Combine을 공부하다가 주로 receive(on: ) 을 통해 메인 스레드 혹은 Runloop.main으로 스레드를 변경할 때가 있습니다. 어떤 차이점이 있는지 궁금해서 알아보았습니다. 번역을 통해 진행하였습니다. https://www.avanderlee.com/combine/runloop-main-vs-dispatchqueue-main/ What is a Combine scheduler? Combine scheduler란 클로저가 언제, 어떻게 실행될지를 정의하는 것이다. Scheduler들은 Scheduler 프로토콜을 따르고 있고, RunLoop.main과 DispatchQueue.main 또한 따르고 있다. 가장 흔히 사용되는 예시는 receive(on: option:) 으로 Combine stream을 설정(s
Combine - DispatchQueue.main VS RunLoop.main
공부하면서 정리한 내용이기에 잘못된 내용이 있을 수 있습니다. 댓글 피드백 환영합니다! RunLoop에 대해 생소하시다면 개발자 소들이님의 'iOS) 런 루프(RunLoop) 이해하기' 글을 먼저 읽어보시길 강력 추천드립니다. DispatchQueue.main 그리고 RunLoop.main Apple에서 제공하는 Combine 프레임워크를 사용하다보면 다음과 같은 상황을 마주할 때가 있다. sink 내부에는 보통 메인쓰레드에서 동작해야 하는 작업들, 이를테면 UI 업데이트와 같은 로직들을 넣게 되는데, 이 때 중요한건 Scheduler를 지정하는 부분이다. Scheduler로 DispatchQueue.main을 썼을 때와 RunLoop.main을 썼을 때, 차이가 존재할까? 그냥 둘 중 아무거나 사용해도 상관없는걸까? 비교 테스트 아래의 뷰 및 코드로 두 Schedu
User Event & MainRunLoop
TableView에서 스크롤 동작을 진행 할 때마다, 기존에 진행되고 있었던 Timer의 로직이 수행되지 않는 이슈를 만나게 되었습니다. 트러블 슈팅 도중에 RunLoop와 연관이 있었다는 것을 알게 되었으며, 이슈 해결 방법과 Runloop에 대해 알아보는 시간을 가졌으면 해서 글을 작성해보려 합니다. 이야기를 시작하기 앞서 AppLifeCycle에 대해서 알아보겠습니다. MainRunLoop의 생성을 엿 볼 수 있기 때문인데요! AppLifeCycle의 순서는 아래와 같습니다. > 사용자가 앱의 아이콘
RunLoop
RunLoop란? 런루프는 thread와 관련있는 중요한 인프라 부분이다. 런루프는 이벤트 처리 loop로 작업을 스케쥴하거나 다가오는 이벤트를 조작하기위해서 사용한다. 런루프의 목적은 작업이 있을 경우 쓰레드를 바쁘게 유지하거나 해야할 작업이 없을 경우 쓰레드를 sleep하게 만들도록 한다. 런루프 관리는 전체가 자동으로 되어있지 않다. 적절한 시간에 런루프를 시작하기위해서 thread의 코드를 설계해야하고 다가오는 이벤트에 반응해야 한다. Cocoa와 Core Foundation는 thread의 런루프를 만들고 관리하기 위해서 런루프 objects를 제공한다. 사용하는 application는 명확하게 이런 objects를 생성할 필요는 없다. 각 쓰레드, apllication의 메인쓰레드를 포함해서 관련 런루프 object를 가지고 있다. 오로지 2번째 쓰레드는 명확하게 이 런루프를 실행할 필요가 있다. app 프레임워크는 application 시작 프로세스의
Target / Action
Target / Action은 사용자 interaction을 처리하는 주요 방법으로 알려져있다. 문서를 읽으며 알아보자. Target/Action Target/Action은 대표적인 비동기 이벤트이다. Action이 왔을 때, 처리되는 방식이기 때문이다. 간단하게 Target/Action에 대해서 알아보자. 객체간의 소통을 위해 delegation, notification 등이 있으나, 이것만으로는 화면상에 보이는 것들의 소통에는 부족함이 있다. User Interface에서 가장 전형적인 것은 Graphic 요소이고, 이것들을 구성하는 대부분은 Control이다. 우리가 마주하는 Control은 보통, Button, SLider, Checkbox 등등이 있다. 이 녀석들과의 원할한 소통을 위해 해당 구조를 채택했다. 
Timer
이전 글에서 RunLoop에 대해 알아보았다. Timer도 같이 처리한다 했었는데, 이번에는 Timer에 대해서 알아보려한다. Timer > 특정 시간 간격이 지난 후, Target 객체로 메시지를 전송한다. 문서를 읽어보니, Run loop는 Timer에 대해 강한 참조를 유지하기 때문에, Run loop에 타이머를 추가한 후에 강한 참조를 유지하지 않아도 된다고 한다. 이게 무슨말인가 싶어 좀 찾아보니, run loop에 timer를 추가할 수 있는데 그 뒤로는 timer 객체를 들고 있을 필요가 없다라는 말인 것 같다. 하지만 fire를 위해서는 들고 있는 것이 좋을 수도 있다. 그 다음으로 문서에서는 Timer가 실시간 매커니즘이 아니라고 한다. 이는 Run loop에 대해 알아야 한다. 이전 글을 참고하자. 일단 생각해보면, Timer는 Run loop안에서 돌아가는 녀석이다. 그런데 run loop는 input source역시 처리한다. 만약 내가
RunLoop
RunLoop이란 무엇일까? RunLoop Run loop은 일단 Thread와 관련된 녀석이다. 간단하게 말하면, Run loop은 event를 처리하기 위해 만들어진 loop이다. Timer 또한 함께 처리한다. 하지만 이를 바깥에서 한번 감싼 구조인데, 이렇게 만든 이유는 할 일이 있을 경우에는 Thread를 busy하게 두고, 그렇지 않을 때는 sleep 하도록 하기 위함이다. Run loop의 관리는 자동적으로 되는 것이 아니다. 적절한 타이밍에 thread code를 시작하도록 해야하고, 들어오는 이벤트에 맞추어서 반응하도록 설계해야 한다. Cocoa, Core Foundation에서는 내가 만들고 싶은 thread의 run loop을 쉽게 설정하기 위해 run loop 객체를 제공한다. 즉, 명시적으로 생성해서 사용할 필요가 없다. 각각의 thread (main 포함)에는 각각의 run loop object를 가지고 있다. main thread의
Run Loop
RunLoop는 앱 구동간에 생성되는 Thread와 함께 생성되어 해당 Thread가 수행해야 할 이벤트들을 핸들링하여 적절한 수행을 요청하고, 이벤트 처리가 종료되면 대기 상태로 접어들어 다음 이벤트에 대한 모니터링을 해주는 추상화입니다. RunLoop의 구조 iOS에서 이벤트 소스에서 이벤트가 발생하면 스레드르 깨운 후 이벤트를 런루프로 전달한다. 이벤트를 받은 런루프에서 등록된 핸들러를 통해 이벤트를 처리한다. 처리할 이벤트가 없을 때에는 스레드를 대기상태로 변화시킨다.