이 문서의 내용
+-
+
- 미리 보기 SDK +
- 개발자 관련 문서 +
- 하드웨어 시스템 이미지 +
+ Android M 미리 보기 SDK에는 개발 도구, Android 시스템 파일 및 라이브러리 파일이 포함되어 있어 앱을 테스트하고 플랫폼의 다음 릴리스에 도입되는 새 API를 테스트하는 데 유용합니다. + 이 문서에서는 미리 보기의 다운로드할 수 있는 구성 요소를 가져와 앱을 테스트하는 방법에 대해 설명합니다. + +
+ + +미리 보기 SDK
+ ++ 미리 보기 SDK는 Android SDK Manager를 통해 다운로드할 수 있습니다. 미리 보기 SDK를 다운로드하고 구성하는 데 관한 자세한 정보는 미리 보기 SDK 설정하기를 참조하십시오. + +
+ + +개발자 관련 문서
+ ++ 개발자 관련 문서 다운로드 패키지에서는 자세한 API 참조 정보와 미리 보기에 대한 API 차이점 보고서를 제공합니다. +
+ +| 설명 | +다운로드/체크섬 | +
|---|---|
| Android M 미리 보기 개발자 문서 |
+ m-preview-1-developer-docs.zip + MD5: b65201b0d35416f5a1b7a071b52854a7 + SHA-1: d47e856aa65e06897e6edd902ad8d2b1f05ac3ec + |
+
| 기기 | +다운로드/체크섬 | +
|---|---|
| Nexus 5(GSM/LTE) "hammerhead" |
+ hammerhead-MPZ44Q-preview-55d76d3a.tgz + MD5: 9e2631b06c6525e401ceaae3677ff320 + SHA-1: 55d76d3a379b18f3363f28d8a462c236ab96fc36 + |
+
| Nexus 6 "shamu" |
+ shamu-MPZ44Q-preview-c1d6506a.tgz + MD5: 307cbf9dab0a38df4ab2639d02be12aa + SHA-1: c1d6506a74094bdb2f4b8677c7fe4967334f9ea8 + |
+
| Nexus 9 "volantis" |
+ volantis-MPZ44Q-preview-d15ad483.tgz + MD5: fae40377fd999d2b09128665c915264d + SHA-1: 7ab05f96093b2cb370b226f65931202714cbc2ca + |
+
| Nexus Player "fugu" |
+ fugu-MPZ44Q-preview-2406ba05.tgz + MD5: 815902141a85cc65e7725f005cad31d5 + SHA-1: 2406ba0598dea1e69110497ac0bc8e16789bc8fb + |
+
기기에 이미지 설치
+ ++ 기기 이미지를 테스트용으로 사용하려면, 이를 호환되는 기기에 설치해야만 합니다. 시스템 이미지를 설치하려면 아래의 지침을 따르십시오. + +
+ +-
+
- 여기 목록에 나열된 시스템 이미지 중 하나를 다운로드하여 압축을 해제합니다. +
- 기기에서 보존하고자 하는 데이터를 모두 백업합니다. +
- 이미지를 기기에 플래시하려면 developers.google.com/android에 있는 지침을 따릅니다. + + +
+ 참고: 일단 개발 기기에 미리 보기 시스템 이미지를 플래시하고 나면 이것은 OTA(over-the-air) 업데이트를 통해 다음 미리 보기 릴리스에 맞춰 자동으로 업그레이드됩니다. + +
+ +기기를 공장 사양으로 되돌리기
+ ++ 미리 보기의 설치를 제거하고 기기를 공장 사양으로 되돌리고자 하는 경우, developers.google.com/android를 방문하여 기기에 플래시하고자 하는 이미지를 다운로드하십시오. + + 해당 페이지에 있는 지침을 따라 기기에 이미지를 플래시하면 됩니다. + +
+ + + + + + + + diff --git a/docs/html-intl/intl/ko/preview/features/app-linking.jd b/docs/html-intl/intl/ko/preview/features/app-linking.jd new file mode 100644 index 0000000000000..0e23801b5b435 --- /dev/null +++ b/docs/html-intl/intl/ko/preview/features/app-linking.jd @@ -0,0 +1,123 @@ +page.title=앱 링크 +page.image=images/cards/card-app-linking_2x.png +page.keywords=applinking, 딥 링크, 인텐트 +@jd:body + +이 문서의 내용
+-
+
- 웹사이트 연관 선언 +
- 앱 링크 확인 요청 +
- 앱 링크 설정 관리 +
+ Android 인텐트 시스템은 유연한 메커니즘이라 앱이 콘텐츠와 요청을 처리할 수 있습니다. + 여러 개의 앱이 자신의 인텐트 필터에서 모두 일치하는 URI 패턴을 선언할 수 있습니다. 사용자가 기본 시작 처리자가 없는 웹 링크를 클릭하는 경우 플랫폼이 대화창을 표시하여 해당 사용자가 일치하는 인텐트 필터를 선언한 앱 목록에서 선택 할 수 있습니다. + + +
+ ++ Android M 개발자 미리 보기에서는 앱 링크에 대한 지원을 도입합니다. 이를 통해 앱 개발자들이 앱을 본인이 소유한 웹 도메인과 연관시켜 기존의 링크 처리를 한 단계 개선합니다. + 개발자가 이 연관 관계를 생성하면 플랫폼이 특정 웹 링크를 처리하는 데 사용된 기본 앱을 알아서 판단하여 사용자에게 물어보는 과정을 건너뛸 수 있습니다. + + +
+ + +웹사이트 연관 선언
+ ++ 웹사이트 소유자가 앱 링크를 설정하려면 앱과의 연관 관계를 선언해야 합니다. 사이트 소유자는 앱에 대한 이러한 관계를 선언하는 데 JSON 파일을 호스팅하는 방식을 씁니다. 일명 {@code statements.json}이라는 파일을 도메인에서 잘 알려진 위치에 선언합니다. + + +
+ +http://<domain>:<optional port>/.well-known/statements.json+ +
+ 참고: + M 개발자 미리 보기 기간 중에는 JSON 파일을 http 프로토콜을 통해 확인합니다. 플랫폼이 공식적으로 출시되면 이 파일을 암호화된 https 프로토콜에서 확인하게 됩니다. + +
+ ++ 이 JSON 파일은 이 도메인 아래에서 URL에 대한 기본 처리자로 사용되어야 하는 Android 앱을 나타냅니다. + 이것이 앱을 식별하는 기반은 다음과 같은 필드입니다. +
+ +-
+
- {@code package_name}: 앱의 매니페스트에 선언된 패키지 이름입니다. + +
- {@code sha256_cert_fingerprints}: 앱의 서명 인증서의 SHA256 지문입니다.
+ Java keytool을 사용하여 이 지문을 생성하려면 다음과 같은 명령을 사용십시오.
+
keytool -list -v -keystore my-release-key.keystore
+
+
+ 다음 파일 목록은 +{@code statements.json} 파일의 콘텐츠와 형식을 예를 들어 나타낸 것입니다. +
+ +
+[{
+ "relation": ["delegate_permission/common.handle_all_urls"],
+ "target": {
+ "namespace": "android_app",
+ "package_name": "<package name>",
+ "sha256_cert_fingerprints": ["6C:EC:C5:0E:34:AE....EB:0C:9B"]
+ }
+}]
+
+
+
+앱 링크 확인 요청
+ ++ 앱은 플랫폼에 자신의 인텐트 필터의 데이터 요소 내에서 호스트 이름으로 정의된 모든 앱 링크를 자동으로 확인해달라고 요청할 수 있습니다. 이때 비교 대상은 각각의 웹 도메인에서 호스팅된 {@code statements.json} 파일입니다. + + 앱 링크 확인을 요청하려면 매니페스트에서 원하는 인텐트 필터 각각에 {@code android:autoVerify} +특성을 하나씩 추가하면 됩니다. 다음 매니페스트 코드 조각에 나타낸 내용을 참고하십시오. + +
+ ++<activity ...> + <intent-filter android:autoVerify="true"> + <action android:name="android.intent.action.VIEW" /> + <category android:name="android.intent.category.DEFAULT" /> + <category android:name="android.intent.category.BROWSABLE" /> + <data android:scheme="http" android:host="www.android.com" /> + <data android:scheme="https" android:host="www.android.com" /> + </intent-filter> +</activity> ++ +
+ 앱 매니페스트에 {@code android:autoVerify} 특성이 있으면, 플랫폼은 앱이 설치된 시점에 앱 링크를 확인하려 시도합니다. + 플랫폼이 앱 링크를 성공적으로 확인하지 못하면 해당 앱은 웹 링크를 처리하기 위한 기본 설정 앱으로 설정되지 않습니다. + 다음번에 사용자가 그런 링크 중 하나를 열면, 플랫폼은 사용자에게 메시지를 표시하는 방식으로 변경합니다. + + +
+ ++ 참고: 테스트 중에는 확인에 실패하고 나서 거짓 긍정 결과가 나올 가능성이 있지만, 사용자가 앱에 물어보지 않고 지원되는 링크를 열도록 명시적으로 활성화해 놓았고 이때 시스템 설정 앱을 사용한 경우, 대화창이 표시되지 않고 링크는 개발자 본인의 앱으로 이동하지만 이는 순전히 사용자 설정 때문이고 확인이 성공해서가 아닙니다. + + + +
+ + +앱 링크 설정 관리
+ ++ 사용자가 앱 링크 설정을 변경하여 URL을 본인이 선호하는 방식으로 처리하도록 할 수 있습니다. 앱 링크를 검토하고 관리하려면 설정 > 앱 > 앱 정보 > 기본으로 열기 아래의 시스템 설정 앱에서 하면 됩니다. + + +
diff --git a/docs/html-intl/intl/ko/preview/index.jd b/docs/html-intl/intl/ko/preview/index.jd new file mode 100644 index 0000000000000..15b14f9609742 --- /dev/null +++ b/docs/html-intl/intl/ko/preview/index.jd @@ -0,0 +1,67 @@ +page.title=Android M 개발자 미리 보기 +page.tags="preview", +meta.tags="preview, M preview", androidm +fullpage=true +section.landing=true +header.hide=1 +footer.hide=1 +@jd:body + +
+ Android M 개발자 미리 보기
++ Android의 다음 버전을 만나볼 준비가 되셨습니까? 여러분의 앱을 Nexus 5, 6, 9 및 Player에서 테스트해보십시오. + 새로운 내용은 무엇인지 둘러보십시오. 런타임 권한, Doze 및 앱 대기 모드 절전 기능, 새로 나온 지원 기술, 이외에도 많은 것이 있습니다. + + +
+ + + + 지금 시작하세요! ++
+Android SDK 미리보기를 시작하려면 우선 다음과 같은 사용 약관에 동의해야 합니다. 아래에 설명한 바와 같이, 이것은 Android SDK의 미리 보기 버전이며 변경될 가능성이 있고 이를 사용하는 위험 부담은 계약자 본인에게 있음을 유의하십시오. + Android SDK 미리보기는 안정된 릴리스가 아니며, 오류나 결함이 들어있을 수 있고 이 때문에 컴퓨터 시스템, 기기 및 데이터에 심각한 손상을 초래할 수 있습니다. +
+ ++이것은 Android SDK 미리 보기 라이선스 계약서입니다(이하 "라이선스 계약"). +
++ 다음 코드 샘플은 M 개발자 미리 보기를 위해 제공된 것입니다. Android Studio에서 샘플을 다운로드하려면 파일 > 샘플 가져오기 메뉴 옵션을 선택하십시오. + +
+ ++ 참고: 이러한 다운로드 가능한 프로젝트는 Gradle 및 Android Studio와 함께 쓰도록 만들어진 것입니다. + +
+ + +런타임 권한
+ ++ Android M은 시스템 권한이 작동하는 방식을 확 바꾸어 놓습니다. 사용자는 설치 중이 아니라 런타임에 권한 요청을 승인해 달라는 요청을 받습니다. + 이 샘플은 이와 같은 권한을 요청하는 방법을 나타낸 것입니다. + +
+ + + +확인 자격 증명
+ ++ 이 샘플은 앱에서 기기 자격 증명을 인증 방법으로 사용하는 법을 나타낸 것입니다. +
+ + + +지문 대화창
+ ++ 이 샘플은 앱에서 사용자를 인증하기 위해 등록된 지문을 인식하는 방법을 나타낸 것입니다. + +
+ + + +앱용 자동 백업
+ ++ Android M은 앱 설정에서 사용할 수 있는 자동 백업을 도입합니다. 이 샘플은 설정 백업을 관리하기 위해 앱에 필터링 규칙을 추가하는 방법을 나타낸 것입니다. + +
+ + + +카메라 2 RAW
+ +
+ Camera2 API를 사용해 RAW 카메라 버퍼를 캡처하고 이를 DNG 파일로 저장하는 법을 나타낸 것입니다.
+
+
활성 알림
+ +
+ 이 샘플은 NotificationManager를 사용하여 앱이 현재 표시하고 있는 알림 수가 몇 개인지 알게 되는 원리를 나타낸 것입니다.
+
+
+
이 문서의 내용
+ +M 개발자 미리 보기 SDK는 Android SDK Manager에서 이용할 수 있습니다. 이 문서에서는 독자 여러분이 Android 앱 개발, 예를 들어 Android SDK Manager 사용이나 프로젝트 생성 등에 익숙하다고 가정합니다. + + Android를 처음 사용하시는 경우, 우선 첫 앱 구축하기 학습 단원부터 참조하십시오. + +
+ +Android Studio 1.3 가져오기
+ +개발자 미리 보기는 역시 미리 보기 상태인 Android Studio 1.3과 함께 사용하는 것이 가장 좋습니다. + Android Studio 1.3의 미리 보기 버전을 설치하여 미리 보기 SDK 작업에 사용하는 것을 적극 추천합니다. +
+ +주의: Android Studio 1.3의 카나리아 미리 보기는 아직도 활발히 개발 중인 상태입니다. + 기본 개발 머신을 사용하여 개발자 미리 보기를 테스트하는 경우, 두 번째 Android Studio 설치를 하나 더 생성해 테스트에 사용하면 됩니다. + +
+ +Android Studio 1.3 미리 보기를 설치하려면 다음과 같이 하면 됩니다.
+ +-
+
- Android Studio를 다운로드하여 시작합니다. + + + +
- 설정 창을 엽니다(또는 Windows의 경우 파일 > 설정을 선택해도 됩니다).
+ 외관 및 동작 > 시스템 > 설정 > 업데이트 패널을 선택하십시오.
+
+
+
+
OSX의 경우, 외관 및 동작 패널은 Android Studio의 기본 설정 창에 있습니다. + +
+
+
+ - 업데이트 패널에서 다음에 대해 업데이트 자동 확인: + Canary 채널이라는 선택 사항을 선택합니다. + + +
- 업데이트 패널에서 지금 확인을 선택하여 최신 카나리아 빌드를 확인합니다. + 메시지가 표시되면 빌드를 다운로드하고 설치하십시오. + + +
미리 보기 SDK 가져오기
+ +개발 환경에 미리 보기 SDK 구성 요소를 추가하려면 다음과 같이 하면 됩니다.
+ +-
+
- Android Studio 1.3 미리 보기를 시작합니다. + + +
- 설정 창을 엽니다(또는 Windows의 경우 파일 > 설정을 선택해도 됩니다).
+ 외관 및 동작 > 시스템 > 설정 > 업데이트 패널을 선택하십시오.
+
+
+
+
OSX의 경우, 외관 및 동작 패널은 Android Studio의 기본 설정 창에 있습니다. + +
+
+
+ - 업데이트 패널에서 다음에 대해 업데이트 자동 확인: + Canary 채널 및 Android SDK에 대한 업데이트 자동 확인: + 미리 보기 채널 선택 사항을 선택합니다. + + +
- Android SDK Manager를 시작합니다 (Android Studio 1.3에서는 SDK Manager가 독립 실행형 애플리케이션이 아니고 Android Studio에 통합되어 있습니다). + + + + +
- 플랫폼 섹션 아래에서 Android MNC 미리 보기를 선택하십시오. + + + +
- 도구 섹션에서 최신 Android SDK 도구, 플랫폼-도구, 및 빌드-도구를 선택합니다. + + + + +
- 패키지 설치를 클릭하고 패키지 전체에 대해 라이선스 사용 계약을 수락합니다. + + + +
- M 개발자 미리 보기가 설치되었는지 확인하려면 설정 창을 열고 외관 및 동작 > 시스템 설정 > Android SDK 패널을 선택하면 됩니다. + + + +
- Android SDK 패널에서 SDK 플랫폼 탭을 선택합니다. + Android MNC 미리 보기가 설치됨 아래 목록으로 나열되어 있는 것이 정상입니다. + 또한, SDK 도구 탭을 열어 최신 도구가 설치되었는지 확인하십시오. + + + +
이러한 단계를 완료하고 나면 미리 보기 구성 요소를 본인의 개발 환경에서 이용할 수 있습니다. +
+ + +프로젝트 생성 또는 업데이트
+ ++ 미리 보기 API를 사용하려면 개발 프로젝트를 하나 생성하거나 업데이트하여 미리 보기 구성 요소를 사용해야 합니다. + +
+ + +새 프로젝트 생성하기
+ ++ 미리 보기로 프로젝트를 생성하려면 Android Studio를 사용할 것을 권장합니다. 프로젝트 생성하기에 설명되어 있는 단계를 쭉 따라가다 보면 프로젝트 마법사의 폼 팩터 화면에 도달합니다. + + 그러면 다음과 같은 단계를 따라 미리 보기에 맞게 구성된 프로젝트를 생성하면 됩니다. + +
+ +-
+
- 전화기 및 태블릿을 확인합니다. +
- MNC: Android M(미리 보기)를 선택합니다. 이것은 최소 SDK 안에 있습니다. + +
기존 프로젝트 업데이트
+ +
+ 기존 프로젝트의 경우, 미리 보기 API를 활성화하려면 프로젝트 구성을 수정해야 합니다. 개발 환경에서 본인의 모듈에 대한 build.gradle 파일을 열고 다음의 값을 다음과 같이 설정합니다.
+
+
+
-
+
compileSdkVersion을'android-MNC'로 설정
+ minSdkVersion을'MNC'로 설정
+ targetSdkVersion을'MNC'로 설정
+
테스트를 위해 설정
+ ++ 앱을 미리 보기로 테스트하려면 플랫폼의 미리 보기 버전으로 구성한 기기 또는 가상 기기가 있어야 합니다. + 호환되는 기기를 가지고 있으면 미리 보기 플랫폼을 설치하여 테스트에 쓰면 됩니다. + 그렇지 않은 경우, 가상 기기를 구성하여 테스트에 사용할 수도 있습니다. +
+ +물리적 기기 설정
+ ++ Nexus 5, Nexus 6, Nexus 9 또는 Android TV를 가지고 있는 경우, 이들 기기에 미리 보기 시스템 이미지를 설치하여 앱을 테스트하는 데 쓸 수 있습니다. 플랫폼의 미리 보기 버전으로 가상 기기를 설정하려면 Android Studio 내에서 해당 버전을 다운로드하면 됩니다. 이때 Android 가상 기기 관리자 도구를 사용하십시오. + + + +
+ ++ 중요: 기기에 미리 보기 이미지를 설치하면 기기에서 모든 데이터를 제거하므로, 미리 보기 이미지를 설치하기에 앞서 데이터를 모두 백업하는 것이 좋습니다. + +
+ +가상 기기 설정
+ ++ 플랫폼의 미리 보기 버전으로 가상 기기를 설정하려면 Android Studio 내에서 해당 버전을 다운로드하면 됩니다. 이때 Android 가상 기기 관리자 도구를 사용하십시오. + +
+ +AVD Manager로 AVD를 생성하려면 다음과 같이 하면 됩니다.
+ +-
+
- 미리 보기 SDK 설정하기에 설명된 바에 따라 개발 환경에 미리 보기 SDK를 설치합니다. + + +
- AVD Manager로 AVD 관리하기에 나온 단계를 따르십시오.
+
+ 다음과 같은 설정을 사용하면 됩니다.
+
-
+
- 기기: Nexus 5, Nexus 6, Nexus 9 또는 Android TV +
- 대상: + Android M(미리 보기) - API 레벨 M +
- ABI: x86 +
+
+ 테스트를 위해 가상 기기를 생성하는 데 대한 자세한 정보는 가상 기기 관리하기를 참조하십시오. +
diff --git a/docs/html-intl/intl/ko/preview/support.jd b/docs/html-intl/intl/ko/preview/support.jd new file mode 100644 index 0000000000000..36d083daf1023 --- /dev/null +++ b/docs/html-intl/intl/ko/preview/support.jd @@ -0,0 +1,67 @@ +page.title=지원 +page.image=images/cards/card-support_16-9_2x.png + +@jd:body + ++ M 개발자 미리 보기에서 버그가 발생했거나 이에 대한 피드백을 보내려면 문제 추적기에서 문제를 생성해 주십시오. + + +
+ ++ 더 많은 지원이 필요하시면 M 개발자 미리 보기 Google+ 커뮤니티에 가입하여 여러분의 개발 경험에 대해 논의해보시면 좋습니다. + + +
+ +릴리스 노트
+ + + +
M 개발자 미리 보기, 수정 버전 1 (2015년 5월)
+
+
-
+
- 최초 릴리스입니다. +
이 문서의 내용
+-
+
- 권한 테스트 +
- Doze 및 앱 대기 모드 테스트 +
- 자동 백업 및 기기 식별자 +
+ Android M 개발자 미리 보기에서는 앱이 플랫폼의 다음 버전에서 제대로 작동할 것인지 확인해볼 기회를 부여합니다. + 이 미리 보기에는 앱에 영향을 미칠 수 있는 수많은 API와 동작 변경 내용이 포함되어 있습니다.이 내용은 API 개요와 동작 변경에 설명해 놓았습니다. + + 미리 보기로 앱을 테스트할 때에는 사용자에게 좋은 환경을 제공하기 위해 개발자 여러분이 꼭 주안점을 두어야 할 몇 가지 특정한 시스템 변경 내용이 있습니다. + + +
+ ++ 이 가이드는 앱에서 테스트할 미리 보기 기능은 어떤 것이고, 테스트 방법은 어떤지에 대해 설명한 것입니다. 이와 같은 특정 미리 보기 기능을 먼저 테스트하는 것이 좋습니다. 이들은 앱의 동작에 미치는 영향이 클 가능성이 높기 때문입니다. + + +
+ +-
+
- 권한 + +
- Doze 및 앱 대기 모드 + +
- 자동 백업 및 기기 식별자 +
+ 테스트용 미리 보기 시스템 이미지로 기기 또는 가상 기기를 설정하는 방법에 대한 자세한 정보는 미리 보기 SDK 설정하기를 참조하십시오. + +
+ + +권한 테스트
+ ++ 새로운 권한 모델은 사용자가 여러분의 앱에 권한을 할당하는 방법을 바꿔 놓습니다. + 설치 절차 중에 모든 권한을 허용하는 것이 아니라, 앱이 런타임에 사용자에게 각각의 권한을 요청해야 합니다. + + 사용자 입장에서는 이러한 동작으로 각 앱의 액티비티에 대해 더 세분화된 제어권을 행사할 수 있을 뿐만 아니라 이 앱이 어째서 특정한 권한을 요청하고 있는 것인지 맥락을 더 잘 이해할 수 있게 되기도 합니다. + 사용자는 언제든 앱에 개별적으로 권한을 허용할 수 있고, 이를 취소할 수도 있습니다. + 미리 보기의 이러한 기능은 앱의 동작에 영향을 미칠 가능성이 가장 높고, 앱의 몇 가지 기능이 작동하지 않도록 막거나 저하된 상태로 작동하게 할 수도 있습니다. + + +
+ ++ 이 변경 내용은 새 플랫폼에서 실행되는 모든 앱에 영향을 비치며, 새 플랫폼 버전을 대상으로 하지 않는 앱도 예외가 아닙니다. + 레거시 앱에 대해 플랫폼이 제한된 호환성 동작을 제공하기는 하지만, 지금 바로 새 권한 모델로 앱의 마이그레이션 계획을 시작하는 편이 좋습니다. 플랫폼이 공식적으로 출시될 때에 맞춰 앱의 업데이트된 버전을 게시하는 것을 목표로 하십시오. + + +
+ + +테스트 팁
+ ++ 다음은 새 권한 동작에 대해 앱 테스트를 계획하고 실행하는 데 유용한 몇 가지 테스트 팁입니다. + +
+ +-
+
- 앱의 현재 권한과 관련된 코드 경로를 확인합니다. +
- 권한 보호된 서비스 및 데이터 전반에 걸친 사용자 흐름을 테스트합니다. +
- 허용된/취소된 권한을 여러 가지로 조합하여 테스트합니다. +
- 명령줄에서 권한을 관리할 때 {@code adb} 도구를 사용합니다.
+
-
+
- 권한과 상태를 그룹별로 목록으로 나열합니다.
+
adb shell pm list permissions -d -g
+
+ - 하나 이상의 권한을 다음과 같은 구문을 사용하여 허용하거나 취소합니다.
+adb shell pm [grant|revoke] <permission.name> ...
+
+
+ - 권한과 상태를 그룹별로 목록으로 나열합니다.
+
- 권한을 사용하는 서비스에 대해 앱을 분석해봅니다. +
테스트 전략
+ ++ 권한을 변경하면 앱의 구조와 디자인은 물론 사용자 환경과, 개발자가 사용자에게 제공하는 흐름에도 영향을 미칩니다. + 앱의 현재 권한 사용 내용을 평가한 다음 제공하고자 하는 새로운 흐름을 계획하기 시작해야 합니다. + 플랫폼의 공식 릴리스에서 호환성 동작을 제공할 예정이지만, 이와 같은 동작에만 의존하지 말고 앱 업데이트를 계획하는 것이 좋습니다. + + +
+ ++ 앱이 실제로 필요로 하고 사용하는 권한을 확인한 다음, 권한 보호된 서비스를 사용하는 여러 가지 코드 경로를 찾습니다. + 이렇게 하려면 새 플랫폼에서 여러 가지로 조합한 테스트를 거치고 코드 분석을 통해야 합니다. + 테스트에서는 런타임 권한에 옵트인하는 것에 주안점을 두는 것이 좋습니다. 앱의 {@code targetSdkVersion}을 미리 보기 버전으로 변경하세요. + 자세한 정보는 미리 보기 SDK 설정하기를 참조하십시오. + +
+ ++ 불러내고 추가한 여러 가지 권한들을 다양하게 조합해서 테스트해보면 권한에 좌우되는 사용자 흐름을 강조할 수 있습니다. + 종속성이 분명하지 않거나 논리적인 경우, 리팩터링을 고려해 보거나 해당 흐름을 구분하여 종속성을 제거, 또는 해당 권한이 왜 필요한지 분명히 하는 방안을 고려해야 합니다. + + +
+ ++ 런타임 권한의 동작, 테스트 및 모범 사례에 대한 자세한 정보는 권한 개발자 미리 보기 페이지를 참조하십시오. + + +
+ + +Doze 및 앱 대기 모드 테스트
+ ++ Doze 및 앱 대기 모드의 절전 기능은 기기가 유휴 상태에 있을 때 또는 사용자가 앱에 초점을 맞추고 있지 않을 때 앱이 수행할 수 있는 배경 처리의 양을 제한합니다. + 시스템이 앱에 부과할 수 있는 제한 사항에는 네트워크 액세스를 제한하거나 없애기, 배경 작업을 일시 중지시키기, 알림 일시 중지, 절전 모드 해제 및 알람 요청 무시 등이 포함됩니다. + + 이러한 절전 기능에 앱이 적절히 동작하도록 확실히 해 두려면 이와 같은 저전력 상태를 시뮬레이트하여 앱을 테스트해보아야 합니다. + + +
+ +앱에서 Doze 테스트하기
+ +앱으로 Doze 기능을 테스트하려면 다음과 같이 하면 됩니다.
+ +-
+
- 하드웨어 기기 또는 가상 기기를 M 미리 보기 시스템 이미지로 구성합니다. +
- 기기를 개발 머신에 연결시키고 앱을 설치합니다. +
- 앱을 실행시킨 다음 활성 상태로 그냥 둡니다. +
- 기기가 Doze 모드에 들어가는 것을 시뮬레이트하려면 다음 명령을 실행하십시오.
+
+
+$ adb shell dumpsys battery unplug +$ adb shell dumpsys deviceidle step +$ adb shell dumpsys deviceidle -h +
+ +
+ - 기기가 다시 활성화되면 앱이 어떻게 동작하는지 살펴보십시오. 기기가 Doze 모드를 종료할 때 정상적으로 복구되는지 확인해야 합니다. + +
앱에서 앱 대기 모드 테스트하기
+ +앱으로 앱 대기 모드를 테스트하려면 다음과 같이 하면 됩니다.
+ +-
+
- 하드웨어 기기 또는 가상 기기를 M 미리 보기 시스템 이미지로 구성합니다. +
- 기기를 개발 머신에 연결시키고 앱을 설치합니다. +
- 앱을 실행시킨 다음 활성 상태로 그냥 둡니다. +
- 앱이 대기 모드에 들어가는 것을 시뮬레이트하려면 다음 명령을 실행하십시오.
+
+
+$ adb shell am broadcast -a android.os.action.DISCHARGING +$ adb shell am set-idle <packageName> true +
+ +
+ - 앱이 절전 모드 해제되는 상태를 시뮬레이트하려면 다음 명령을 사용하면 됩니다.
+
$ adb shell am set-idle <packageName> false
+
+ - 앱이 절전 모드에서 해제되면서 어떻게 동작하는지 살펴보십시오. 대기 모드에서 정상적으로 복구되는지 확인해야 합니다. + 특히, 앱의 알림과 배경 작업이 계속 예상했던 대로 기능하는지 확인해야 합니다. + +
앱용 자동 백업 및 기기별 식별자
+ +앱이 내부 저장소에서 각 기기에 따라 다른 식별자를 유지하는 경우(예: Google Cloud 메시지 등록 ID), 모범 사례를 따라 저장소 위치를 자동 백업에서 배제해야 합니다. 이 내용은 앱용 자동 백업에 설명되어 있습니다. + + + +
diff --git a/docs/html-intl/intl/ko/preview/testing/performance.jd b/docs/html-intl/intl/ko/preview/testing/performance.jd new file mode 100644 index 0000000000000..ce2bf27bbfc12 --- /dev/null +++ b/docs/html-intl/intl/ko/preview/testing/performance.jd @@ -0,0 +1,656 @@ +page.title=표시 성능 테스트 +page.image=images/cards/card-test-performance_2x.png +page.keywords=성능, FPS, 도구 + +@jd:body + + +이 문서의 내용
+-
+
- UI 성능 측정
+
-
+
- 프레임 상태 집계 +
- 정확한 프레임 타이밍 정보 +
- 단순한 프레임 타이밍 덤프 +
- 상태 수집 창 제어 +
- 성능 저하 진단 +
- 추가 리소스 +
+ - UI 성능 테스트 자동화
+
-
+
- UI 테스트 설정 +
- 자동화된 UI 테스트 설정 +
- 관측된 문제 심사 및 수정 +
+
+ 사용자 인터페이스(UI) 성능 테스트를 수행하면 앱이 기능적인 요건에 부합할 뿐만 아니라 사용자가 앱과 부드럽고 매끈하게 상호작용하며 초당 60 프레임의 일관된 속도로(왜 60fps일까요?) 생략되거나 지연된 프레임, 또는 전문 용어로 jank(프레임이 넘어가는 현상)가 없이 실행되게 보장할 수 있습니다. + + + 이 문서에서는 UI 성능을 측정하는 데 사용할 수 있는 몇 가지 도구를 설명하고, 테스트 방법에 UI 성능 측정법을 통합하는 데 쓰이는 접근법을 보여드립니다. + + +
+ + +UI 성능 측정
+ ++ 성능을 개선하려면 우선 시스템의 성능을 측정할 수 있는 능력부터 갖추고, 그 다음에 파이프라인의 여러 부분에서 나올 수 있는 다양한 문제를 진단하고 식별해야 합니다. + + +
+ ++ dumpsys는 Android 도구의 일종으로 기기에서 실행되면서 시스템 서비스의 상태에 대한 흥미로운 정보를 덤프하는 역할을 합니다. + + gfxinfo 명령을 dumpsys에 전달하면 기록 단계 중에 발생하는 애니메이션 프레임과 관련된 성능 정보가 담긴 logcat으로 출력을 제공합니다. + + +
+ ++> adb shell dumpsys gfxinfo <PACKAGE_NAME> ++ +
+ 이 명령은 프레임 타이밍 데이터의 서로 다른 변형을 여러 개 작성할 수 있습니다. +
+ +프레임 상태 집계
+ ++ M 미리 보기에서 이 명령은 프레임 데이터의 집계된 분석을 logcat으로 출력합니다. 이는 프로세스의 전 수명을 통틀어 수집한 것입니다. + 예를 들면 다음과 같습니다. +
+ ++Stats since: 752958278148ns +Total frames rendered: 82189 +Janky frames: 35335 (42.99%) +90th percentile: 34ms +95th percentile: 42ms +99th percentile: 69ms +Number Missed Vsync: 4706 +Number High input latency: 142 +Number Slow UI thread: 17270 +Number Slow bitmap uploads: 1542 +Number Slow draw: 23342 ++ +
+ 이와 같은 높은 레벨의 통계는 레벨이 높을 때 앱의 렌더링 성능을 나타내며, 이외에도 여러 프레임에 걸친 앱의 안정성을 나타내기도 합니다. + +
+ + +정확한 프레임 타이밍 정보
+ ++ M 미리 보기에서는 gfxinfo에 사용할 수 있는 새 명령어를 도입했습니다. 바로 framestats로, 이는 최근 프레임으로부터 극히 상세한 프레임 타이밍 정보를 제공하여 문제를 더욱 정확하게 추적하고 디버그할 수 있습니다. + + +
+ ++>adb shell dumpsys gfxinfo <PACKAGE_NAME> framestats ++ +
+ 이 명령은 프레임 타이밍 정보를 나노초 타임스탬프로 출력하며, 그 출처는 앱이 만든 마지막 120개의 프레임입니다. 아래는 adb dumpsys gfxinfo + <PACKAGE_NAME> framestats에서 가져온 원시 출력을 예로 나타낸 것입니다. + +
+ ++0,49762224585003,49762241251670,9223372036854775807,0,49762257627204,49762257646058,49762257969704,49762258002100,49762265541631,49762273951162,49762300914808,49762303675954, +0,49762445152142,49762445152142,9223372036854775807,0,49762446678818,49762446705589,49762447268818,49762447388037,49762453551527,49762457134131,49762474889027,49762476150120, +0,49762462118845,49762462118845,9223372036854775807,0,49762462595381,49762462619287,49762462919964,49762462968454,49762476194547,49762476483454,49762480214964,49762480911527, +0,49762479085548,49762479085548,9223372036854775807,0,49762480066370,49762480099339,49762481013089,49762481085850,49762482232152,49762482478350,49762485657620,49762486116683, ++ +
+ 이 출력의 각 줄은 앱이 만든 프레임을 나타냅니다. 각 줄에는 정해진 숫자의 열이 있으며 이 열은 프레임 제작 파이프라인의 각 단계에서 소요한 시간을 나타냅니다. + 다음 섹션에서는 각 열이 무엇을 나타내는지 등, 이 형식에 대해 좀 더 자세히 다뤄보겠습니다. + +
+ + +Framestats 데이터 형식
+ ++ 데이터 블록은 CSV 형식으로 출력되기 때문에 이를 개발자가 선택한 스프레드시트 도구에 붙여넣거나 수집해서 스크립트로 구문 분석하기 등의 작업이 매우 단도직입적입니다. + 다음 표는 출력 데이터 열의 형식을 설명한 것입니다. + 타임스탬프는 모두 나노초 단위입니다. +
+ +-
+
- 플래그
+
-
+
- 플래그 열에 '0'이 기재되어 있는 행의 경우, 총 프레임 시간을 계산하려면 FRAME_COMPLETED 열에서 INTENDED_VSYNC 열을 빼면 됩니다. + + + +
- 이것이 0이 아니면 그 행은 무시해야 합니다. 해당 프레임이 정상 성능의 이상값인 것으로 판별되었기 때문이며, 여기에서는 레이아웃과 그리기에 16ms 이상이 걸릴 것으로 예상됩니다.
+
+ 다음은 이런 일이 일어나는 몇 가지 이유입니다.
+
-
+
- 창 레이아웃이 변경되었습니다(애플리케이션의 첫 프레임 또는 한 회 회전 이후). + + + +
- 프레임을 건너뛰었을 가능성도 있습니다. 이 경우 몇몇 값에 가비지 타임스탬프가 있을 것입니다. + 프레임을 건너뛰는 것은 해당 프레임이 60fps를 초과하는 경우 또는 화상에 나타난 것 중 아무 것도 변한 것이 없을 때 등이며, 이는 반드시 앱에 문제가 있음을 나타내는 징후는 아닙니다. + + + +
+
+
+ - INTENDED_VSYNC
+
-
+
- 프레임에 대한 원래 의도한 시작 지점입니다. 이 값이 VSYNC와 다른 경우, UI 스레드에서 발생한 작업이 있어 이것이 vsync 신호에 적절한 시간 내에 응답하지 못하도록 한 것입니다. + + + +
+
+ - VSYNC
+
-
+
- Vsync 수신기 전체와 프레임에 대한 드로잉에서 사용된 시간 값입니다.(Choreographer 프레임 콜백, 애니메이션, View.getDrawingTime() 등) + + + +
- VSYNC와 이것이 애플리케이션에 미치는 영향에 대해 더 자세히 알아보려면 VSYNC 이해하기 비디오를 확인하십시오. + + + +
+
+ - OLDEST_INPUT_EVENT
+
-
+
- 입력 대기열에서 가장 오래된 입력 이벤트의 타임스탬프 또는 프레임에 대한 입력 이벤트가 없는 경우 Long.MAX_VALUE입니다. + + + +
- 이 값은 기본적으로 플랫폼 작업을 위해 의도된 것이며 앱 개발자에게는 한정된 정도로 유용한 값입니다. + + +
+
+ - NEWEST_INPUT_EVENT
+
-
+
- 입력 대기열에서 가장 최근 입력 이벤트의 타임스탬프 또는 프레임에 대한 입력 이벤트가 없는 경우 Long.MAX_VALUE입니다. + + + +
- 이 값은 기본적으로 플랫폼 작업을 위해 의도된 것이며 앱 개발자에게는 한정된 정도로 유용한 값입니다. + + + +
- 다만 앱이 얼마나 긴 대기 시간을 추가하고 있는지를 대략적으로 알아볼 수는 있습니다. (FRAME_COMPLETED - NEWEST_INPUT_EVENT)를 살펴보면 됩니다. + + +
+
+ - HANDLE_INPUT_START
+
-
+
- 입력 이벤트가 애플리케이션에 발송된 시점의 타임스탬프입니다. + + +
- 이것과 ANIMATION_START 사이의 시간을 보면 애플리케이션이 입력 이벤트를 처리하느라 보낸 시간을 측정할 수 있습니다. + + + +
- 이 숫자가 크면(2ms 초과) 이는 앱이 입력 이벤트를 처리하느라 보기 드물게 긴 시간을 소요한다는 뜻입니다. 예를 들어 View.onTouchEvent()는 이 작업을 최적화해야 하거나 다른 스레드로 오프로드해야 한다는 뜻일 수 있습니다. + + 다른 시나리오도 몇 가지 있을 수 있다는 점을 유의하십시오. 예를 들어 새 액티비티를 시작하는 클릭 이벤트나 그와 비슷한 것의 경우, 이 숫자가 클 것을 예상하고 받아들일 수 있습니다. + + + +
+
+ - ANIMATION_START
+
-
+
- Choreographer에 등록된 애니메이션이 실행된 시점의 타임스탬프입니다. + + +
- 이것과 PERFORM_TRANVERSALS_START 사이의 시간을 보면 실행 중인 애니메니터 전체((ObjectAnimator, ViewPropertyAnimator 및 Transitions가 보편적인 것들임)를 평가하는 데 시간이 얼마나 걸렸는지 판단할 수 있습니다. + + + + +
- 이 숫자가 크면(2ms 초과), 앱이 사용자 지정 애니메이터를 작성한 적이 있는지 확인하십시오. 아니면 ObjectAnimators가 애니메이션 효과를 실행하는 필드가 어느 것인지 알아보고 이들이 애니메이션에 대해 적절한지 확인해야 합니다. + + + + +
- Choreographer에 대한 자세한 정보는 버터거나 나쁘거나(For Butter or Worse) 비디오를 참조하십시오. + + +
+
+ - PERFORM_TRAVERSALS_START
+
-
+
- 이 값에서 DRAW_START를 빼면 레이아웃과 측정 단계를 완료하는 데 얼마나 걸렸는지 추출할 수 있습니다(스크롤 또는 애니메이션 중에는 이 값이 0에 가까울 것이라는 예상이 나와야 한다는 점을 유의하십시오). + + + + +
- 렌더링 파이프라인의 측정 및 레이아웃 단계에 대한 자세한 정보는 무효화, 레이아웃 및 성능 비디오를 참조하십시오. + + + +
+
+ - DRAW_START
+
-
+
- PerformTraversals의 그리기 단계가 시작된 시점입니다. 이것은 무효화된 모든 보기의 표시 목록을 기록하는 시작 지점입니다. + + + +
- 이것과 SYNC_START 사이의 시간이 트리의 모든 무효화된 보기에서 View.draw()를 호출하는 데 걸린 시간입니다. + + + +
- 드로잉 모델에 대한 자세한 정보는 하드웨어 가속 또는 무효화, 레이아웃 및 성능 비디오를 참조하십시오. + + + +
+
+ - SYNC_START
+
-
+
- 드로잉의 동기화 단계가 시작된 시점입니다. + + +
- 이것과 ISSUE_DRAW_COMMANDS_START 사이의 시간이 상당히 큰 값인 경우(0.4ms 초과 또는 그와 유사), 일반적으로 새로운 비트맵이 많이 그려져서 이를 GPU에 업로드해야 한다는 뜻입니다. + + + + +
- 동기화 단계에 대해 더 자세히 알아보려면 프로필 GPU 렌더링 비디오를 참조하십시오. + + +
+
+ - ISSUE_DRAW_COMMANDS_START
+
-
+
- 하드웨어 렌더러가 GPU에 드로잉 명령을 발행하기 시작한 시점입니다. + + +
- 이것과 FRAME_COMPLETED 사이의 시간을 보면 앱이 얼마나 많은 GPU 작업을 생성하고 있는지 대략적으로 알 수 있습니다. + Overdraw가 너무 많거나 렌더링 효과가 비효율적인 것 등의 문제가 여기에 나타납니다. + + +
+
+ - SWAP_BUFFERS
+
-
+
- EglSwapBuffers가 호출된 시점으로, 플랫폼 작업 외에는 비교적 흥미롭지 않습니다. + + +
+
+ - FRAME_COMPLETED
+
-
+
- 모두 끝났습니다! 이 프레임에 작업하느라 소요된 총 시간을 계산하려면 FRAME_COMPLETED - INTENDED_VSYNC를 수행하면 됩니다. + + +
+
+
+ 이 데이터는 여러 가지 방법으로 사용할 수 있습니다. 한 가지 단순하면서도 유용한 시각화는 프레임 시간의 분배(FRAME_COMPLETED - INTENDED_VSYNC)를 여러 가지 대기 시간 버킷에서 표시한 히스토그램을 예로 들 수 있습니다. 아래 그림을 참조하십시오. + + 이 그래프를 보면 한 눈에 대부분의 프레임이 아주 양호했다는 것을 알아볼 수 있습니다. 대부분 16ms 최종 기한(빨간색으로 표시)보다 한참 아래에 있지만, 최종 기한을 크게 넘어선 프레임도 몇 개 있습니다. + + 이 히스토그램에서 시간 경과에 따른 변화를 살펴보면 대규모 이동이나 새 이상값이 생성되는 것을 확인할 수 있습니다. + 이외에도 데이터 내의 수많은 타임스탬프를 근거로 입력 대기 시간, 레이아웃에서 보낸 시간 또는 여타 비슷한 흥미로운 메트릭도 그래프로 표현할 수 있습니다. + + +
+ +
+
+
+단순한 프레임 타이밍 덤프
+ +
+ 프로필 GPU 렌더링이 개발자 옵션에서 adb 셸의 dumpsys gfxinfo로 설정된 경우, adb shell dumpsys gfxinfo 명령이 가장 최근의 120개 프레임에 대한 타이밍 정보를 출력하되, 몇 개의 서로 다른 카테고리로 나누어 탭으로 구분된 값을 담아 표현합니다.
+
+
+ 이 데이터를 사용하면 드로잉 파이프라인의 어떤 부분이 레벨이 높을 때 느려지는지 나타내는 데 유용합니다.
+
+
+ 위의 framestats와 마찬가지로, 이것을 개발자가 선택한 스프레드시트 도구에 붙여넣거나 수집해서 스크립트로 구문 분석하는 작업은 매우 단도직입적입니다. + + 다음 그래프는 앱이 생성한 수많은 프레임이 어디에서 시간을 보내는지 분석한 내용을 표시한 것입니다. + +
+ +
+
++ Gfxinfo를 실행한 결과, 그 출력을 복사하여 이를 스프레드시트 애플리케이션에 붙여넣은 다음 데이터를 누적 가로 막대형 그래프로 나타내는 것입니다. + +
+ ++ 각 세로 막대는 애니메이션 한 프레임을 나타냅니다. 그 막대의 높이가 해당 애니메이션 프레임을 계산하는 데 걸린 밀리초 수를 나타냅니다. + 막대에서 색이 지정된 각 세그먼트는 렌더링 파이프라인의 각기 다른 단계를 나타내므로, 개발자는 이것을 보고 애플리케이션의 어떤 부분이 병목 현상을 유발하고 있는지 확인할 수 있습니다. + + 렌더링 파이프라인을 잘 이해하고 이에 맞게 최적화하는 법에 대한 자세한 내용은 무효화 레이아웃 및 성능 비디오를 참조하십시오. + + +
+ + +상태 수집 창 제어
+ ++ Framestats와 단순한 프레임 타이밍은 양쪽 모두 아주 짧은 시간 범위 동안 데이터를 수집합니다. 렌더링 약 2초에 상당하는 시간입니다. + 이 시간 범위를 정확하게 제어하려면(예: 데이터를 특정 애니메이션에 제한), 카운터를 모두 초기화한 다음 수집한 통계를 집계하면 됩니다. + + +
+ ++>adb shell dumpsys gfxinfo <PACKAGE_NAME> reset ++ +
+ 이 방법은 명령 자체를 덤프하는 방법과 함께 써서 정기적인 간격을 두고 수집과 초기화를 반복하여 계속해서 2초 미만의 프레임 창을 캡처하도록 하는 데 쓰일 수도 있습니다. + + +
+ + +성능 저하 진단
+ ++ 성능이 저하된 것을 알아내는 것은 문제를 추적하고 애플리케이션의 건강 상태를 높은 수준으로 유지 관리하는 데 좋은 첫 단계입니다. + 그러나 dumpsys는 문제의 존재 여부와 상대적인 심각도만 식별하는 데 그치지 않습니다. + 각 성능 문제의 제각기 다른 원인을 진단하고 이를 해결하기 위해 적절한 방법을 찾아야 하는 것은 변하지 않습니다. + 이를 위해, systrace 도구를 사용하는 것을 적극적으로 추천합니다. + +
+ + +추가 리소스
+ ++ Android의 렌더링 파이프라인의 작동 원리나 여기에서 마주칠 수 있는 보편적인 문제와 그 해결 방법에 대한 자세한 정보를 원하시면, 다음 리소스 중 몇 가지를 유용하게 쓸 수 있습니다. + + +
+ +-
+
- 렌더링 성능의 기초 + +
- 왜 60fps일까요? + +
- Android UI와 GPU + +
- 무효화 레이아웃 및 성능 + +
- Systrace로 UI 성능 분석하기 + +
UI 성능 테스트 자동화
+ ++ UI 성능 테스트에 대한 한 가지 관점은 그저 인간 테스터가 대상 앱에서 일련의 사용자 작업을 수행하도록 하는 것입니다. 그러면서 육안으로 jank가 있는지 살펴보든가, 아니면 오랜 시간을 들여 도구 중심적인 관점으로 jank를 찾아내는 것입니다. + + 하지만 이와 같은 수동식 방법은 위험 투성이입니다. 프레임 속도 변화를 인지하는 사람의 능력에는 개인차가 극명하고, 시간도 오래 걸릴 뿐더러 지루하고 오류가 발생할 가능성이 높습니다. + + +
+ ++ 보다 효율적인 접근 방식은 자동화된 UI 테스트로부터 가져온 주요 성능 메트릭을 기록하고 분석하는 것입니다. + Android M 개발자 미리 보기에는 새로운 로깅 기능이 포함되어 있어 애플리케이션 애니메이션의 jank의 양과 심각도를 판별하기 쉽고, 이를 사용해 현재 성능을 판단하고 앞으로의 성능 목표를 추적하기 위해 철저한 프로세스를 구축할 수도 있습니다. + + + +
+ ++ 이 글에서는 그러한 데이터를 사용하여 성능 테스트를 자동화하는 데 권장되는 방안을 찬찬히 알려드립니다. + +
+ ++ 이것은 주로 두 가지 주요 작업으로 나뉘어 있습니다. 첫째로 무엇을 테스트할지, 어떻게 테스트할지를 확인합니다. 그런 다음 두 번째로 자동화된 테스트 환경을 설정하고 유지 관리하는 것입니다. + + +
+ + +UI 테스트 설정
+ ++ 자동화된 테스트를 시작하기 전에 우선 몇 가지 수준 높은 결정을 내려야 합니다. 그래야 테스트 공간과 스스로에게 필요한 부분을 제대로 숙지할 수 있습니다. + +
+ ++ 테스트할 주요 애니메이션/흐름 알아내기 +
+ ++ 성능이 불량한 것이 사용자에게 가장 눈에 띄는 것은 애니메이션이 원활히 작동하지 않을 때라는 점을 명심하십시오. + 따라서, 테스트할 UI 작업 유형을 식별할 때에는 사용자가 가장 많이 접하게 되는 애니메이션이나 사용자 환경에 가장 중요한 것에 주안점을 두면 유용합니다. + + 예를 들어 다음은 이처럼 식별하는 데 유용하게 쓰일 수 있는 몇 가지 보편적인 시나리오입니다. +
+ +-
+
- 기본 ListView 또는 RecyclerView를 스크롤링 + + +
- 비동기 대기 주기 동안 표시되는 애니메이션 + + +
- 비트맵 로딩/조작이 들어 있을 수 있는 모든 애니메이션 + + +
- 알파 혼합이 포함된 애니메이션 + + +
- Canvas로 사용자 지정 보기 드로잉 + +
+ 팀 구성원인 엔지니어, 디자이너와 제품 관리자와 협력하여 이와 같이 테스트 대상 범위에 넣어야 하는 주요 제품 애니메이션의 우선 순위를 지정하십시오. + +
+ ++ 앞으로의 목표를 정의하고 그것을 추적하기 +
+ ++ 레벨이 높을 때에는 특정한 성능 목표를 알아내고 테스트 작성에 집중하며, 그에 관한 데이터를 수집하는 것이 매우 중요할 수 있습니다. + 예를 들면 다음과 같습니다. +
+ +-
+
- 처음에만 UI 성능을 추적하여 좀 더 자세히 알아보기만 했으면 합니까? + + +
- 앞으로 마주치게 될 성능 저하를 방지하고자 합니까? + + +
- 지금은 매끄러운 프레임 비율이 약 90% 정도이지만 이번 사분기 내에 98%까지 올리고자 합니까? + + +
- 지금 매끄러운 프레임이 약 98%이고 성능이 저하되지 않기를 바랍니까? + + +
- 저사양 기기에서 성능을 개선하는 것이 목표입니까? + +
+ 이 모든 경우, 애플리케이션의 여러 버전에 걸쳐 성능을 나타내주는 사용 기록 추적을 수행하는 것이 좋습니다. + +
+ ++ 테스트할 기기 정하기 +
+ ++ 애플리케이션의 성능은 어느 기기에서 실행되는지에 따라 여러 가지로 달라집니다. 메모리 용량이 적고 GPU 파워가 딸리거나 CPU 칩 속도가 느린 기기도 있습니다. + 이는 즉 한 가지 하드웨어 세트에서는 잘 작동하는 애니메이션이 다른 곳에서는 그렇지 않을 수도 있다는 뜻입니다. 더 나쁜 경우로는 파이프라인의 서로 다른 부분에서 병목 현상이 일어나는 결과를 초래할 수도 있습니다. + + 따라서, 사용자가 볼 수도 있는 이러한 변형을 감안하기 위해 테스트를 실행할 기기를 여러 가지로 선택하는 것이 중요합니다. 최신 고사양 기기, 저사양 기기, 태블릿 등 양쪽 측면을 모두 고려하십시오. + + CPU 성능, RAM, 화면 밀도, 크기 등의 변형을 잘 살피십시오. + 고사양 기기를 통과하는 테스트가 저사양 기기에서는 실패할 수도 있습니다. + +
+ ++ UI 테스트의 기본 프레임워크 +
+ ++ UI Automator와 Espresso 등의 도구 스위트는 개발자의 애플리케이션을 통과하는 사용자의 동작을 자동화하는 데 도움이 되도록 구축된 것입니다. + + 이들은 단순한 프레임워크로, 사용자와 기기의 상호작용을 흉내 냅니다. + 이러한 프레임워크를 사용하려면, 사실상 개발자가 나름의 고유한 스크립트를 생성해야 합니다. 이는 일련의 사용자-동작을 통해 실행되고, 이를 기기 자체에서 재생합니다. + + +
+ +
+ 이렇게 자동화된 테스트를 여러 가지로 조합하여 dumpsys gfxinfo와 함께 사용하면 재현 가능한 시스템을 재빨리 만들어내 테스트를 실행하고 해당 조건 하에서 성능 정보를 측정할 수 있습니다.
+
+
+
자동화된 UI 테스트 설정
+ ++ UI 테스트를 실행할 수 있게 되고, 한 번의 테스트로부터 데이터를 수집할 파이프라인을 갖추게 되면 다음으로 중요한 단계는 해당 테스트를 여러 번, 여러 기기에 걸쳐 실행하고 그 결과 도출된 성능 데이터를 집계하여 개발 팀이 한층 더 상세하게 분석할 수 있게 해주는 프레임워크를 채택하는 것입니다. + + + +
+ ++ 테스트 자동화를 위한 프레임워크 +
+ ++ UI 테스트 프레임워크(예: UI Automator)는 대상 기기/에뮬레이터에서 직접 실행된다는 점에 주목할 만한 가치가 있습니다. + 반면 dumpsys gfxinfo에 의해 완료되는 성능 수집 정보는 호스트 머신이 구동하여 ADB를 통해 명령을 전송합니다. + 이러한 각각의 항목 자동화를 연결하는 데 도움을 주기 위해 MonkeyRunner 프레임워크가 개발되었습니다. 이것은 호스트 머신에서 실행되는 스크립팅 시스템으로, 일련의 연결된 기기에 명령을 발행하기도 하고 이들로부터 데이터를 수신할 수도 있습니다. + + + +
+ ++ UI 성능 테스트를 제대로 자동화하기 위해 최소한의 수준으로 일련의 스크립트를 구축하는 경우, 다음과 같은 작업을 수행하기 위해 monkeyRunner를 활용할 수 있어야 합니다. + +
+ +-
+
- 원하는 APK를 대상 기기(하나 이상일 수 있음) 또는 에뮬레이터에 로드하여 시작합니다. + + +
- UI Automator UI 테스트를 시작하고 실행되도록 허용하십시오. + + +
- dumpsys gfxinfo를 통해 성능 정보를 수집합니다. + + +
- 정보를 집계하고 이를 다시 유용한 방식으로 표시해 개발자에게 보여줍니다. + +
관측된 문제 심사 및 수정
+ ++ 문제의 패턴이나 성능 저하를 확인했으면, 다음 단계는 해결 방법을 알아내어 적용합니다. + 자동화된 테스트 프레임워크가 프레임에 대해 정확한 타이밍 분석을 유지하는 경우, 최근의 의심스러운 코드/레이아웃 변경 내용을 꼼꼼히 훑어보거나(성능 저하의 경우) 수동 조사로 전환했을 때 시스템의 어느 부분을 분석할지 범위를 좁히는 데 도움이 될 수 있습니다. + + + 수동 조사의 경우, systrace부터 시작하는 것이 좋습니다. 이렇게 하면 렌더링 파이프라인의 모든 단계, 시스템에 있는 모든 스레드와 코어는 물론 개발자가 정의한 사용자 지정 이벤트 마커 일체에 대해 정확한 타이밍 정보를 나타내주기 때문입니다. + + +
+ ++ 임시 타이밍을 적절하게 프로파일링하기 +
+ ++ 렌더링 성능에서 타이밍을 가져와 이를 측정하는 데 수반되는 몇 가지 어려움을 알아두는 것이 중요합니다. + 이와 같은 숫자는 본래 결정적인 것이 아니고 시스템 상태, 이용 가능한 메모리 용량, 열 제한 및 개발자가 사는 지역에 태양 플레어가 마지막으로 영향을 미친 시점 등에 따라 변동폭이 큽니다. + + 요점은 같은 테스트를 두 번 실행하면서 서로 근사치이지만 완전히 똑같지는 않은, 약간 다른 숫자를 얻어내는 데 있습니다. + + +
+ ++ 이런 식으로 데이터를 제대로 수집하고 프로파일링한다는 것은 같은 테스트를 여러 번 거듭 실행하면서 얻어지는 결과를 평균 또는 중간값(너무 복잡해지니 이것을 '배치(batch)'라고 부르기로 합시다)으로 누적한다는 것을 뜻합니다. 이렇게 하면 테스트 성과를 대략적으로 어림잡을 수 있으면서 정확한 타이밍은 없어도 됩니다. + + + +
+ ++ 이러한 배치를 코드 변경 사이사이에 사용하여 그러한 변경 내용이 성능에 미치는 상대적인 영향을 알아볼 수도 있습니다. + 변경 전 배치의 평균 프레임 속도가 변경 후 배치에서보다 빠른 경우, 해당 변경에 대해 전반적으로 좋은 WRT 성능을 성취했다는 뜻입니다. + + +
+ ++ 이는 즉 개발자가 수행하는 자동화된 UI 테스트는 모두 이 개념을 감안해야 한다는 뜻이기도 하고, 테스트 중에 일어나는 모든 변칙적인 부분 또한 감안해야 한다는 뜻입니다. + 예를 들어 애플리케이션 성능이 일종의 기기 문제(본인의 애플리케이션에서 기인한 것이 아님) 때문에 갑자기 뚝 떨어지는 경우라면 해당 배치를 다시 실행하여 조금 덜 혼란스러운 타이밍을 얻어야 할 수도 있습니다. + + + +
+ ++ 그렇다면 측정값이 의의를 지니려면 테스트를 몇 번이나 수행하는 것이 좋습니까? 최소한 10번은 해야 합니다. 실행 횟수가 50이나 100처럼 커질수록 더욱 정확한 경과를 도출할 수 있습니다(물론, 이제는 정확도와 시간을 맞바꿔야 하는 셈입니다). + + +