@archansel Faced with same issue, did you fix this problem?
같은 문제를 겪었는데, 이 문제를 해결하셨나요?

Nope, as I said, I end up using useSafeAreaInsets and avoiding SafeAreaView as much as I can because of this performance issue
아니요, 말씀드렸듯이, 저는 이 성능 문제 때문에 useSafeAreaInsets 를 사용하고 SafeAreaView 는 최대한 피하고 있습니다.

@archansel thank you, yes also use useSafeAreaInsets, but it triggers multiple times
감사합니다, 네 useSafeAreaInsets도 사용하지만 여러 번 호출됩니다.

LOG  {"insets": {"bottom": 0, "left": 0, "right": 0, "top": 44}}
 LOG  {"insets": {"bottom": 0, "left": 0, "right": 0, "top": 44}}
 LOG  {"insets": {"bottom": 0, "left": 0, "right": 0, "top": 0}}
 LOG  {"insets": {"bottom": 0, "left": 0, "right": 0, "top": 0}}
 LOG  {"insets": {"bottom": 0, "left": 0, "right": 0, "top": 44}}
 LOG  {"insets": {"bottom": 0, "left": 0, "right": 0, "top": 44}}

as you can see in the logs, there is lots of flickers in top property, as described here
로그에서 볼 수 있듯이, 여기서 설명한 것처럼 top 속성에 많은 깜박임이 있습니다

luckily for me, my current implementation doesn't give me any flickers, and when I check using logs, insets stay the same all the time (my app only use portrait orientation)
다행히도, 제 현재 구현에서는 깜박임이 전혀 없고, 로그를 확인해보면 인셋이 항상 동일하게 유지됩니다(제 앱은 세로 방향만 사용합니다)

another note, SafeAreaView problem only happens if I render 'heavy' list item, for basic list item it seems fine
또 다른 참고 사항으로, SafeAreaView 문제는 '무거운' 리스트 아이템을 렌더링할 때만 발생하며, 기본 리스트 아이템에서는 문제가 없는 것 같습니다

@archansel yes, problem occurred when use both portrait and landscape orientation
네, 문제는 세로 및 가로 방향을 모두 사용할 때 발생했습니다

For me, this issue only occurs when the SafeAreaView is first rendered while outside the viewport. Here's what I think is going on.
저에게 이 문제는 SafeAreaView 가 뷰포트 밖에서 처음 렌더링될 때만 발생합니다. 제가 생각하는 상황은 다음과 같습니다.

In order to decide whether to offset its children, SafeAreaView needs to know where it is being laid out on-screen. For instance, if you have a navigation layout where you have a tab bar at the bottom, and a SafeAreaView wrapping the main content above the TabBar, the SafeAreaView should avoid applying any bottom padding.
자식 요소의 오프셋을 결정하기 위해 SafeAreaView 는 화면에 어디에 배치되는지 알아야 합니다. 예를 들어, 하단에 탭 바가 있고 TabBar 위에 메인 콘텐츠를 감싸는 SafeAreaView 이 있는 내비게이션 레이아웃이 있다면, SafeAreaView 는 하단 패딩을 적용하지 않아야 합니다.

When SafeAreaView's initial render is outside the viewport, it doesn't know whether it should apply padding. Using useSafeAreaInsets goes around this issue because you are explicitly deciding which padding to apply. Another workaround is to use react-native-safe-area-view, which has a forceInset prop that lets you explicitly decide which insets to apply.
SafeAreaView 의 초기 렌더링이 뷰포트 밖에 있을 때, 패딩을 적용해야 하는지 알 수 없습니다. useSafeAreaInsets 을 사용하면 어떤 패딩을 적용할지 명시적으로 결정하기 때문에 이 문제를 우회할 수 있습니다. 또 다른 해결책은 forceInset prop이 있어 어떤 인셋을 적용할지 명시적으로 결정할 수 있는 react-native-safe-area-view 를 사용하는 것입니다.

