정보
요청한 주제가 아래에 표시됩니다. 그러나 이 주제는 이 라이브러리에 포함되지 않습니다.

Windows Phone 8의 앱 성능 고려 사항

2014-06-18

적용 대상: Windows Phone 8 및 Windows Phone Silverlight 8.1 | Windows Phone OS 7.1

 

성능은 Windows Phone 장치용 앱을 만들 때 중요한 고려 사항입니다. Windows Phone 장치는 데스크톱 또는 랩톱 PC에 비해 CPU(중앙 처리 장치) 및 GPU(그래픽 처리 장치)가 제한됩니다. Windows Phone 에서 앱의 성능을 최적화하기 위해 XAML 에서 그래픽 및 기타 개체를 처리하는 방식이 몇 가지 변경되었습니다. 이 항목에서는 Windows Phone 앱의 성능을 향상시킬 수 있는 방법에 대해 설명하며 여러 코드 샘플을 포함합니다.

이 항목에는 다음 단원이 포함되어 있습니다.

 

Windows Phone 앱의 성능 최적화를 지원하는 데 사용할 수 있는 여러 도구가 있습니다.

도구

설명

Windows Phone용 앱 모니터링

느린 시작 시간, 입력에 대한 느린 응답 시간, 높은 배터리 방전 등의 문제를 식별하는 데 도움이 됩니다.

Windows Phone 응용프로그램 분석

코드에서 성능 관련 문제를 측정 및 평가하고 대상으로 지정할 수 있게 합니다.

Windows Phone 에뮬레이터의 프레임 속도 카운터

프레임 속도 카운터를 사용하여 앱의 성능을 모니터링할 수 있습니다.

EnableRedrawRegions

개발 중 각 프레임에서 다시 그려지는 영역을 표시하여 앱 성능을 조정하는 데 사용되는 진단 기능을 설정합니다.

또한 Windows Phone 8 의 경우 앱이 배포되고 스토어 를 통해 배포될 때 휴대폰에서 실행되는 방식에 변경 내용이 있습니다. 자세한 내용은 Windows Phone의 정품 버전 앱을 테스트하는 방법을 참조하세요.

이러한 도구에 대한 자세한 내용은 그래픽을 많이 사용하는 앱의 성능 문제 식별 섹션을 참조하세요.

앱에 이미지를 포함할 때 성능을 향상시킬 수 있는 여러 가지 고려 사항이 있습니다. 이 섹션에서는 이미지와 관련된 고려 사항에 대해 설명합니다.

JPG 및 PNG 이미지 형식 간 선택

앱의 성능을 향상시키기 위해 수행할 수 있는 가장 쉬운 작업 중 하나는 적절한 이미지 형식을 사용하는 것입니다. Windows Phone 에 대해 지원되는 두 가지 이미지 형식은 JPG와 PNG입니다. 일반적으로 JPG 디코더가 PNG 디코더보다 훨씬 더 빠르며 완전 불투명 이미지에 사용해야 합니다. JPG는 투명도를 지원하지 않으므로 투명도를 사용하는 이미지는 PNG로 저장해야 합니다. JPG는 사진을 포함하여 연속 톤 이미지에 효과적이지만 다양한 색과 그라데이션이 포함된 이미지에서 물결 현상 및 차단 아티팩트가 발생할 수 있습니다.

이미지 만들기

Windows Phone OS 7.1 성능 최적화와 관련하여 확인할 사항은 UI 스레드를 차단하는 대신 이미지 디코딩을 백그라운드 스레드로 이동하는 옵션입니다. 이렇게 하려면 CreateOptions 특성을 BackgroundCreation으로 설정합니다. 예:

<Image Height="100" Width="100" Margin="12,0,9,0">
  <Image.Source>
    <BitmapImage UriSource="{Binding ImgURL}" CreateOptions="BackgroundCreation"/>
  </Image.Source>
</Image>

이미지와 XAML 간 선택

Expression Design에서 복잡한 시각적 요소를 만들 수 있습니다. 이러한 시각적 요소를 XAML이나 이미지 파일로 내보낼 수 있습니다. 시각적 요소가 정적인 경우 XAML 대신 이미지로 저장해야 합니다. 이미지를 디코딩하고 렌더링하는 것과 반대로 XAML에는 추가 처리가 필요할 수 있습니다. 시각적 요소에 XAML을 사용하는 경우 XAML을 구문 분석하고 시각적 트리에서 개체를 만들고 개체를 렌더링해야 합니다. 예를 들어 체커 게임 앱을 만드는 경우 Expression Design을 사용하여 게임의 각 체커에 대해 복잡한 디자인을 만들 수 있습니다. 하지만 체커는 정적이므로 체커를 XAML 대신 이미지로 내보내는 것이 앱 성능에 더 좋습니다.

이미지 크기 제한

Windows Phone 의 화면 해상도가 제한되므로 성능을 최적화하는 다른 방법은 이미지 크기를 Windows Phone 환경의 이미지 크기 제한인 2000 x 2000 픽셀로 제한하는 것입니다. 큰 이미지는 더 낮은 해상도로 샘플링됩니다. 또한 2000 x 2000 픽셀보다 큰 이미지를 사용하는 경우 표시 속도가 훨씬 더 느려집니다.

2000 x 2000보다 큰 이미지를 사용해야 하는 경우 2000 제한을 충족하는 파일의 일부만 표시해야 합니다. 이렇게 하려면 이미지를 WriteableBitmap에 로드하고 LoadJpeg(WriteableBitmap, Stream) 확장 메서드를 사용합니다. 다음 코드는 큰 이미지를 로드하는 권장 방법을 보여 줍니다.

이 샘플을 다운로드합니다.

<StackPanel>
    <Image Height="3000" Width="3000" Name="image1" Stretch="Fill" />
    <Button Content="Load" Height="70" Width="152" Click="btnLoad_Click" />
</StackPanel>

private void btnLoad_Click(object sender, RoutedEventArgs e)
{
    StreamResourceInfo sri = null;
    Uri uri = new Uri("LoadJpegSample;component/Test3k3k.JPG", UriKind.Relative);
    sri = Application.GetResourceStream(uri);

    WriteableBitmap wb = new WriteableBitmap((int)this.image1.Width, (int)this.image1.Height);

    wb.LoadJpeg(wb, sri.Stream);
    this.image1.Source = wb;
}

WinPhonePerf_LoadingLargeImages

