Stackflow 성능 상의 잠재적 이슈 조사

Stackflow는 메모리 관리와 성능을 고려한 구조이긴 하지만, 너무 많은 activity를 stack에 쌓는다면 다음과 같은성능 문제가 발생할 수 있습니다:

⚠️ 성능 상의 잠재적 문제

1.DOM 오버헤드

각 activity는 React 컴포넌트 단위로 렌더링되며, 기본적으로 DOM에 남아 있습니다.

Activity 수가 많아지면 렌더링 성능 저하 및 메모리 사용량 증가 우려가 있습니다.

특히 이미지, 동적 이벤트, 리스너 등 무거운 DOM을 포함한 activity가 많다면 렌더링 비용이 커집니다.

2.상태 보존 부담

activity 간 이동 시 상태를 그대로 유지하는 구조이므로, 너무 많은 activity가 보존되면 메모리 누수 및 상태 충돌이 발생할 수 있습니다.

내부적으로useState,useEffect, 리액트 context 등을 사용하는 경우 컴포넌트가 사라지지 않으면 side effect가 누적될 수 있습니다.

3.전환 애니메이션 지연

각 activity 전환 시 애니메이션 처리 대상이 많아질수록 프레임 드롭이 발생할 수 있습니다.

✅ 권장 기준

Stackflow 공식 문서나 커뮤니티에서 명시적으로 “최대 몇 개”라는 한도는 없지만, 일반적인 경험 기준으로:

활동 수

권장 여부

설명

1~5개

✅ 안전

일반적인 모바일 내비게이션 시나리오

6~10개

⚠️ 주의

메모리 및 상태 관리 확인 필요

10개 이상

❌ 비권장

SPA에서 DOM과 상태 누적 위험 증가

10개 이상 push되는 상황이 반복된다면, 구조적인 개선이 필요합니다. 예를 들어:

"탭 뷰 안에서 push 반복" vs "루트 단위 replace or reset" 같은 방식 고려

🔧 실전 대응 전략

1.불필요한 activity는replace혹은popAndPush사용

actions.replace("NewActivity", { params: {} });

2.Stack 관리 로직 구현

특정 조건에서 stack depth가 일정 이상이면 자동 pop or reset 처리

3.activityRenderer 최적화

activityRenderer={({ activity, isActive }) => { return isActive ? : null; }};

→ 활성화된 activity만 DOM에 유지 (→ 상태, 스크롤, 로컬 변수 등모두 초기화)

상태를 유지하면서 DOM만 detach하는 방식 (activityRenderer 커스터마이징 + keep-alive 패턴)

(하지만 굳이 이렇게까지..?)

4.경량화 컴포넌트 구성

각 activity는 최대한 상태를 외부화하고, 렌더링 DOM 요소를 줄이도록 설계

🧪 실전 체크 포인트

Performance탭에서 렌더링 트레이싱

React DevTools에서 activity component 트리 확인

Memory탭에서 snapshot 비교

SPA 모바일 환경에서 5~8개 activity 전환 기준으로 FPS 측정

✅ 결론

Stackflow는 기본적으로 5~8개 수준까지는 성능 문제가 없도록 설계되어 있습니다.

그 이상 쌓이는 구조라면replace / pop / activityRenderer 최적화를 통해 stack depth를 관리하는 것이 중요합니다.

특히 모바일 웹뷰에서는 activity 수보다는/wiki/spaces/~712020c3094f0296ec441199b2f5971b251995/pages/1511817254와 리소스 무게가 더 큰 영향을 미칩니다.

필요하시면 stack depth에 따라 자동 pop하거나activityRenderer로 비활성화된 activity를 DOM에서 제거하는 코드 예시도 드릴게요.