@archansel Thanks for your solution, it is working perfectly even on very old devices both iOS and Android.
솔루션 감사합니다, 매우 오래된 iOS 및 Android 기기에서도 완벽하게 작동합니다.

Here is the SafeAreaView I created:
제가 만든 SafeAreaView 입니다:

type SafeAreaViewProps = {
  disableBottomSafeArea?: boolean,
  disableTopSafeArea?: boolean,
  disableSidesSafeArea?: boolean,
  children: React.Node
}

export const SafeAreaView: FunctionComponent<SafeAreaViewProps> = (props: SafeAreaViewProps) => {

  const { disableBottomSafeArea = false, disableTopSafeArea = false, disableSidesSafeArea = false, children } = props;

  const insets = useSafeAreaInsets();

  const style: StyleSheet = {};

  if (!disableBottomSafeArea) {
    style.marginBottom = insets.bottom;
  }

  if (!disableTopSafeArea) {
    style.marginTop = insets.top;
  }

  if (!disableSidesSafeArea) {
    style.marginRight = insets.right;
    style.marginLeft = insets.left;
  }

  return <View style={[{ flex: 1 }, style]}>
    {children}
  </View>;
};

@Rotemy and @archansel Thank you, thats a big help!
그리고 감사합니다, 큰 도움이 되었습니다!

Thank you!   감사합니다!@archansel @Rotemy

What's up with that custom SafeAreaView ? It looks like you coded the SafeAreaView again
그 커스텀 SafeAreaView는 도대체 뭐죠? SafeAreaView를 다시 코딩한 것처럼 보이네요
The original SafeAreaView also uses the hook useSafeAreaInsets, and applies margin (or padding) on the edges you want
원래 SafeAreaView도 useSafeAreaInsets 훅을 사용하고, 원하는 가장자리 부분에 마진(또는 패딩)을 적용합니다

Brain dump of some investigation I did into this:
제가 이 문제에 대해 조사한 내용을 정리한 것입니다:

I'm seeing something similar, and it doesn't have to be rendered outside the viewport. On iOS, the SafeAreaView shows up without any padding when it first enters the hierarchy, and then the padding is added. Most of the time it's too fast to show up in a frame, but sometimes it does, particularly when there's "a lot of other stuff going on", so I would expect it to be more common on older devices as well. Regardless, the layout with zero padding always happens (whether you see it or not). Using initial window metrics in the provider does not solve this.
저도 비슷한 현상을 보고 있는데, 뷰포트 밖에서 렌더링될 필요는 없습니다. iOS에서는 SafeAreaView가 계층 구조에 처음 들어올 때 패딩 없이 나타나고, 그 후에 패딩이 추가됩니다. 대부분의 경우 너무 빨라서 한 프레임 내에 나타나지 않지만, 때때로 "다른 작업이 많을 때" 특히 나타나기도 하므로 오래된 기기에서 더 흔할 것으로 예상됩니다. 어쨌든 패딩이 0인 레이아웃은 항상 발생합니다(보이든 안 보이든). 프로바이더에서 초기 윈도우 메트릭을 사용하는 것으로는 이 문제를 해결할 수 없습니다.

