관리 메뉴

제목없음

저비용 장치를 위한 앱 최적화 본문

프로그램 작성/WPF/Silverlight

저비용 장치를 위한 앱 최적화

다람군 2012.06.30 02:45
번역을 하면서 일부 의역하거나 문장을 뺐습니다. 또한 Google 번역을 통해 얻어온 결과를 일부 수정한 내용이기 때문에 좀 더 읽기 편하게 글을 보시려거나 원래의 문장을 보고자 하시는 분들은 아래의 원문 바로가기를 통해 읽어보시기 바랍니다.

원문 바로가기

저비용 장치를 위한 앱 최적화

Joe가 남긴 에 언급되었듯, 새로운 시장에 낮은 비용의 장치와 지원의 도입은 여러분의 Windows Phone 앱들이 새로운 많은 잠재 고객에게 다가갈 수 있는 기회를 제공합니다. 이러한 더 낮은 비용의 장치에 대해 앱을 최적화하려면 사용자가 장치에 관계없이 최상의 경험을 얻을 수 있도록 하는 것이 중요합니다.

더 낮은 비용의 Windows Phone을 위한 최적화 가이드는 오늘날의 세대의 장치에 대한 최적화와 같습니다. 성능 모범 사례를 따르는 앱은 많은 노력없이 모든 장치에 걸쳐 잘 실행됩니다. 낮은 비용의 장치에서 눈에 띄게 느리게 수행될 수도 있습니다. 여러분의 앱을 저렴한 비용의 장치에서 뿐만 아니라 최근의 장치에서 제대로 동작하게 하려면 다음과 같은 원칙을 고려해보시기 바랍니다.

시작 시간 최적화

시작 시간을 빠르게 유지하기 바랍니다. 여기에 대한 기본적인 지침은 앱의 첫 번째 프레임이 렌더링 될 때까지 가능한 한 많은 활동을 연기하는 것입니다. 이것은 App/Page 생성자의 코드를 최소화하고 Launching/OnNavigatedTo 활동을 최소한으로 유지하는 것을 의미합니다.

만약 페이지 초기화에서 네트워크 요청을 하거나, 파일 I/O를 수행하는 경우 시간이 조금 걸리게 될 것입니다. 그럴 경우 다음 활동으로 전환하기까지 진행바를 표시합니다. 최상의 성능을 위해 시스템 트레이의 ProgressIndicator를 활용할 수도 있습니다. 이를 활용할 때에는 페이지 레이아웃에 영향을 주지 않을 수 있으며, 사용 후에는 시스템 트레이의 불투명도를 0으로 설정하여 끌 수 있습니다.

첫 번째 프레임이 렌더링되면 UI 스레드가 한번 차단됩니다. 격리 스토리지 작업은 비동기적으로 수행하지 않을 경우 UI 스레드가 차단될 수 있습니다. 시작시 반응하는 UI를 유지하기 위해 이러한 호출은 비동기적으로 유지하시기 바랍니다.

스플래시 화면을 추가하는 것은 이 프레임이 시작 순서의 부분에 OS 스스로 그리도록하여 시작 시간을 향상시킬 수 있습니다. 또한 페이지에서 불필요한 XAML 코드를 단순화하고 제거하는 것은 시작 시에 XAML 분석에 대한 영향을 줄일 수 있습니다.

메모리 사용량 줄이기

인증 요구 사항 5.2.5에 따라, 앱은 256MB의 장치에서 메모리 사용량을 90MB를 초과하면 안됩니다. Lumia 610과 같은 256MB 장치의 도입과 매우 관련이 깊습니다.

메모리 프로파일러메모리 관련 API를 사용하여 여러분의 앱의 메모리 사용량을 프로파일합니다. 가장 중요한 기본적인 규칙은 필요한 때에만 필요한 만큼의 메모리를 불러오고, 필요하지 않은 항목은 곧바로 폐기하는 것입니다. 시작 시에 게임의 모든 자산을 미리 불러오는 대신, 화면 경험을 위한 자산만을 불러오는 것과, 경험이 바뀔 때 자산을 플러시(flush)하는 것입니다. 리스트들의 모든 데이터 세트를 불러오는 대신, 사용자가 요청한 데이터의 페이지를 불러옵니다.

메모리 누수를 조심하십시오. 앱에서 홈 버튼을 사용할 경우, 중복된 페이지 인스턴스로 뒤로 가기 스택을 채울 수 있어 원형 네비게이션 루프가 발생할 수 있습니다. 이런 페이지 인스턴스들은 여러분의 앱을 사용자가 탐색하는 동안 메모리를 소비하고 Out-Of-Memory 예외를 발생시켜 충돌을 일으킬 수 있습니다. 이 경우, 홈 버튼 기능을 제거하거나, Windows Phone 7.5에서 새로이 추가된 뒤로 가기 스택 조작 API를 활용하여 원형 네비게이션 루프를 방지합니다.

또다른 메모리 누수의 공통적인 출처는 정적 객체의 이벤트 핸들러를 등록 해제할 때 무시되는 것입니다. 만약 그런 이벤트 핸들러가 등록 해제되지 않을 경우, 가비지 컬렉터에 의해 정리될 수 없습니다. 사용자가 검색 결과의 세부 정보 및 검색 결과 페이지 자체 사이에서 앞 뒤로 이동하는 검색 결과 페이지를 상상해보시기 바랍니다. 세부 정보 페이지가 생명 주기가 긴 객체를 참조하는 경우 사용자가 다시 뒤로 이동해도 메모리에 계속 상주해있을 수 있습니다. 이러한 누수를 방지하기 위해서는 더 이상 필요하지 않게 되었을 때 정적 객체의 이벤트 핸들러를 등록 해제해야 합니다. OnRemovedFromJournal은 뒤로 가기 탐색을 통해서 뿐만 아니라 뒤로 가기 스택 조작 API를 통해 페이지 클로저 처리 이후 작업을 수행하기 위해 권장되는 곳입니다.

