1. React Native 동작 원리

• Android / iOS Native Project 안에 React-Native Project가 있다.
• Thread란?
  • 실행되는 프로세스 내에서 실제로 작업을 실행하는 주체
  • 명령어를 실행하여 처리 하는 주체
  • (like 음식점에서 음식을 만드는 행위와 비슷)
• React-Native Thread (1)
  • Main Thread or UI Thread
  • Native 영역에 레이아웃을 그려주는 역할
• React-Native Thread (2)
  • JavaScript Thread
  • 작성한 Javascript가 실행 되는곳
• React-Native Thread (3)
  • Native Module Thread
  • Native Module을 다룰때 사용하게 되는 Thread
  • 특정 리소스등을 요청하고자 할때 사용
• React-Native Thread (4)
  • Shadow Thread
  • virtual DOM으로부터 새로운 Layout으로 변환하도록 계산해주는 역할

1.1 React Native intialize process

1
Main Thread → JS Thred → Shadow Thread → Native Module Thread

• Diffing : virtual DOM과 실제 DOM element를 비교하며 변경되었는지 체크
• React-Native Bridge
  • Javascript와 Native가 서로 소통 하는 할수 있도록 돕는 역할

2. Native Module

• Native Module 이란 Native API를 사용하기 위한것.
  • 주로 현재 위치, wifi 상태 등 native 영역에서만 알고 있는 정보에 접근하는것
  • 또는 image processing 처럼 연산이 native의 높은 performance가 필요할때 사용
• Native Module
  • 로직/연산에 대한 Native Module
  • 어떤 Native Library의 함수를 호출 할 때 사용
• Native UI Component
  • View에 대한 Native Module
  • 주로 카메라 등 연산이 많은 View에 대해서 작성

3. New Architecture

3.1 Why New Architecture ?

Bridge가 가지고 있는 본질적인 문제를 해결 하기 위함

3.2 Bridge가 가진 제한점

3.2.1 It was asyncronous (비동기 처리)

• 비동기 처리 : 어떤 작업이 끝날때까지 다음 프로세스를 기다리지 않고 다른 작업을 바로 실행하는것
• 작업이 끝났는지 보장이 되지 않아, 끝났을때에 별도 처리가 필요

3.2.2 It was single threaded (싱글 스레드)

• Javascript가 싱글 스레드에서 동작하기 때문에 Bridge도 싱글 스레드로 동작 함

3.2.3 It imposed extra overheads (변환시 드는 과도한 비용)

• Bridge로 이동 하게 될때 JSON Object 변환하는 비용이 큼

3.3 New Architecture

• 기존에 있던 Bridge를 버리고, JSI가 해당 역할을 대신 하도록 수정
• JSI : Javascript Interface, C++ 객체에 대한 참조를 할수 있게 해주는 역할

3.3.1 Old Architecture

Bridge를 통해 Native Module과 Javascript 로직간 통신

1
JS → Bridge → Native UI
2
            → Module

3.3.2 New Architecture

Bridge를 통해 Native Module과 Javascript 로직간 통신

1
JS → JSI Fabric              → Native UI
2
         Turbo Native Module → Module

3.4 New Architecture를 적용하며 얻은것

1. 동기 실행이 가능하게 됨
   • C++ 모듈로 직접 접근을 할 수 있다보니 비동기 통신이 아니어도 됨
2. 동시성
   • Javascrript에서 다른 스레드에 있는 함수를 호출 할 수 있음
3. Overhead가 줄어듬
   • JSON Object로 변환 하지 않고 C++ 언어로 통신하게 되었기 때문
4. iOS, Android간 내부 네이티브 모듈 코드 공유 가능
   • C++이 추가됨으로 인하여 플랫폼이 다르더라도 한개의 코드로 관리 가능
5. 타입의 안정성
   • 자동으로 생성 되는 코드 레이어에 의해서 자동으로 타입을 생성 하도록 되어있음

4. New Architecture

4.1 Fabric

• Fabric이란 ?
  • New Architecture의 새로운 rendering system.
  • 이전 Architecture에서는 UI Manager가 담당하던 부분
• Fabric 개선점
  • Shadow Thread에서 새로운 Shadow Tree를 계산하던 로직을 C++ 로직으로 변환 가능하도록 수정
  • onLayout, onMeasure등 View의 위치, 사이즈등을 계산하던 로직을 비동기에서 동기 함수로 변환 했기 때문에 많은 퍼포먼스 이득

4.2 Turbo NativeModule

• Turbo NativeModules
  • 기존 Architecture에서는 NativeModule로 사용되던 것
  • Bridge가 사라지게 되면서 추가됨
• Turbo NativeModules 장점
  1. Platform 전반적으로 Typecheck가 잘됨
  2. 플랫폼 별 코드 공유가 쉬움 (C++로 작성된 코드를 공유)
  3. Native Module Lazy Loading이 적용됨
     • Lazy Loading : 최초에 모든 리소스를 로드 하는것이 아닌, 필요 할때 로드하는 방식.
     • (최초 로드시 부하를 줄이기 위함)
  4. JSI 사용으로 인하여 Native와 Javascript코드간 통신이 효율적
     • JSON Object로 변환 없이 C++ 코드만으로 통신 가능

4.3 CodeGen

• CodeGen
  • 3rd-party library에서 제공되는 코드를 인터페이스에 맞게 작성하면
  • JSI 관련 코드들을 만들어 주는것
  • 프로젝트를 빌드 할때 자동으로 실행 (빌드 시간에 영향)
