성능 계획

느리고 응답하지 않으며 배터리를 많이 사용하는 앱 환경은 사용자 불만의 가장 큰 원인이 됩니다. 신속하고 응답이 빠르며 배터리를 인식하는 앱을 사용하면 사용자가 만족하고 연결된 상태를 유지할 수 있습니다. Windows 스토어 앱을 계획할 때는 성능을 염두에 두어야 합니다.

성능은 앱의 다른 기능과 마찬가지로 계획하고 디자인하고 테스트해야 하는 기능입니다. 다음 프로세스에 따라 앱 성능을 계획합니다.

  1. 앱의 성능 목표를 설정합니다.
  2. 성능 향상을 위해 디자인합니다.
  3. 성능 향상을 위해 앱을 계측합니다.
  4. 앱에서 성능 목표를 테스트하고 측정합니다.
  5. 성능 테스트 결과에 따라 앱 디자인을 반복하고 개선합니다.

다음은 이 프로세스의 각 단계에 대한 세부 정보입니다.

앱 성능 목표 설정

앱 성능 목표는 구체적이고 측정 가능해야 합니다. 이러한 목표를 구체적으로 설정하려면 사용자가 앱에서 작업을 완료하는 데 시간이 얼마나 걸리는지, 앱이 사용자 조작에 응답할 때 어떻게 응답하는지, 앱이 배터리 사용 시간을 얼마나 잘 절약하는지 등 앱이 얼마나 빠르고 유연하며 효율적일 수 있는지에 대해 생각해 보면 도움이 됩니다.

빠름

한 가지 시작 방법은 사용자가 앱에서 작업을 완료하는 데 허용되는 시간 범위를 고려하는 것입니다. 이러한 시간 범위를 조작 클래스라고 합니다. 이러한 각 조작 클래스에 대해 레이블, 인식된 사용자 정서, 대상 기간, 최대 기간 등을 할당할 수 있습니다. 다음은 몇 가지 제안된 조작 클래스와 각 클래스에 대한 예입니다.

조작 클래스 레이블사용자 인식대상최대 구성예제
빠름최소한의 인지할 수 있는 지연100밀리초200밀리초앱 바 표시, 단추 누르기(첫 응답)
일반적당히 빠름300밀리초500밀리초크기 조정, 시맨틱 줌
응답신속하지 않지만 응답성 있음500밀리초1초다른 페이지로 이동, 일시 중단 상태에서 앱 다시 시작
실행경쟁 환경1초3초처음으로 또는 이전에 종료된 후 앱 실행
계속더 이상 응답 없음500밀리초5초인터넷에서 파일 다운로드
종속오래 걸리지만 사용자가 전환할 수 있음500밀리초10초Windows 스토어에서 여러 앱 설치

 

일련의 조작 클래스가 있으면 앱의 성능 시나리오에 할당할 수 있습니다. 각 시나리오에 대해 앱의 지정 시간 참조, 사용자 환경의 일부, 조작 클래스 등을 할당할 수 있습니다. 다음은 예제 음식 및 식사 앱에 대해 제안된 몇 가지 성능 시나리오입니다.

시나리오시점사용자 환경조작 클래스
조리법 페이지로 이동 첫 번째 응답페이지 전환 애니메이션 시작됨빠름(100 - 200밀리초)
응답재료 목록 로드됨, 이미지 없음응답(500밀리초 - 1초)
표시 완료모든 콘텐츠 로드됨, 이미지 표시됨연속(500밀리초 - 5초)
조리법 검색첫 번째 응답검색 단추 클릭함빠름(100 - 200밀리초)
표시 완료현지 조리법 제목 목록 표시됨일반(300 - 500밀리초)

 

일련의 성능 시나리오가 있으면 앱의 속도를 더 잘 테스트, 분석 및 개선할 수 있습니다.

유연

원활한 사용자 응답성을 위한 구체적이고 측정 가능한 앱의 성능 목표에는 다음이 포함될 수 있습니다.

  • 화면 다시 그리기가 중지되었다가 시작되지 않습니다(결함).
  • 화면 애니메이션이 60FPS(초당 프레임), 프레임당 16밀리초의 CPU 및 GPU(그래픽 처리 장치) 작업으로 수행됩니다.
  • 사용자가 앱을 이동할 때 초당 3-6페이지의 콘텐츠 표시를 목표로 해야 합니다.

효율

