Microsoft-ui-xaml: 제안: Auto-dispatch 속성이 UI 스레드에 이벤트를 변경했습니다.

요약

UI가 아닌 스레드에서 알림 변경 사항을 발생시키는 속성에서 UI 바인딩이 발생하도록 허용

이론적 해석

속성을 바인딩할 때 항상 UI 스레드에서 속성 변경 알림을 발생시켜야 합니다. 그렇지 않으면 런타임 예외가 발생합니다. 이로 인해 UI가 뷰 모델 및 모델로 흘러들어가 적절한 스레드를 올릴 수 있으므로 .NET Standard 라이브러리에서 INPC를 사용할 수 없게 됩니다(bait'n'switch에 들어가고 싶지 않은 경우). .

또한 한 프레임 동안 속성이 여러 번 변경될 수 있으므로 실제로 필요한 것보다 훨씬 더 많이 UI 스레드로 이동할 수 있습니다(필요한 모든 것은 속성을 "더티"로 플래그 지정하고 다음 렌더 패스.

이 모든 것은 코드 복잡성을 크게 증가시키고 오류가 발생하기 쉽습니다.

또한 WinUI 3.0에서 문제가 발생합니다. 이제 Legacy UWP와 WinUI 스레드의 두 가지 UI 스레드가 있기 때문입니다. 어느 것을 올려야 합니까?

범위

• 모든 스레드에서 INotifyPropertyChanged 및 INotifyCollectionChanged를 발생시킬 수 있어야 합니다.
• 프레임을 여러 번 저렴하게 수행할 수 있어야 하지만 단일 업데이트만 트리거합니다(마지막 업데이트가 승리).
• UI를 업데이트하기 위해 읽는 동안 설정되는 속성을 처리할 수 있어야 합니다.
• 이미 UI 스레드에 있는 경우 UI 스레드로의 전환을 방지합니다.

중요 참고 사항

스레딩 문제는 물론 유효하지만 결국 이것이 실제로 문제라고 생각하지 않습니다. 마지막 이벤트만 중요하므로 UI ​​업데이트 전에 여러 INPC 이벤트가 발생하는 것은 중요하지 않습니다. 이는 UI 스레드로 여러 번 전환하는 기존 코드와 다르지 않습니다. 첫 번째 항목이 UI 스레드로 전환되면 속성이 이미 여러 번 업데이트되어 마지막 항목이 승리할 수 있습니다.
당연히 값을 읽을 때 더티 플래그가 설정되는 것을 방지하는 짧은 잠금이 필요하므로 속성이 읽는 것과 동시에 업데이트되는 경우 다음 프레임에서 두 번째 UI 업데이트가 발생합니다.
실제로 인스턴스의 값이 false에서 true로, 다시 false로 변경되면 Dependency Property는 이미 값이 변경되지 않았음을 감지할 만큼 충분히 똑똑하고 속성으로 인해 새 렌더링 패스를 일으키지 않음으로써 최적화할 수 있습니다. 변하지 않는.