• New Architecture
  • 2022년 말 현재, 아직까지는 실험적인 부분들이 많음
  • 안정화 된 뒤 정식 릴리즈 예정

5. Hermes

• Facebook에서 만든 javascript Engine
• Bytecode 형태로 미리 컴파일 하여 저장 해 둔 뒤 사용
• [Hermes Announcement]
  • 앱 최초 로딩시 jsbundle 파일을 읽어와 동작 가능한 javascript로 compile 하게 됨
  • 이 과정이 대략 4초(Android 기준) 정도 걸리는것으로 파악됨
  • 앱 빌드 시간에 parse와 compile등 필요한 작업을 빌드 할 때 하도록 함
  • Bytecode형태로 미리 컴파일 해두면 실행만 시키면 되기 때문
• 또다른 장점
  • 사용하는 Memory의 감소 (기존 185mb -> 136mb)
  • AAB / APK 크기 감소 (기존 41mb -> 22mb)
• 적용 되어있는지 확인
  • Hermes의 장점을 온전히 보기 위해서는 release build Type으로 확인

6. Wrap-up

사용하는 Thread

• Main Thread : 실제로 UI들이 그려지는 thread
• Javascript Thread : JS가 동작하는 thread
• NativeModule Thread : Native Module 동작을 위한 thread
• Shadow Thread : virtalDOM을 실제 반영할 화면으로 변환 하는 thread

Bridge

• Javascript와 Native간 통신을 할 수 있도록 도와주는것
• JSON으로 들어와서 JSON으로 다시 넘겨주게 되어있음
• New Architecture : Bridge를 통해 Native Module과 Javascript 로직간 통신
• Hermes : 앱 빌드 시간에 parse와 compile등 필요한 작업을 빌드 할 때 하도록 함

7. react-native-reanimated

• React-Native에서 Animation을 Frame drop 없이 사용가능 하도록 만든 패키지
• React-Native Animated가 가지고 있는 단점(병목 현상)을 해결
• react-native-reanimated
  • animation 관련된 작업을 모두 Main Thread에서 실행
  • worklet을 이용하여 JS Thread로 전달

7.1 worklet, shared values

• worklet : 작은 조각의 javascript 조각
  • 뷰 속성을 업데이트 하거나, 이벤트에 반응할때 UI Thread에서 바로 실행 시킬 수 있는 JS 조각
  • worklet 생성방법
    • 함수 상단에 worklet이라는 string을 추가
• SharedValues
  • JS Thread와 Main Thread 모두에서 읽기 또는 수정이 가능 한 값
  • Main Thread에서는 값이 변경됨을 바로 감지 할 수 있어 읽기에 특화됨

8. FCM

• Push Notification 이란 ?
  • 서버에서 설치된 앱에 메시지를 전달하고, 앱에서 전달된 메시지를 보여주는것
• Push : Message를 전달 하는 것
• Notification : Message를 보여 주는 것

8.1 Push Notification 종류

• Data Message
• 데이터만 전달 해주는 푸시
• Notification은 별도로 띄우지 않음
• 앱의 설치 여부 또는 데이터의 갱신이 필요 할때 사용
• Notification Message
• 실제로 유저에게 메시지와 함께 알려주는 것
• 단순 광고성 메시지, 채팅 메시지 수신 등에서 주로 사용

9. Jest

9.1 Mocking

• 가짜 데이터를 만들어 사용하는것
• e.g.) HTTP 요청시 특정 값을 Response로 지정

9.2 without Mocking

• Mocking 없이 Test를 돌리게 된다면, 실제로 서버로 요청이 가게 됨
• 인증이 필요 없는 API는 문제 없이 동작
• 인증이 필요 한 API는 요청 실패로 인한 failed
• 인증이 필요한 API와, 아닌 API를 구분하여 각각 상황에 맞게 호출
• 테스트를 위해 챙겨야 할게 너무 많음
• Native Module은 Native API를 사용 하게 되어있음
• Jest는 핸드폰이 아닌 Local PC 환경에서 실행 됨
• Native API (위치, 카메라 등)를 사용하는 경우에는 무조건 failed 처리

9.3 with Mocking

• 응답값을 별개로 선언하여 받기 때문에 인증여부와 상관없이 사용가능
• API 요청시, 성공 또는 실패시에 대한 응답값 정의 가능
• Native API 호출시에도 되돌려 받는 값을 정의 가능

9.4 spyOn

• 몰래 정보를 빼내오는 기능
• 함수가 호출 될때 어떤 값과 함께 호출되었는지 파악 가능

10. Storybook

• UI 컴포넌트들을 상태 별로 볼 수 있도록 도와주는 도구
• 상태를 제어를 하며 맞게 렌더되는지 시각적으로 확인 가능
• react-native뿐만 아니고 Frontend 전반적으로 사용되는 도구
• 도입의 가장 큰 고민 Point
  • 모든 앱의 기능들을 전부 돌려보지 않는 이상 모든 상태를 확인하는것은 사실상 불가능
• 도입 결정의 이유
  • 디자인 시스템 적용을 하기 위해서 도입을 해보고자 research
  • 디자이너와 개발자간 같은 컴포넌트의 상태를 바라보고자 결정
• Story ?
  • UI 컴포넌트 하나에 대한 상태를 보여주는것
  • Component와 Story는 1:N의 관계
• 주요 Add-on #1
  • @storybook/addon-ondevice-knobs
  • props 제어를 통해서 상태를 바꿔 볼 수 있도록 도와주는 addon
• 주요 Add-on #2
  • @storybook/addon-ondevice-notes
  • 설명을 추가 할 수 있도록 도와주는 addon