효율성을 위한 구체적이고 측정 가능한 앱의 성능 목표에는 다음이 포함될 수 있습니다.

  • 최대 메모리 사용이 항상 지정된 CPU 비율 및 메모리(MB) 이하입니다.
  • 사용자가 앱을 사용하지 않을 때마다 CPU 및 디스크 비율이 0에서 유지됩니다.

배터리 사용 감소

개발자가 수행하는 대부분의 성능 작업은 자연스럽게 앱에서 사용되는 전원 양을 줄입니다. CPU는 이용률이 낮더라도 장치 배터리 전원의 주요 소비자입니다. Windows 8은 CPU를 절전 상태로 유지하려고 하지만 작업을 예약할 때마다 CPU를 활성화합니다. 유휴 상태일 때 앱에서 타이머가 CPU에 불필요한 예약 작업을 수행하지 않게 함으로써 앱의 배터리 전원 소비를 더욱 줄일 수 있습니다. 예를 들어 앱은 웹 서비스와 센서(예: GPS(글로벌 위치 시스템))에서 데이터를 폴링할 수 있습니다. 데이터 폴링 빈도를 결정할 때 배터리 소비를 고려하세요.

화면을 지속적으로 업데이트해야 하고 CPU 및 그래픽 파이프라인을 활성 상태로 유지하는 애니메이션의 경우에도 이 고려 사항이 중요합니다. 애니메이션을 통해 멋진 사용자 환경을 효과적으로 전달할 수 있지만 애니메이션을 사용하는 경우는 주의해서 선택하세요. 이는 사용자가 앱을 보고 있지만 조작하지 않을 수 있는 데이터 기반 앱의 경우 특히 중요합니다. 예를 들어 사용자가 앱을 조작하지 않고 잠시 동안 뉴스 뷰어나 사진 뷰어에서 콘텐츠를 볼 수 있습니다. 또한 사용자는 앱에만 집중하고 있지 않으므로 애니메이션을 스냅 모드에서 사용하는 것은 낭비적인 일일 수 있습니다.

많은 앱이 웹 서비스에 연결되어 사용자에 대한 새로운 정보를 얻습니다. 새 정보를 폴링하는 빈도를 줄이면 배터리 소비가 향상될 수 있습니다.

메모리 사용 감소

메모리를 줄이면 속도 저하를 방지할 수 있고 PLM(프로세스 수명 관리) 시스템이므로 Windows 스토어 앱의 경우 메모리 감소가 훨씬 더 중요합니다. PLM 시스템은 종료할 앱을 결정할 때 앱의 메모리 사용 공간도 참조합니다. 앱의 메모리 사용 공간을 최소화함으로써 앱이 사용되지 않을 때 종료될 가능성을 낮출 수 있습니다. 예를 들어 일시 중단된 이미지와 같은 불필요한 리소스를 해제하면 앱의 메모리 사용 공간을 줄일 수 있습니다.

PLM 시스템에서 앱을 디스크로 전환하고 다음에 앱이 전환될 때 앱을 다시 메모리로 전환하도록 선택할 수도 있습니다. 앱의 메모리 사용 공간을 낮추면 앱이 더 빠르게 다시 시작됩니다.

성능 목표가 있으면 앱의 디자인에 영향을 줄 수 있습니다.

성능 향상을 위해 디자인

앱을 디자인할 때는 성능 목표를 염두에 두어야 합니다. 예제 음식 및 식사 앱을 사용할 경우 사용자가 조리법 페이지로 이동한 후 가상화를 기술로 사용하여 보다 신속하게 초기 재료 목록을 로드하고 함께 제공되는 이미지를 나중까지 표시하지 않도록 할 수 있습니다. 다음은 고려해야 할 몇 가지 다른 영역입니다.

여러 페이지의 콘텐츠

여러 페이지의 콘텐츠를 표시하기 위한 성능 디자인 및 코딩 기술은 다음과 같습니다.

  • 가능한 경우 언제나 일정한 크기의 항목으로 목록 및 그리드에 가상화를 사용합니다. 자세한 내용은 목록 또는 그리드와 함께 가상화 사용을 참조하세요.
  • UI의 첫 번째 페이지만 응답하도록 앱을 개발합니다. 사용자에게 필요할 때까지 추가 UI를 로드하지 않습니다.
  • 우선 순위가 낮은 작업을 나중에 수행하도록 예약합니다. JavaScript를 사용하는 Windows 스토어 앱의 경우 자세한 내용은 WinJS.Utilities.Scheduler 네임스페이스 및 HTML 스케줄러 샘플을 참조하세요. C++, C# 또는 Visual Basic을 사용하는 Windows 스토어 앱의 경우 비동기 프로그래밍, Dispatcher 속성, CoreDispatcher 클래스 및 여러 보기 샘플을 참조하세요.
  • 사용자에게 필요할 때까지 콘텐츠를 축소합니다. JavaScript로 작성한 Windows 스토어 앱의 경우 자세한 내용은 display:nonedisplay 속성을 참조하세요. C++, C# 또는 Visual Basic으로 작성한 Windows 스토어 앱의 경우 CollapsedVisibility 속성을 참조하세요.