Windows Phone의 MediaElement는 Windows Phone 운영 체제의 일부인 네이티브 미디어 처리 및 하드웨어 디코더를 사용합니다. 이 때문에 미디어 처리 및 재생 방법에서 개발자가 알아야 하는 두 가지 차이점이 있습니다.

  • Windows Phone 에서는 재생 속도와 해상도가 제한됩니다.

  • 메모리 내 스트림이 재생에 최적화되지 않습니다.

최적 재생 속도와 해상도에 맞게 미디어 인코딩

wphone 에 필요한 최적 재생 속도와 해상도를 충족하도록 미디어를 인코딩해야 합니다. 지원되는 미디어 코덱과 최적 재생 속도 및 해상도의 전체 목록을 보려면 Windows Phone에 지원되는 미디어 코덱을 참조하세요.

미디어에 대해 빌드 작업을 콘텐츠로 설정

Windows Phone 의 미디어 처리는 메모리 내 스트림이 아니라 파일과 네트워크 스트림을 사용하도록 최적화됩니다. 즉, 사운드 효과와 같이 앱에 포함된 모든 미디어 파일의 빌드 작업리소스가 아니라 콘텐츠로 설정되어 있어야 합니다. 미디어 파일을 콘텐츠로 컴파일하면 앱 파일(.XAP)과 함께 느슨한 파일로 저장되며 파일 내에 저장되지 않습니다. 미디어 파일을 리소스로 컴파일하면 일반적으로 파일에 대한 스트림을 검색하여 액세스하므로 성능이 저하될 수 있습니다. 또한 콘텐츠로 컴파일된 미디어 파일을 재생하는 경우 바로 재생됩니다. 미디어 파일을 리소스로 컴파일하면 콘텐츠가 재생되기 전에 Windows Phone 의 파일에 복사되며 성능이 저하됩니다. 다음 그림은 Visual Studio에서 파일의 빌드 작업을 설정하는 방법을 보여 줍니다.

WinPhonePerf_BuildActionContent

메모리 내 스트림을 재생해야 하는 경우 MediaStreamSource의 구현을 제공할 수 있습니다. MediaElement의 구현을 제공할 수 없는 경우 다른 해결 방법은 격리된 저장소의 파일에 스트림을 저장하고 이 파일에서 액세스하는 것입니다.

화면에서 개체를 숨길 수 있는 두 가지 방법이 있습니다. Visibility 속성이나 Opacity 속성을 사용할 수 있습니다. 각 방법의 성능 특성을 이해하면 앱에서 전환을 최적화할 수 있습니다.

Visibility 속성

요소의 Visibility 속성을 Collapsed로 설정하면 XAML 에서 요소의 시각적 데이터를 시각적 메모리에 유지하지 않으며 요소와 관련된 처리를 수행하지 않습니다. 하지만 VisibilityVisible로 설정하여 요소를 다시 화면에 표시하는 경우 시각적 트리의 콘텐츠를 다시 그려야 합니다. 요소가 완전히 다시 그려집니다.

Opacity 속성 및 비트맵 캐싱

비트맵 캐싱을 사용할 때 요소의 Opacity 속성을 조작하여 앱의 성능을 향상시킬 수 있습니다. CacheMode 속성을 BitmapCache로 설정하여 비트맵 캐싱을 사용합니다. 비트맵 캐싱을 사용하면 첫 번째 렌더링 처리 단계 후 시각적 요소를 비트맵으로 저장할 수 있습니다. 요소가 캐시된 후 앱은 캐시된 시각적 요소에 대해 렌더링 단계를 생략하고 저장된 비트맵을 대신 표시합니다. 앱의 성능이 저하될 수 있으므로 캐싱을 사용하지 않고 Opacity를 조작하면 안 됩니다.

캐시된 요소의 Opacity를 0으로 설정하면 요소의 비트맵 표현이 메모리에 저장됩니다. 이 요소는 컴퍼지션 스레드에서 지원되지 않는 속성의 변경 내용이 없는 한 메모리에 유지됩니다. Opacity를 0이 아닌 값으로 다시 설정하면 표준 채우기 비율이 적용됩니다.

Visibility 및 Opacity 간 선택

일반적으로 비트맵 캐싱과 함께 Opacity 속성을 사용하여 성능을 향상시킵니다. 하지만 앱에 풍부한 시각적 요소가 여러 개 포함된 경우와 같이 Visibility 속성을 사용할 때 성능이 향상되는 경우도 있습니다. 사례별로 각 방법의 성능을 평가해야 합니다. 이렇게 하려면 VisibilityOpacity 속성을 전환하는 코드를 작성합니다.

개체 숨기기 샘플

이 샘플을 사용하면 OpacityVisibility 속성을 설정해 보고 앱에서 성능이 더 나은 속성을 확인할 수 있습니다.

이 샘플을 다운로드합니다.

이 샘플을 실행하면 애니메이션이 적용된 파란색 정사각형 1개, 애니메이션이 적용된 빨간색 정사각형 1개 및 직사각형 150개가 표시됩니다. 다음 버튼도 표시됩니다.

  • Opac x% - 직사각형의 Opacity를 지정한 백분율로 설정합니다.

  • Cache - 직사각형의 캐시 여부를 전환합니다. 기본값은 true입니다.

  • Collapse/Visible - 직사각형의 Visibility 속성을 전환합니다. 기본값은 Visible입니다.

이 샘플을 테스트하려면 다음 작업을 수행합니다.

  • 직사각형의 Visibility를 전환하고 Opacity를 변경합니다. Visibility에 비해 Opacity를 변경할 때 직사각형이 훨씬 더 빨리 표시됩니다. 또한 Opacity가 0이 아닌 값이면 애니메이션이 느려집니다. 이것은 150개의 직사각형이 채우기 비율에 영향을 주기 때문입니다.

  • 캐시를 사용하지 않고 직사각형을 조작합니다. 직사각형이 채우기 비율에 영향을 주지 않기 때문에 정사각형의 애니메이션이 원활하게 작동합니다. 또한 Opacity를 설정하거나 Visibility를 전환할 때 직사각형을 표시하는 데 걸리는 시간에 차이가 없습니다. 이것은 캐싱을 사용하지 않을 경우 항상 직사각형을 다시 그려야 하기 때문입니다.

WinPhonePerf_HidingObjects

Windows Phone 의 사용자 입력에는 조작 이벤트, 마우스 이벤트 및 터치 이벤트가 포함됩니다.

조작 이벤트 사용

