Metro 스타일 앱의 성능을 향상시키는 방법

Windows 8 앱 개발자 블로그

Windows 8 엔지니어링 팀에서 제공하는 Windows 8용 Metro 스타일 앱 개발의 이해

Metro 스타일 앱의 성능을 향상시키는 방법

  • Comments 0

실행 속도가 늦거나 응답하지 않는 앱을 좋아할 사람은 아무도 없습니다. 사용자는 앱을 사용할 때 터치, 탭, 클릭, 제스처 및 키 누름 등에 즉시 응답하기를 기대합니다. 또한 애니메이션 효과가 물 흐르듯이 자연스럽게 구현되고, 음악과 동영상을 신속하게 재생, 일시 중지 및 다시 시작할 수 있고, 앱이 이러한 동작에 응답할 때까지 기다릴 필요가 없기를 바랍니다. 이 글은 앱을 "빠르고 유연"하게 만드는 방법에 대한 시리즈의 첫 번째 글입니다.

Microsoft 엔지니어 팀은 Metro 스타일 앱의 성능을 최적화하는 방법에 대해 오랫동안 고민했습니다. 그 결과 빠르고 유연한 성능을 제공하기 위해 플랫폼에서 할 수 있는 것이 무엇인지, 그리고 뛰어난 경험을 제공하는 앱을 제작하는 데 효과가 있는 것과 그렇지 않은 것이 무엇인지를 배웠습니다. 이 글을 통해 우리의 경험에서 얻은 몇 가지 확실한 교훈을 앱 개발자들과 공유하고자 합니다. 여러분이 최상의 사용자 경험을 제공하는 앱을 개발하는 데 이러한 정보가 많은 도움이 되기를 바랍니다.

성능의 심리학

성능은 단순히 스톱워치나 효율적인 알고리즘만을 의미하는 것은 아닙니다. 저는 성능에 대해 생각할 때 숲 전체를 본다는 생각으로 "사용자가 앱을 사용하면서 시간을 보낼 때 어떤 경험을 하게 될까?"에 대해 자주 생각합니다. 앱이 빠르고 유연하다는 것은 어떤 의미일까요? 이러한 의미에 대해 생각해 보는 한 가지 기준은 사용자 경험을 인식, 인내 및 반응의 세 가지 범주로 구분하는 것입니다.

인식: 시간이 너무 오래 걸립니다!

인식은 빠른 속도와 유연한 성능의 두 가지 측면 중에서 "빠른 속도"와 관련이 있습니다. 우리는 사용자가 경험하게 되는 성능에 대한 인식을 앱을 사용하면서 보낸 시간이 얼마나 즐거웠는지로 정의합니다. 이상적으로는 사용자의 인식이 실제와 일치해야 합니다. 하지만 이런 경우는 거의 없으므로 시간에 대한 인식이 실제보다 더 중요합니다. 설치가 자동으로 완료되도록 두었지만 돌아와보니 하나 이상의 질문에 대한 대답을 기다리면서 설치가 일시 중지된 사실을 발견한 경험이 있으십니까?

사용자가 프로세스에 대해 기억할 수 있는 단계가 많을수록 속도는 더 느린 것처럼 보입니다.

해야 할 일:
  • 사용자가 작업을 완료하기 위해 수행해야 하는 활동 간의 시간을 줄입니다.
  • 사용자에게 아무 때나 질문해야 하는지, 아니면 예정된 모든 질문에 대한 정보를 제공해야 하는지 확인합니다.
하지 말아야 할 일:
  • 사용자 활동을 중간에 시간을 두고 여러 기간으로 구분합니다.

인내: 즐거울 땐 시간 가는 줄 모릅니다.

인내는 빠른 속도와 유연한 성능 모두와 관련이 있습니다. 인식이 얼마나 많은 시간이 흘렀는지에 대한 사용자의 기억에 대한 척도라면 인내는 이렇게 보낸 시간이 얼마나 즐거웠는지에 대한 척도입니다.

