requestAnimationFrame

보통 애니메이션을 적용할 때 CSS를 이용하여 구현을한다. 하지만 사용자와의 상호작용을 통한 애니메이션을 구현할 경우 자바스크립트를 통해 애니메이션을 구현할 수 있다. 하지만 CSS보다는 성능이 좋지가 않다. 

이를 위해 최적화된 애니메이션을 구현하기 위해 제공되는 API가 requestAnimation이다.

 

위에서 "최적화된" 애니메이션 구현이라는 것은 뭘까? 

이를 비교하기 위해 다른 방식의 애니메이션을 구현하는 방법을 봐보자. 

setInterval, setTimeout을 통해 반복되는 로직으로 width와 같은 값을 변경하여 구현할 수가 있다.

그럼 requestAnimationFrame과의 차이가 뭐고 왜 requestAnimationFrame이 더 최적화되어 있다고 말할 수 있나 봐보자. 

 

보통 브라우저의 경우 1초에 60프레임을 보여주고 가장 부드러운 애니메이션을 출력해준다. 이를 기반으로 보면 1000ms / 60fps, 즉 16.6666 밀리세컨드 간격으로 프레임을 생성하여 노출이 이루어져야한다는 것이다.

setInterval을 통해 1000/60 간격으로 나타내보자.

const animation = () => {
	// 스타일변경 -> reflow 발생되도록
}

setInterval(animation, 1000 / 60);

이와 같이 구현이 될 것이다. 

이와 같이 구현되면 어떤 문제가 존재할까?

계속해서 밀려들어오는 animation처리에 따른 reflow가 발생되고 이 과정은 비용이 많이 드는 과정이다. 비용에 따라 결국 따라가지 못하고 누락되는 문제 또한 발생할 수 있다.

 

반면, requestAnimationFrame은 어떻게 될까?

requestAnimationFrame은 브라우저가 렌더링 준비가 완료 됐을 때 실행되도록 스케줄링하는 API이다. 즉, 아직 reflow가 진행중이라고 하면 끝날때까지 기다렸다가 다음 작업을 진행되도록 한다. 이렇게 되면 setInterval에서 생겼던 문제가 사라지게된다.

 

이 뿐만 아니라 다른 차이도 존재한다.

setInterval의 경우 다른 탭을 보거나, 브라우저가 최소화 화면이 되어있다고 한들 계속 돌아가게 된다. 

반면, requestAnimationFrame의 경우 페이지가 비활성화 되면, 작업이 중단되어 리소스를 낭비하지 않게된다.

이 장점의 경우 의도적으로 비활성화된 페이지에도 계속해서 작업을 진행하고자하면 단점이 될 수도 있긴하다.

 

다음으로 requestAnimationFrame이 event loop에서 어떻게 처리가 되고 있을까?

우선 event loop에서 queue가 존재한다는 것은 많은 이들이 알것이다. 

이는 크게 micro task queue, macro task queue로 구성이 되어있고, micro task queue가 가장 높은 우선순위를 가졌다.

여기서 세부적으로 들어가면 macro task queue의 경우

 

Task Queue : setTimeout, setInterval과 같은 비동기 작업이 이 큐에 들어감.

I/O Queue : 파일 시스템 작업 또는 네트워크 요청과 같은 입출력 작업이 이 큐에 들어감.

AnimationFrame Queue : requestAnimationFrame 콜백 함수가 이 큐에 들어감.

Render Queue : 브라우저가 렌더링을 위해 다음 프레임을 준비하는 작업이 이 큐에 들어감.

 

이처럼 requestAnimationFrame 또한 이벤트루프 내에서 큐에 의해 task가 하나씩 처리가 된다.