一.역사：React Native 는 시작부터 현재까지
React Native 의 위치는 React 를 통해 네이티브 App 을 구축하는 것입니다:
A framework for building native apps with React.
5 대 특성을 가집니다:
-
Create native apps for Android and iOS using React: React 를 사용하여 Android, iOS 애플리케이션 생성
-
Written in JavaScript—rendered with native code: 쓰는 것은 JavaScript, 실제 렌더링되는 것은 Native 인터페이스
-
Native Development For Everyone: 플랫폼 무관한 기초 컴포넌트를 기반으로 개발하면 플랫폼 네이티브 경험을 획득
-
Seamless Cross-Platform: 원활한 전환, Native 코드는 React Native 사용 가능한 컴포넌트로 패키징 가능
-
Fast Refresh: 변경 즉시 유효, Web 과 같은 개발 속도 보유
그렇다면, 2 가지 질문이 있습니다:
-
왜 React(또는 JavaScript) 를 사용하여 Native 애플리케이션을 쓰는가? 원동력은 무엇인가?
-
왜 이 방식으로 크로스플랫폼하는가, WebView 는 아닌가?
탐색 사고
React 로 Native 애플리케이션을 쓰는 이유는, 2 측면이 있습니다:
-
React 자신의 우위: 선언적 뷰 정의가 가져오는 UI 예측 가능성, 컴포넌트화 메커니즘 하의 복잡도 분해 등
-
Web 개발의 우위: 빠른 이터레이션, 빠른 피드백, 빠른 개발
Native 가 React 를 사용하면, React 의种种 혜택도 획득할 수 있습니다. 물론, 이는 일면일 뿐이며, 배후의 진정한 원동력은 Native 개발이 Web 처럼 move fast 할 수 있기를 희망하는 것입니다
두 번째 질문에 대해서는, React Native 의 유래부터 말해야 합니다
실제로, Facebook 은 3 가지 사고를 시도했습니다:
-
WebView: Native 가 Webview 컨테이너를 제공하고, 비즈니스는 Web 기술로 개발
-
Porting React to native: React 를 Native 구현에 이식
-
Scripting native: JavaScript 를 통해 Native API 호출
저비용 WebView 방안을 크로스플랫폼에 이용하지 않는 것은, Web 기술에 제한되어, 경험이 Native 와 동렬로 논할 수 없어, 최종적으로 성능과 확장성이 예상에 도달하지 않아 포기했습니다
React 를 Native 에 이식하는 것은 좋은 사고이지만, React 자신의 몇 가지 혜택만 획득할 수 있으며 (JavaScript 세계의 React 의 번영한 생태계는 포함하지 않음), Native 의 move fast 에도 도움이 되지 않습니다. Native 는 여전히 순수한 Native 이기 때문입니다
그에 비해, React Native 는 JavaScript 를 통해 Native API 를 호출하는 것은 양쪽 모두 아름답게 하는 방안으로, Native 가 React(및 JavaScript 의 번영한 생태계) 를 사용할 수 있고, Web 의 개발 속도도 가질 수 있습니다. 쓰는 것도 실제로 실행되는 것도 JavaScript 이며, Native 는 뷰 렌더링 능력과 플랫폼 특정 능력만 제공할 뿐입니다
발전 이력
React Native 는 2013 년 Facebook 내부 해커톤 (hackathon) 에서 탄생했습니다
2015 년 1 월의 React.js Conf 에서, 이 내부 프로젝트가 처음 공개되었고, 5 월의 F8 Conference 에서 정식 오픈소스되었습니다. 처음에는 iOS 만 지원했고, 같은 해 9 월에 Android 지원
2016 년 제공된 Microsoft UWP 와 Samsung Tizen 지원은, React Native 가 모바일 단에서 PC(Win 10), 게임기 (Xbox One), 팔찌 (Gear Fit 2), 스마트 TV(SUHD) 심지어 홀로그래픽 안경 (HoloLens) 으로 걸어갔음을 의미합니다
2018 년 6 월에 아키텍처 업그레이드 계획 Fabric 을 시작하여, 스레드 모델을 리팩토링하고 React Native Core 를 간소화하여, Native & React Native 혼합 App 을 더 잘 지원
2019 년 7 월에 JavaScript 엔진 레벨 성능 향상을 맞이하여, Android 플랫폼이 이전에 사용하던 JavaScriptCore 를 Hermes 로 교체
P.S.React Native 발전사에 대한 상세 정보는, React Native 간사 참조
二.아키텍처：원래, 너는 이런 RN 이구나!
쓰는 것은 JavaScript, 실제 렌더링되는 것은 Native 인터페이스
따라서, 매우 높은 시점에서 보면, React Native 기술 (또는 Scripting Native 방안) 을 이렇게 이해할 수 있습니다:
JavaScript 층
---------------------------------
???
---------------------------------
Native 층
중요한 점은: 중간은 무엇인가? 상하 두 세계는 어떻게 연결되는가?
아키텍처 설계
React Native 에서, 중간은 Bridge 층으로, 메시지 통신을 통해 JavaScript 세계와 Native 세계를 연결합니다
구체적으로, Shadow Tree 는 UI 효과와 인터랙션 기능을 정의하고, Native Modules 는 Native 기능 (예를 들어 블루투스) 을 제공하며, 둘은 JSON 메시지를 통해 상호 통신합니다:
Bridge 층은 React Native 기술의 핵심으로, 설계상 3 가지 특징을 가집니다:
-
비동기 (asynchronous): 동기 통신에 의존하지 않음
-
직렬화 가능 (serializable): 모든 UI 조작이 JSON 으로 직렬화되고 다시 변환될 수 있음을 보장
-
배치 처리 (batched): Native 호출을 큐에 넣고, 배치 처리
P.S.React Native 아키텍처에 대한 상세 정보는, React Native 아키텍처 일람 참조
스레드 모델
React Native 에는 주로 3 개의 스레드가 있으며, 각각:
-
UI Thread: Android/iOS(또는 기타 플랫폼) 애플리케이션 중의 메인 스레드
-
Shadow Thread: 레이아웃 계산과 UI 인터페이스 구축을 수행하는 스레드
-
JS Thread: React 등 JavaScript 코드가 모두 이 스레드에서 실행
게다가, Native Modules 스레드라는 카테고리가 있으며, 다른 Native Module 은 다른 스레드에서 실행 가능 (상세는 Threading 참조)
시작 프로세스
전체적으로, 시작 프로세스는 Bridge 초기화와 비즈니스 코드 실행 두 부분으로 나뉘며, 그림의 상하 두 부분에 해당:
렌더링 메커니즘
첫 렌더링 시 (그림 중 오른쪽에서 왼쪽으로의 플로우), JS 스레드는 뷰 정보 (구조, 스타일, 속성 등) 를 Shadow 스레드에 전달하여, 레이아웃 계산에 사용하는 Shadow Tree 를 생성하고, Shadow 스레드는 레이아웃을 계산한 후, 완전한 뷰 정보 (폭높이, 위치 등 포함) 를 메인 스레드에 전달하며, 메인 스레드는 이에 따라 Native View 를 생성
사용자 인터랙션 시 (그림 중 왼쪽에서 오른쪽으로의 플로우), 먼저 메인 스레드가 관련 정보를 이벤트 메시지로 패키징하여 Shadow 스레드에 전달하고, Shadow Tree 가 확립한 매핑 관계에 따라 해당 요소의 지정 이벤트를 생성하며, 마지막으로 이벤트를 JS 스레드에 전달하여, 대응하는 JS 콜백 함수를 실행
아키텍처 진화
최초의 설계는 몇 가지 제한도 가져왔습니다:
-
비동기: JavaScript 로직을 동기 답변을 필요로 하는 많은 Native API 와 직접 통합할 수 없음
-
배치 처리: React Native 애플리케이션이 Native 구현의 함수를 호출하는 것은 매우 어려움
-
직렬화 가능: 불필요한 copy 가 존재하며, 직접 메모리를 공유할 수 없음
이러한 문제들은 Native + React Native 의 혼합 애플리케이션에서 특히 두드러지므로, 2018 년 6 월에 대규모 아키텍처 업그레이드 계획을 제안:
구체적으로 3 가지 중대한 변경을 포함:
-
JavaScript 층: JSI 를 도입하여, 다른 JavaScript 엔진을 교체 가능하게
-
Bridge 층: Fabric 과 TurboModules 두 부분으로 나누어, 각각 UI 관리와 Native 모듈 담당
-
Native 층: 코어 모듈을 간소화하고, 비코어 부분을 분리하여 커뮤니티 모듈로 독립적으로 업데이트 유지
Fabric 은 렌더링 플로우 중의 복잡한 크로스스레드 인터랙션을 간소화하고, JavaScript 가 직접 고우선순위 UI 조작을 제어하는 것을 허용하며, 동기 호출도 허용 (리스트 빠른 스크롤, 페이지 전환, 제스처 처리 등 장면 대응)
TurboModules 는 Native 모듈을 필요에 따라 로드하는 것을 허용하며, 모듈 초기화 후 직접 그 참조를 보유하며, 메시지 통신에 의존하여 모듈 기능을 호출하는不再
P.S.React Native 아키텍처 업그레이드에 대한 상세 정보는, React Native 아키텍처 진화 참조
三.생태계：Learn once, write anywhere ?
React Native 의 최초의 비전은learn once, write anywhere입니다:
It's worth noting that we're not chasing "write once, run anywhere." Different platforms have different looks, feels, and capabilities, and as such, we should still be developing discrete apps for each platform, but the same set of engineers should be able to build applications for whatever platform they choose, without needing to learn a fundamentally different set of technologies for each. We call this approach "learn once, write anywhere."
(React Native: Bringing modern web techniques to mobile 에서 인용)
애플리케이션 생태계
플랫폼 지원상, 현재 (2019/9/21), 공식이 제공하는 Android, iOS 지원 외에, 커뮤니티는 UWP, Tizen, Web, Mac, Apple TV, 심지어 微信미니프로그램 등의 지원도 제공
P.S.더 많은 지원 플랫폼은, Out-of-Tree Platforms 참조
기업 애플리케이션方面에서는, Facebook 외에, React Native 는 騰訊, 百度, 京東 등의 대규모 기업에서도 응용되고 있습니다:
툴 생태계
React Native 가 발전하여 오늘의 4 년 동안, 툴 생태계도 일정 정도의 발전이 있었습니다:
-
개발 툴: Nuclide(공식 제공이지만 이미 유지不再), deco-ide, 그리고 Visual Studio Code, Webstorm, Sublime Text, ATOM 등의 주류 IDE 는 모두 React Native 지원
-
애니메이션: lottie-react-native, react-native-animatable 등
-
UI 컴포넌트: NativeBase, React Native Elements 등
-
디버그 툴: Chrome developer tools, Reactotron
P.S.React Native 생태계에 대한 상세 정보는, Exploring React Native Ecosystem – Tools, backend, database and best libraries 참조
축적의 깊은 Android, iOS 기술 생태계와 비교하여, React Native 생태계는 아직较低 성숙도의 단계에 있어,そのため Native 기반시설과의 통합, 크로스언어스택디버그 등의 난제에 직면하고 있습니다. 그러나 어떻게 해도, Learn once, write anywhere 의 비전은 길 위에 있으며, 우리에게 달려오고 있습니다
아직 댓글이 없습니다