사용자가 작업에 얼마나 오랜 시간이 걸릴지 모른다면 기다림은 고통입니다. 앱을 사용하여 사진을 편집하는 경우를 예로 들어 보겠습니다. 여러분이 필터를 적용하려고 클릭했지만 앱이 응답하지 않습니다. 정지된 상태로 보낸 시간은 몇 초라도 금세 참을 수 없게 됩니다.

우리는 사진 앱에 진행률 표시줄 또는 필터를 적용하는 중임을 나타내는 작은 애니메이션을 추가하여 이 문제를 해결했습니다. 불확실성이 없기 때문에 사용자가 작업이 완료될 때까지 기꺼이 기다릴 수 있는 시간이 크게 증가합니다. 이 앱은 빠르고 유연한 것으로 사용자에게 기억됩니다. 사소한 차이가 결국은 큰 차이를 만들게 됩니다.

해야 할 일:

  • 1초 이상의 상당히 긴 로드 시간이 필요할 수 있는 앱 영역을 확인합니다.
  • 이러한 시나리오 중에 사용자의 불확실성을 제한하거나 없애는 조치를 취합니다.
  • 사용자에게 진행 상태 및 소요 시간을 나타내는 시각적 표시를 제공합니다.
  • UI 스레드 차단 및 앱이 정지된 상태로 표시되는 것을 방지하도록 비동기 API를 사용합니다.

하지 말아야 할 일:

  • 사용자 피드백을 제공하지 않고 장기 실행 작업을 계속합니다.

반응: 반사 < 반응 < 확인

반응은 빠른 속도와 유연한 성능 중에서 후자와 관련이 있습니다. 인내가 시간에 대한 기대 및 즐거움에 대한 척도라면 반응은 시간에 대한 기대가 수행 중인 활동과 관련이 있다는 개념입니다. 작업의 성능을 측정하려면 비교할 시간 간격이 있어야 합니다. 저는 이러한 시간 간격을 '상호 작용 클래스'라고 부릅니다. 내부적으로 우리는 이러한 상호 작용 클래스를 사용하여 Windows 전체의 핵심 시나리오에 대한 반응 목표를 정의하고 이러한 목표를 달성하지 못한 것을 제품의 버그로 추적합니다.

상호 작용 클래스

목표

상한

사람의 인식

일반적인 시나리오

즉시

50밀리초 이하

100밀리초

구별할 수 있는 지연 없음

입력 응답 - 마우스 클릭, 단추 탭 등

빠름

50~100밀리초

200밀리초

구별할 수 있는 최소한의 지연. 피드백은 필요하지 않음

화면 이동/스크롤

보통

100~300밀리초

500밀리초

신속하지만 빠르다고 설명하기에는 너무 느림. 피드백은 필요하지 않음

페이지 내 대화 상자 열기(즉, 정보 팁, 팝업, 플라이아웃, 알림 등)

응답적

300~500밀리초

1초

빠르지 않지만 여전히 응답성이 좋다고 느낌. 피드백은 필요하지 않음

새 페이지로 이동, 확대/축소, 처리되거나 준비된 데이터 표시

계속

500밀리초 초과

10초

보통 대기 시간, 응답성이 좋다고 느끼지 않음. 다른 작업을 수행할 정도로 오래 걸리지 않음. 피드백이 필요할 수 있음

앱 시작, 앱 끌기, 오류 메시지, 시간 초과, 진행률 표시 업데이트

연장

5초 초과

1분 초과

기다리는 동안 다른 작업을 수행할 정도로 오래 걸림. 피드백이 필요할 수 있음

장치/라이브러리 동기화 또는 인덱싱

해야 할 일:

  • 앱의 중요한 시나리오를 원하는 경험을 나타내는 상호 작용 클래스에 할당합니다.
  • 이러한 목표를 충족하지 않는 시나리오를 확인하고 최적화합니다.
  • 시나리오에 사용자 피드백이 필요한지 확인하고 이를 제공합니다.

최적화할 주요 경험

