새 리액트 네이티브 아키텍처 설명: 세번째 파트
작성자: LORENZO SCIANDRA
작성일: 2019/04/09
번역일: 2019/11/21
이 글은 formidable.com에 기재된 The New React Native Architecture Explained: Part Three을 번역한 것입니다.
Part Three: Fabric과 TurboModules
2018년에 처음 발표된 리액트 네이티브 재구성 프로젝트는 페이스북이 이 크로스 플랫폼 모바일 솔루션에 오랫동안 제기되어 온 이슈에 엄청난 공을 들여서 착수한 프로젝트입니다.
이번 시리즈에서는 리액트 네이티브의 새 아키텍처의 주요 요소들에 대해서 알아보겠습니다. 코드를 보여드리기보단, 가능한한 설명에 치중하도록 하겠습니다. 또 이 프로젝트를 도입하며 저희를 흥분시켰던 것들을 공유하고자 합니다.
이번 글에서는 이번 새 아키텍처의 “메인 요리” 부분에 대해서 파고들어 보겠습니다. 아마도 모든 리액트 네이티브 개발자들이 한번씩은 Fabric과 TurboModules를 들어봤을 것입니다.
전에 알아봤듯이, 새 리액트는 큐잉 개념을 허용하고, JSI는 자바스크립트 코드를 “맞은 편에 있는” 네이티브 코드와 원활하게 상호작용 하도록 해줍니다.
이해를 쉽게 하고 접근성을 용이하게 하기 위해, 기존 아키텍처의 브릿지 부분을 심히 간략하게 표현하면 이렇습니다.
이 부분의 요소들은 기본적으로 두가지 기능을 합니다: UI가 어떻게 보여지고 동작하는지(Shadow Tree를 통해서)를 정의하는 기능과 네이티브 사이드를 관리하는 것(Native Modules를 통해서)입니다. 전에 설명했듯이, 이런 커뮤니케이션은 비동기 JSON 메세지들이 네이티브 사이드와 쌍방향 통신으로 이루어지게 됩니다. 그리고 예상하실 수 있듯이, 이 메세지들이 커뮤니케이션 채널을 통하여 엮어지고 보내지는 과정에서 혼잡해짐으로써 이상 현상을 야기시킬 수 있습니다.
페이스북 팀은 이 거대한 브릿지를 다음의 두개의 기능으로 분리하기로 결정했습니다. Fabric: 새 아키텍처의 UI 매니저와, TurboModules : 네이티브 사이드와 상호 작용하는 “신세대” 구현체입니다.
Fabric은 리액트 네이티브의 렌더링 레이어를 현대화 시키는데 초점을 맞췄습니다. 기존에는 모든 UI 작업들은 일련의 크로스-브릿지 “단계들”에 의해 처리되었습니다. (React -> Native -> Shadow Tree -> Native UI) 그러나 새롭게 도입된 방식으로는 UI 매니저가 Shadow Tree를 C++로 직접 생성하게 되는데, 이는 영역간의 “점프들”을 줄임으로써 프로세스의 속도를 굉장히 신속화 시켜주고, 이로 인해 사용자 인터페이스의 반응속도를 크게 향상시켜 주게 됩니다.
또한, JSI를 사용함으로써 Fabric은 UI 작업들을 자바스크립트 함수로써 노출시키게 됩니다. 새 Shadow Tree(스크린에 무엇을 띄울지 결정하는)는 두 영역 간(자바스크립트 영역과 네이티브 영역 — 역주)에 공유되며, 양쪽 모두에서 직접적인 상호 작용을 가능하게 해 줍니다.
여기까지는 별로 큰 개선이 아닌것 같아 보일지도 모르지만, 이 자바스크립트 사이드의 직접적인 컨트롤은 UI 작업들에 대해 새 리액트의 priority queue(첫번째 글에서 언급했던)를 가질 수 있게 되면서, 퍼포먼스 향상을 위한 동기적 수행들에 참여할 수 있게 되어 리스트, 네비게이션, 제스쳐 핸들링 등에서 자주 발생하는 고질적인 퍼포먼스 위험요소들을 개선시킬 수 있는 기초가 됩니다.
기존에는 자바스크립트 코드로 사용되는 Native Modules (블루투스같은)는 앱이 시작할 때 initialized되어야 했습니다 — 심지어 사용되지 않는 경우에도 — 첫번째 글에서 언급한 두 영역간의 서로를 “잘 인지하지 못하는” 문제 때문이죠. 새 TurboModules 접근방식은 자바스크립트 코드로 하여금 각 모듈이 필요할 때만 불러오게 하고, 직통 reference를 유지하여 예전 브릿지의 방식처럼 JSON 메세지들을 엮어서 소통할 필요가 없어졌습니다. 이는 다른 글들에서 언급했던 직접 통신과 아울러, 많은 수의 Native Modules를 사용하는 앱의 시작시간을 획기적으로 향상시켜줄 것입니다.
이 세번째 파트의 모든 변경사항은, 저번 글에서 알아봤던 자바스크립트 인터페이스에 의존하고 있습니다. 우리가 현재 단계까지의 페이스북 팀의 새 아키텍처가 어떤지를 본다고 하면 이와 같습니다.
이것을 끝으로 리액트 네이티브 아키텍처 재구성 탐구의 세번째 파트를 마치도록 하겠습니다. 다음 주에 이번 시리즈의 마지막 글을 올리도록 하겠습니다. 그동안 이 글을 동료 개발자들에게 공유하는 것을 잊지 마세요. 또한 트위터 계정을 통해 질문을 하셔도 됩니다. (DM도 가능합니다).
여러분이 코드를 (전혀) 다시 작성하지 않고도 이 강력한 변화가 여러분의 코드베이스에 끼칠 영향에 대해 많은 기대를 하시길 바랍니다.
다들 이 새로운 변화의 흐름에 편승하시길 바랍니다!