조작 이벤트는 사용자 입력을 처리하는 권장 방법입니다. 특정 요구가 없는 한 마우스 이벤트는 성능 및 하드웨어 호환성 때문에 Windows Phone 앱에서 사용하지 않는 것이 좋습니다. 대신 조작 이벤트를 사용해야 합니다. 기본 컨트롤과 같은 UIElement에서 파생된 임의 요소에 Tap, DoubleTapHold 이벤트를 사용할 수도 있습니다.

Touch 클래스는 개별 터치 접촉 지점을 가져오는 데 사용되는 FrameReported 이벤트를 제공합니다. 이 이벤트는 Windows Phone 에서 지원되지만 손가락 모았다 펴기와 같은 제스처를 처리하는 경우 사용하지 않는 것이 좋습니다. 개별 터치 접촉 지점이 필요하지 않은 경우 조작 이벤트를 사용해야 합니다.

조작 이벤트를 사용하는 방법에 대한 자세한 내용은 Windows Phone의 조작 이벤트 처리 방법을 참조하세요.

시간이 오래 걸리는 작업을 수행하는 경우 진행률 표시기를 사용하여 앱이 작동 중임을 사용자에게 표시해야 합니다. 진행률을 표시하려면 다음 컨트롤 중 하나를 사용하면 됩니다.

  • ProgressIndicator를 사용하여 시스템 트레이에 진행률 표시기를 표시할 수 있습니다. 기본 제공 앱은 보통 ProgressIndicator를 사용합니다.

  • Visual Studio 도구 상자에서 진행률 표시줄 컨트롤을 사용할 수 있습니다. 이 컨트롤을 사용하는 방법에 대한 자세한 내용은 ProgressBar 클래스를 참조하세요.

Windows Phone SDK 7.1을 사용하여 개발하는 경우 ProgressBar 대신 PerformanceProgressBar 사용

Windows Phone SDK 7.1 을 사용 중인 경우 Visual Studio 도구 상자의 진행률 표시줄을 사용하여 미정 진행률을 보고하면 앱의 성능이 저하될 수 있습니다. Windows Phone SDK 8.0 에서는 ProgressBar 클래스가 업데이트되었으며 도구 상자의 진행률 표시줄을 사용해도 Windows Phone 8 에서 앱의 성능이 저하되지 않습니다.

Windows Phone SDK 7.1 의 ProgressBar 성능 문제를 해결하기 위해 Microsoft는 PerformanceProgressBar라는 지원되지 않는 대체 방법을 만들었습니다. PerformanceProgressBar는 UI 스레드에서 작성자 스레드로 애니메이션을 이동합니다. 자세한 내용은 사용자 지정 미정 진행률 표시줄 추가를 참조하세요.

Windows Phone 8 에는 LongListSelector를 사용하여 항목 목록을 표시하는 옵션이 있고 ListBox 컨트롤에 비해 이 컨트롤을 사용하는 것이 좋습니다.

배터리 수명을 유지하기 위해 운영 체제는 미리 구성된 제한 시간 간격 후에 장치 라디오를 끕니다. 앱이 적은 데이터를 자주 요청하는 경우 직렬 방식이 아니라 병렬 방식으로 이러한 요청을 실행하는 것이 좋습니다. 그러면 장치의 라디오 스택이 절전 모드로 전환되지 않으므로 각 요청에 대해 라디오를 켜고 끌 때 발생하는 지연을 방지할 수 있습니다.

앱을 로드하고 시작할 때 성능을 향상시키기 위해 수행할 수 있는 여러 작업이 있습니다. 이 섹션에서는 이러한 항목에 대해 설명합니다.

시작 화면 사용

다운로드가 완료될 때까지 앱이 표시되지 않더라도 특정 리소스를 미리 로드하여 앱이 상호 작용을 시작하기 전에 사용할 수 있어야 한다는 것이 앱 설계의 요구 사항일 수도 있습니다. 시작 화면은 다른 콘텐츠가 로드되는 동안 사용자에게 표시할 수 있는 초기 콘텐츠 영역입니다.

주의주의:

일반적으로 Windows Phone 8 앱은 매우 빠르게 시작되고 시작 화면이 필요하지 않습니다.

Windows Phone SDK 7.1 프로젝트 템플릿에는 SplashScreenImage.jpg라는 기본 시작 화면 이미지가 포함되어 있습니다. 이 이미지는 앱을 시작하는 동안 자동으로 표시됩니다. Windows Phone SDK 7.1 프로젝트 템플릿에서 제공된 기본 시작 화면 이미지를 수정하거나 시작 화면을 Windows Phone SDK 8.0 프로젝트에 추가할 수 있습니다. 고유한 이미지를 만들어서 앱에 대한 고지 사항과 같은 브랜딩 및 제품 정보를 표시합니다.

시작 화면을 사용자 지정하려면 기본 이미지를 사용자 지정 이미지로 대체합니다. 기본 이미지를 선택한 이미지로 바꿀 수 있지만 이미지는 올바른 크기여야 하고 이름이 SplashScreenImage.jpg여야 합니다. 앱에 대한 고지 사항이나 기타 정보와 같은 브랜딩 및 제품 정보를 표시할 수 있습니다. Windows Phone OS 7.1 앱의 경우 시작 화면 이미지 크기가 480 × 800 픽셀이어야 합니다. Windows Phone 8 앱의 경우 이미지 크기가 768 × 1280 픽셀이어야 합니다. 이미지 크기는 앱을 실행 중인 휴대폰의 올바른 해상도에 맞게 조정됩니다. 또한 이미지의 빌드 작업 속성을 콘텐츠로 설정해야 합니다.

시작 화면을 추가하거나 수정하는 방법에 대한 자세한 내용은 Windows Phone의 시작 화면을 만드는 방법을 참조하세요.

다른 옵션은 앱이 빨리 시작되고 있다는 인상을 주기 위해 앱의 첫 페이지에 대한 화면 캡처를 표시하는 것입니다. 앱의 화면 캡처를 시작 화면에 사용하려는 경우 화면 캡처를 생성할 때 다음을 고려합니다.

  • 앱을 실행할 때 변경되는 데이터를 숨깁니다.

  • 에뮬레이터가 100% 배율로 설정되었는지 확인합니다.

  • 이미지를 잘라 에뮬레이터 크롬을 제거합니다.

  • 이미지가 올바른 크기이고 SplashScreenImage.jpg로 저장되었는지 확인합니다.