성능 문제는 여러 측면에서 나타납니다. 성능 문제로 인해 배터리 수명이 감소하거나, 화면 이동 및 스크롤이 손가락 제스처에 뒤늦게 반응하거나, 앱이 장시간 동안 실행을 멈춘 것처럼 보일 수 있습니다. 한정된 시간 안에 성능을 개선해야 하는 개발자의 입장을 감안하여 이 섹션에서는 최적화를 통해 가장 큰 효과를 볼 수 있는 영역을 찾는 데 도움이 되는 몇 가지 팁과 이러한 최적화를 구현하는 데 효과적인 몇 가지 지침에 대해 알아보겠습니다.

최적화에 대해 생각할 수 있는 한 가지 방법은 사용자가 차이점을 인식하기 전에 프로세스가 20% 더 빠르거나 느려야 한다는 것입니다.

현재 시간보다 20% 더 빠르거나 느린 차이를 보여 주는 다이어그램

여러분은 식은 죽 먹기처럼 쉽게 주요 시나리오에 대한 앱 성능을 대폭 향상하는 방법을 찾을 수 있습니다. 이러한 문제를 해결한 경우 프로세스 기간을 20% 정도 즉시 단축하는 단일 성능 문제를 우연히 발견���지 못할 가능성이 점점 커집니다. 그보다 모두 동일한 사용자 경험 문제에 기여하는 보다 작은 문제가 같은 경로를 따라 누적되는 경우가 많습니다. 따라서 다음 섹션에서는 이러한 경로를 발견하는 데 유용한 도구에 대해 알아보겠습니다.

앱 프로파일링

최적화가 가장 효과적인 영역을 확인할 수 있는 가장 간단하고 즉시 사용 가능한 기술 중 하나는 앱 프로파일링을 수행하는 것입니다. 프로파일링은 앱이 여러 기능에서 소요하는 시간에 대한 데이터를 제공하므로 앱이 대부분의 작업을 수행하는 핫 스폿을 확인할 수 있습니다. 다행히 Visual Studio 11에 Windows 8 Consumer Preview에서 액세스할 수 있는 유용한 프로파일링 도구가 있습니다.

그러나 시작하기 전에, Windows 8은 다양한 장치에서 실행될 것이므로 강력한 하드웨어에 대한 성능 측정이 실제로 다른 폼 팩터의 성능 특성을 저하시키지는 않을 것임을 기억해야 합니다. 개인적으로 저는 대부분 측정을 수행할 때 성능이 낮은 랩톱을 사용합니다. 자세한 내용은 Consumer Preview 실행: 시스템 권장 사항에 대한 글을 참조하십시오.

다음은 측정을 위해 컴퓨터를 준비하는 방법입니다.

  1. 컴퓨터가 연결되어 있고 배터리를 사용하고 있지 '않은지' 확인합니다. 대부분의 시스템은 전원을 절약하기 위해 여러 다양한 배터리 방식으로 작동합니다.
  2. 원격 데스크톱으로 측정하지 않도록 합니다. 하드웨어 가속화를 사용할 수 없고 결과가 왜곡될 수 있습니다.
  3. 시스템의 전체 메모리 사용률이 50% 미만인지 확인합니다. 이보다 높으면 50%에 도달할 때까지 앱을 닫아 다른 프로세스를 제외한 앱에 대한 실제 영향만 측정하십시오.

앱 프로파일링을 시작하려면

  1. Visual Studio에서 앱을 시작합니다.
  2. 디버그 메뉴에서 두 가지 성능 분석 옵션 중 하나를 선택합니다.
  3. 성능 분석 시작(Alt+F2) 및 성능 분석 시작 일시 중지(Ctrl+Alt+F2)가 포함된 메뉴

    • 성능 분석 시작: 사용 정보 기록을 즉시 시작하고 앱을 실행합니다.
    • Start Performance Analysis Paused(성능 분석 시작 일시 중지): 앱을 시작하고 나중에 정보 기록을 재개할 수 있습니다. 정보를 기록(예: 특정 사용자 시나리오를 테스트하기 위해)하기 전에 앱을 특정 상태로 전환하는 데 사용됩니다.
  4. 측정할 작업을 수행한 후 Visual Studio로 돌아가서 프로파일링 중지를 클릭합니다. 그러면 VS에서 보고서를 생성하고 앱 작업에 대한 주요 정보를 표시합니다.

Visual Studio의 프로파일링 중지 링크