또한, 이미지의 사용을 같이 하는 것이 효율적입니다. 여러분의 UI 안에서 고해상도 이미지를 불러올 때 필요한만큼 작은 컨테이너에 맞게 크기를 축소하면 더 많은 메모리를 덜 사용할 수 있습니다.

기능 저하 처리

일반적인 배경 에이전트(PeriodicTasks/ResourceIntensiveTasks)를 끄면, 256MB 장치의 전경을 위한 RAM을 확보할 수 있습니다.

현재의 장치들은 사용자가 설정 패널을 통해 수동으로 앱의 배경 에이전트를 끌 수 있습니다. 그리고 시스템은 지원 가능한 배경 에이전트가 최대 개수를 초과되는 경우 앱의 배경 에이전트를 끌 수 있습니다. 이러한 상황은 앱이 InvalidOperationException을 반드시 처리하여 이를 통해 앱을 표면화하게 합니다.

256MB 장치에서, 앱은 배경 에이전트를 예약하려고 할 때(지원 가능 배경 에이전트의 최대 개수가 0이기 때문에) 최대 범위 초과의 경우와 같은 InvalidOperationException을 받습니다. 이것이 의미하는 것은 앱이 최대 개수 초과를 처리하기 위해 작성된 경우 256MB 장치에서 바꾸지 않고 계속 일을 할 수 있는 것을 의미합니다.

여러분의 앱이 이 예외 경로와 기능을 사용할 경우 성능 저하가 있는지 확인합니다. 이것은 현재의 세대뿐 아니라 새로운 낮은 비용의 장치 모두에게 앱을 경험할 수 있도록 해줍니다. WPSDK 7.1.1에서 소개된 256MB 에뮬레이터는 여러분의 코드 경로를 쉽게 테스트할 수 있도록 해줍니다.

추가적으로 여러분은 메모리 사용을 추적하여 낮은 메모리를 갖는 장치에 감소/수정하는 기능을 원할 수 있습니다. WebBrowserMaps 컨트롤에서 메모리를 강조하려는 경우 WebBrowserTaskBingMapsTask를 사용하면, 네이티브 프로세스로부터 여러분의 메모리 사용을 추적하여 여러분의 앱에서 Out-Of-Memory가 사용자의 상호 작용에 의해 발생할 수 있는 가능성을 감소할 수 있습니다. 만약 사용자화된 지도 경험이 여러분의 메모리에 중요한 경우, 낮은 비용의 장치에서 Maps 컨트롤에 적은 오버레이를 추가하여 약간의 메모리를 아끼는데 도움이 될 수 있습니다. 여러분의 앱이 이미 256MB 장치를 위한 90MB 인증 조건을 충족하는 경우 이러한 절감은 불필요할 수 있습니다.

사용자 입력에 응답

UI 반응은 사용자가 기본적으로 예상하는 앱의 기능입니다. 이에 대한 기본적인 가이드는 절대적으로 불필요해질 때까지 UI 스레드의 활동을 가능한 많이 유지하는 것입니다.

페이지 로드 시간을 유지하고 앱 내에서 탐색 반응이 있을 때 첫 번째 프레임이 렌더링 될 때까지 로드 활동을 연기합니다. 여러분의 MainPage(상층부)의 시작 시간을 최적화 하기 위한 가이드는 후속 페이지 로드의 시작 시간 최적화에도 잘 적용이 됩니다. 추가적으로, 사용자의 경험뿐 아니라 느낌이 좀 더 First-party 앱과 비슷하도록 입력을 반영하기 위해 TiltEffect를 활용합니다.

많은 앱은 앱 내 탐색에 스타일을 추가하고 전환 애니메이션을 추가합니다. 이것은 여러분의 앱을 보다 역동적이게 만들 수 있는 좋은 시도이지만, 전환 애니메이션의 과다한 사용은 로드 시간을 지연시키며, 특히 메모리/CPU 사용량에서 생성/실행을 망칠 수 있습니다. 스타일과 성능 사이의 균형을 잡는 것은 앱에 따라 결정을 해야 합니다. 만약 애니메이션이 여러분의 앱에서 성능 문제를 일으킨다면 전환 애니메이션을 완전히 비활성화하거나, 낮은 비용의 장치에서만사용할 수 있게 하는 경우 크게 탐색 성능을 향상시킬 수 있습니다.

결론

이러한 원칙에 따라, 여러분은 목표 시장에 상관없이 여러분의 Windows Phone 앱이 사용자에 상관 없이 좋은 경험을 할 수 있도록 해줍니다. 뿐만 아니라 이러한 최적화는 낮은 비용의 휴대폰에서 극대화된 성능을 낼 수 있게 해주지만, 현재 세대의 장치에서도 잘 작동하게 만들어줍니다. 추가적으로 256MB 장치의 런타임 동작은 256MB 에뮬레이터를 활용해 테스트할 수 있습니다. 가장 중요한 것은, Windows Phone을 위한 재미있는 것을 만드는 것입니다. 우리는 여러분이 Windows Phone 마켓플레이스에 가져올 수 있는 멋진 경험을 볼 수 있기를 기대합니다.
0 Comments
댓글쓰기 폼