로드하는 데 시간이 오래 걸리는 앱의 경우 애니메이션 효과가 적용된 시작 화면을 만들어서 앱 실행을 준비하는 동안 진행률을 표시하는 것이 좋습니다.

로드 시간을 지연시키지 않고 시작 화면에 중요한 정보를 표시하려는 경우 초기 화면을 시작 화면의 복제본으로 만듭니다. 예를 들어 페이지에 대한 OnNavigatedTo(NavigationEventArgs) 메서드를 재정의하고 동일한 시작 화면 이미지가 포함된 팝업을 만들어 시작 화면을 표시하려는 시간 동안 표시할 수 있습니다.

앱 어셈블리의 크기 최소화

앱 시작을 향상시킬 수 있는 다른 방법은 앱 어셈블리의 크기를 최소화하는 것입니다. 앱을 Windows Phone 스토어 에 제출하면 확인 용도로 서명되고 앱을 시작할 때마다 서명이 확인됩니다. 어셈블리 서명을 확인하는 데 걸리는 시간은 앱 어셈블리의 크기가 증가할 수록 늘어납니다. 이후에 앱을 로드할 때는 서명이 캐시되었으므로 서명 확인의 영향이 제한되지만 앱을 처음 로드할 때는 여전히 영향을 받습니다. 다음은 어셈블리 크기를 줄이는 몇 가지 팁입니다.

  • 가능한 경우 빌드 작업을 리소스로 설정하여 이미지, 미디어, XML 파일 등의 리소스를 어셈블리에 포함하지 않도록 합니다. 대신 이러한 파일의 빌드 작업을 콘텐츠로 설정합니다.

  • 선행 슬래시를 사용하여 이미지의 소스 URI 경로를 설정합니다(예: "/folder/myImage.jpg").

  • 투명도가 필요하지 않은 경우 PNG 이미지 대신 JPG 이미지를 사용합니다.

  • 앱을 지역화하는 경우 지역화된 리소스를 기본 앱 어셈블리에 포함하지 않도록 합니다. 대신 각 언어에 대해 위성 어셈블리를 만듭니다. 자세한 내용은 Windows Phone에 지역화된 앱 빌드 방법를 참조하세요.

참고참고:

다시 사용 가능한 컨트롤이나 구성 요소를 만드는 경우 빌드 작업을 리소스로 설정하여 리소스를 앱에 포함해야 합니다. 이 경우 이미지와 리소스 사용을 줄여야 합니다.

앱을 작은 어셈블리로 분할

시작 시간을 최소화하기 위해 앱을 필요한 경우에만 로드되는 작은 어셈블리로 나눌 수 있습니다. 이렇게 하려면 요청 시 로드될 페이지를 포함할 새 Windows Phone 클래스 라이브러리 프로젝트를 앱에 추가합니다. 그런 다음 필요에 따라 Windows Phone 페이지를 프로젝트에 추가하고 기본 앱 프로젝트에서 클래스 라이브러리 프로젝트를 참조합니다. 사용자가 페이지 간에 이동할 수 있도록 하이퍼링크 버튼을 사용하거나 이벤트를 추가할 수 있습니다. 다음 코드 예제에서는 PageInExternalAssembly 어셈블리에 있는 ExternalPage.xaml이라는 페이지를 탐색하는 방법을 보여 줍니다.

이 샘플을 다운로드합니다.

private void button1_Click(object sender, RoutedEventArgs e)
{
     // Use the name of the separate assembly when generating the Uri for the page
     NavigationService.Navigate(new Uri("/PageInExternalAssembly;component/ExternalPage.xaml", 
           UriKind.Relative));
}

생성자 및 로드된 이벤트의 코드 최소화

페이지에 대한 Loaded 이벤트 처리기의 생성자와 코드는 모두 앱의 첫 프레임이 표시되기 전에 실행됩니다. 페이지 및 컨트롤 생성자는 XAML을 구문 분석하고 XAML로 선언된 개체를 인스턴스화하므로 시간이 오래 걸릴 수 있습니다. 이 때문에 이러한 메서드에서는 다른 장기 실행 작업을 제한해야 합니다. 파일을 로드하거나 부담이 큰 다른 처리를 수행해야 하는 경우 이후 이벤트에서 수행하거나 백그라운드 스레드에 예약해야 합니다. 이렇게 하는 한 가지 방법은 OnNavigatedTo(NavigationEventArgs)를 재정의하고 이 메서드에서 장기 실행 프로세스를 시작하는 것입니다. OnNavigatedTo는 페이지가 활성 페이지가 될 때 호출됩니다. 다음 예제에서는 이 작업을 수행하는 방법을 보여 줍니다.

protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
    // Do lengthy page initialization in a new 
    // thread so the UI can continue to update.
    System.Threading.Thread startupThread = 
        new System.Threading.Thread(new System.Threading.ThreadStart(initializePage));
    startupThread.Start();
}

void initializePage()
{
    // Do lengthy page initialization here...
}

격리된 저장소 사용 모니터링

ApplicationSettings 개체는 개체를 처음 사용할 때(일반적으로 앱을 시작할 때) 저장소에서 할당되고 역직렬화되는 singleton입니다. 앱에 도우미 속성을 만들어 ApplicationSettings에 액세스하고 도우미 속성에 타이머를 배치하여 앱 설정을 역직렬화하는 데 걸리는 시간을 측정할 수 있습니다. 데이터 역직렬화 작업을 완료하는 데 100밀리초 이상 걸리는 경우 백그라운드 스레드의 호출로 이동해야 합니다.

격리된 저장소의 데이터로 페이지를 채우는 경우 데이터를 포함할 ObservableCollection<T> 개체를 할당하고 컬렉션을 UI의 요소에 바로 바인딩해야 합니다. 그런 다음 ObservableCollection 개체에 격리된 저장소의 데이터를 채워야 합니다. 필요한 경우 BeginInvoke(Action) 메서드를 사용하여 데이터 채우기를 여러 호출로 나눌 수 있습니다.

UI 스레드 차단 방지

UI 스레드를 차단하여 앱 시작을 연기할 수 있는 여러 가지 방법이 있습니다. 위치 서비스, 푸시 알림, 네트워크 정보, 라디오 등의 서비스와 API는 UI 스레드를 차단할 수 있습니다.

위치 서비스