성능 보고서의 가장 유용한 두 가지 보기는 호출 트리 보기와 함수 정보 보기입니다. 호출 트리 보기에서는 실행 중에 앱에서 호출한 모든 함수, 각 함수가 호출된 횟수 및 각 함수를 실행하는 데 걸린 시간을 볼 수 있습니다. 또한 실행 시간이 가장 오래 걸린 함수를 보여 주는 실행 부하 과다 경로 확장 단추도 있습니다. 이러한 영역은 가장 큰 영향을 미치기 때문에 최적화에 집중해야 할 첫 번째 영역입니다.

호출 트리 보기의 실행 부하 과다 경로 확장 단추

보고서에는 각 함수에 대한 포괄 시간과 전 시간이 둘 다 표시됩니다. 전용 시간은 해당 함수의 코드를 실행하는 데 소요된 시간의 비율을 측정합니다. 포괄 시간은 함수가 호출된 시간과 함수에서 결과를 반환한 시간 간의 시간 비율입니다. 즉, 함수에서 코드를 실행하는 데 소요된 시간뿐 아니라 해당 함수에서 호출한 모든 함수에서 코드를 실행하는 데 소요된 시간을 의미합니다.

앱의 모든 함수에 대해 함수 정보 보기를 열어 함수에서 수행한 작업에 대한 자세한 정보(실행한 특정 코드, 호출한 함수 및 이러한 함수를 실행하는 데 걸린 시간 포함)를 가져올 수 있습니다. 그림에 표시된 예에서 Array.concat 함수는 앱 실행 시간의 29.7%를 차지하므로 앱에 과부하를 일으키는 주요 요인입니다. 함수 정보 보기를 보면, 실제로 Array.concat 함수 자체의 시간(주황색)은 약 12.6%만 차지하고 대부분의 시간은 연결 함수에서 해당 실행의 일부로 호출(보라색)한 get_MainResourceMap 함수에서 소요된 것을 알 수 있습니다. 이러한 함수 중 하나를 클릭하면 자세한 정보를 확인할 수 있습니다.

호출하는 함수 비율, 현재 함수 비율 및 호출된 함수 비율을 보여 주는 Array.concat에 대한 함수 정보 보기

Windows 8 Consumer Preview가 릴리스되기 몇 주 전에 저는 어떤 앱을 사용하면서 랩톱이 과열되어 팬이 작동하기 시작한 것을 경험했습니다. 우리는 앱 개발자들과 함께 프로파일링을 사용하여 불필요하게 CPU를 많이 사용하는 몇 가지 코드 경로를 확인한 후 수정했습니다. 차이점을 즉시 구별할 수 있었기 때문에 변경 작업을 통해 다른 앱 시나리오(예: 끌기)도 향상되었습니다.

유용한 일시 중단

앱 시작은 앱이 일시 중단되지 않은 경우에만 발생합니다. 일시 중단된 경우에는 앱이 거의 재개되는 즉시 보기에 다시 나타납니다. 앱을 일시 중단된 상태로 유지하는 것은 인식, 인내 및 반응을 관리하는 방법입니다. 사용자는 앱을 보다 빠르게 즐길 수 있으며, 앱을 사용할 때마다 로드되기를 기다리는 불확실성을 경험하지 않아도 됩니다. 앱이 종료되지 않도록 하는 것은 앱의 성능에 있어 그랜드슬램을 달성한 것과 같습니다. 이렇게 하는 가장 쉬운 방법은 일시 중단된 경우 앱의 메모리 사용량을 낮게 유지하는 것입니다.

앱이 일시 중단되기 전에 일부 작업을 수행할 수 있는 몇 초의 여유가 있습니다. 이 시간 동안 재개 시 손쉽게 다시 가져올 수 있는 큰 개체를 모두 해제하십시오. 이렇게 하면 앱의 메모리 사용량이 낮게 유지되고 시스템에서 다른 앱을 위한 공간을 확보하기 위해 여러분의 앱을 종료할 가능성이 현저하게 낮아집니다. 다음은 앱이 올바르게 일시 중단되었는지 확인하는 방법입니다.

  1. 앱을 시작한 다음 바탕 화면으로 다시 이동합니다.
  2. Ctrl+Shift+Esc를 눌러 작업 관리자를 시작하고 "More details(자세히)"를 클릭하여 사용 가능한 모든 옵션을 표시합니다.
  3. 보기 > 상태 값 > Show suspended status(일시 중단 상태 표시)를 클릭합니다.