풍부한 비주얼 및 기능

풍부한 비주얼 및 기능을 표시하기 위한 성능 디자인 및 코딩 기술은 다음과 같습니다.

  • UI 및 코드 로드를 최대한 지연시킵니다.
  • 가능한 경우 언제나 코드가 없는 UI—(런타임에 일괄 처리로 로드할 수 있는 많은 부분의 하드 코드된 HTML 또는 XAML(Extensible Application Markup Language))—를 사용합니다.
  • 앱의 고유한 기능을 식별하여 가능하면 언제나 최소한의 요소를 로드합니다.
  • 여러 단계에서 사용자에게 UI의 일부를 표시합니다.
  • 로드하는 이미지는 GetThumbnailAsync 메서드를 사용하여 이미지를 표시할 뷰에 적합한 크기로 로드되어야 합니다.
  • JavaScript로 작성한 Windows 스토어 앱의 애니메이션에는 CSS 스타일시트 애니메이션, WinJS.UI.Animation 네임스페이스 또는 둘 다를 사용합니다. HTML 애니메이션 라이브러리 샘플을 참조하세요.
  • JavaScript를 사용하는 Windows 스토어 앱의 경우 HTML 및 CSS를 사용하여 UI 구성 요소를 배치하고 offsetWidthoffsetHeight 속성과 같은 인라인 레이아웃을 방지합니다.
  • C++, C# 또는 Visual Basic을 사용하는 Windows 스토어 앱의 경우 XAML 테마 전환 및 애니메이션을 사용합니다. 자세한 내용은 Windows 스토어 앱의 빠르고 유연한 애니메이션XAML 특성 애니메이션 샘플을 참조하세요.

라이브 콘텐츠

라이브 콘텐츠를 표시하기 위한 성능 디자인 및 코딩 기술은 다음과 같습니다.

  • 콘텐츠 최신 상태 목표를 식별합니다. 예를 들어 목표가 몇 초마다 콘텐츠를 새로 고치는 것입니까? 또는 몇 분마다, 몇 시간마다 또는 하루에 한 번 콘텐츠 새로 고침이 허용되는 사용자 환경입니까?
  • 가능하면 언제나 콘텐츠를 캐시합니다. 자세한 내용은 다음을 참조하세요.
  • 콘텐츠 캐시가 불가능한 경우, 사용자가 탐색할 수 있지만 앱이 일부 콘텐츠를 로드 중이라고 사용자에게 표시하는 —반응형 UI를 최대한 빨리 표시합니다.
  • 사용자에게 방해가 되지 않은 방법으로 캐시된 콘텐츠에서 라이브 콘텐츠로 전환합니다. 예를 들어 앱이 라이브 콘텐츠를 로드할 때는 사용자 손가락 아래의 콘텐츠 위치가 변경되지 않습니다.
  • 콘텐츠를 프리페치합니다. 자세한 내용은 다음을 참조하세요.

앱 실행

앱을 실행하기 위한 성능 디자인 및 코딩 기술은 다음과 같습니다.

앱 다시 시작

앱을 다시 시작하기 위한 성능 디자인 및 코딩 기술은 다음과 같습니다.

  • 사용자에게 방해가 되지 않은 방법으로 캐시된 콘텐츠에서 라이브 콘텐츠로 매끄럽게 전환합니다. 예를 들어 앱이 라이브 콘텐츠를 로드할 때는 사용자 손가락 아래의 콘텐츠 위치가 변경되지 않습니다.
  • 앱을 다시 실행하거나 콘텐츠를 다시 애니메이션하지 않습니다.
  • 메모리 사용량이 많을수록 앱 다시 시작 속도가 느려집니다. 다음과 같이 앱의 메모리를 관리합니다.
    • 코드의 작업 집합을 줄입니다.
    • 가능하면 언제나 이벤트 처리기 등록을 취소하고 시각적 요소를 역참조하여 메모리 누수를 방지합니다.
    • JavaScript를 사용하는 Windows 스토어 앱의 경우 createObjectUrl 메서드 및 oneTimeOnly 속성을 사용합니다.
    • 가능한 경우 순환 참조를 최소화하기 위해 HTML/JavaScript 및 XAML을 둘 다 사용하는 하이브리드 앱을 만들지 마세요.