This appears to be a bug in the iOS implementation of the native version of SafeAreaView. I'm a little out of my depth, but I see we're invalidating the insets in several lifecycle-y methods: safeAreaInsetsDidChange, layoutSubviews, and didMoveToWindow. It looks like didMoveToWindow is at least one culprit wherein the native frameworks return empty insets (all 0) when the view is first added to the hierarchy. I question whether we need to be setting insets from all three of these places (though I have no idea), and safeAreaInsetsDidChange (which I have a suspicion is the "most correct" one) is actually returning early and not invaliding the insets due to the fact that the _providerView (which I'm guessing has something to do with the SafeAreaViewProvider) is null at the time. I haven't chased down when/how the _providerView gets set, or whether its actually the source of the insets we're getting. That's where I stopped.
이것은 SafeAreaView 의 네이티브 버전 iOS 구현에서 버그로 보입니다. 저는 이 분야에 익숙하지 않지만, 여러 생명주기 메서드인 safeAreaInsetsDidChange , layoutSubviews , 그리고 didMoveToWindow 에서 인셋을 무효화하고 있는 것을 봤습니다. 네이티브 프레임워크가 뷰가 계층에 처음 추가될 때 빈 인셋(모두 0)을 반환하는 최소한 한 가지 원인으로 didMoveToWindow 가 보입니다. 이 세 곳 모두에서 인셋을 설정할 필요가 있는지 의문이 듭니다(물론 잘 모르겠습니다). 그리고 safeAreaInsetsDidChange (제가 생각하기에 "가장 올바른" 것일 가능성이 있는)는 실제로 조기에 반환되어 인셋을 무효화하지 않는데, 이는 _providerView (제가 추측하기로는 SafeAreaViewProvider 과 관련된)이 그 시점에 null이기 때문입니다. _providerView 이 언제/어떻게 설정되는지, 또는 실제로 우리가 받는 인셋의 출처인지 추적하지 않았습니다. 거기서 멈췄습니다.

As for temporary solutions, neither useSafeAreaInsets nor SafeAreaViewContext.Consumer seem to exhibit this same behavior, which is why @Rotemy's code above works. However, I agree with @Snowirbix that it's a reimplementation of the non-native version of SafeAreaView, and is incomplete in that it just wraps the children, rather than modifying any passed-in styles. (Also the default behavior would be to modify the padding, not the margin.)
임시 해결책으로는 useSafeAreaInsets 도 SafeAreaViewContext.Consumer 도 동일한 동작을 보이지 않는 것 같아 위의 's 코드가 작동하는 이유입니다. 하지만 SafeAreaView 의 비원주민 버전을 재구현한 것이고, 전달된 스타일을 수정하지 않고 자식 요소만 감싸는 불완전한 방식이라는 점에 동의합니다. (또한 기본 동작은 마진이 아니라 패딩을 수정하는 것입니다.)

I haven't found a way to ignore the platform-specific (native) version and specifically import the non-native version, but I'm not sure how safe that would be to do anyway since in theory that version would be meant for react-native-web and could therefore break down the road, so my solution has been to copy the non-native SafeAreaView implementation and modify it for our purposes, since it's effectively just an example of how to use useSafeAreaInsets. (I also changed it to be class-based and use SafeAreaViewContext.Consumer instead.)
플랫폼별(네이티브) 버전을 무시하고 비네이티브 버전을 명시적으로 가져오는 방법을 찾지 못했지만, 이론적으로 해당 버전은 react-native-web 용으로 설계되었기 때문에 향후 문제가 발생할 수 있어 그렇게 하는 것이 얼마나 안전한지 확신할 수 없습니다. 그래서 제 해결책은 비네이티브 SafeAreaView 구현을 복사하여 우리 목적에 맞게 수정하는 것이었는데, 사실상 useSafeAreaInsets 를 사용하는 방법에 대한 예제일 뿐이기 때문입니다. (또한 클래스를 기반으로 하고 SafeAreaViewContext.Consumer 을 사용하도록 변경했습니다.)

TLDR: The native (iOS) implementation of SafeAreaView briefly has zero padding/margin when it first enters the layout. The non-native (pure TypeScript) version does not.
요약: SafeAreaView 의 네이티브(iOS) 구현은 레이아웃에 처음 들어올 때 잠시 0 패딩/마진이 있습니다. 비네이티브(순수 TypeScript) 버전은 그렇지 않습니다.

Interesting, @jonthanon, I am actually seeing something similar what you described in Android only and not in iOS. On my Android device, inset.bottom renders first at 16 and then updates to the correct value, 0.
흥미롭네요, 실제로 저는 iOS가 아니라 Android에서만 당신이 설명한 것과 유사한 현상을 보고 있습니다. 제 Android 기기에서는 inset.bottom 가 처음에 16 로 렌더링되었다가 올바른 값인 0 로 업데이트됩니다.

Brain dump of some investigation I did into this:
이 문제에 대해 제가 조사한 내용을 정리한 브레인 덤프입니다:

Thanks for the dump @jonthanon. I've dug a bit deeper and placed some logs into RNCSafeAreaView to figure out what's causing the issues. This is what gets logged when navigating to a screen in which I have a SafeAreaView wrapping a custom Header component.
덤프 감사합니다. 문제의 원인을 파악하기 위해 RNCSafeAreaView에 로그를 좀 더 깊게 삽입해 보았습니다. SafeAreaView가 커스텀 헤더 컴포넌트를 감싸고 있는 화면으로 이동할 때 기록되는 로그는 다음과 같습니다.

2021-11-06 14:16:51.915841+0100 RNCSafeAreaView: didMoveToWindow
2021-11-06 14:16:51.919771+0100 RNCSafeAreaView: safeAreaInsetsDidChange
2021-11-06 14:16:51.919855+0100 RNCSafeAreaView: invalidateSafeAreaInsets before {0.000000, 0.000000, 0.000000, 0.000000}
// flicker!
2021-11-06 14:16:51.919875+0100 RNCSafeAreaView: invalidateSafeAreaInsets after {0.000000, 0.000000, 0.000000, 48.000000}
2021-11-06 14:16:51.919927+0100 RNCSafeAreaView: safeAreaInsetsDidChange
2021-11-06 14:16:51.926069+0100 RNCSafeAreaView: layoutSubviews
2021-11-06 14:16:51.947294+0100 RNCSafeAreaView: safeAreaInsetsDidChange
2021-11-06 14:16:51.947397+0100 RNCSafeAreaView: safeAreaInsetsDidChange
2021-11-06 14:16:51.948794+0100 RNCSafeAreaView: layoutSubviews

I found that the reason for this flicker is because the _currentSafeAreaInsets is initialized with default values of 0. We then need to wait for safeAreaInsetsDidChange to set the correct values. Setting default values for _currentSafeAreaInsets doesn't help either, because they are reset to zeros by the didMoveToWindow method. That is what I found from the logs, please correct me if I'm wrong.
이 깜빡임 현상의 원인은 _currentSafeAreaInsets 이 기본값 0으로 초기화되기 때문임을 발견했습니다. 이후 safeAreaInsetsDidChange 이 올바른 값을 설정할 때까지 기다려야 합니다. _currentSafeAreaInsets 에 기본값을 설정해도 didMoveToWindow 메서드에 의해 0으로 재설정되기 때문에 도움이 되지 않습니다. 로그에서 찾은 내용이며, 틀렸다면 알려주세요.

TLDR: The native (iOS) implementation of SafeAreaView briefly has zero padding/margin when it first enters the layout. The non-native (pure TypeScript) version does not.
요약: SafeAreaView 의 네이티브(iOS) 구현은 레이아웃에 처음 들어갈 때 잠시 0의 패딩/마진을 가집니다. 반면 비네이티브(순수 TypeScript) 버전은 그렇지 않습니다.

Unfortunately, in my case the non-native version does not suffice. During the first render, useSafeAreaInsets returns insets relative to the entire viewport. I am only trying to wrap the header, so I don't need the bottom inset. This also lead to a flicker:
안타깝게도 제 경우에는 비네이티브 버전으로는 충분하지 않습니다. 첫 렌더링 시 useSafeAreaInsets는 전체 뷰포트를 기준으로 한 인셋을 반환합니다. 저는 헤더만 감싸려고 하므로 하단 인셋은 필요하지 않습니다. 이로 인해 깜빡임 현상도 발생했습니다:

 LOG  INSETS {"bottom": 34, "left": 0, "right": 0, "top": 48}
 LOG  INSETS {"bottom": 0, "left": 0, "right": 0, "top": 48}

I know that I am free to use only the "top" value, in which case there is no flicker with this method, but I have another use-case. I would like to have paddingBottom = Math.max(insets.bottom, 20) for some footer that does not overlap the home indicator. In this case there will be a flicker as the padding changes from 34 to 20.
저는 "top" 값만 사용하는 것이 자유롭다는 것을 알고 있으며, 이 경우 이 방법에서는 깜박임이 없습니다. 하지만 저는 다른 사용 사례가 있습니다. 홈 인디케이터와 겹치지 않는 일부 푸터에 대해 paddingBottom = Math.max(insets.bottom, 20) 을 원합니다. 이 경우 패딩이 34에서 20으로 변경되면서 깜박임이 발생합니다.

I'm not sure how to solve this and whether it can even be solved. Can any of the maintainers please take a look? The utility that this SafeAreaView provides is completely clouded by this annoying flicker. Usually it happens quickly, but as some have noted earlier, it causes problems on older devices and heavy renders.
이 문제를 어떻게 해결해야 할지, 그리고 해결이 가능한지 확신이 서지 않습니다. 유지보수 담당자 중 누군가가 이 문제를 살펴봐 주실 수 있나요? SafeAreaView가 제공하는 유틸리티가 이 성가신 깜박임 때문에 완전히 가려져 버립니다. 보통은 빠르게 발생하지만, 앞서 언급한 바와 같이 오래된 기기나 무거운 렌더링에서는 문제가 발생합니다.

Can confirm I am seeing this too with the native SafeAreaView. It's weird that it happens intermittently
네이티브 SafeAreaView에서도 저도 이 현상을 확인했습니다. 간헐적으로 발생한다는 점이 이상합니다.

Initial load:  초기 로드:

then insets applied:  그런 다음 적용된 인셋:

which causes a flicker:
깜박임을 유발하는:

Seeing the same thing. This happens with RN's own SafeAreaView, and I was hoping that this library wouldn't have the same issue, but it does!
같은 현상을 보고 있습니다. 이 문제는 RN의 자체 SafeAreaView에서도 발생하며, 이 라이브러리에서는 그런 문제가 없기를 바랐지만, 똑같이 발생합니다!

FWIW, I've been using the same workaround as @Rotemy.
참고로, 저는 와 같은 해결책을 사용하고 있습니다.

Interesting, @jonthanon, I am actually seeing something similar what you described in Android only and not in iOS. On my Android device, inset.bottom renders first at 16 and then updates to the correct value, 0.
흥미롭네요, , 저는 실제로 iOS가 아닌 Android에서만 당신이 설명한 것과 비슷한 현상을 보고 있습니다. 제 Android 기기에서는 inset.bottom 가 먼저 16 에 렌더링되고, 그 후에 올바른 값인 0 로 업데이트됩니다.

I have the exact same problem on my android device. When I navigate from Screen B to Screen A, the Screen A bottom inset is 0 then 16 then 0 in a fraction of time, causing the flicker.
제 Android 기기에서도 똑같은 문제가 있습니다. 화면 B에서 화면 A로 이동할 때, 화면 A의 하단 인셋이 0에서 16으로, 그리고 다시 0으로 아주 짧은 시간 내에 변해서 깜빡임이 발생합니다.

The react-native-safe-area-context doc says "if [the SafeAreaProvider] overlaps with any system elements (status bar, notches, etc.) these values will be provided to descendent consumers".
react-native-safe-area-context 문서에는 "만약 [SafeAreaProvider]가 시스템 요소(상태 표시줄, 노치 등)와 겹치는 경우, 이 값들이 하위 소비자에게 제공됩니다"라고 나와 있습니다.

I don't know where this 16 value comes from as it's still happening even when I disable the screen transition animations.
이 16 값이 어디서 나오는지 모르겠는데, 화면 전환 애니메이션을 비활성화해도 여전히 발생하고 있습니다.

The only workaround I found is to use a custom tabBar. https://reactnavigation.org/docs/bottom-tab-navigator/#tabbar
제가 찾은 유일한 해결책은 커스텀 tabBar를 사용하는 것입니다. https://reactnavigation.org/docs/bottom-tab-navigator/#tabbar
The custom tabBar function actually gets those props: { state, descriptors, navigation, insets }
커스텀 tabBar 함수는 실제로 다음과 같은 props를 받습니다: { state, descriptors, navigation, insets }
So I created my own TabBar component based on the example provided in the docs and didn't added the insets values.
그래서 문서에 제공된 예제를 기반으로 나만의 TabBar 컴포넌트를 만들었고 insets 값을 추가하지 않았습니다.

I guess the default tabBar has it's marginBottom changed by insets.bottom.
기본 tabBar는 insets.bottom에 의해 marginBottom이 변경되는 것 같습니다.

This is for v3 of the library, and we're on v4. Please re-open a new issue if you're still facing issues
이것은 라이브러리의 v3용이며, 우리는 v4를 사용 중입니다. 여전히 문제가 발생하면 새 이슈를 다시 열어주세요.

This still happening with v4.5 on react navigation animation transition.
react navigation 애니메이션 전환에서 v4.5에서도 여전히 이 문제가 발생하고 있습니다.

The hook useSafeArea has a delay compared to the native SafeAreaView, which causes a flicker. You can mitigate some of it with initialMetrics - but if you rotate to landscape or something, you'll see a flicker again - and we can't fix it at the moment. If you - or any libraries you are using - are using the hook, you will see a flicker. The real fix is to make sure every single instance is using the native view.
훅 useSafeArea 은 네이티브 SafeAreaView에 비해 지연이 있어 깜빡임이 발생합니다. initialMetrics 을 사용하면 일부를 완화할 수 있지만, 가로 모드로 회전하거나 하면 다시 깜빡임이 발생하며 현재로서는 이를 수정할 수 없습니다. 만약 당신이나 사용하는 라이브러리들이 이 훅을 사용하고 있다면 깜빡임이 발생할 것입니다. 진정한 해결책은 모든 인스턴스가 네이티브 뷰를 사용하도록 하는 것입니다.

still facing this issue in 2025!
2025년에도 여전히 이 문제가 발생하고 있습니다!

@mabdurrafey-afl I don’t know if it can help, but I’ve just created a React context that calls the useSafeAreaInsets hook once. Then, whenever I need it, I just use const { inset } = useTheme() (where useTheme is my context). I’ve also created a custom <SafeAreaView /> that uses my context instead. Now, I don’t get any flickering (since the hook is only calculated once) :
도움이 될지 모르겠지만, 저는 useSafeAreaInsets 훅을 한 번만 호출하는 React 컨텍스트를 방금 만들었습니다. 그리고 필요할 때마다 const { inset } = useTheme() 을 사용합니다( useTheme 는 제 컨텍스트입니다). 또한 제 컨텍스트를 사용하는 커스텀 <SafeAreaView /> 도 만들었습니다. 이제 훅이 한 번만 계산되기 때문에 깜빡임이 전혀 없습니다:

const ThemeProvider = ({children}: ThemeProviderProps) => {
	const [colors, setColors] = useState(Colors.dark);
	const applyColors = (colorTheme: TColors) => {
		setColors(colorTheme);
	};
	const inset = useSafeAreaInsets();

	DefaultTheme.colors.background = colors.background;

	return (
		<ThemeContext.Provider
		value={{
			applyColors,
			colors,
			inset,
		}}
		>
			{children}
		</ThemeContext.Provider>
	);
};