보기 메뉴에서 Group by type(유형별 분류)을 선택한 다음 Show suspended status(일시 중단 상태 표시) 선택

몇 초 후 앱 이름 옆에 "일시 중단됨"이라는 단어가 표시됩니다. 일시 중단된 동안 앱의 개인 작업 집합 메모리 사용량이 실행 중일 때보다 크게 감소했는지 확인합니다. 앱의 복잡성 및 일반적인 크기를 기반으로 일시 중단된 동안 앱에 대해 다음과 같은 메모리 메트릭 목표를 지정하는 것이 좋습니다.

앱 복잡성(대략)

일시 중단된 동안 개인 집합(최대)

최소 앱(예: Hello World)

40~60MB

중간 앱(예: Weather)

60~80MB

큰 앱(예: Windows Live 사진)

120~150MB

다음은 중단된 동안 앱에서 사용하는 메모리 양을 확인하는 방법입니다.

  1. 앞서 설명된 단계를 사용하여 앱이 일시 중단되었는지 확인합니다.
  2. 작업 관리자에서 앱 이름을 마우스 오른쪽 단추로 클릭하고 "Go to details(세부 정보 보기)"를 클릭합니다. 그러면 앱의 프로세스에 대한 자세한 정보가 표시됩니다(JavaScript를 사용하는 모든 Metro 스타일 앱의 프로세스는 WWAHost.exe로 표시되고, 그렇지 않은 앱은 해당 이름이 프로세스로 표시됨).
  3. "메모리(개인 작업 집합)" 열이 있는지 확인합니다. 없는 경우 아무 열이나 마우스 오른쪽 단추로 클릭하고 열 선택으로 이동하여 메모리(개인 작업 집합)를 선택합니다.
  4. 열 이름 목록에서 선택된 메모리(개인 작업 집합)

  5. 이 열 아래에 나열된 값이 앱의 개인 작업 집합입니다.


20,736K로 표시된 메모리 사용량

앱 에코시스템에 기여하는 개발자

실망스럽게 들리겠지만 여러분의 앱만 사용되는 것이 아니라 여러 앱이 함께 작동합니다. 따라서 사용자 시스템에서 실행될 때 시스템에서 인식된 지연을 여러분의 앱 탓으로 돌리지 않고 심증적으로 시스템의 낮은 성능 또는 배터리 수명과 관련 지을 수 있도록 앱 에코시스템에 기여하는 개발자가 되어야 합니다. 다음은 앱이 다른 앱과 함께 원활하게 작동하는 데 유용한 몇 가지 팁입니다.

메모리 사용량 급증 방지

시스템은 사용자가 리소스를 관리할 필요 없이 일시 중단된 앱을 자동으로 종료하여 새로운 앱에 대한 공간을 확보함으로써 모든 Metro 스타일 앱의 리소스 요구를 수용해야 합니다. 하지만 이 경우 앱에서 대용량 메모리를 요청하면 다른 앱이 종료될 수 있다는 부작용이 있습니다. 이는 메모리를 요청한 이후에 즉시 해당 메모리를 해제한 경우에도 마찬가지입니다. 메모리 사용량이 많은 작업을 시작할 때 이러한 문제를 방지하려면 해당 작업을 작은 청크로 접근하는 것이 가장 좋습니다.

메모리 관리 언어(예: JavaScript 또는 C#)로 코딩하는 경우에는 메모리 할당이 발생할 때 제어하기가 매우 어렵습니다. 그러나 이 경우 현재 시스템의 해상도에 비해 너무 큰 리소스를 로드한 후 크기를 줄이는 함정에 빠지기 쉽습니다. 새로운 축소판 API를 사용하여 대상 해상도에 적합한 리소스를 가져와 불필요하게 큰 오버헤드를 방지할 수 있습니다. 우리는 이 접근 방법을 사용하여 테스트에 사용하는 그림 기반 퍼즐 게임의 메모리 사용량을 대폭 줄일 수 있었습니다.

언어에 관계없이 앱의 복잡성 및 일반적인 크기를 기반으로 앱에 대해 다음과 같은 런타임 메모리 메트릭 목표를 지정하는 것이 좋습니다.

앱 복잡성(대략)

전체 작업 집합(최대)

최소 앱(예: Hello World)

50~70MB

중간 앱(예: Weather)

80~100MB

큰 앱(예: 사진)

120~150MB

다음은 앱이 실행되는 동안 앱에서 사용하는 메모리 양을 확인하는 방법입니다.

  1. Ctrl+Shift+Esc를 눌러 작업 관리자를 시작하고 More details(자세히)를 클릭하여 사용 가능한 모든 옵션을 표시합니다.
  2. 옵션 메뉴 항목을 클릭하고 항상 위가 선택되어 있는지 확인합니다.
  3. 앱을 시작합니다. 작업 관리자에 앱이 표시되면 앱을 마우스 오른쪽 단추로 클릭하고 Go to details(세부 정보 보기)를 클릭합니다.
  4. 작업 집합(메모리) 열이 있는지 확인합니다. 없는 경우 아무 열이나 마우스 오른쪽 단추로 클릭하고 열 선택으로 이동합니다. 작업 집합(메모리) 열을 선택합니다.

    열 목록에서 선택된 작업 집합(메모리)

  5. 이 열 아래에 나열된 값이 앱의 전체 작업 집합입니다.

유휴 상태 또는 끌어온 상태에서 시스템 리소스 사용 최소화

사용자의 가장 큰 관심사 중 하나는 장치의 배터리 수명입니다. 따라서 Metro 스타일 앱은 사용자가 해당 앱과 활발하게 상호 작용하지 않는 경우 시스템 리소스 사용을 해제하여 에너지를 절감하도록 도와주는 것이 좋습니다. 다음은 리소스 사용량을 줄을 수 있는 몇 가지 팁입니다.

끌어온 상태에서는 애니메이션, 오디오 또는 배경 동영상을 실행하지 마십시오.

  • 여러분의 앱은 더 이상 관심의 중심에 있지 않습니다. 앱을 화려하고 사용하기 편리하도록 만들되, 기본 앱의 가용 리소스를 뺏거나 배터리를 사용하지 않도록 하십시오.
  • 이는 앱이 전용 음악/동영상 재생 클라이언트가 아닌 경우에 해당합니다.

무한 루프에서 애니메이션, 오디오 또는 배경 동영상을 실행하지 마십시오.

  • 사용자가 일정 시간 동안 앱과 상호 작용하지 않는 경우 이러한 작업을 일시 중지하십시오. 다음에 사용자가 앱과 상호 작용할 때 안전하게 재개할 수 있습니다.
  • 저는 백그라운드 작업을 일시 중지하여 CPU 사용량이 40%인 앱이 유휴 상태에서 0%로 CPU 사용량을 낮추는 것을 보았습니다.

끌어온 상태 또는 유휴 상태 중에 파일 캐싱, 장치 동기화 또는 그 밖에 디스크를 많이 사용하는 모든 작업을 수행하지 마십시오.

  • 디스크를 사용하면 다른 작업에 대한 검색 시간이 불필요하게 증가하고 많은 전원이 사용됩니다.

이후에 다룰 주제

이 글에서는 성능에 대해 생각하는 방법 및 앱의 주요 경험에 대한 목표 설정 방법을 설명하고 최적화가 필요한 영역을 확인하는 데 유용한 일부 도구에 대해 알아보았습니다. 다음 글에서는 가장 큰 문제가 있는 영역에 대해 이러한 최적화를 수행하는 방법 및 몇 가지 일반적인 함정을 피하는 방법에 대해 다룰 예정입니다. 이러한 팁이 유용하기 바랍니다.

다음 편도 많이 기대해 주시기 바랍니다.

- Windows 프로그램 관리자, David Tepper

  • Loading...
Leave a Comment
  • Please add 8 and 2 and type the answer here:
  • Post