앱 크기 조정 및 회전

앱 크기 조정 및 회전을 위한 성능 디자인 및 코딩 기술은 다음과 같습니다.

  • C++, C# 또는 Visual Basic을 사용하는 Windows 스토어 앱의 경우 VisualStateManager 클래스를 사용합니다.
  • JavaScript로 작성한 Windows 스토어 앱의 경우 가능한 한 JavaScript 대신 HTML/CSS를 사용합니다.
  • 필수 작업만 즉시 완료하고 부하가 큰 앱 작업을 나중까지 지연합니다. —앱이 200~800밀리초 내에 작업을 완료하지 못하면 앱의 UI가 잘린 상태로 표시됩니다.

콘텐츠 이동

콘텐츠를 이동하기 위한 성능 디자인 및 코딩 기술은 다음과 같습니다.

  • 초당 3 ~ 6페이지의 사용자 이동을 계획합니다.
  • 큰 항목 집합을 가상화합니다. 자세한 내용은 목록 또는 그리드와 함께 가상화 사용을 참조하세요.
  • 최대한 적은 수의 요소에서 프로젝트 템플릿을 사용합니다.
  • 여러 단계에서 콘텐츠를 렌더링합니다.

진행하면서 이러한 성능 시나리오와 일치하지 않는 다른 일반적인 성능 관련 디자인 고려 사항이 있다는 것을 알 수 있습니다. 예를 들어 장치에 간헐적인 무선 연결이 있거나, 더 느린 전화 접속 연결이 있거나, 인터넷 연결이 전혀 없는 경우 어떻게 됩니까? 예제 음식 및 식사 앱의 경우 처음 다운로드한 후 함께 제공되는 이미지를 캐시하는 방법이 있을 수 있습니다. 다른 방법을 보려면 연결 사용 데이터를 참조하세요.

성능 관련 디자인을 사용하여 앱 코딩을 시작할 수 있습니다.

성능 계측

앱을 코딩할 때 앱이 실행되는 동안 특정 지점에서 메시지 및 이벤트를 기록하는 코드를 추가할 수 있습니다. 나중에 앱을 테스트할 때 Windows 성능 기록기 및 Windows 성능 분석기(둘 다 Windows 성능 도구 키트에 포함되어 있음)와 같은 도구를 사용하여 앱의 성능에 대한 보고서를 만들고 볼 수 있습니다. 이 보고서에서 이러한 메시지 및 이벤트를 검색하면 보고서 결과를 보다 쉽게 분석할 수 있습니다.

Windows 런타임은 Windows 스토어 앱에 풍부한 이벤트 로깅 및 추적 솔루션을 함께 제공하는 로깅 API(ETW(Windows용 이벤트 추적)에서 지원)를 제공합니다. Windows.Foundation.Diagnostics 네임스페이스의 일부인 API에는 FileLoggingSession, LoggingActivity, LoggingChannelLoggingSession 클래스가 포함됩니다.

앱이 실행되는 동안 특정 지점에서 보고서에 메시지를 로깅하려면 다음과 같이 LoggingChannel 개체를 만든 다음 개체의 LogMessage 메서드를 호출합니다.



// using Windows.Foundation.Diagnostics;
// ...

LoggingChannel myLoggingChannel = new LoggingChannel("MyLoggingChannel");

myLoggingChannel.LogMessage(LoggingLevel.Information, "Here's my logged message.");

// ...


앱이 실행되는 일정 기간 동안 보고서에 시작 및 중지 이벤트를 로깅하려면 다음과 같이 LoggingActivity 개체를 만든 다음 개체의 LoggingActivity 생성자를 호출합니다.



// using Windows.Foundation.Diagnostics;
// ...

LoggingActivity myLoggingActivity;

// myLoggingChannel is defined and initialized in the previous code example.
using (myLoggingActivity = new LoggingActivity("MyLoggingActivity"), myLoggingChannel))
{   // After this logging activity starts, a start event is logged.
    
    // Add code here to do something of interest.
    
}   // After this logging activity ends, an end event is logged.

// ...


추가 예제는 LoggingSession 샘플FileLoggingSession 샘플을 참조하세요.

앱의 코드를 계측한 후에는 앱의 성능을 테스트하고 측정할 수 있습니다.