Windows Phone 이 시작된 후 PositionChanged 이벤트가 GeoCoordinateWatcher에서 발생하는 데 몇 초 정도 걸릴 수 있습니다. DesiredAccuracy에 대한 설정에 따라 PositionChanged 이벤트가 처음 발생하기 전에 3-13초가 경과할 수 있습니다. 이것은 위치 서비스에서 서비스를 시작하고, 위성을 찾고, 기타 작업을 수행하는 데 걸리는 시간 때문입니다. Windows Phone 이 이미 실행되고 있으면 이 작업은 그리 오래 걸리지 않으며 PositionChanged 이벤트가 500밀리초 전에 발생합니다. 위치 이벤트 발생을 사용하는 호출이 있는 경우 UI 스레드를 차단하여 앱 시작을 연기할 수 있습니다. 위치 서비스를 사용하는 방법에 대한 자세한 내용은 Windows Phone 8의 위치를 참조하세요.

푸시 알림

Microsoft 푸시 알림 서비스를 사용하면 웹 서비스에서 앱의 업데이트를 받을 수 있습니다. 푸시 알림 서비스에 대한 일부 호출이 반환되는 데 오랜 시간이 걸릴 수 있으므로 푸시 알림 API는 비동기적입니다. UI 스레드가 푸시 알림 서비스에 대한 호출이 반환되기를 기다리는 상황은 항상 피해야 합니다. 예를 들어 UI 스레드에서 푸시 알림 서비스에 대한 채널을 만들고 열 수 있지만 UI 스레드가 이 이벤트의 발생을 기다리는 상황은 만들지 않는 것이 좋습니다. 자세한 내용은 Windows Phone의 푸시 알림을 참조하세요.

네트워크 정보

Windows Phone 이 시작될 때 GetIsNetworkAvailable()에 대한 첫 번째 호출이 반환되는 데 최대 20초 정도 걸릴 수 있습니다. 이것은 Windows Phone 에서 처음에 사용 가능한 모든 네트워크 연결을 열거하기 때문입니다.

라디오

Windows Phone 이 시작될 때 FMRadio 클래스에 대한 호출이 반환되는 데 최대 3초 정도 걸릴 수 있습니다. 라디오를 초기화한 후에는 이러한 호출이 반환되는 데 걸리는 시간이 100밀리초까지 줄어듭니다. UI 스레드에서 라디오를 설정하거나 조정하면 안 됩니다. 대신 백그라운드 스레드를 사용하여 이 작업을 수행해야 합니다. 자세한 내용은 이 항목의 뒷부분에 있는 백그라운드 스레드 및 비동기 프로그래밍 섹션을 참조하세요.

Windows Phone 의 그래픽 스레드 아키텍처는 장치에 최적화되었습니다. Windows Phone 은 UI 스레드 외에도 컴퍼지션 스레드를 지원합니다. Windows Phone 의 성능을 최적화하는 방법을 이해하려면 Windows Phone 의 두 가지 기본 스레드와 백그라운드 스레드 사용 방법을 이해해야 합니다.

UI 스레드

UI 스레드는 Windows Phone 의 기본 스레드입니다. 다음은 UI 스레드에서 처리되는 작업 목록입니다.

  • XAML에서 개체를 구문 분석하고 만듭니다.

  • 처음 그릴 때 모든 시각적 요소를 그립니다.

  • 프레임당 콜백을 처리하고 다른 사용자 코드를 실행합니다.

간단한 UI 스레드 유지는 응답이 빠른 앱 개발의 관건입니다.

컴퍼지션 스레드

컴퍼지션 스레드는 일반적으로 UI 스레드가 처리하는 일부 작업을 처리하므로 Windows Phone 앱의 성능을 향상시킵니다. 컴퍼지션 스레드는 그래픽 질감을 결합하고 그리기를 위해 GPU에 전달합니다. 또한 컴퍼지션 스레드에서 실행되는 Windows Phone 스토리보드 기반 애니메이션은 장치의 GPU에서 자동 캐싱이라는 프로세스를 통해 자동으로 캐시되고 처리됩니다.

컴퍼지션 스레드는 RenderTransformProjection 속성과 연결된 단순 애니메이션을 처리합니다. 다음 목록은 일반적으로 컴퍼지션 스레드가 처리하는 애니메이션을 보여 줍니다.

참고참고:

컴퍼지션 스레드를 사용하려면 배율 변환이 원본 크기의 50% 미만이어야 합니다.

또한 OpacityClip 속성 설정이 컴퍼지션 스레드에서 처리됩니다. 하지만 Opacity 마스크나 직사각형이 아닌 클립을 사용하는 경우 이러한 작업이 UI 스레드에 전달됩니다.

애니메이션 및 스레드

앞에서 언급했듯이 스토리보드 기반 애니메이션은 컴퍼지션 스레드에서 처리됩니다. 이 동작은 컴퍼지션 스레드가 처리를 위해 이러한 작업을 GPU에 전달하기 때문에 적절합니다. 또한 CPU가 오버로드된 경우 컴퍼지션 스레드가 UI 스레드보다 자주 실행될 수 있습니다. 하지만 스토리보드 애니메이션이 앱의 요구 사항을 충족하지 않는 경우가 있습니다. 이 경우 코드에서 애니메이션을 구동할 수 있습니다. 이러한 애니메이션은 프레임 단위로 처리됩니다. 대부분의 경우 이 처리 방식도 괜찮지만 프레임당 콜백에서 애니메이션을 실행할 경우 어떤 영향이 있는지 알아야 합니다.

프레임당 콜백은 엄격하게 UI 스레드에서 처리됩니다. 애니메이션은 UI 스레드가 처리할 수 있는 속도로만 업데이트되며, 앱에서 수행 중인 다른 작업에 따라 애니메이션이 컴퍼지션 스레드에서 실행되는 경우보다 덜 부드럽게 표시될 수도 있습니다. 또한 코드에서 애니메이션을 업데이트하는 경우 스토리보드에서 업데이트되는 경우처럼 요소가 자동으로 캐시되지 않습니다. 수동으로 이러한 요소에 비트맵 캐시를 배치하면 변환 및 혼합이 GPU에 전달되지만 애니메이션은 여전히 프레임당 콜백에서 업데이트되고 UI 스레드에서 처리됩니다. 이 경우 애니메이션이 UI 스레드의 프레임 속도로만 업데이트됩니다.

백그라운드 스레드 및 비동기 프로그래밍

