Update: Wikified 129 files from Datacollector_MAC/out_wiki (P-Reinforce v3.0)
This commit is contained in:
@@ -1,4 +1,36 @@
|
||||
# [[Performance Optimization]]
|
||||
---
|
||||
category: Architecture
|
||||
tags: [auto-wikified, technical-documentation, merged, architecture]
|
||||
title: React Native Performance Optimization
|
||||
description: "React Native의 성능 최적화는 주로 자바스크립트 스레드와 네이티브 스레드 간의 통신 병목 현상을 해결하는 데 초점을 맞추고 있습니다."
|
||||
last_updated: 2026-05-04
|
||||
---
|
||||
|
||||
# React Native Performance Optimization
|
||||
|
||||
|
||||
## 📌 Brief Summary
|
||||
React Native의 성능 최적화는 주로 자바스크립트 스레드와 네이티브 스레드 간의 통신 병목 현상을 해결하는 데 초점을 맞추고 있습니다. 최근 '새로운 아키텍처(New Architecture)'의 도입을 통해 기존의 비동기 브릿지(Bridge) 구조를 제거하고 동기식 통신을 가능하게 하여 성능을 극적으로 향상시켰습니다. 이를 통해 직렬화 오버헤드를 줄이고, 렌더링 속도와 앱의 초기 로딩 및 메모리 성능을 효율적으로 최적화하고 있습니다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **새로운 아키텍처(New Architecture)와 브릿지리스 모드:** 과거 React Native의 가장 큰 성능 병목은 JS와 네이티브 간의 통신을 담당하며 데이터를 JSON 문자열로 직렬화했던 비동기 브릿지였습니다 [1]. 최근 버전(0.74 이상)에서는 이를 기본적으로 제거한 브릿지리스 아키텍처를 채택하여 성능을 크게 최적화했습니다 [1, 2].
|
||||
* **JSI (JavaScript Interface):** 기존 브릿지를 대체하는 경량 C++ 기반의 레이어로, 자바스크립트 코드가 네이티브 객체에 대한 직접적이고 동기적인 참조를 가질 수 있게 합니다 [3, 4]. 이로 인해 통신 간의 데이터 직렬화(Serialization) 오버헤드가 완전히 제거되어 실시간에 가까운 고성능 통신이 가능해집니다 [3, 4].
|
||||
* **Fabric 렌더러:** 새로운 UI 관리 및 렌더링 시스템으로, 비동기적 왕복 처리 없이 메인 스레드에서 네이티브 뷰를 측정하고 렌더링할 수 있습니다 [4, 5]. 이는 React 18의 동시성(Concurrent) 렌더링을 지원하며, 동기적인 레이아웃 계산을 통해 UI 요소의 반응성과 애니메이션이 훨씬 매끄럽게 동작하도록 개선합니다 [4, 5].
|
||||
* **TurboModules:** 기존 네이티브 모듈은 앱 시작 시 모두 한꺼번에 초기화되어 시작 시간을 늦추는 원인이었으나, TurboModules는 모듈이 처음 사용될 때만 로드되는 지연 로딩(Lazy Loading) 방식을 도입했습니다 [4, 6]. 이는 앱의 초기 시작 성능을 높이고 초기 메모리 사용량(Footprint)을 크게 줄여줍니다 [4, 6].
|
||||
* **Codegen 도입:** 자바스크립트와 네이티브(Java/Kotlin, Objective-C/Swift) 간 통신을 위한 C++ 보일러플레이트 코드를 빌드 타임에 자동으로 생성해 줍니다 [7]. 이는 두 계층 간의 강력한 타입 안전성을 제공하여 런타임이 아닌 컴파일 타임에 오류를 잡아냄으로써 성능과 코드 안정성에 기여합니다 [7].
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **초기 시작 시간(Cold Start) 지연:** AOT(Ahead-Of-Time) 컴파일을 통해 머신 코드로 직접 변환되는 방식과 달리, React Native는 앱 실행 시 자바스크립트 엔진(주로 Hermes)을 초기화하고 JS 번들을 파싱하는 과정을 거쳐야 합니다 [8]. 이 과정 때문에 대체로 300~600ms 수준의 초기 콜드 스타트 지연 시간이 발생할 수 있습니다 [8].
|
||||
* **기존 브릿지 아키텍처의 레거시 부채:** 새로운 아키텍처로 완전히 전환하지 않은 환경에서는 자바스크립트와 네이티브 간 브릿지 통신에서 메모리 누수(Memory leaks)가 발생할 수 있으며, 시간이 지남에 따라 점진적인 성능 저하 문제가 발생할 수 있습니다 [9].
|
||||
* **서드파티 라이브러리 및 유지보수의 복잡성:** 새로운 아키텍처와 JSI의 성능적 이점을 온전히 얻기 위해서는 서드파티 라이브러리들 역시 새 구조를 지원해야 합니다 [4, 9]. 또한 OS 업데이트나 메이저 버전 업그레이드 시 플랫폼 종속적인 코드 재작성과 광범위한 테스트가 요구되어, 큰 유지보수 비용(최대 2~3개월 소요)이 발생할 수 있습니다 [7, 9].
|
||||
* **애니메이션 제어의 렌더링 한계:** 자체적인 렌더링 파이프라인을 온전히 통제하는 방식이 아니므로, 매우 복잡한 커스텀 애니메이션(파티클 효과 등)에서는 렌더링 성능의 한계가 드러날 수 있습니다 [10, 11]. 하지만 실제 네이티브 플랫폼 컴포넌트를 직접 사용하기 때문에 별도의 커스텀 렌더링 트리를 유지할 필요가 없어, 기본 메모리 사용량과 번들 크기는 더 작게 유지되는 긍정적 반대 급부도 가집니다 [8, 12].
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-03*
|
||||
|
||||
## 📚 Legacy Insights & Additional Context
|
||||
> [!NOTE]
|
||||
> Below is content merged from previous versions of this documentation.
|
||||
|
||||
## 📌 Brief Summary
|
||||
성능 최적화(Performance Optimization)는 소프트웨어의 기능적 동작을 동일하게 유지하면서 시간이나 메모리와 같은 자원 사용량을 개선하기 위해 내부 구조를 변경하는 과정입니다 [1-3]. 코드를 더 이해하고 수정하기 쉽게 만드는 리팩토링(Refactoring)과 유사하게 기능은 유지하지만, 구조 개선이 아닌 속도 향상이나 자원 효율성을 주된 목적으로 삼는다는 점에서 구별됩니다 [1, 2, 4]. 성공적인 성능 최적화를 위해서는 이해하기 쉬운 코드로 먼저 리팩토링하여 튜닝하기 좋은 상태를 만드는 것이 필수적인 선행 조건으로 간주됩니다 [5-7].
|
||||
@@ -35,4 +67,4 @@
|
||||
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-03*
|
||||
*Last updated: 2026-05-03*
|
||||
|
||||
Reference in New Issue
Block a user