성능 목표 테스트 및 측정

앱을 계측한 후에는 다음 기술 및 도구를 사용하여 앱이 원래 성능 목표에 대해 어떻게 스택되는지를 테스트합니다.

  • 통합 및 데스크톱 PC, 노트북 및 울트라북, 태블릿 등 사용자가 사용할 것 같은 광범위한 하드웨어 구성을 테스트합니다.
  • 사용자가 사용할 것 같은 다양한 화면 크기를 테스트합니다. 화면 크기가 클수록 더 많은 콘텐츠를 표시할 수 있지만 추가 콘텐츠를 모두 표시하면 성능에 부정적인 영향을 줄 수 있습니다.
  • 임의 테스트 변수를 최대한 많이 제거합니다. 예를 들면 다음과 같습니다.
    • 테스트 장치에서 백그라운드 앱을 끕니다. 이렇게 하려면 Windows에서 설정 참 메뉴 > PC 설정 변경 > PC 및 장치를 선택합니다. 잠금 화면용 앱 영역에서 각 활성 앱을 선택한 다음 잠금 화면에서 앱 알림 해제를 선택합니다.
    • C# 또는 Visual Basic을 사용하는 Windows용으로 작성된 Windows 스토어 앱의 테스트 장치에서 네이티브 코드 이미지를 만듭니다. 이렇게 하려면 Windows의 바탕 화면에서 관리 센터를 엽니다. 유지 관리 영역의 자동 유지 관리에서 유지 관리 시작을 선택합니다.
    • 앱을 여러 번 실행하여 임의 테스트 변수를 제거하고 일관된 측정을 보장합니다.
  • 배터리 사용 감소를 위해 테스트합니다. 앱을 만들 때 염두에 둘 점은 사용자가 쓰는 컴퓨터 유형의 전원 수준이 개발 환경보다 크게 낮을 수 있다는 것입니다. Windows 8은 태블릿과 같은 절전 장치를 염두에 두고 설계되었습니다. 또한 Windows RT는 이와 동일한 설계 원칙에 따라 ARM 기반 플랫폼의 저 전원 소비 특성을 활용합니다. Windows 스토어 앱을 실행하여 이러한 장치에서 제대로 작동하는지 확인해야 합니다. 개발 컴퓨터에서 빠르게 실행되는 것처럼 보이는 작업이 절전 장치에 있는 사용자 환경에 큰 영향을 미칠 수 있습니다. 경험적으로 절전 장치는 데스크톱 컴퓨터보다 4배 정도 더 느릴 것으로 예상되므로 이에 따라 목표를 설정하세요.
  • Microsoft Visual Studio 및 Windows 성능 분석기와 같은 도구 집합을 함께 사용하여 앱 성능을 측정합니다. Visual Studio는 소스 코드 연결과 같은 앱 중심 분석을 제공하도록 설계되었습니다. Windows 성능 분석기는 시스템 정보 제공, 터치 조작 이벤트에 대한 정보, 디스크 I/O(입출력) 및 GPU 비용에 대한 정보 등 시스템 중심 분석을 제공하도록 설계되었습니다. 두 도구 집합은 모두 추적 캡처 및 내보내기를 제공하며 공유된 추적 및 사후 추적을 다시 열 수 있습니다.
  • 인증을 위해 Windows 스토어에 앱을 제출하려면 먼저 Windows 앱 인증 키트 테스트의 "성능 테스트" 섹션 및 Windows 스토어 앱 테스트 사례의 "성능 및 안정성" 섹션에 설명된 대로 테스트 계획 및 성능 관련 테스트 사례에 통합해야 합니다.

성능 테스트 결과에 따라 앱 디자인 반복 및 개선

성능 테스트 결과를 분석한 후 변경이 필요한지 여부를 결정합니다. 예를 들면 다음과 같습니다.

  • 기존의 앱 성능 목표를 변경해야 합니까?
  • 현재 디자인 결정을 변경해야 합니까?
  • 코드에서 계측을 추가, 제거 또는 변경해야 합니까?

변경이 필요한 경우 이 프로세스의 시작 부분으로 돌아가 반복합니다.

관련 항목

앱 계획
성능(Windows 스토어 앱)
일반적인 성능 모범 사례
JavaScript를 사용하는 Windows 스토어 앱의 성능 모범 사례
C++, C# 또는 Visual Basic을 사용하는 Windows 스토어 앱의 성능 모범 사례

 

 

표시:
© 2015 Microsoft