UI 스레드를 차단하는 복잡한 프로세스를 방지하기 위해 백그라운드 스레드라는 보조 스레드에 처리를 오프로드하고 이 처리를 비동기적으로 수행할 수 있습니다. 예를 들어 웹 서비스 API는 UI 스레드를 차단하지 않도록 모두 비동기적으로 사용되도록 설계되었습니다. 백그라운드 스레드를 사용하는 경우 백그라운드 스레드의 데이터를 다시 UI 스레드로 이동하는 메커니즘을 제공해야 합니다. 이렇게 하려면 공유 변수 및 데이터를 이동하는 이벤트를 사용하거나 BeginInvoke(Action) 메서드를 사용하여 UI 스레드에 알림을 보냅니다. 또는 BackgroundWorker 클래스와 해당 이벤트 기반 메커니즘을 비동기 처리에 사용할 수 있습니다. 자세한 내용은 Windows Phone의 백그라운드 작업자 사용 방법을 참조하세요.

앱의 성능을 모니터링하고 성능 문제를 식별할 수 있는 여러 가지 방법이 있습니다. 한 가지 방법은 앱의 메모리 사용을 모니터링하는 것입니다. 영역 다시 그리기와 캐시 시각화의 색 입히기를 사용하도록 설정하여 이러한 요소가 앱에서 사용되는 방식을 시각적으로 모니터링할 수 있습니다. Windows Phone 에뮬레이터에서 사용 가능한 프레임 속도 카운터를 켤 수도 있습니다. 프레임 속도 카운터를 사용하면 앱의 다양한 성능 측면을 모니터링할 수 있습니다. 다음 섹션에서는 이러한 기능을 사용하는 방법에 대해 설명합니다.

메모리 사용 모니터링

앱의 메모리 사용을 모니터링해야 합니다. 이렇게 하려면 DeviceStatus API의 여러 속성을 호출합니다. 자세한 내용은 Windows Phone의 단말기 상태를 참조하세요. Windows Phone 스토어 테스트 키트를 사용하여 앱의 전체 메모리 사용을 평가할 수도 있습니다. 자세한 내용은 Windows Phone 스토어 테스트 키트를 참조하세요.

영역 다시 그리기 사용

Windows Phone 에뮬레이터에서 영역 다시 그리기를 사용하도록 설정하여 그려지는 앱 영역을 시각적으로 확인할 수 있습니다. 페이지 구성에서 EnableRedrawRegions 속성을 true로 설정합니다. 다음 코드와 같이 이 속성은 현재 앱 설정을 통해 액세스할 수 있습니다.

Application.Current.Host.Settings.EnableRedrawRegions = true;

이제 앱을 실행하고 영역이 완전히 그려지면 색으로 음영이 표시됩니다. 색이 지정된 영역은 GPU가 아니라 CPU를 사용하여 그리기가 수행되었음을 나타냅니다. CPU를 사용하여 그리는 경우 소프트웨어 그리기라고 합니다. 처음 표시될 때 소프트웨어가 모든 항목을 그려야 하기 때문에 소프트웨어 그리기는 정상적인 동작이지만 과도한 소프트웨어 그리기를 확인해야 합니다. 앱에 모든 프레임을 변경하는 깜박이는 색이 포함되어 있는 경우 해당 요소에 비트맵 캐싱을 사용해야 합니다.

캐시 시각화 사용

캐시 시각화를 사용하도록 설정하여 사용 중이고 컴퍼지션 스레드에 전달되는 그래픽 질감을 시각적으로 확인할 수 있습니다. 컴퍼지션 스레드는 이러한 그래픽 질감을 GPU에 전달합니다. 이렇게 하려면 페이지 생성자에서 EnableCacheVisualization 속성을 true로 설정합니다. 다음 코드와 같이 이 속성은 현재 앱 설정을 통해 액세스할 수 있습니다.

Application.Current.Host.Settings.EnableCacheVisualization = true;

캐시 시각화를 사용하도록 설정하면 앱의 각 질감에 파란색과 투명도가 적용됩니다. 이 경우 앱의 다양한 질감과 질감이 겹치는 위치를 확인할 수 있습니다. 파란색의 가장 어두운 음영은 여러 질감이 겹치는 영역을 나타냅니다. 높은 채우기 비율에 영향을 줄 수 있는 앱의 숨겨진 개체를 확인할 수 있습니다. Windows Phone 캐시 시각화는 다른 플랫폼의 캐시 시각화와 약간 다릅니다. 다른 플랫폼에서는 색조 영역이 개발자가 명시적으로 캐시하지 않은 질감을 나타냅니다. 하지만 Windows Phone 에서는 각 색조 영역이 컴퍼지션을 위해 GPU에 전달된 질감을 나타냅니다. 이 경우 앱이 시각적으로 더 복잡해지면 GPU의 기능을 초과할 수 있기 때문에 모니터링해야 합니다.

캐시 시각화를 사용하도록 설정하면 GPU가 추가 작업을 수행해야 하며 이로 인해 프레임 속도가 저하될 수 있으므로 이 플래그를 사용하는 경우 프레임 속도 카운터에 의존하면 안 됩니다.

프레임 속도 카운터 사용

Windows Phone 에뮬레이터는 앱을 개발하는 동안 성능을 모니터링할 수 있도록 프레임 속도 카운터를 제공합니다. 다음 코드와 같이 디버거를 연결하면 App 생성자에서 프레임 속도 카운터가 기본적으로 사용하도록 설정됩니다.

// Show graphics profiling information while debugging.
if (System.Diagnostics.Debugger.IsAttached)
{
    // Display the current frame rate counters.
    Application.Current.Host.Settings.EnableFrameRateCounter = true; 
참고참고:

프레임 속도 카운터를 보기 위해 SystemTray.IsVisible 속성을 false로 설정해야 할 수도 있습니다.

다음 그림에서는 프레임 속도 카운터를 보여 줍니다.

Frame Rate Counters with Labels

다음 표에서는 각 프레임 속도 카운터에 대해 설명합니다.

카운터

설명

컴퍼지션 스레드 프레임 속도

이 값은 화면이 업데이트되는 속도를 나타냅니다. 또한 스토리보드에서 구동된 지원되는 애니메이션이 업데이트되는 빈도를 나타냅니다. 이 값은 가능한 한 60에 가까워야 합니다. 이 값이 30 미만이면 앱 성능이 저하되기 시작합니다. 이 카운터의 텍스트가 30 미만의 값을 표시할 때는 빨간색입니다.

UI 스레드 프레임 속도

이 값은 UI 스레드가 실행되는 속도를 나타냅니다. UI 스레드는 입력, 프레임당 콜백 및 컴퍼지션 스레드에서 처리되지 않는 다른 모든 그리기를 구동합니다. 이 값이 클수록 앱의 응답 성능이 향상됩니다. 일반적으로 사용자 입력에 대한 응답 시간이 허용되는 수준이려면 이 값이 20보다 커야 합니다. 이 카운터의 텍스트가 15 미만의 값을 표시할 때는 빨간색입니다.

질감 메모리 사용

이 값은 앱에서 사용되는 질감의 동영상 메모리 및 시스템 메모리 복사본을 나타냅니다. 이것은 앱의 일반 메모리 카운터가 아니라 화면에서 사용하는 메모리만 나타냅니다.

화면 카운터

이 값은 처리를 위해 GPU에 전달되는 명시적 화면의 원시 개수를 제공합니다. 이 개수에 가장 큰 영향을 주는 요인은 자동 요소나 개발자가 캐시한 요소입니다.

중간 화면 카운터

이 값은 캐시된 화면의 결과로 생성되는 암시적 화면을 나타냅니다. 이러한 화면은 앱이 UI에서 요소의 Z 순서를 정확하게 유지할 수 있도록 UI 요소 간에 생성됩니다.

채우기 비율 카운터

이 값은 화면 측면에서 프레임당 그려지는 픽셀 수를 나타냅니다. 값 1은 480 x 800 픽셀을 나타냅니다. 권장 값은 약 2.5입니다. 이 카운터의 텍스트가 3을 초과하는 값을 표시할 때는 빨간색으로 바뀝니다.

채우기 비율 모니터링

채우기 비율은 각 프레임의 컴퍼지션을 위해 GPU에 전달되는 그래픽 질감의 픽셀 수입니다. 채우기 비율은 근본적으로 GPU에서 수행하는 작업량을 측정한 값입니다. 이 때문에 GPU 기능을 쉽게 초과하여 프레임 속도가 저하될 수 있으므로 앱의 채우기 비율에 주의해야 합니다. 앱의 채우기 비율이 2개 화면(800x480)의 픽셀을 초과하면 프레임 속도가 저하되기 시작합니다. 일반적으로 프레임 속도의 저하는 채우기 비율이 약 3.5개 화면의 픽셀에 도달할 때까지 사용자에게 표시되지 않습니다. 프레임 속도 카운터의 마지막 숫자를 보고 앱의 채우기 비율을 확인할 수 있습니다. 또한 UI 스레드의 프레임 속도는 컴퍼지션 스레드의 프레임 속도를 초과하지 않으므로 채우기 비율이 너무 높으면 앱의 전체 성능에 영향을 주게 됩니다.

채우기 비율에 대한 영향

질감이 필요한 모든 그래픽 개체가 앱의 채우기 비율에 영향을 줍니다. 질감의 픽셀 수가 많을수록 채우기 비율이 더 높습니다. 일반적으로 채우기 비율에 영향을 주는 두 가지 주요 요인이 있습니다. 첫 번째 요인은 캐시되지 않은 모든 항목을 둘러싸는 직사각형인 기본 화면입니다. 두 번째 요인은 캐시되는 모든 항목으로, 컴퍼지션 스레드에서 자동으로 캐시되는 질감과 개발자가 요소의 BitmapCache를 설정하여 캐시하는 요소를 포함합니다. 컴퍼지션 스레드에서 캐시되는 질감뿐 아니라 다음 요소도 자동으로 캐시됩니다.

권장 프레임 속도 및 채우기 비율

다음 표에서는 앱의 성능을 조정할 때 확인해야 하는 카운터의 권장 임계값과 상한값을 보여 줍니다. 에뮬레이터 성능은 각각 다르기 때문에 실제 Windows Phone 장치에서 이러한 카운터를 테스트하는 것이 중요합니다. 스레드에서 처리 중인 애니메이션이 없는 경우 카운터 업데이트가 중지될 수도 있습니다. 항상 카운터 값을 확인하려는 경우 개발 및 테스트 중에 간단한 반복 애니메이션을 앱에 추가할 수 있습니다. 앱을 릴리스하기 전에 애니메이션을 제거할 수 있습니다.

카운터

빨간색 값 임계값*

권장 값

상한값

컴퍼지션 스레드 프레임 속도

30 프레임/초

45 프레임/초

60 프레임/초

UI 스레드 프레임 속도

15 프레임/초

30 프레임/초

60 프레임/초

화면 채우기 비율

>3

<= 2.5

3.0

*카운터가 특정 임계값에 도달하면 빨간색이 됩니다. 빨간색 값은 잠재적 성능 문제가 있음을 나타냅니다.

채우기 비율 테스트 샘플

이 샘플을 사용하면 애니메이션 효과가 적용된 직사각형을 추가하고 제거하여 채우기 비율에 미치는 영향을 확인할 수 있습니다. 각 직사각형은 화면 크기의 1/8이며 애니메이션 효과가 적용되었기 때문에 질감 한 개를 나타냅니다.

이 샘플을 다운로드합니다.

이 샘플을 실행하면 다음 세 개의 버튼이 표시됩니다.

  • Add - 직사각형을 추가합니다.

  • Dlt - 직사각형을 삭제합니다.

  • Hide - Hide and Add 버튼을 숨기고 Dlt 버튼을 Show로 변경합니다.

또한 오른쪽 위에 숫자 두 개가 표시됩니다. 첫 번째 숫자는 단일 직사각형의 픽셀 수를 화면 단위로 나타내고, 두 번째 숫자는 총 픽셀 수를 화면 단위로 나타냅니다(채우기 비율).

이 샘플을 테스트하려면 다음 작업을 수행합니다.

  • 채우기 비율이 2를 초과할 때까지 직사각형을 추가하고 프레임 속도가 저하되는 것을 확인합니다.

  • 프레임 속도가 45에서 60 사이가 될 때까지 직사각형을 추가합니다 Hide 버튼을 탭한 다음 프레임 속도가 증가하고 채우기 비율이 감소하는 것을 확인합니다. 이것은 버튼이 포함된 화면이 축소되었기 때문입니다. 맨 아래의 버튼 두 개가 사라지면 버튼이 표시될 때 90%였던 것과 달리 화면이 전체 화면의 약 10%까지만 아래로 늘어납니다. 화면이 다시 커지면 Show 버튼을 탭하여 프레임 속도를 줄입니다.

WinPhonePerf_FillRateTest

원근감 채우기 비율 샘플

이 샘플을 사용하면 평면 프로젝션 또는 원근감 변환이 앱 성능에 미치는 영향을 확인할 수 있습니다. 디자이너에서 생성된 XAML에는 멋진 시각적 효과를 만들지만 앱 성능에 영향을 주는 많은 원근감 변환이 포함된 경우가 많습니다. 이 샘플에서는 원근감 및 애니메이션의 캐싱 동작을 보여 줍니다. 애니메이션이 없는 원근감 변환은 자동으로 캐시되므로 애니메이션을 추가해도 성능에 더 이상 영향을 주지 않습니다. 하지만 원근감 변환이 없는 직사각형에 애니메이션을 추가하면 영향을 주게 됩니다.

이 샘플을 다운로드합니다.

이 샘플을 실행하면 다음 네 개의 버튼이 표시됩니다.

  • Add - 임의의 직사각형을 추가합니다.

  • Dlt - 최근 직사각형을 삭제합니다.

  • Persp - 직사각형에 원근감 변환이 적용되는지 여부를 전환합니다.

  • Animate - 직사각형에 애니메이션 효과가 적용되는지 여부를 전환합니다.

이 샘플을 테스트하려면 다음 작업을 수행합니다.

  • 가운데 정사각형의 애니메이션이 끊어지기 시작할 때까지 직사각형을 여러 개 추가하고 원근감 버튼을 전환합니다. 직사각형이 더 이상 캐시되지 않으므로 끊김이 사라집니다. 직사각형은 페이지의 버튼 및 텍스트와 단일 화면을 공유합니다. 원근감을 적용하는 즉시 자동으로 각 직사각형에 배치됩니다. 직사각형은 채우기 비율에 영향을 주는 화면을 추가합니다.

  • 가운데 정사각형의 애니메이션이 끊어지기 시작할 때까지 직사각형을 여러 개 추가합니다. Animate 버튼을 탭하고 끊김이 증가하지 않는 것을 확인합니다. 애니메이션이 없는 원근감은 자동으로 이미 캐시되었으므로 원근감에 애니메이션을 적용해도 추가 질감이 생성되지 않습니다. 원근감이 없는 직사각형에서 애니메이션을 전환하는 동작과 이 동작을 비교합니다. 원근감이 적용되지 않고 정사각형 외에 애니메이션이 없는 경우 직사각형을 원하는 개수만큼 추가해도 정사각형 애니메이션에 영향을 주지 않습니다. 이러한 직사각형은 캐시되지 않으므로 모두 텍스트 및 버튼과 동일한 화면을 공유합니다. 하지만 직사각형에 애니메이션 효과를 적용하는 즉시 자동 비트맵 캐시가 직사각형에 배치되며, 직사각형의 각 질감 영역에 대해 채우기 비율이 즉시 증가합니다.

WinPhonePerf_PerspectiveFillRate

프레임당 콜백 샘플

이 샘플을 사용하면 프레임당 콜백과 스토리보드 기반 애니메이션을 사용하여 애니메이션 효과를 적용할 경우의 영향을 비교할 수 있습니다.

이 샘플을 다운로드합니다.

이 샘플을 실행하면 스토리보드를 사용하여 애니메이션 효과가 적용되어 컴퍼지션 스레드에서 실행 중인 작은 파란색 정사각형과 다음 5개 버튼이 표시됩니다.

  • Add - 화면 크기의 1/8이고 프레임당 콜백을 사용하여 애니메이션 효과가 적용된 직사각형을 추가합니다.

  • Dlt - 최근 직사각형을 삭제합니다.

  • Redraw - EnableRedrawRegions 디버그 플래그를 전환합니다.

  • Cache - 직사각형에 수동 비트맵 캐시가 적용되는지 여부를 전환합니다. 기본값은 true입니다.

  • Hide/Show - 화면 맨 아래에 버튼을 표시할지 여부를 전환합니다.

이 샘플을 테스트하려면 다음 작업을 수행합니다.

  • 파란색 정사각형과 직사각형이 눈에 띄게 끊어질 때까지 직사각형을 여러 개 추가합니다. 이것은 수동 캐시가 적용되었기 때문입니다. 수동 캐시 때문에 작성자 스레드에서 정사각형에 애니메이션 효과가 적용되고, UI 스레드에서 직사각형에 애니메이션 효과가 적용됩니다. 두 스레드는 모두 각 프레임에 대한 직사각형을 그리는 채우기 비율에 의해 바인딩됩니다.

  • 직사각형에 대해 수동 캐시를 끄는 Cache 버튼을 전환합니다. 정사각형에 애니메이션 효과가 부드럽게 적용되기 시작하지만 직사각형은 더 많이 끊어집니다. 이것은 캐시가 적용되지 않아 이제 UI 스레드가 각 프레임에 대한 직사각형을 그리기 때문입니다. 한편, 컴퍼지션 스레드는 더 이상 직사각형 질감을 처리하지 않으므로 정사각형에 애니메이션 효과가 부드럽게 적용됩니다. 직사각형을 캐시하지 않는 경우 질감이 메모리에 유지되지 않습니다. 직사각형 위치를 업데이트할 때마다 픽셀이 처음부터 다시 그려집니다. 이 고비용 작업은 CPU를 통해 UI 스레드에서 수행됩니다. 한편, 간단한 컴퍼지션 스레드는 비록 직사각형에서 많은 CPU가 사용되지만 60 프레임/초 속도로 정사각형을 업데이트할 수 있습니다.

  • 다시 그리기 및 캐시 버튼을 사용하여 계속 실험합니다. 영역 다시 그리기를 사용하는 경우 직사각형을 캐시하면 직사각형이 깜박이지 않습니다. 깜박임은 개체가 프레임마다 처음부터 다시 그려지는 것을 의미하며 피해야 합니다. 직사각형을 캐시하지 않으면 프레임마다 직사각형에 새 색조가 적용되고 깜박임이 표시됩니다. 이 경우 정사각형이 스토리보드 애니메이션으로 구동되며 자동으로 캐시되기 때문에 깜박이지 않습니다.

WinPhonePerf_PerFrameCallback

성능 분석 도구 사용

Windows Phone 성능 분석 도구는 Windows Phone SDK의 일부로 설치되는 프로파일링 도구입니다. 그래픽을 많이 사용하는 앱의 실행 및 메모리 성능을 식별, 평가 및 개선하는 데 성능 분석 도구를 사용할 수 있습니다.

자세한 내용은 Windows Phone 응용프로그램 분석을 참조하세요.

표시: